Simple SSH Security
41–50 of 97 posts
Re: Simple SSH Security
#42Earlier quoted context omitted.
I was long of that conviction too. But the default install optimizes for a different thing, compatibility. Or at least emphasizes is more than I would do. 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.
> ...For example I never use RSA keys. 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?
> What's the rationale for keeping RSA as a default these days?
I think they recently changed this, but for the longest time RSA keys were the only kind AWS supported for EC2 keypairs.
For staff that weren't deploying EC2 instances, EC keys were fine, but for the ops people setting them up where the EC2 keypair was the initial access key, they needed RSA keys.
Re: Simple SSH Security
#43I belong to the camp that believes in using the defaults when it comes to ciphers. I am not an expert in cryptography, nor do I like copypasting stuff I don't fully understand. The openssh guys know this stuff better than I do and I think that's fine.
[deleted]
Re: Simple SSH Security
#44Earlier quoted context omitted.
I was long of that conviction too. But the default install optimizes for a different thing, compatibility. Or at least emphasizes is more than I would do. 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.
> ...For example I never use RSA keys. 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?
What? RSA keys are insecure?
Re: Simple SSH Security
#45"If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong" still applies, even though we now type chacha20. https://people.eecs.berkeley.edu/~daw/teaching/cs261-f12/mis...
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.
Re: Simple SSH Security
#46Just a quick note on this excerpt: > 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, t…
The link to Mozilla infosec gives a better reason to disallow root login in ssh: auditing in multi-user environments. I am still unconvinced, though. Auditing can by done by recording the IP address, for instance.
Basing things on source IP is really inexact and easily muddied, though. For instance, the source IP is a workstation or a laptop—now we have to go through DHCP logs to figure out who had that IP address at the time the incident occurred. Or if we've properly implemented source limitations through a bastion host, all we'll see on the end server is the source IP of the bastion host, so we'll need to go to the bastion to figure out who was logged in at that time and what they were doing—hopefully there was only one engineer logged in at the time! And that assumes they didn't just SSH-jump through, in which case we just have the transitory SSH logs...which leaves us with the DHCP problem above unless they used their own userID to connect to the bastion itself. If it's a publicly available AWS host (which...oy gevalt), was that login from "dhcp-host-X.Y.Z.Q-suspiciouscablehosting.regionalisp.net" a hack, or an engineer trying to fix something by logging in from his home Internet connection?
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. :)
Re: Simple SSH Security
#47I like to refer to: https://infosec.mozilla.org/guidelines/openssh
I prefer limiting to DJB ciphers where possible (the AES-GCM suites might also be helpful, but otherwise anything below is legacy crypto):
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
Re: Simple SSH Security
#48Just a quick note on this excerpt: > 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, t…
The goal is to avoid password sharing. 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.
I typically frame this as accounts are for accountability.
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).
Re: Simple SSH Security
#49Just a quick note on this excerpt: > 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, t…
If you are logged in as root, you can do anything.
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.
Re: Simple SSH Security
#50Port 22: I always change it to something else and bots leave my servers alone. I wonder why they don't try all the ports. I understand it's 16 bits but they should do it only for the addresses that don't answer on port 22.