6 ms·

> sshmux, and by extension, sshmuxd, can only forward normal sessions (ssh'ing directly to sshmuxd without a ProxyCommand) if agent forwarding is enabled. This

> sshmux, and by extension, sshmuxd, can only forward normal sessions (ssh'ing directly to sshmuxd without a ProxyCommand) if agent forwarding is enabled. This is very dangerous. With the average setup, anyone with root access on the middle box can borrow the ssh key of any user connecting through it. See http://unixwiz.net/techtips/ssh-agent-forwarding.html#sec http://unixwiz.net/techtips/ssh-agent-forwarding.html#sec for more info.

hlieberman 11y ago
Considering this seems intended for use in somewhat corporate situations, it may or may not be that serious of a problem. This is yet another situation where Kerberos got it right years and years ago, but is almost impossible to actually /use/ even now after n years.
- beagle3 11y ago
  Could you give a quick summary (or a link) about how Kerberos works in this respect ?
- joushou 11y ago
  Exactly. And yes, Kerberos got it somewhat right, but as someone who have used configured and used it, it is quite the exercise to set up. It took ages to get working, and even then, it was slightly cumbersome to use.
  - cpach 11y ago
    "It took ages to get working, and even then, it was slightly cumbersome to use." I've wondered from time to time why Kerberos more or less faded into obscurity. I guess we have the answer then.
- asdfaoeu 11y ago
  Kerberos is just as open as ssh-agents. The middle server is still able to impersonate you.
  - joushou 11y ago
    ssh-agent, as a protocol-concept is not as broken as it sounds. It's just that the implemented interface (socket) is bad when combined with no user acknowledgment of sign requests. I think the worst part is that the agent doesn't ask the user for confirmation, which would essentially invalidate most of the ways you would abuse the agent. Attacks would be reduced to spamming or attempted phishing with agent requests. Kerberos could have bad interface as well, but I don't know how that would work in this scenario. The protocol itself is secure, but just as with ssh agent forwarding, if you let everyone make authentication requests without requiring user interaction to verify it, it will have the same problems.
    - throwaway2048 11y ago
      you can have the agent ask you for confirmation, see ssh-add -c in the appropriate manpage.
joushou 11y ago
Agent forwarding can be dangerous, yes, in the sense that you are giving the remote host you are connecting to (or jumphost in this case) permission to sign things with your private key. In the normal case, this is done through a socket, which means that root on the machine can access it, and sign arbitrary things. A compromised machine is therefore dangerous. This is no different than getting root access on the local machine, as you can access your local ssh agent there as well. However, with sshmux, the agent channel is not forwarded as a socket, but instead internally handled as the ssh channel it really is. This means that compromising the agent at sshmux requires arbitrary memory access, which is a considerably more difficult feat, and means that the machine is 100% compromised regardless.
- noja 11y ago
  Wait your last sentence lost me: why did you write "and means that the machine is 100% compromised regardless." I am root, I have arbitrary memory access on the jumphost. I could write a tool, like the heartbleed poc, to find the data I want.
  - joushou 11y ago
    You need arbitrary read and write memory access to abuse it (how would you otherwise make the signing request? You can't just steal one, as they're unique for their purpose), not just read, which is much more than heartbleed was capable of. You of course have this with root, but I'd like to point it out regardless. I wrote it because, in the case that you have an evil user that scans all physical memory, you can't do anything on the computer and still be safe. ssh -W bypasses the host, and due to various cryptographic features of that setup, the only thing that could happen would be to have someone break the connection or present you with incorrect host keys, which the client would detect. I'm of course assuming that they don't have a SSH vulnerability, as that's a completely different story regardless of agent forwarding. You can't use that machine for anything else and still be safe, and the presence of that machine on your network is a bad sign, most likely indicating that other things will be taken over as well in the same way that they got first one, or already is compromised, including some of your endpoints. While agent forwarding to the final host isn't necessary, your network is compromised, meaning that other important thing most likely got stolen, just not your private key. If your trumph card is that they don't have your private key, it's kind of like standing at a house that has been completely destroyed with all valuables in it, holding a key and saying "Well, at least they didn't get the key for the front door!". In this case, having private keys for different purposes would be a good way to isolate things, just in case. I personally separate work keys and private (as in spare time) keys. I know I'm exaggerating the comparison a bit, but the setup required to take over agent forwarding on a network you control, means that you're screwed regardless. Agent forwarding should be used with care, ssh-add -c being absolutely necessary, but agent forwarding has its uses, and many of the cases where I'd be attacked means that I have more pressing matters to deal with.
keeperofdakeys 11y ago
Personally I have a confirmation dialogue for any agent forwarding request. When I require it, this seems like the best compromise. (I still have my key decrypted in memory, I just get a "Use key?" window that I need to hit enter for).
- joushou 11y ago
  +1, although a bit more information would be nice ("Use key for session XYZ"). I'm curious, how did you get that set up?
  - keeperofdakeys 11y ago
    ssh-add has a -c option, which uses ssh-askpass for confirmation. Unfortunately it doesn't give much information, but you hope you would notice it coming up when you didn't initiate it. You may also be able to do something with gpg-agent, it seems to have more options.
    - joushou 11y ago
      Oooooooh, I missed that one. It would have been better if it wasn't an option, but default behaviour, but I guess we can't win every time...

hlieberman 11y ago

Considering this seems intended for use in somewhat corporate situations, it may or may not be that serious of a problem. This is yet another situation where Kerberos got it right years and years ago, but is almost impossible to actually /use/ even now after n years.

beagle3 11y ago
Could you give a quick summary (or a link) about how Kerberos works in this respect ?
joushou 11y ago
Exactly. And yes, Kerberos got it somewhat right, but as someone who have used configured and used it, it is quite the exercise to set up. It took ages to get working, and even then, it was slightly cumbersome to use.
- cpach 11y ago
  "It took ages to get working, and even then, it was slightly cumbersome to use." I've wondered from time to time why Kerberos more or less faded into obscurity. I guess we have the answer then.
asdfaoeu 11y ago
Kerberos is just as open as ssh-agents. The middle server is still able to impersonate you.
- joushou 11y ago
  ssh-agent, as a protocol-concept is not as broken as it sounds. It's just that the implemented interface (socket) is bad when combined with no user acknowledgment of sign requests. I think the worst part is that the agent doesn't ask the user for confirmation, which would essentially invalidate most of the ways you would abuse the agent. Attacks would be reduced to spamming or attempted phishing with agent requests. Kerberos could have bad interface as well, but I don't know how that would work in this scenario. The protocol itself is secure, but just as with ssh agent forwarding, if you let everyone make authentication requests without requiring user interaction to verify it, it will have the same problems.
  - throwaway2048 11y ago
    you can have the agent ask you for confirmation, see ssh-add -c in the appropriate manpage.

joushou 11y ago

Agent forwarding can be dangerous, yes, in the sense that you are giving the remote host you are connecting to (or jumphost in this case) permission to sign things with your private key. In the normal case, this is done through a socket, which means that root on the machine can access it, and sign arbitrary things. A compromised machine is therefore dangerous. This is no different than getting root access on the local machine, as you can access your local ssh agent there as well. However, with sshmux, the agent channel is not forwarded as a socket, but instead internally handled as the ssh channel it really is. This means that compromising the agent at sshmux requires arbitrary memory access, which is a considerably more difficult feat, and means that the machine is 100% compromised regardless.

noja 11y ago
Wait your last sentence lost me: why did you write "and means that the machine is 100% compromised regardless." I am root, I have arbitrary memory access on the jumphost. I could write a tool, like the heartbleed poc, to find the data I want.
- joushou 11y ago
  You need arbitrary read and write memory access to abuse it (how would you otherwise make the signing request? You can't just steal one, as they're unique for their purpose), not just read, which is much more than heartbleed was capable of. You of course have this with root, but I'd like to point it out regardless. I wrote it because, in the case that you have an evil user that scans all physical memory, you can't do anything on the computer and still be safe. ssh -W bypasses the host, and due to various cryptographic features of that setup, the only thing that could happen would be to have someone break the connection or present you with incorrect host keys, which the client would detect. I'm of course assuming that they don't have a SSH vulnerability, as that's a completely different story regardless of agent forwarding. You can't use that machine for anything else and still be safe, and the presence of that machine on your network is a bad sign, most likely indicating that other things will be taken over as well in the same way that they got first one, or already is compromised, including some of your endpoints. While agent forwarding to the final host isn't necessary, your network is compromised, meaning that other important thing most likely got stolen, just not your private key. If your trumph card is that they don't have your private key, it's kind of like standing at a house that has been completely destroyed with all valuables in it, holding a key and saying "Well, at least they didn't get the key for the front door!". In this case, having private keys for different purposes would be a good way to isolate things, just in case. I personally separate work keys and private (as in spare time) keys. I know I'm exaggerating the comparison a bit, but the setup required to take over agent forwarding on a network you control, means that you're screwed regardless. Agent forwarding should be used with care, ssh-add -c being absolutely necessary, but agent forwarding has its uses, and many of the cases where I'd be attacked means that I have more pressing matters to deal with.

keeperofdakeys 11y ago

Personally I have a confirmation dialogue for any agent forwarding request. When I require it, this seems like the best compromise. (I still have my key decrypted in memory, I just get a "Use key?" window that I need to hit enter for).

joushou 11y ago
+1, although a bit more information would be nice ("Use key for session XYZ"). I'm curious, how did you get that set up?
- keeperofdakeys 11y ago
  ssh-add has a -c option, which uses ssh-askpass for confirmation. Unfortunately it doesn't give much information, but you hope you would notice it coming up when you didn't initiate it. You may also be able to do something with gpg-agent, it seems to have more options.
  - joushou 11y ago
    Oooooooh, I missed that one. It would have been better if it wasn't an option, but default behaviour, but I guess we can't win every time...