6 ms·

Some quick tips for securing SSH: 1. Disable password authentication altogether 2. Create and use keypairs 3. Add an "AllowUsers foo" line to /etc/ssh/sshd_c

Some quick tips for securing SSH: 1. Disable password authentication altogether 2. Create and use keypairs 3. Add an "AllowUsers foo" line to /etc/ssh/sshd_config so that only your user is allowed to SSH 4. Install sshguard or fail2ban and set the ban limit to a week There are other things you can do, but I find this to be the lowest hanging fruit for the best security.

scintill76 11y ago
I like to do "PermitRootLogin no" as well, but I guess it's not really necessary if one uses some of the other config you've given.
- thaumaturgy 11y ago
  IIRC I think "PermitRootLogin no" is now the default on most distributions. Debian at least: https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root-login-via-ssh/ https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root...
  - protomyth 11y ago
    Just got set to the default on OpenBSD, so it should be shipped in 5.8.
  - anonova 11y ago
    I was curious, so I checked different distros. Debian-based distros set `without-password`, and others use the default `no`. * Arch Linux (openssh-6.9p1-1): #PermitRootLogin no * CentOS 7 (openssh-server 6.6.1p1-12.el7_1): #PermitRootLogin yes * Debian 8.1 (openssh-server 1:6.7p1-5): PermitRootLogin without-password * Fedora 22 (openssh-server 6.9p1-2.fc22): #PermitRootLogin yes * openSUSE 13.2 (openssh 6.6p1-5.1.3): #PermitRootLogin yes * Ubuntu 14.04.2 (openssh-server 1:6.6p1-2ubuntu1): PermitRootLogin without-password * Ubuntu 15.04 (openssh-server 1:6.7p1-5ubuntu1): PermitRootLogin without-password
    - deleted 11y ago
      [deleted]
    - deleted 11y ago
      [deleted]
    - scintill76 11y ago
      Thanks for checking, but I'm not sure you're correct. AFAICT setting the default to "no" is not due for official release until later this month[1]. Maybe some of the distros are patching the upstream default directly in their source (seems bad idea to me), but I at least checked the CentOS version you referenced and it appears to default to "yes" in the source (and the config excerpt you cited is commented out.) I looked into OpenSSH's commit history ([2],[3],[4],[5]) and it looks like some waffling and/or release-process side-effects resulted in the man page in 6.9 saying the default is "no", but the actual code retaining "yes" (confirmed in the portable 6.9p1 tarball). I kind of hope I'm wrong somehow; this is a bit disturbing. [1] http://www.openssh.com/txt/release-6.9 http://www.openssh.com/txt/release-6.9 [2] https://github.com/openssh/openssh-portable/commit/88a7c598a94ff53f76df228eeaae238d2d467565 https://github.com/openssh/openssh-portable/commit/88a7c598a... [3] https://github.com/openssh/openssh-portable/commit/d921082ed670f516652eeba50705e1e9f6325346 https://github.com/openssh/openssh-portable/commit/d921082ed... [4] https://github.com/openssh/openssh-portable/commit/47aa7a0f8551b471fcae0447c1d78464f6dba869 https://github.com/openssh/openssh-portable/commit/47aa7a0f8... [5] https://github.com/openssh/openssh-portable/commit/7de4b03a6e4071d454b72927ffaf52949fa34545 https://github.com/openssh/openssh-portable/commit/7de4b03a6...
      - anonova 11y ago
        Ah, you're right. I read sshd_config(5) on Arch, which uses 6.9p1 and says the incorrect default is "no". I assumed this was the case on other distros. So to correct my previous post (I can't seem to edit?), it should be, "Debian-based distros set `without-password`, and others use the default `yes`." Thanks for the correction!
        scintill76 11y ago
        Thanks for the reply. On editing, I'm not sure exactly how it works, but posts on HN become uneditable at some point. I came across this post[1] and bug comment[2]. If I'm understanding correctly, Red Hat will not follow the OpenBSD upstream on this! So I would guess CentOS and Fedora will also keep allowing root login, with password, by default. [1] https://lists.fedoraproject.org/pipermail/package-announce/2015-July/161692.html https://lists.fedoraproject.org/pipermail/package-announce/2... [2] https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26 https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26
- chmielewski 11y ago
  The reason for this isn't security-related, if you've followed the steps above and have applied them to root. The reason to not allow root login is so that each of multiple administrators must login using their username and then become root or use sudo. That way if you look to see who did what, you get a username rather than "root did that". Which, of course, you usually need root to do things that end up being checked into.
  - scintill76 11y ago
    I would say auditability is still security-related, but yes, this is good practice too. You should probably also make sure root has a locked password, so that things other than SSH won't allow root login.
joeyspn 11y ago
> There are other things you can do, but I find this to be the lowest hanging fruit for the best security. During the years I've found that changing the port to something like 7865 decreases login attempts up to 100%. Personally it's always the first thing I do along with changing LoginGraceTime to 5s
- ryanlol 11y ago
  What actual benefits does changing the port offer?
  - junkblocker 11y ago
    Usually automated bulk (non-targeted) hacking tools don't like to spend time looking for services on non-standard ports. I get zero ssh hack attempts on my machines ever since I changed to a non-standard port vs 100s of attempts everyday previously on standard ssh port.
  - bittercynic 11y ago
    It stops your log from filling up with half-assed attempts to break in.
this_user 11y ago
Here is a pretty good guide for configuring SSH in a secure way that also goes into detail regarding the crypto side: https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht... You probably also want to set kex, ciphers and MAC preferences in your client config for when you connect to servers with suboptimal settings. Personally, I have also moved away from RSA keys and prefer using Ed25519 ones instead.
mbubb 11y ago
I am curious as to why DenyHosts is not mentioned in this context (beside fail2ban and sshguard. Is its use deprecated? I ask because I administer about 300 servers with DenyHost grandfathered on the servers. I've googled a bit to see the relative merits and DH is just for ssh whereas fail2ban is more general. I somehow didn't know about sshguard - it looks interesting (and also seems to do more than just ssh brute force blocking). So... do I need to take DH off the herd and replace?

scintill76 11y ago

I like to do "PermitRootLogin no" as well, but I guess it's not really necessary if one uses some of the other config you've given.

thaumaturgy 11y ago
IIRC I think "PermitRootLogin no" is now the default on most distributions. Debian at least: https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root-login-via-ssh/ https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root...
- protomyth 11y ago
  Just got set to the default on OpenBSD, so it should be shipped in 5.8.
- anonova 11y ago
  I was curious, so I checked different distros. Debian-based distros set `without-password`, and others use the default `no`. * Arch Linux (openssh-6.9p1-1): #PermitRootLogin no * CentOS 7 (openssh-server 6.6.1p1-12.el7_1): #PermitRootLogin yes * Debian 8.1 (openssh-server 1:6.7p1-5): PermitRootLogin without-password * Fedora 22 (openssh-server 6.9p1-2.fc22): #PermitRootLogin yes * openSUSE 13.2 (openssh 6.6p1-5.1.3): #PermitRootLogin yes * Ubuntu 14.04.2 (openssh-server 1:6.6p1-2ubuntu1): PermitRootLogin without-password * Ubuntu 15.04 (openssh-server 1:6.7p1-5ubuntu1): PermitRootLogin without-password
  - deleted 11y ago
    [deleted]
  - deleted 11y ago
    [deleted]
  - scintill76 11y ago
    Thanks for checking, but I'm not sure you're correct. AFAICT setting the default to "no" is not due for official release until later this month[1]. Maybe some of the distros are patching the upstream default directly in their source (seems bad idea to me), but I at least checked the CentOS version you referenced and it appears to default to "yes" in the source (and the config excerpt you cited is commented out.) I looked into OpenSSH's commit history ([2],[3],[4],[5]) and it looks like some waffling and/or release-process side-effects resulted in the man page in 6.9 saying the default is "no", but the actual code retaining "yes" (confirmed in the portable 6.9p1 tarball). I kind of hope I'm wrong somehow; this is a bit disturbing. [1] http://www.openssh.com/txt/release-6.9 http://www.openssh.com/txt/release-6.9 [2] https://github.com/openssh/openssh-portable/commit/88a7c598a94ff53f76df228eeaae238d2d467565 https://github.com/openssh/openssh-portable/commit/88a7c598a... [3] https://github.com/openssh/openssh-portable/commit/d921082ed670f516652eeba50705e1e9f6325346 https://github.com/openssh/openssh-portable/commit/d921082ed... [4] https://github.com/openssh/openssh-portable/commit/47aa7a0f8551b471fcae0447c1d78464f6dba869 https://github.com/openssh/openssh-portable/commit/47aa7a0f8... [5] https://github.com/openssh/openssh-portable/commit/7de4b03a6e4071d454b72927ffaf52949fa34545 https://github.com/openssh/openssh-portable/commit/7de4b03a6...
    - anonova 11y ago
      Ah, you're right. I read sshd_config(5) on Arch, which uses 6.9p1 and says the incorrect default is "no". I assumed this was the case on other distros. So to correct my previous post (I can't seem to edit?), it should be, "Debian-based distros set `without-password`, and others use the default `yes`." Thanks for the correction!
      - scintill76 11y ago
        Thanks for the reply. On editing, I'm not sure exactly how it works, but posts on HN become uneditable at some point. I came across this post[1] and bug comment[2]. If I'm understanding correctly, Red Hat will not follow the OpenBSD upstream on this! So I would guess CentOS and Fedora will also keep allowing root login, with password, by default. [1] https://lists.fedoraproject.org/pipermail/package-announce/2015-July/161692.html https://lists.fedoraproject.org/pipermail/package-announce/2... [2] https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26 https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26
chmielewski 11y ago
The reason for this isn't security-related, if you've followed the steps above and have applied them to root. The reason to not allow root login is so that each of multiple administrators must login using their username and then become root or use sudo. That way if you look to see who did what, you get a username rather than "root did that". Which, of course, you usually need root to do things that end up being checked into.
- scintill76 11y ago
  I would say auditability is still security-related, but yes, this is good practice too. You should probably also make sure root has a locked password, so that things other than SSH won't allow root login.

joeyspn 11y ago

> There are other things you can do, but I find this to be the lowest hanging fruit for the best security. During the years I've found that changing the port to something like 7865 decreases login attempts up to 100%. Personally it's always the first thing I do along with changing LoginGraceTime to 5s

ryanlol 11y ago
What actual benefits does changing the port offer?
- junkblocker 11y ago
  Usually automated bulk (non-targeted) hacking tools don't like to spend time looking for services on non-standard ports. I get zero ssh hack attempts on my machines ever since I changed to a non-standard port vs 100s of attempts everyday previously on standard ssh port.
- bittercynic 11y ago
  It stops your log from filling up with half-assed attempts to break in.

this_user 11y ago

Here is a pretty good guide for configuring SSH in a secure way that also goes into detail regarding the crypto side: https://stribika.github.io/2015/01/04/secure-secure-shell.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht... You probably also want to set kex, ciphers and MAC preferences in your client config for when you connect to servers with suboptimal settings. Personally, I have also moved away from RSA keys and prefer using Ed25519 ones instead.

mbubb 11y ago

I am curious as to why DenyHosts is not mentioned in this context (beside fail2ban and sshguard. Is its use deprecated? I ask because I administer about 300 servers with DenyHost grandfathered on the servers. I've googled a bit to see the relative merits and DH is just for ssh whereas fail2ban is more general. I somehow didn't know about sshguard - it looks interesting (and also seems to do more than just ssh brute force blocking). So... do I need to take DH off the herd and replace?