Earlier quoted context omitted.
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?
OpenSSH: client bug CVE-2016-0777
191–200 of 226 posts
Re: OpenSSH: client bug CVE-2016-0777
#192Earlier quoted context omitted.
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?
What do you do now if someone leaves? Remove that person's key from all 50 hosts one at a time?
Or, at the very least, you use tmux with sync panes or csshx - and log into all 50 hosts at once, and then you can issue one rm / scp command if you are still doing things manually.
Re: OpenSSH: client bug CVE-2016-0777
#193Earlier quoted context omitted.
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?
You could use something like ansible for the management of keys. Or you could centralize your authentication, which would probably be a lot more sane.
Even with config management this won't scale past about 2 or 3 people and 10-20 boxes.
Central auth is an option I guess but I think the better way to go would be a 2 factor with the key and hotp.
Re: OpenSSH: client bug CVE-2016-0777
#194If 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)
$ for SSH_CONF in /etc/ssh/ssh_config /etc/ssh_config /private/etc/ssh_config; do [ -f $SSH_CONF ] && ! grep -q 'UseRoaming no' $SSH_CONF && echo "Patching $SSH_CONF" && echo -e '\nHost *\n UseRoaming no' | sudo tee -a $SSH_CONF > /dev/null; done
Re: OpenSSH: client bug CVE-2016-0777
#195Earlier quoted context omitted.
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?
What is "boxen"?
Re: OpenSSH: client bug CVE-2016-0777
#196Earlier quoted context omitted.
Ughhh, that's insane.
> Ughhh, that's insane. Not really. This is for deploy systems which deploy to a trusted environment (for instance through VPN, network security etc.).
This allows you to verify hosts while having never seen their keys. Just totally shutting off verification is a horrible idea.
Re: OpenSSH: client bug CVE-2016-0777
#197Earlier quoted context omitted.
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.
> 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.
Re: OpenSSH: client bug CVE-2016-0777
#198Use 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…
Make sure you patch BEFORE doing something like ssh'ing into whoami.filippo.io "just because someone on the internet told me to"
This site is (from what I can tell) not malicicous, but copy pasting scripts and blindly following advice from the internet is a prime example of how an exploit would occur.
Re: OpenSSH: client bug CVE-2016-0777
#199Earlier quoted context omitted.
Indeed. The page gives bad advise. If your config has `Host` blocks, like often in people's personal configs, or if you have a `Match` block, the new directive only applies to the last of those blocks in the config file.
Sufficient to place it at the top of ~/.ssh/config? Or does it also need a block header of its own, like: Host * UseRoaming no
For instance:
UseRoaming no
Host *
Blah yes
Test with: ssh -v remote.ssh.host.com uptime 2>&1 | grep -i roamingIf it returns nothing, the config fix is active. If it isn't active, you'll see 'debug1: Roaming not allowed by server'
Re: OpenSSH: client bug CVE-2016-0777
#200Earlier quoted context omitted.
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 fo…
What in the hell are you on about?
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.