Live data from Hacker News

Simple SSH Security

disknotifier.com

31–40 of 97 posts

Re: Simple SSH Security

#31
post #27

Just 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.

Re: Simple SSH Security

#32
post #27

Just 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…

You're right. Also, you also need to know the password to give sudo.

Re: Simple SSH Security

#33
post #27

Just 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.

Re: Simple SSH Security

#34
post #27

Just 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…

I haven't seen anyone changing the default user logins for their instances in AWS, though - everyone uses ubuntu, ec2-user, or whatever is the default of their distribution.

Re: Simple SSH Security

#35
post #15
post #13

I 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.

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?

Re: Simple SSH Security

#36
post #27

Just 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.

If all users have a unique key for root access, and only keyed authentication is possible, then you can match the key fingerprint in the logs to a physical user.

Re: Simple SSH Security

#37
post #27

Just 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.

Even easier: key signature

Re: Simple SSH Security

#38
post #15

Earlier 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?

Can't think of any reason except backwards compatibility and regulatory compliance.

I don't use anything except ED25519 in my own setup.

Re: Simple SSH Security

#40
post #22

I always wonder if something like Teleport is going to catch on to change this conversation a little bit. https://goteleport.com/

I use https://tailscale.com , Teleport looks similar? Or do you prefer one over the other?

Tailscale and Teleport are similar, but operate at different levels of the network stack. Tailscale governs access and routing at L3 in the OSI model. See Hashicorp's Boundary or VPNs for alternatives. As a generalization, Teleport works at L7 -- doing auth and routing at the application protocol (ssh, psql, k8s) level.

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.

Post reply on HN