161–170 of 226 posts
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...
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…
> 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. A better mandate would be to use ssh-agent. Using separate key pairs without an agent doesn't prevent key theft due to memory disclosure vulnerabilities like this one; it merely compartmentalizes the damage. But if you use an ag…
This is what I would assume, but has it been confirmed that this vulnerability doesn't affect identities provided by an SSH agent? If any of this "roaming" support was provided by the agent, it could be the case that the leakage can be triggered via SSH agent protocol requests. I doubt this is the case but I don't see anything confirming or denying it.
It would be nice to hear some official word on whether agent-based authentication is vulnerable, because if it isn't, the seriousness to me is greatly reduced, as I never load identities in the client directly.
Earlier quoted context omitted.
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.
Of course local, not forwarded ssh-agent on the terminal would be super-handy to avoid typing pass-phrase time and again; but that's different and independent from ForwardAgent.
Earlier quoted context omitted.
> 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. A better mandate would be to use ssh-agent. Using separate key pairs without an agent doesn't prevent key theft due to memory disclosure vulnerabilities like this one; it merely compartmentalizes the damage. But if you use an ag…
> But if you use an agent, the client never loads the private key, so it's safe from memory disclosure vulnerabilities. This is what I would assume, but has it been confirmed that this vulnerability doesn't affect identities provided by an SSH agent? If any of this "roaming" support was provided by the agent, it could be the case that the leakage can be triggered via SSH agent protocol requests. I doubt this is the c…
https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-077...
This means they are basically able to dump the memory of just the running `ssh` process -- eerily similar to Heartbleed.
This means private keys stored by the `ssh-agent` process, outside of the `ssh` process connecting to an Evil Server(TM) are not affected.
This is because the protocol used between SSH Agent and SSH client does not transfer the entire private key, rather the SSH client asks the Agent to do a signing operation on it's behalf.
Earlier quoted context omitted.
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? :)
yubikeys support ssh key auth (via gpg-agent in ssh mode). It's sometimes a bit wobbly, but in general works fine.
Earlier quoted context omitted.
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.
If you have clean network path from your terminal to the dev vm, why need for either ProxyCommand or ForwardAgent - just ssh to the vm directly, no? Of course local, not forwarded ssh-agent on the terminal would be super-handy to avoid typing pass-phrase time and again; but that's different and independent from ForwardAgent.
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)
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)
Earlier quoted context omitted.
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