
OpenSSH: client bug CVE-2016-0777 - moviuro
http://undeadly.org/cgi?action=article&sid=20160114142733
======
patio11
Use the workaround immediately and patch ASAP, both on your workstation and
across your infrastructure where SSH is used, which can be in surprising
places.

SSH is designed so that, even if you connect to an evil host, the host only
learns your public key, not your private key. This leaks your _private_ key to
an evil host. You might think "I only SSH into boxes that I own, so I'm good,
right?", but if you in the future lose a box to the enemy, they can then use
that box to grab your private key, and then use that key to get into _every
other box you can access with that keypair._

This turns your sysadmin's photo blog hosted on Digital Ocean into a potential
vector into your entire infrastructure, since there is a high likelihood they
use the same private key for both.

If you were to mandate a key rotation across all employees and mandate all
employees use a keypair prepared for work and no other purpose I would rate
those mandates as not being excessive.

You should expect adversaries to add an exploit for this to their rootkits.
That would be bad enough since attackers targeting your infrastructure may
exist, but this is also plausibly exploitable in a spray-and-pray fashion.
Root any server on the Internet, using e.g. a WordPress vulnerability. Install
key-stealing malicious SSH server. Forward all keys to your C&C
infrastructure. Your infra does a reverse lookup from public key to Github
account (trivial -- try "ssh whoami.filippo.io" if you don't believe me) and
immediately optimistically tries to use the stolen key to log into the web
tier of any site listed in their email/bio/Twitter profile/etc, pinging the
attacker when it succeeds.

~~~
moviuro
This may be a start:

    
    
      Host *
      IdentityFile ~/.ssh/%h
    

_Comment:_ One key per host, named after the host you connect to

~~~
mioelnir
You also need to set

    
    
        IdentitiesOnly yes
    

if I remember the config setting correct. Note however that this only limits
the offered keys during the authentication phase. If you use AgentForwarding,
this still has the entire keyring available afterwards.

~~~
semi-extrinsic
Does anyone know how this interacts with ProxyCommand? If I fix this in
~/.ssh/config on my laptop, and I ssh to hostB through hostA using

    
    
      Host hostB
        ...
        ProxyCommand ssh hostA -W %h:%p
    

in the config on my laptop, do I also need to fix it on hostA?

~~~
aexaey
CVE-2016-0777 doesn't interact with ProxyCommand in any special way. That
said, after connecting to hostB with your example config above you will have 2
ssh sessions:

1) from your client to hostA

2) from your client to hostB

So to answer your question - no, vulnerable client on hostA is not a problem
(or at least not in this particular use-case).

~~~
semi-extrinsic
> Vulnerable client on hostA is not a problem.

Ok, that's what I was wondering. Thanks.

------
StefanKarpinski
Does it strike anyone else as bizarre / poor form for an experimental feature
to be enabled by default in OpenSSH, which is normally very conservative with
option defaults?

~~~
drzaiusapelord
It just sounds like a big code-base fuckup. They more or less admit it:
"Server side was disabled/gutted for years already, but this aspect was
surprisingly forgotten."

Sounds like this was put in at one time, forgotten about, and the code
lingered for a long time until someone pointed it out. SSH as a protocol is
pretty crazy. Everyone loves it, but its a lot of things in one, which
ironically goes against the unix philosophy. Its a remote terminal, a file
transfer server, a network tunnel server, a socks server, etc. There's a lot
of stuff in there and I imagine difficult to work with sometimes.

No word if this is enabled in Putty, but I imagine it is if its using openssh
libraries.

~~~
jlgaddis
Pretty sure this is OpenSSH only. PuTTY and SecureCRT, at least, are reported
not to be affected.

~~~
larrymcp
We use WinSCP also, a file copying utility; it would be useful to know whether
that's affected if anybody has that info.

~~~
voltagex_
Last time I looked WinSCP used PuTTY components or a fork. Would appreciate
additional verification of this, though.

------
ryanlol
Someone tweeted this, the roaming code doesn't seem to be very well managed:
[https://twitter.com/marver/status/687644904575627264](https://twitter.com/marver/status/687644904575627264)

Edit 1: Here's some relevant commits too [https://marc.info/?l=openbsd-
cvs&m=145278217421101&w=2](https://marc.info/?l=openbsd-
cvs&m=145278217421101&w=2)

Edit 2: This mailing list post seems to discuss the vulnerable feature
[http://www.gossamer-
threads.com/lists/openssh/dev/49018?do=p...](http://www.gossamer-
threads.com/lists/openssh/dev/49018?do=post_view_threaded#49018)

Edit 3: Got a better description of actual impact of the bugs:

>Experimental roaming code in the ssh client could be tricked by a hostile
sshd

>server, potentially leaking key material. CVE-2016-077 and CVE-0216-078.

>Prevent this problem immediately by adding the line "UseRoaming no" to

>/etc/ssh/ssh_config.

~~~
kardos
So the real question is, can a MITM intercept connections to boxen you
frequent to exploit this? Or is it limited to connecting to hostile honeypots?

~~~
DrRobinson
Apparently not possible with MITM.

"The authentication of the server host key prevents exploitation by a man-in-
the-middle, so this information leak is restricted to connections to malicious
or compromised servers."

[https://lists.mindrot.org/pipermail/openssh-unix-
dev/2016-Ja...](https://lists.mindrot.org/pipermail/openssh-unix-
dev/2016-January/034680.html)

~~~
kardos
... and those that you haven't established TOFU with yet

------
jlgaddis
Workaround (yes, it's client-side):

    
    
      # echo -e "Host *\n\tUseRoaming no\n" >> /etc/ssh/ssh_config
    

Disclaimer: won't work on all operating systems, shells, etc. YMMV. Consult a
doctor before following any advice you get from the Internet. Void where
prohibited. Restrictions may apply.

 _Edited per comments below_

~~~
doogle88
Presumably you would have to connect to a malicious host to be effected? Or
perhaps a MITM on your connection to a legit host can exploit you somehow.

~~~
amatix
From the updated OP:

> The authentication of the server host key prevents exploitation by a man-in-
> the-middle, so this information leak is restricted to connections to
> malicious or compromised servers.

~~~
jon-wood
Malicious, compromised, or new servers. Because really, how many people check
the host key for a newly spun up EC2 instance?

------
nulltype
If you have a mac (Yosemite), it looks like you want to add " UseRoaming no"
under the "Host *" line in /etc/ssh_config (as root). You can test it before
and after with this:

ssh -v -T git@github.com 2>&1 | grep Roaming

debug1: Roaming not allowed by server <\- bad

ssh -v -T git@github.com 2>&1 | grep Roaming

(no output is good)

~~~
super_mario
On El Capitan the file is /etc/ssh/ssh_config

~~~
snowwrestler
On Mountain Lion it's /private/etc/ssh_config.

~~~
astrange
/etc points to /private/etc on OS X, so it's all good.

------
joe_bleau
Testing the ssh client config workaround:

    
    
       ssh -v user@localhost 2>&1 >/dev/null | grep -i 'roaming'
    

returns "debug1: Roaming not allowed by server" when vulnerable, and nothing
when not. YMMV, only tested on a few machines, etc.

~~~
clort
does this require a ssh server running on localhost?

~~~
pmuk
Yes, that command is connecting to an ssh server on localhost, but you could
connect to any ssh server that you trust...

    
    
      ssh -v -T git@github.com 2>&1 | grep -i 'roaming'

------
sharjeel
Since this is a client side issue, can this be used to exploit those automated
scanners who try to break into your SSH machine?

~~~
Stefan-H
Authenticated scanners that use key auth like Qualys' security appliances
could have private keys that are valid across the organization, and if using
an affected client version, could leak this information to a malicious system
on your network.

------
Aissen
Release is here, with many more details, and other security issues fixed:
[https://lists.mindrot.org/pipermail/openssh-unix-
dev/2016-Ja...](https://lists.mindrot.org/pipermail/openssh-unix-
dev/2016-January/034680.html)

------
kondbg
Details: [http://www.openwall.com/lists/oss-
security/2016/01/14/7](http://www.openwall.com/lists/oss-
security/2016/01/14/7)

------
aexaey
Does anybody else find this eerily reminiscent of heartbleed?

Obscure broken feature that nobody uses (or needs) is enabled by default and
allow private keys to leak.

~~~
tomjen3
It is OpenSSH, the clown car of bugs in obscure features nobody uses.

Does anybody know if LibraSSL has released an SSH client yet? I can't code
well enough to make security code safe, so I won't be able to help them out on
it, but it sounds more and more like OpenSSH can't either.

~~~
jldugger
You seem confused. The LibreSSL people released a SSH client years ago, called
OpenSSH. Which is not the same as OpenSSL, which suffered Heartbleed.

~~~
Gigablah
I can't blame him, considering that people have been encouraging this sort of
attitude towards the OpenSSL maintainers. It's time they tasted their own
medicine.

------
slasaus
My hardened ~/.ssh/config on OS X 10.11:

    
    
      Host *
        Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr
        MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
        KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
        HostKeyAlgorithms ssh-ed25519,ssh-rsa
        ChallengeResponseAuthentication no
        UseRoaming no
    

If you only connect to newer servers you can further restrict ciphers to only
use AEADs (only list the chacha20-poly1305 and aes-gcm ciphers). I assume
using AEADs-only makes the MACs keyword obsolete, is this correct?

Config is based on tips from [https://stribika.github.io/2015/01/04/secure-
secure-shell.ht...](https://stribika.github.io/2015/01/04/secure-secure-
shell.html)

~~~
zackelan
> I assume using AEADs-only makes the MACs keyword obsolete, is this correct?

Correct. You can test this by running SSH with -v/\--verbose and observing
these log lines:

    
    
        debug1: kex: server->client aes256-gcm@openssh.com <implicit> none
        debug1: kex: client->server aes256-gcm@openssh.com <implicit> none
    

When using a cipher that does not support AEAD, the 2nd field will include the
MAC instead of <implicit>

    
    
        debug1: kex: server->client aes256-ctr hmac-sha2-256-etm@openssh.com none
        debug1: kex: client->server aes256-ctr hmac-sha2-256-etm@openssh.com none
    

I wasn't sure what the 3rd "none" field is, but after some digging it appears
to be the compression algorithm: [https://github.com/openssh/openssh-
portable/blob/master/kex....](https://github.com/openssh/openssh-
portable/blob/master/kex.c#L818)

And I confirmed this with ssh -C:

    
    
        debug1: kex: server->client aes256-ctr hmac-sha2-256-etm@openssh.com zlib@openssh.com
        debug1: kex: client->server aes256-ctr hmac-sha2-256-etm@openssh.com zlib@openssh.com

------
Jadestuart1
Having been through some difficult times when i had been let down by everyone
around me, i came across Brandon Reid who is a hacker its actually impossible
to put in words how much of a Genius he is and also cant stop thanking him for
helping me through my divorce, and also my Nephews grades. He is a Blackhat
hacker and very capable of almost and everything, he is actually one of the
best out there and also shows you proof before charging you, in my own case
the money wasnt the problem and i can gladly say every money spent was so
worth it. I have reffered a number of people who will prefer not to be named
to Brandon and all have been immensly satisfied with the Top Notch hacking
service Brandon offers.To whoever who is lucky enough to read this its a new
year and i am only doing this for those genuine people out there who would
want the services of a hacker please as i said before be careful how you speak
to him his a BigFish. He can be contacted on his services email
Brandonreid001@gmail.com or text +1 813 379 2141 . Do mention the name Jade

------
Aissen
Roaming feature has been in OpennSSH code for a while, but is undocumented:
[http://superuser.com/a/826734/47771](http://superuser.com/a/826734/47771)

~~~
ryanlol
AFAIK the roaming feature has been disabled on the server side for a while,
but mistakenly left enabled on the client.

~~~
DrRobinson
Seems correct: [https://marc.info/?l=openbsd-
cvs&m=145278217421101&w=2](https://marc.info/?l=openbsd-
cvs&m=145278217421101&w=2)

------
hamburglar
How does a client bug end up leaking private key material to the server if the
private key is in an entirely different process (the agent)? Or is this only
an issue if you are loading your identity directly in the client?

~~~
singlow
I would love to hear from someone who knows the answer to this. Does this
affect ssh-agent? I am rotating my keys regardless, but I am curious.

~~~
TimWolla
According to:
[https://news.ycombinator.com/item?id=10902833](https://news.ycombinator.com/item?id=10902833)
it does not:

> Finally, for these three reasons, passphrase-encrypted SSH keys are leaked
> in their encrypted form, but an attacker may attempt to crack the passphrase
> offline. On the other hand, SSH keys that are available only through an
> authentication agent are never leaked, in any form.

------
peterwwillis
So, if there was forgotten code in OpenSSH (which, how the fuck does that
happen?), where else might there be forgotten code?

Also: this is a really great example of why you should _never have
undocumented features in your code_.

------
ygjb-dupe
While the bug doesn't expose a user to mitm attacks in general, am I correct
in thinking that folks using "-o UserKnownHostsFile=/dev/null -o
StrictHostKeyChecking=no" have basically opened the door for that?

[https://github.com/search?q=-o+UserKnownHostsFile%3D%2Fdev%2...](https://github.com/search?q=-o+UserKnownHostsFile%3D%2Fdev%2Fnull&type=Code&utf8=%E2%9C%93)

~~~
tobiasu
Ughhh, that's insane.

~~~
the_mitsuhiko
> Ughhh, that's insane.

Not really. This is for deploy systems which deploy to a trusted environment
(for instance through VPN, network security etc.).

~~~
throwaway2048
Even if you are using some kind of prebaked images to deploy, you should be
generating individual keys using the SSH PKI features per machine as part of
your individual host configurations.

This allows you to verify hosts while having never seen their keys. Just
totally shutting off verification is a horrible idea.

~~~
the_mitsuhiko
If someone can actively MITM in your network you have other problems.

~~~
throwaway2048
That argument has been shown to be nonsense for years, it can apply to any
mitigation technology or privilege reduction technique. The point is to reduce
the amount of harm that can be done, because "just write software without
bugs" isn't a solution at all.

~~~
the_mitsuhiko
> That argument has been shown to be nonsense for years, it can apply to any
> mitigation technology or privilege reduction technique. The point is to
> reduce the amount of harm that can be done, because "just write software
> without bugs" isn't a solution at all.

I don't disagree with this, but if you can MITM my traffic then impersonating
SSH is the least of my worries. The chance that I will randomly SSH into a
machine is pretty small to begin with whereas the deployment tools themselves
for instance will push out code changes in regular intervals throughout the
cluster. My point is: if you can actively MITM my traffic or anything similar
in severity, then there are much more interesting targets than SSH.

------
merqurio
As far as I know, this will affect any OSX, am I right ?

~~~
rsync
It will affect any OSX that is new enough to have that code in it. Same is
true with other OS. For instance, on an older, patched FreeBSD 7.2 system, we
see this result:

    
    
      /root/.ssh/config: line 1: Bad configuration option: UseRoaming
      /root/.ssh/config: terminating, 1 bad configuration option
    

... which means that sshd predates the roaming code. I haven't tested, but
I'll bet my snow leopard workstation also predates that code.

So ... if that line:

    
    
      UseRoaming no
    

produces no errors when you ssh as that user, then you had the problem and you
fixed it. If it produces the error above, you never had the problem in the
first place (although with an older sshd like that, you should make sure
you're not exposed to other, older vulnerabilities).

~~~
rsync
Ok, an update - snow leopard is indeed too old for this to be relevant. SL
with the last and latest software updates still doesn't have the roaming code
in sshd and therefore you don't need to fix anything (at least wrt roaming...)

------
moviuro
The most terrible thing here is that OpenBSD usually does some full
disclosure. This is sure going to be a nasty bug.

~~~
praseodym
Why is this terrible? In any case, the software is open source so any security
fix commit can also be considered as full disclosure.

~~~
kardos
But they didn't disclose the bug yet. The implication is that this bug is /so
bad/ that it justified breaking the normal "just disclose it" approach.

------
noir_lord
[http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/010_ss...](http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/010_ssh.patch.sig)

~~~
fulafel
Leaking private keys seems to be all the rage these days.

------
mag00
I'm curious how typo and bit squatting would come into play here, and if
attacks leveraging them could collect private keys at a dangerously high rate
before people can patch their clients.

Products like heroku, or the stripe CTF, or other things that come to mind
that operate over SSH going rogue a bit scarier. If one were to be compromised
it would be a case where mass amounts of private keys could leak. AWS, github,
all cloud VPS providers, etc.

Multifactor is relevant as a defense with a vulnerability like this.

------
LinuxBender
This wasn't the only feature that was activated without much documentation.
MaxSessions has a significant impact on any systems using 2FA (as the default
allows bypassing it if you are phished).

Just like unrestricted sudo, people have because accustom to the bad default
behavior of MaxSessions being 10 and allowing un-authenticated multiplexing.
(meaning, you auth once, and my trojan can use your session without
authentication)

------
ewindisch
For the single other ChromeOS user (how many of us are there?), note your SSH
client is also based on OpenSSH. Add '-o UseRoaming=no' to your arguments.

Watch this repo for updates (or submit a PR?)
[https://chromium.googlesource.com/chromiumos/platform/assets...](https://chromium.googlesource.com/chromiumos/platform/assets/+log/master/chromeapps/ssh_client)

------
matt_wulfeck
This is a surprisingly bad fail. I've never seen or heard of this option
before. In fact, my vimlint for ssh_config doesn't even show it as a valid
option!

------
protomyth
Check me on this, so this is a client-side problem only, so ssh-ing into only
know servers shouldn't be an issue and clients cannot cause problems for
servers?

~~~
scardine
If an enemy takes control of just one of the hosts you ssh into, he will get
your private key and can use it to ssh into any other box where you use
RSAAuthentication.

~~~
protomyth
I already added the mitigation, but I wondering if my servers can be patched
on the weekend.

~~~
drummer32
There is nothing to patch on the server side. You need to ensure the ssh
client is updated on the machines you are sshing from.

~~~
protomyth
ok thanks, that's what I figured, but it I was getting a bit worried that I
was missing something.

------
eljimmy
Some good news was added to the updates:

> The agent will never send a private key over its request channel. Instead,
> operations that require a private key will be performed by the agent, and
> the result will be returned to the requester. This way, private keys are not
> exposed to clients using the agent.

------
jlgaddis
_ETA: I was way off... you can ignore this..._ :-)

cf. section 3.3.5 [0], which describes "Roaming (Suspend/Resume)". This is
documentation for an application by a company called AppGate (later acquired
by Cryptzone) that wrote {some|most} of the code in OpenSSH's
"roaming_client.c".

This gives a hint of what the ramifications may be: basically, a MITM, who
observed the initial session negotiation, can disconnect the client and hijack
an active session.

> _Roaming is a feature which allows clients to suspend the connection to the
> AppGate server and later to resume it again. The user does not need to re-
> authenticate when reconnecting. Indeed, the entire process can be completely
> automated and nearly invisible to the user. All established connections will
> remain alive while roaming. This feature is intended for mobile users who
> move around between networks._

> _Technically, roaming is accomplished by closing the TCP tunnel when the
> connection is suspended. When resuming, a new TCP connection is made to the
> server and the SSH data stream is continued through this new connection. The
> user does not need to authenticate again, instead the client authenticates
> to the server, without user interaction, with the help of a random password
> which was made up when the user authenticated at the start of the session.
> In addition to knowing this password, the client must also know the
> encryption keys and encryption state to be able to reconnect. It is
> therefore impossible for a third party to break in and take over a suspended
> session._

I particularly like that last sentence.

[0]:
[http://download.cryptzone.com/files/download/AppGate-10.2.3/...](http://download.cryptzone.com/files/download/AppGate-10.2.3/doc/manual_chunked_html/ch03s03.html)

~~~
ryanlol
That's not correct though, MITM cannot exploit this. A malicious SSH server
can exploit this during a connection though, but only after host key
verification.

------
betaby
Could we say it partially because of mono-culture? Almost no one uses GNU lsh
as a client/server, dropbear is mostly used as a embedded system sshd. OpenSSH
has to many thing integrated and enabled by default.

------
ams6110
CentOS/RHEL 6.7 has:

    
    
      $ ssh -V
      OpenSSH_5.3p1 OpenSSL 1.0.1e-fips 11 Feb 2013
    

So... not vulnerable? Posted article says: _This affects OpenSSH versions 5.4
through 7.1._

------
rnhmjoj
Does this affect mosh?

~~~
fulafel
No, the roaming in Mosh is unrelated to OpenSSH's roaming feature.

~~~
rakoo
But authentication in Mosh still relies on OpenSSH, so auth could be
intercepted by an attacker after which Mosh is completely open to them:

[https://mosh.mit.edu/](https://mosh.mit.edu/)

> However, in typical usage, Mosh relies on SSH to exchange keys at the
> beginning of a session, so Mosh will inherit the weaknesses of SSH—at least
> insofar as they affect the brief SSH session that is used to set up a long-
> running Mosh session.

------
kevincox
Is there an explanation of why the roaming feature was removed from the
server? It sounds like a useful feature to me and I run into this all the
time.

------
mjevans
For shells where echo is a builtin that does not know about -e:

printf 'Host *\nUseRoaming no\n' >> /etc/ssh/ssh_config

------
devin
Am I correct that YubiKey users are unaffected by this vulnerability? As I
understand it, the private key never enters into memory.

~~~
feld
I guess it depends on what you mean? I have yubikey 2FA on my servers for SSH,
but also have SSH keys. I use SSH keys when I can, and yubikey when I don't
have my SSH keys handy.

I suppose if you're doing yubikey+password auth and don't have _any_ keys
configured for your ssh client you're fine because... you don't have any keys?
:)

~~~
Freaky
You can use a Yubikey _NEO_ to handle key authentication on your computer's
behalf:

[https://blog.habets.se/2013/02/GPG-and-SSH-with-Yubikey-
NEO](https://blog.habets.se/2013/02/GPG-and-SSH-with-Yubikey-NEO)

~~~
feld
Sure, but this capability isn't unique to Yubikey. The question was just
worded confusingly. Really it's just "ssh key on a smart card".

~~~
devin
Yes, my bad on the wording of the original question.

------
sgtnasty
Does it affect RHEL 6, using openssh 5.3?

------
sly010
Is there an easy way to verify that the workaround is effective? ssh -v
doesn't display anything related.

~~~
paulannesley
ssh SOMEHOST -v 2>&1 1>/dev/null | grep -i roaming

A vulnerable client will show:

debug1: Roaming not allowed by server

------
fixermark
So how does the exploit actually work? How can a malicious sshd actually use
this to acquire the private key?

~~~
d23
Yet another direct-link post to a cryptic CVE for those of us who aren't in
the know on security issues. Upvoting is a great shibboleth to show that some
posters "get it", while the rest of us are left in the dark on severity, left
to wade through the comments section to try to get a sense of what the real
impact is.

From what I can tell, if I accidentally SSH to the wrong server (or a
compromised one), my private key can be obtained. I have no clue if that's
actually the correct interpretation.

~~~
Estragon
Oh, come on. The issue is very clear. Your interpretation is correct.

------
ChALkeR
Note: this actually means that everyone should regenerate all their key-pairs
after updating.

------
sygma
Patch for OS X: echo -e 'Host *\nUseRoaming no' >> ~/.ssh/config

------
ctstover
What was this experimental / undocumented roaming feature even suppose to do?

~~~
noja
Complete guess: handle changes of ip address on the client side.

~~~
jlgaddis
Allow a mobile user to reconnect to a disconnected session without (user) re-
authentication.

------
nightfox0205
After edit config file , Do we need to rotated/genrate ssh keys also?

------
nightfox0205
After adding in config, Do we need to rota/generate ssh keys also ?

------
Estragon
So has anyone run git-blame yet? Who did this?

------
SFjulie1
theo must be mad.

Shaming people for leaving useless non essential feature in their code that
results in security breach.

And now the jewel of his crown has been compromised.

The funniest part is now that his jewel has been tarnished, maybe people will
understand what he was saying.

And maybe too, people that believed privacy can be achieved on the internet
will finally look at the problem of believing the 2 general paradox can be
solved without at least 2 different constant link on different plans. And the
problem is belief is a poor substitute for thinking - critical thinking.

And maybe people will discover the sad truth of the internet.

Security requires a perfect world, where human beings neither makes mistakes
nor are corruptible.

Errare humanum est, perseverare diabolicum

Oh! Some says that is what 2 factor authentication is.

I will answer, my intuition is telling me that 2 factor is good for a fixed
amount of time/information and that using it correctly would annoy people to
the utmost points.

Then people would say well let's accept that fraud exists. Business first.
(costs/benefits)

Then I say giving 3% of all e-commerce to the bad guys is like admitting
organized crime have a strong budget for even more crime ... and that we are
fucked.

Unless you don't understand that ISIS is basically a startup. A startup that
overthrow a state to make even more money and industrialize crime.

~~~
marios
What Theo (and other OpenBSD developers) have been saying all these years is
that it's impossible to /not/ make mistakes, which is why sane design and
exploit mitigations are important.

Mad ? Maybe, I wouldn't know. On the other hand, I bet he's really glad all
that effort to have ASLR by default was made, because it makes it more
difficult for an attacker to exploit vulnerabilites such as this one.

~~~
SFjulie1
ASLR makes exploits more difficult as long as you have true randomness. It is
just a mitigation ... for another problem.

In this case the elephant in the room is stack injection and dynamic
libraries. If processes where confined to a well known address space that was
self contained ASLR would be useless.. But dependency management would be
hellish.

Back to the case. OpenSSH has been openly criticize by 9plan teams for exactly
the same reason openSSL has been criticized by openSSH team : too much
complexity (not to say plan9 came to anything usable and were right (2 wrongs
do not make a right)).

[http://harmful.cat-v.org/software/ssh](http://harmful.cat-v.org/software/ssh)

I do have a feeling as a physicist that the S in CS stands for Shortness of
thinking. What is obscure is not profound.

And, at the opposite of engineers I don't believe that security is achievable
at all on computers. It is like believing there exists a way to avoid
triangulation with one strong radio source.

Computers leak to much information (especially in the physical world), and C
is a map that is taken too much for the territory. Every bugs are exploiting a
wrong mapping of concepts to implementation.

Modern security is like string theory, admired by everyone because it requires
great technical knowledge to master, understood by none because it is way to
complex for our "human" brains. We live in an era of belief in solutions.

A bit of critical thinking and of distrusts of experts and stuff that you
cannot understand without devoting your life to a subject is at my opinion a
must.

I distrust mathematicians for their capacity of dealing with the real world
and its uncertainties, and cryptography (as much as functional programming,
big data, algorithmic, IA, machine learning) is math driven in a pure
Aristotelian world. Where perfection and harmony is the pillar of thinking.

I come from micro-electronics, I only see wires (that are antennas),
oscillators, multiplexers, gates and basically a dumb automat I can automatize
in respect to time of propagation of signal, and I know that modern computers
under the hood are in the physical realm of relativity with approximate
answers.

I theorize, build, measure, and retheorize ad nauseum until the product is
measured to work the way I expect it to in the domain of validity with a good
enough confidence and margins of errors are always on my mind to be controled.

Security requires a zero margin of ambiguity. Physical world is bound to
heisenberg equation and coupling. Purity does not exist and this cannot be
mitigated. The postulate of cryptography are wrong from the core. Real world
always win at the end.

Aristotle way of thinking must die. Math is not science.

~~~
serge2k
What in the hell are you on about?

~~~
SFjulie1
The base of science : critical thinking as opposed to expertise and "commonly
accepted wisdom".

Trust, but check.

And if cannot check, I cannot trust.

Their map (model) is very nice, very detailed and self consistent. But is is
not the territory (implementation) and the more complexity we stack the
greater we prove the map diverge from the territory. And also the less it can
be audited.

Don't expect normal people to trust what they cannot check. It is faith
security experts are expecting from users, not trust.

I do my part of the contract as stated by common accepted risk management
"best practice" regarding computer security.

I do not trust blindly.

------
ck2
If it's not obvious, don't just add that config option, you have to also
restart it.

Actually wait, is this only affecting the ssh client and not the server/daemon
?

~~~
jlgaddis
Yes, it's client-side only. Server-side, it's disabled (cf. readconf.c).

------
axelfontaine
We went to other way and kissed SSH goodbye a long time ago in favor of
immutable infrastructure and automation: [https://boxfuse.com/blog/no-
ssh](https://boxfuse.com/blog/no-ssh)

~~~
feld
you've never had to debug anything in production, have you?

~~~
axelfontaine
It's not 2006 anymore. For the vast majority of the cases there is no need for
SSH when it comes to logging, profiling and debugging.

------
Corrado
Just a note: the default AWS Linux AMI doesn't seem to have this problem on
the server side. Connecting to one of my EC2 instances with verbose on I get
the following message:

    
    
      debug1: Roaming not allowed by server
    

Yeah! AWS Linux for the win. :)

~~~
Skunkleton
OpenSSH server doesn't support roaming. This is a client only issue. The
problem is that your connection could be MITM'd by someone looking to exploit
this bug.

~~~
hackuser
> your connection could be MITM'd

MITM isn't a risk, if I understand this statement in the undeadly.org
announcement:

    
    
       The authentication of the server host key prevents exploitation
       by a man-in-the-middle, so this information leak is restricted
       to connections to malicious or compromised servers.

~~~
kardos
Unless it's your first connection to a legit uncompromised server, yes? (AWS
instance, etc)

