121–130 of 226 posts
debug1: Roaming not allowed by server
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…
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 agent, the client never loads the private key, so it's safe from memory disclosure vulnerabilities. Stealing a private key would require filesystem access or remote code execution, at which point all of your private keys are at risk, so you might as well just use a single private key per device.
For the best security, store your private key on a smartcard, so even an attacker with filesystem access or remote code execution can't steal it.
Watch this repo for updates (or submit a PR?) https://chromium.googlesource.com/chromiumos/platform/assets...
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. :)
The matching server code has never been shipped, but the client
code was enabled by default and could be tricked by a malicious
server into leaking client memory to the server, including private
client user keys.[1]
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
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.
Host hostB
...
ProxyCommand ssh hostA -W %h:%p
Earlier quoted context omitted.
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.
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.
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. :)
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. :)
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…
Do you ever feel like ideas or sentences that you are talking about need to be talked about urgently or are you ever annoyed by others telling you to calm down or talk slower?
[1]: https://en.wikipedia.org/wiki/Derailment_(thought_disorder)
Earlier quoted context omitted.
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.
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?
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).