5 ms·

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 authentic

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.

aexaey 11y ago
Don't use SSH agent forwarding. https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/ https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-con...
- Xylakant 11y ago
  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 since the key never enters the process memory.
  - aexaey 11y ago
    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.
    - Xylakant 11y ago
      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.
      - aexaey 11y ago
        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.
        Xylakant 11y ago
        I do ssh directly to the VM. It sits behind a VPN connection at aws. I need to make ssh connections from there to github. The key resides on a smartcard in my laptops usb slot. And that's where ssh-agent/ForwardAgent comes into play. I forward my local key to the remote VM.
        aexaey 11y ago
        Fair enough. Makes perfect sense, thanks!
semi-extrinsic 11y ago
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 11y ago
  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 11y ago
    > Vulnerable client on hostA is not a problem. Ok, that's what I was wondering. Thanks.

aexaey 11y ago

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

Xylakant 11y ago
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 since the key never enters the process memory.
- aexaey 11y ago
  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.
  - Xylakant 11y ago
    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.
    - aexaey 11y ago
      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.
      - Xylakant 11y ago
        I do ssh directly to the VM. It sits behind a VPN connection at aws. I need to make ssh connections from there to github. The key resides on a smartcard in my laptops usb slot. And that's where ssh-agent/ForwardAgent comes into play. I forward my local key to the remote VM.
        aexaey 11y ago
        Fair enough. Makes perfect sense, thanks!

semi-extrinsic 11y ago

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 11y ago
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 11y ago
  > Vulnerable client on hostA is not a problem. Ok, that's what I was wondering. Thanks.