> Disallowing root login is also frequently recommended. I believe this has limited merit in our current landscape since 95% of the time, the user you log in with has sudo privileges. Then it adds no extra security. But you should really judge this for your own situation.
Disallowing explicit `root` login makes it harder for attackers to guess the usernames which have sudo access, thus I'd say it decreases the attack surface area. Yes, sudo gives them the same level of access as root but the path to get there from an attacker's perspective is not the same.
if 20 people have root password, and server supports root login, then you can't know which of the 20 people had their machines compromised.
if 20 people each have to sudo, then you can trace which user was compromised.
Reducing accountability isn't typically a goal for organizations so it's strictly better to have 20 accounts with sudo versus everyone using a single shared account (shared accountability) UNLESS the accountability is managed some other way (I think this something Gravitational Teleport tries to sell on this forum often).
That’s not necessarily the case if you su as root and run the same commands.
If 20 people have the root password, there is a single password that will allow your machine to be pwned.
If 20 people have 20 passwords and sudo access, then any of 20 passwords will allow your machine to be pwned.
You can't know which of the 20 people you're trusting to pick a password is reusing it.
If you are logged in as a sudo user, provided allowing only an ssh key, can you can't do anything unless:
- you know the password
- you trick the user into doing the action for you (E.G: a line in the bashrc)
The first one will slow down the attaker, the second one may trigger the user BS detector.
This assumes one isn't using password-less sudo (NOPASSWD), which several distros do set by default and many users change to it for convenience.
Or rather, it forces attackers to enumerate other usernames because the default root account isn't available to brute force. In general, when password authentication is in use (which it should never be for SSH), then disabling the default user account acts as a simple way of mitigating brute force attacks. If best practices are followed and passwords are not used to authenticate to SSH servers, then this additional measure might be moot. Even so, I can't think of a reason not to disable root SSH login anyway, even if password authentication is disabled. A layered defense assumes the possibility that other defenses might fail. Noone wants to be the person who wrote off an additional defense measure because they didn't think it was possible to exploit, only to have a new CVE come out to prove them wrong.
I am still unconvinced, though. Auditing can by done by recording the IP address, for instance.
Ultimately, it's just much easier to force individual logins and require sudo. Even just an engineer logging in and doing 'sudo su -' is significantly more traceable than everyone logging in directly as root. Even better if you can force the individual logins and sudo sessions to use multi-factor auth—then you can keep root non-multi-factored and get in with just a password on the console when your MFA solution has gone pear-shaped. :)
Technically correct I guess, but isn't password logins considered bad practice anyway? So if you have passphrase protected, key-based authentication only, is it really relevant whether you have it against root or a user with sudo permissions?
Imagine two products that could easily exist, almost the same features:
A by default works just fine, but there's a risk an adversary spends $10M to attack you. You can tweak the config and replace all the OmniCorp CheapDevices in your estate to get rid of that attack which is best practice.
B by default requires that you replace all the OmniCorp CheapDevices in your estate or it won't work. You can tweak the config and risk that an adversary spends $10M to attack you so that the OmniCorp CheapDevices still work.
Which one do you buy? You buy A of course. Nobody is going to sign off on the budget to replace all the OmniCorp CheapDevices. What's this nonsense about a $10M attack anyway?
At some point the risk is judged to be too high, and people flip the defaults for those risks. For example OpenSSH decided the risk for SHA1 authentication is now too high, like the Web PKI had years before, but despite SSH being a much less plausible target than the Web PKI for various reasons.
Staying ahead of the pack.
The downstream package maintainers for various operating systems or distributions have some more leeway in changing the defaults, but here, also, they have to bow to the impact which a change might have on real-world users. Indeed, since these package maintainers are closer to the actual affected end users, it has been known to happen that upstream authors have changed a default value to be more secure, but the real-world impact has been so large that the package maintainers have reverted this change in the packaged versions of the software, essentially making the software more insecure in the name of compatibility. So, package maintainers are more flexible, but are also more beholden to the wishes of users who might be adversely affected by any changes.
Current version is rocking v8.2.
See https://www.strongdm.com/compare for comparisons.
There are ups and downs to both: L3 is relatively technology agnostic (e.g. you don't need different support for connecting to a database vs ssh). L7 auth & routing gives greater protocol introspection, but means more work to support different use cases.
Depending on your scale and use case, the right answer may be both: Do 2FA for both network access (are you allowed to send packets to the ip:port) and application access (are the packets you send allowed to sign in to the database as an intern or a admin?). The most important part is to get a hardware token and SSO on the path to access.
Disclosure: I work for Teleport. I also think Tailscale is awesome and run it for my home lab.
Ciphers chacha20-poly1305@openssh.com
KexAlgorithms curve25519-sha256@libssh.org
RSAAuthentication no
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
Subsystem sftp internal-sftp
PermitTunnel no
X11Forwarding no
PermitRootLogin no
AllowTcpForwarding no
Lets say there's 2,000,000 IPv4 addresses that are being used on the internet.
If you scan 64,511 ports on each of them (65536-1024-1), that's still 129,022,000,000 connection attempts. Probably not worth it.
I just searched for "ssh -port:22" and found many hits.
But also yes. Switching port (or just blocking China) will vastly reduce SSH probes.
For example I never use RSA keys. So these can go. Less cyphers => less attack surface.
But I do agree that I'm sure the defaults picked are sensible.
Exactly, the default RSA for the keygen is what a lot of users accept without realizing the implications. Well, lots of HowTos out there suggest "enter, enter, enter.." to get your key.
What's the rationale for keeping RSA as a default these days?
For the server's proof of its identity, one gap in older SSH versions is that the client doesn't learn other host keys. So if your client is content with Archaic-host-key, even though the server has been telling anybody new about Shiny-modern-host-key, when the server finally removes Archaic-host-key the client can't verify this server. In modern OpenSSH UpdateHostKeys controls this in clients and defaults to learning new host keys in the most obvious cases.
Switching to only ciphers currently known to be strong puts you a level above that where even if a new weakness was found (publicly or not) it may not be enough to make it breakable.
Whether most really need to worry about any of that is another story. I'd say if you're job task isn't to research how to secure SSH better don't go changing ciphers just because you read it in a blog post. If it is your task consider it one point of data as you dive into understanding the nerd knobs.
The defaults keep the mailing lists from filling up with troubleshooting questions, but anyone with some command line skills can change one parameter at a time and test. If you’re exposing ssh to the internet you should absolutely not be ignoring hardening guides.
I too contributed to the sshd-audit as well.
https://egbert.net/blog/articles/fine-tuning-ssh-authorized_...
https://sshaudit.com/hardening_guides.html#rhel8
Any reason why I shouldn't?
To regenerate the moduli, you run:
ssh-keygen -M generate \
-O bits=4096 \
moduli.candidates
ssh-keygen -M screen \
-f moduli.candidates \
moduli.safe
awk '$5 > 3071' moduli.safe \
| tee /etc/ssh/moduli
Need better updates with the current and present time.
We should aim for not having to fiddle with SSH config, and having sane defaults.
That could involve:
* cryptographers advocating changing OpenSSH defaults
* people refining their threat model to being able to accept weaker defaults
* Distributions or config management solutions that improve on the defaults in a careful considered way.
I use NixOS which generates my sshd_config. By default, NixOS:
* Disables root login via password: https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f0...
* Sets ciphers according to Mozilla's recommendations: https://github.com/NixOS/nixpkgs/blob/8605fbd737e526c40ff8f0...
Other distros, cfgmgmt, and container systems could do this too.