61–70 of 106 posts
Earlier quoted context omitted.
fwknop is a bit lower risk though. If all an attacker can do is open a port, they’ll still have to exploit OpenSSH.
fwknop's default is to run as root, so there's that. Support for separation of privileges is still pending since 2013 ( https://github.com/mrash/fwknop/issues/32 )
Earlier quoted context omitted.
I am not a corporation, so I don't need corporate guidelines. There isn't more than one UID 0. Only more than one password/shadow database entry pointing to it. (It might not be necessary; perhaps there is a way for OpenSSH to remap names, so that our example rotorooter is mapped to root by sshd itself.) > A much better idea is to set up a non-root user and configure sudo correctly. Even if so, the same principle app…
> Whoever wrote that does not know WTF they are talking about ... or they know something you don't.
It has the same optics as an unauthorized entry someone planted: a backdoor to retain root access. It will continuously have to be explained to new people who spot it.
If the intent is to keep the passwords identical (which it probably should be), the tooling doesn't support it. When someone changes the password for root using standard tools, the one for rotorooter doesn't sync. This is a problem if someone is changing the password in order to restrict access to just a specific set of people who know the new password. The unaltered entry turns into a de facto backdoor for everyone knowing the old password.
Pitafall: if you put an alias entry in the wrong spot in in the password file, so that it appears before the canonical entry, then UID 0 maps backward to the alias name (e.g. via the getpwuid() function). This breaks all logic that looks for the string "root" rather than UID 0. E.g. shell scripts looking for root in the output of some command.
Is this actually practically reducing the attack surface? We're replacing a battle hardened service with a random one that has the ability to manipulate the firewall rules.
No, it's not. The article itself is somewhat incoherent; for instance, if you're using key-only authentication (which: of course you are) fail2ban has literally no function (unless you think attackers are brute-forcing ECDH keys). The reality is that there are basically two ways to operate SSH: (1) You can, because OpenSSH is the significant remote service with the literal best track record of any remote service, jus…
Port knocking, and other bespoke middle layers in front of internet services, is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes (or “noise”) manageable, adjust your logging levels. Anything added in front of your normal service also complicates a…
I agree port knocking is a direct violation of Kerckhoff's principle. However, the proposed solution has non-discoverability from unauthorized sources which isn't necessarily in the threat model of OpenSSH or general cryptography. I do feel like this is potentially a desirable trait. I elaborated a bit more here[0], but I'm curious if you have any grander thoughts on how this could be approached [0]: https://news.yco…
I don’t know why this wasn’t mentioned before but why not use a Firewall. If you’re using a virtual box like Hetzner or Scaleway you can specify an ip or range at the router level. For all intents and purposes this removes public exposure. Scaleway also has a cheap VPN bridge. So you never need to connect via the public internet if you don’t want to… hardly gets more secure than that
If you are connecting from a residence or a mobile device (like a laptop), your ip address isn't fixed, so a firewall won't help.
In reality you should use that and then use host based firewall anyway.
What I do is laughably simple. 1. Disable all logging about break-in attempts. 2. Do not have any common user names like "root". Say you want to be able to log in as root from anywhere, just with a password. This is a wise idea; what if you need access, but are in a situation where you are not able to use a certificate? Make up an alternative name like roto-rooter or whatever pops into your head. Install it into the…
This is a bad idea™. You should never have more than one UID 0 on a Unix system. This will violate most corporate security guidelines (STIG and CIS) * . And for good reason. A much better idea is to set up a non-root user and configure sudo correctly. * https://www.stigviewer.com/stigs/red_hat_enterprise_linux_9/...
Could I trouble you to specify? Your link only seems to mention password problems that are trivially avoidable (really, if doubling the guesses is a problem, you're already done).
AI slop article based on a flawed premise. It's 2026, the process of correctly securing an SSH server has exactly two steps: 1. Disable password auth, only public key auth should be enabled 2. Block public access to SSH entirely, use a VPN instead (Tailscale & co. make this trivial) And 2 is entirely optional for most people reading SSH guides who just want a server to host their hobby project. Let's be real, you're…
I assume it's suggested precisely because people use passwords. Which, granted, they shouldn't.
Port knocking, and other bespoke middle layers in front of internet services, is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes (or “noise”) manageable, adjust your logging levels. Anything added in front of your normal service also complicates a…
It violates Kerckhoffs’s principle¹ Appeal to authority? In the real world, it doesn't matter. Anything that makes the attacker's life harder is fair game. Stupid dogmatic sheep-like mindlessness only leads to "herd exploitability". also complicates access That's the whole point.
You run ssh?