
The OpenSSH Bug That Wasn't - glass-
http://bsdly.blogspot.com/2015/07/the-openssh-bug-that-wasnt.html
======
geerlingguy
Key takeaway:

> And as several correspondents have reminded me already -- switching your
> sshd to keys only authentication will let you sleep better at night.

Even with fail2ban and limited retries, there's no excuse for using password-
based authentication anymore. Use an SSH key, protect the key with a password,
and turn off password login on all your servers.

Other than that, the main gist of this post is: on most platforms, the default
settings for remote login already make brute-force login attempts annoying at
best, and with fail2ban or something similar, it's a non-issue.

~~~
heywire
I've always wanted to disable password based auth, but I am worried that if I
need to connect to my machine in a pinch from some random device (wife's
phone, borrowed machine from friend, work, etc), that I won't be able to
connect. How do people get around this? Keep in mind that I'm talking about
home machines and hobby VM instances, I do not manage any production servers
or anything.

~~~
UnoriginalGuy
Create a normal user, DON'T add them to the sudo group (or any other special
group), and then generate keys for them. Store those keys in some online
"cloud" storage (DropBox, Google Drive, OneDrive, et al).

Then if you need to get in, download the key, type in the password, login as
that user, and the su up to root by entering the password only you know.

As an additional layer of security you could encrypt the key using AES-256
(e.g. 7Zip archive, Microsoft Office's Word .docx (NOT .doc) format (just drag
drop the file into Word, "Encrypt with password") now AES-256 encrypted,
others).

Now you have four layers of protection:

\- su password.

\- Key password.

\- AES-256 encryption password.

\- "Cloud" storage credentials.

~~~
larrys
So in short store the keys in some place that you have easy access to by a
password. Kind of a version of two factor "something you know and something
you have" whereby the "something you have" is the cloud storage device with
the key.

------
akkartik
Oh, good old PAM:
[http://web.archive.org/web/20131205090841/http://deadmemes.n...](http://web.archive.org/web/20131205090841/http://deadmemes.net/2010/10/19/fear-
and-loathing-in-debianubuntu-or-who-needs-etcmotd) (Discussed previously:
[https://news.ycombinator.com/item?id=3325510](https://news.ycombinator.com/item?id=3325510))

------
cbsmith
This really is a bug in _how_ OpenSSH USE_PAM is implemented.

Particularly if you presume that PAM is the devil, the last thing you want to
do, from a security standpoint, is to let a client dictate how a server
applies PAM. The policy _has_ to be entirely controlled by the server's
config. Once you let the client decide, you're just asking for things to go
wrong.

~~~
acqq
Yes, and this guy, quoted by the article author:

"I wouldn't call that an OpenSSH bug. I would call it a systemic design flaw
in PAM."

is then clearly wrong, it _is_ an OpenSSH bug.

~~~
cbsmith
Well, it sort of isn't, because the OpenBSD team designed OpenSSH to not use
PAM at all. PAM was patched in by some folks, and _clearly_ they got it wrong,
but I suspect the OpenSSH team doesn't see that as "part of OpenSSH".

~~~
stsp
PAM support is part of OpenSSH portable releases.
[http://www.openssh.com/faq.html#3.15](http://www.openssh.com/faq.html#3.15)

------
feld
Thankfully my use of PAM is for 2FA with SSH when I don't have my key. So they
wouldn't have been successful in pulling off a bruteforce anyway. But it's
annoying that their attempts weren't being limited as it can waste
resources...

~~~
currysausage
You wouldn't have a working config at hand for requiring TOTP (Google
Authenticator) only for OpenSSH password logins on Debian, would you?

------
hyperion2010
I have disabled PAM by default on all my boxes that run sshd for the last 9
years out of habit, I long ago forgot the reason why (probably because the
gentoo sshd handbook entry said it was a good idea). Why UsePAM is set to yes
in sshd_config by default on many distros is beyond me.

~~~
ajross
Because PAM is the default authentication framework on all those distros. Yes,
it's a disaster of complexity and something pretty much no one understands.
But it's what we have.

Maybe a rearchitected replacement will land in systemd someday...

~~~
mjard
Or in pulseaudio as a master troll.

------
liveoneggs
NetBSD is integrating a system called blacklistd to address fail2ban being
less than elegant.

[http://netbsd.gw.com/cgi-bin/man-cgi?blacklistd++NetBSD-
curr...](http://netbsd.gw.com/cgi-bin/man-cgi?blacklistd++NetBSD-current)

~~~
RexRollman
Doesn't NetBSD use PAM? It might behave the same way.

------
j_m_b
I am curious as to what happens when this is done with an existent user? I
feel like there would be different behaviors for timeouts when a non-existent
username is used and when a wrong password is used for an existent username.

~~~
feld
No, the behavior needs to be identical in all failure cases or attackers can
use the different feedback to learn valid usernames, etc

~~~
j_m_b
I should have elaborated better. I think that the feedback should in theory
always be the same. However, the check for existent user and the check for
correct password are different procedures in the program. The program masks
this fact by always having one feedback prompt for actions that don't result
in login. Perhaps the original bug report only allowed multiple retries for
existent users but not for non-existent users, thus shattering the illusion
that the feedback is always the same.

------
baby
They talk about FreeBSD in the original article and the guy tests that on
other OS and say it's not a serious vuln?

This is a serious vuln for FreeBSD. Period.

~~~
glass-
> They talk about FreeBSD in the original article and the guy tests that on
> other OS and say it's not a serious vuln?

Mr Hansteen is saying it is not a serious OpenSSH vuln, like the tech media is
claiming it is.

> This is a serious vuln for FreeBSD. Period.

That's why the original disclosure and subsequent news articles clearly stated
it was a FreeBSD and/or PAM vulnerability, and didn't run with headlines such
as "OpenSSH keyboard-interactive authentication brute force vulnerability"[0]
or "Bug in widely used OpenSSH opens servers to password cracking"[1].

[0] [https://kingcope.wordpress.com/2015/07/16/openssh-
keyboard-i...](https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-
interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/)

[1] [http://arstechnica.com/security/2015/07/bug-in-widely-
used-o...](http://arstechnica.com/security/2015/07/bug-in-widely-used-openssh-
opens-servers-to-password-cracking/)

------
pellaeon
FreeBSD hasn't released a patch, so I patched it myself.

[https://nyllep.wordpress.com/2015/07/25/emergency-fix-for-
cv...](https://nyllep.wordpress.com/2015/07/25/emergency-fix-for-
cve-2015-5600-on-freebsd/)

------
gosukiwi
Lol'd at the blog's title

