
Bug in widely used OpenSSH opens servers to password cracking - lisper
http://arstechnica.com/security/2015/07/bug-in-widely-used-openssh-opens-servers-to-password-cracking/
======
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.

~~~
scintill76
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
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...](https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root-login-
via-ssh/)

~~~
anonova
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

~~~
scintill76
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/88a7c598a...](https://github.com/openssh/openssh-
portable/commit/88a7c598a94ff53f76df228eeaae238d2d467565) [3]
[https://github.com/openssh/openssh-
portable/commit/d921082ed...](https://github.com/openssh/openssh-
portable/commit/d921082ed670f516652eeba50705e1e9f6325346) [4]
[https://github.com/openssh/openssh-
portable/commit/47aa7a0f8...](https://github.com/openssh/openssh-
portable/commit/47aa7a0f8551b471fcae0447c1d78464f6dba869) [5]
[https://github.com/openssh/openssh-
portable/commit/7de4b03a6...](https://github.com/openssh/openssh-
portable/commit/7de4b03a6e4071d454b72927ffaf52949fa34545)

~~~
anonova
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
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...](https://lists.fedoraproject.org/pipermail/package-
announce/2015-July/161692.html) [2]
[https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26](https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26)

------
rascul
Disable password auth and ensure you have another way in if necessary.
Fail2ban, changing ports and port knocking doesn't really add anything more
unless you're concerned about log sizes, and just increases the hassle for
you.

Mozilla's wiki has some information on strengthening the security of your
OpenSSH setup.

[https://wiki.mozilla.org/Security/Guidelines/OpenSSH](https://wiki.mozilla.org/Security/Guidelines/OpenSSH)

~~~
segmondy
what do you mean by port knocking doesn't really add anything? It sure does.
Use a good port knocker. ie.
[http://www.thoughtcrime.org/software/knockknock/](http://www.thoughtcrime.org/software/knockknock/)

~~~
rascul
Use the stuff from that Mozilla wiki page and OpenSSH will be secure enough
already. Unless more vulnerabilities are found that apply to such a
configuration, or keys are compromised, port knocking in this case isn't going
to stop anyone that OpenSSH wouldn't already stop on its own. It's effectively
just a pointless layer of security that only adds more hassle to connect.

I'm not saying that port knocking doesn't have uses, just that it doesn't in
this case. Unless you're trying to hide the service I guess, but I don't see
why that would be necessary.

------
orf
It's interesting to log failed SSH attempts, I normally get someone trying to
brute force access within an hour or two of brining a server up. Changing to a
non standard port doesn't deter them for long.

~~~
DrTung
Have you tried fail2ban? It really helps to keep the hacking attempts down on
your ssh-server(s), especially if you increase the bantime from the default
600 seconds to a couple of million...

~~~
Someone1234
It is all fun and games until you ban yourself for a couple of million
seconds...

Far too many people ban themselves with fail2ban.

~~~
middleclick
I use key-based authentication and fail2ban. Since that won't fail like
passwords, it works wonderfully and the chances of my being banned are nil.

~~~
jasonjayr
* Until you have too may keys on your agent

* Until you have a script repeatedly attempt w/o your keys unlocked

* Until you try from a new computer on the same network and fail to setup your keys first.

Ask me how I know :)

~~~
gtaylor
Important to note: You can whitelist IPs if you are worried about getting
locked out from work/home. They may change periodically, but that's pretty
easy to update as well.

------
blueatlas
Doesn't key authentication protect against this vulnerability?

~~~
reirob
Right. Quote from article: "In some respects, the severity of vulnerability
can be viewed as mild. But that assumes OpenSSH users are using a
cryptographic key for authentication. Under such an arrangement, only
computers with the private key are able to access the Internet-facing server.
On top of that, servers themselves should be configured to limit the number of
login attempts, and that measure should also go a long way toward making
exploitation impractical."

------
noinsight
Shouldn't effective brute forcing be prevented by the fact that this should be
completely choking the server? I'm not completely sure what algorithms are
currently used for password hashes in UNIX-likes but in any case, shouldn't
this choke the server when it has to generate hashes for all those attempts at
once (or consequently)? If you monitor loads at all this is very detectable.
It's a good avenue for DDOS in that case though.

~~~
tedunangst
Heh. I noticed a blistering two guess per second hacking attempt against my
laptop because the fan went full jet engine.

~~~
noinsight
So on OpenBSD the hashes are bcrypt and rounds are based on system performance
as per man crypt_checkpass?

So it's like 15 bcrypt rounds on average hardware for ~500ms per hash?

Linux seems to use a pathetic 5000 rounds of SHA-512:
[http://www.akkadia.org/drepper/SHA-
crypt.txt](http://www.akkadia.org/drepper/SHA-crypt.txt)

------
kazinator
I suspect this could be fixed by adding a sleep(5) call somewhere in the code.
Now you have < 24 attempts in two minutes.

