Hacker News Reader

Hacker News

Comment by stephen-mw | Hacker News Reader

Full thread

stephen-mw

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.

View on HN

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.

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

Just got set to the default on OpenBSD, so it should be shipped in 5.8.

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

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 [2] https://github.com/openssh/openssh-portable/commit/88a7c598a... [3] https://github.com/openssh/openssh-portable/commit/d921082ed... [4] https://github.com/openssh/openssh-portable/commit/47aa7a0f8... [5] https://github.com/openssh/openssh-portable/commit/7de4b03a6...

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!

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/2... [2] https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26

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.

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.

> 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

What actual benefits does changing the port offer?

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.

It stops your log from filling up with half-assed attempts to break in.

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

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?

Reply on news.ycombinator.com