Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSH: client bug CVE-2016-0777

undeadly.org

Post reply on HN
Print view View original

151–160 of 226 posts

Re: OpenSSH: client bug CVE-2016-0777

#151

Post by Freaky »

feld wrote: post #118
devin wrote: post #116

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

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? :)

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

Re: OpenSSH: client bug CVE-2016-0777

#153

Post by super_mario »

nulltype wrote: post #150

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 ssh -v -T git@github.com 2>&1 | grep Roaming (no output is good)

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

Re: OpenSSH: client bug CVE-2016-0777

#154

Post by aexaey »

Xylakant wrote: post #144
aexaey wrote: post #120

Earlier quoted context omitted.

Don't use SSH agent forwarding. https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-con...

which is not very helpful if you for example want to run git via ssh or similar commands on the target server. There's places where there are two alternatives: agent forwarding or copy the key. Using ssh agent forwarding allows me to use a smart card for the key. It still has it's problems but it's much better than having the key on the remote machine - for example the use of a smartcard mitigates this vulnerability…

Not sure which exact scenario do you have in mind with ssh+git. ProxyCommand method works just fine for me with my private jumphost in the middle and github on the far end.

Note that for ProxyCommand to work, you don't need a full shell on a jumphost, just "AllowTcpForwarding yes" is enough. On the other hand, with AgentForwarding method you do need a full shell on a jumphost.

Re: OpenSSH: client bug CVE-2016-0777

#155

Post by snowwrestler »

super_mario wrote: post #153
nulltype wrote: post #150

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 ssh -v -T git@github.com 2>&1 | grep Roaming (no output is good)

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

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

Re: OpenSSH: client bug CVE-2016-0777

#156

Post by Xylakant »

aexaey wrote: post #154
Xylakant wrote: post #144

Earlier quoted context omitted.

which is not very helpful if you for example want to run git via ssh or similar commands on the target server. There's places where there are two alternatives: agent forwarding or copy the key. Using ssh agent forwarding allows me to use a smart card for the key. It still has it's problems but it's much better than having the key on the remote machine - for example the use of a smartcard mitigates this vulnerability…

Not sure which exact scenario do you have in mind with ssh+git. ProxyCommand method works just fine for me with my private jumphost in the middle and github on the far end. Note that for ProxyCommand to work, you don't need a full shell on a jumphost, just "AllowTcpForwarding yes" is enough. On the other hand, with AgentForwarding method you do need a full shell on a jumphost.

I have a vm that I use as development environment, my laptop is just a dumb terminal. I need to check out code there. It's not a jump host.

Re: OpenSSH: client bug CVE-2016-0777

#157

Post by jethro_tell »

moviuro wrote: post #89
patio11 wrote: post #83

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 futur…

This may be a start: Host * IdentityFile ~/.ssh/%h Comment: One key per host, named after the host you connect to

What if my infrastructure is over 50 hosts? How am I going to distribute key files for 50 people with 50 keys every 14 days?

Re: OpenSSH: client bug CVE-2016-0777

#160

Post by TimWolla »

singlow wrote: post #148
hamburglar wrote: post #97

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?

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.

According to: 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.

Post reply on HN