Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple SSH Security

disknotifier.com

Post reply on HN
Print view View original

51–60 of 97 posts

Re: Simple SSH Security

#51

Post by xxpor »

pmontra wrote: post #50

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

the vast vast majority of addresses aren't going to respond on port 22.

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.

Re: Simple SSH Security

#52

Post by cjcampbell »

chasil wrote: post #47
alphabettsy wrote: post #12

I 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 AFAIK, if RSA is off the table, then the moduli file isn't necessary. RSAAuthentication no SFTP-only accounts are advised in "SSH Mastery" by Michael Lucas to follow this form: Match Group sftponly Ch…

Moduli would be relevant to DH kex, though you’re safe when limiting to ed25519.

Re: Simple SSH Security

#53

Post by zamadatix »

pmontra wrote: post #50

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

The real search space is 48 bits (IP+port) 281,474,976,710,656. Searching at 1 million destinations per second it'd take ~9 years. So options are either go build something in the billion destinations per second range (completely feasible just more work to not get blocked) or just to limit the search space. Throwing out unadvertised IP space and throw out around 99.998% of the remaining destinations by just doing port 22 allows you to scan the entire internet extremely quickly with the smallest of scanning setups.

Re: Simple SSH Security

#54

Post by knorker »

xxpor wrote: post #51
pmontra wrote: post #50

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

the vast vast majority of addresses aren't going to respond on port 22. 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.

Doesn't help much when shodan has already portscanned everyone.

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.

Re: Simple SSH Security

#55

Post by zamadatix »

ape4 wrote: post #28

File /etc/ssh/moduli is part of openssh. So shouldn't the distros push out an update.

Openssh allows "weak" ciphers as long as they are still "strong enough" for some values of weak and strong enough, typically where there is no known or imminent way to attack it even if it isn't as strong as other options.

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.

Re: Simple SSH Security

#56

Post by tadbit »

BiteCode_dev wrote: post #49
jsd1982 wrote: 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…

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.

> 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

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.

Re: Simple SSH Security

#57

Post by flatiron »

aljarry wrote: post #34
jsd1982 wrote: 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.

But the default for ec2-user doesn’t allow logging into ssh with a password.

Re: Simple SSH Security

#58

Post by noinsight »

rkeene2 wrote: post #48
adamzochowski wrote: post #33

Earlier quoted context omitted.

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

You can use smart cards as plain SSH keypairs and sshd will of course log the fingerprint of the key used to authenticate. That's pretty foolproof accountability.

Re: Simple SSH Security

#59

Post by aryhdrsfhzdf »

tadbit wrote: post #56
BiteCode_dev wrote: post #49

Earlier quoted context omitted.

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.

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

What are some examples of these "several distros" that set it by default? Of the major ones I'm willing to use in production (Debian, Ubuntu, RHEL and derivs, SuSE, hesitantly Arch), none offer NOPASSWD sudo to users marked as administrative in each distro's normal way. (i.e. various group memberships)

NOPASSWD is poor hygiene.

Re: Simple SSH Security

#60

Post by dumpsterdiver »

jsd1982 wrote: 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…

> Disallowing explicit `root` login makes it harder for attackers to guess the usernames which have sudo access

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.

Post reply on HN