5 ms·

If a bad guy gets root on one server you're currently connected via ssh with, and forwarding said key via, they can also access (unless otherwise firewalled) al

If a bad guy gets root on one server you're currently connected via ssh with, and forwarding said key via, they can also access (unless otherwise firewalled) all systems that ssh key grants them access to. See also: https://github.com/FiloSottile/whoami.filippo.io https://github.com/FiloSottile/whoami.filippo.io Using a private key per system or set of systems means that such an attacker would only gain access to what that key grants them access to. My "github" key only grants access to my github repos, not to my bitbucket repos or to my DigitalOcean servers, or my Scaleway servers. I have an SSH key for each "thing", and each key is kept in a different keyring via https://github.com/ccontavalli/ssh-ident https://github.com/ccontavalli/ssh-ident, _precisely_ to avoid that problem. As an example, an attacker gaining root on my Oracle Cloud free server will not be able to clone all my Github repos with it: I only use that key to connect to that server, and while I may have the github key unlocked at the same time - that's on a different keyring which the server has no visibility of.

riedel 6y ago
But if you use agent forwarding with other keys loaded into the agent, how does hat help?
- mfontani 6y ago
  I don't. Each agent gets one key, and that key alone. That's what helps. https://github.com/ccontavalli/ssh-ident https://github.com/ccontavalli/ssh-ident is what I use to manage those agents - one agent per key.
Boulth 6y ago
I think the proper solution would be 1) don't use forwarding unless necessary 2) setup touch-to-use on a Yubikey so even with your scenario the attacker couldn't just use the key (it requires touch to be used).
- mfontani 6y ago
  I've (admittedly, conceptual only) a couple problem with this approach I'd love to hear folks' thoughts about, with regards to "touch-to-use". 1. I still have a need to "for s in $list_of_servers; ssh -A $s '..'; done" How many times do I have to push the button? Is there a setting that allows that "push to allow" for a short while? Great, if so: 2) when I ssh into a system and touch the button to allow it, and the push allowed the use of they key for a short while, am I not in the same problem as before - as the system may be compromised and may be performing other operations I'm unawares of? A solution for this would be to have multiple hardware keys for things I manage: one for $work, one for $personal, another for $github, etc. etc. but then managing them and - especially!! - their SSH agent which may be in memory but relies on the hardware being present, with all issues _that_ entails.... becomes a frigging mess. So I'm torn... between the simplicity of a hardware key with push-to-allow... and actually being able to _use_ it _securely_.
  - Tyr42 6y ago
    If I ssh in two different tabs back to back, I still need to touch twice. So it's your case 1 that's not supported nicely. Rather than being insecure.
  - Boulth 6y ago
    > Is there a setting that allows that "push to allow" for a short while? Yes there is. In a newer firmware. > 2) when I ssh into a system and touch the button to allow it, and the push allowed the use of they key for a short while, am I not in the same problem as before - as the system may be compromised and may be performing other operations I'm unawares of? Yes but the window of opportunity for the attacker is smaller. Also: it's your setup that requires multiple key operations within short time interval, for some people touching every time is sufficient and most secure.
  - mmalone 6y ago
    Seems the ideal solution would be to trigger push-to-allow for signing requests that come in via agent forwarding, but not for local requests. I’ve been thinking about a reliable & secure way to do this. A modified OpenSSH client could enable this pretty easily by simply indicating to the agent where the request originated. But that’d require changes to both OpenSSH and to the agent protocol.
beagle3 6y ago
The SSH-agent forwarding model is the problem, I think; Every couple of years someone finds another semi-common scenario where it becomes vulnerable. I have, since 2010, practiced "jumps" only - that is, if I need to connect to a non-routeable host through a routeable one ("bastion host" or "jump host"), then the intermediate host is only used as a transport, by way of -L/-R forwarding of the final destination's ssh port, or by netcat, or (since a couple of years ago) SSH's internal ProxyJump or ProxyCommand; compared to agent forwarding, this is less efficient CPU-wise and traffic-wise, but not by much; and it is as safe as connecting to the final destination directly, unlike agent forwarding.
- mmalone 6y ago
  That works for bastions, but not other use cases. One common one is pushing & pulling from git on a remote dev box. Or if you want to SCP something between remote machines without having to pull it down locally. Agent forwarding is the best way to do this (outside of possibly generating an ephemeral key pair and copying public keys around for a single use then destroying them... but ain’t nobody gonna do that).
  - beagle3 6y ago
    It’s probably the easiest way, but also very vulnerable. Never seen this use case or anything similar myself. Do you have other examples? I want to broaden my horizons
    - mmalone 6y ago
      In general I'd say SSHing from a remote box to another remote box is a non-issue since you can always use some sort of tunneling/bastioning to make that work. It's when you want to use some other tool that tunnels over SSH -- scp, git, sftp, rsync, etc. -- that you run into trouble. Consider a remote development instance. So I'm an engineer, and instead of developing on my local I do development on an EC2 instance in AWS (there are a variety of reasons this may be preferential or even required). If I'm pushing & pulling code from GitHub to/from this development instance I'm gonna need to either have a private key on that development instance or have agent forwarding back to my local. Now suppose I want to copy a large database snapshot between two instances on EC2. There are obvious benefits to being able to transfer directly between these two instances, on the same private network, versus bringing the data to your local (where you might not even have sufficient disk space) and pushing it back up. Not sure what other use cases exist, but these two alone I think justify the existence of agent forwarding. SSH agent forwarding does have subtle security issues. But so does putting a private key on a remote server. If you're the only one who has access to the remote server, neither option is problematic. If someone else has root, and you don't trust that person, then both are problematic (and which is worse is debatable).
snowwrestler 6y ago
Ah. I don't use forwarding so didn't consider that. Thanks.

riedel 6y ago

But if you use agent forwarding with other keys loaded into the agent, how does hat help?

mfontani 6y ago
I don't. Each agent gets one key, and that key alone. That's what helps. https://github.com/ccontavalli/ssh-ident https://github.com/ccontavalli/ssh-ident is what I use to manage those agents - one agent per key.

Boulth 6y ago

I think the proper solution would be 1) don't use forwarding unless necessary 2) setup touch-to-use on a Yubikey so even with your scenario the attacker couldn't just use the key (it requires touch to be used).

mfontani 6y ago
I've (admittedly, conceptual only) a couple problem with this approach I'd love to hear folks' thoughts about, with regards to "touch-to-use". 1. I still have a need to "for s in $list_of_servers; ssh -A $s '..'; done" How many times do I have to push the button? Is there a setting that allows that "push to allow" for a short while? Great, if so: 2) when I ssh into a system and touch the button to allow it, and the push allowed the use of they key for a short while, am I not in the same problem as before - as the system may be compromised and may be performing other operations I'm unawares of? A solution for this would be to have multiple hardware keys for things I manage: one for $work, one for $personal, another for $github, etc. etc. but then managing them and - especially!! - their SSH agent which may be in memory but relies on the hardware being present, with all issues _that_ entails.... becomes a frigging mess. So I'm torn... between the simplicity of a hardware key with push-to-allow... and actually being able to _use_ it _securely_.
- Tyr42 6y ago
  If I ssh in two different tabs back to back, I still need to touch twice. So it's your case 1 that's not supported nicely. Rather than being insecure.
- Boulth 6y ago
  > Is there a setting that allows that "push to allow" for a short while? Yes there is. In a newer firmware. > 2) when I ssh into a system and touch the button to allow it, and the push allowed the use of they key for a short while, am I not in the same problem as before - as the system may be compromised and may be performing other operations I'm unawares of? Yes but the window of opportunity for the attacker is smaller. Also: it's your setup that requires multiple key operations within short time interval, for some people touching every time is sufficient and most secure.
- mmalone 6y ago
  Seems the ideal solution would be to trigger push-to-allow for signing requests that come in via agent forwarding, but not for local requests. I’ve been thinking about a reliable & secure way to do this. A modified OpenSSH client could enable this pretty easily by simply indicating to the agent where the request originated. But that’d require changes to both OpenSSH and to the agent protocol.

beagle3 6y ago

The SSH-agent forwarding model is the problem, I think; Every couple of years someone finds another semi-common scenario where it becomes vulnerable. I have, since 2010, practiced "jumps" only - that is, if I need to connect to a non-routeable host through a routeable one ("bastion host" or "jump host"), then the intermediate host is only used as a transport, by way of -L/-R forwarding of the final destination's ssh port, or by netcat, or (since a couple of years ago) SSH's internal ProxyJump or ProxyCommand; compared to agent forwarding, this is less efficient CPU-wise and traffic-wise, but not by much; and it is as safe as connecting to the final destination directly, unlike agent forwarding.

mmalone 6y ago
That works for bastions, but not other use cases. One common one is pushing & pulling from git on a remote dev box. Or if you want to SCP something between remote machines without having to pull it down locally. Agent forwarding is the best way to do this (outside of possibly generating an ephemeral key pair and copying public keys around for a single use then destroying them... but ain’t nobody gonna do that).
- beagle3 6y ago
  It’s probably the easiest way, but also very vulnerable. Never seen this use case or anything similar myself. Do you have other examples? I want to broaden my horizons
  - mmalone 6y ago
    In general I'd say SSHing from a remote box to another remote box is a non-issue since you can always use some sort of tunneling/bastioning to make that work. It's when you want to use some other tool that tunnels over SSH -- scp, git, sftp, rsync, etc. -- that you run into trouble. Consider a remote development instance. So I'm an engineer, and instead of developing on my local I do development on an EC2 instance in AWS (there are a variety of reasons this may be preferential or even required). If I'm pushing & pulling code from GitHub to/from this development instance I'm gonna need to either have a private key on that development instance or have agent forwarding back to my local. Now suppose I want to copy a large database snapshot between two instances on EC2. There are obvious benefits to being able to transfer directly between these two instances, on the same private network, versus bringing the data to your local (where you might not even have sufficient disk space) and pushing it back up. Not sure what other use cases exist, but these two alone I think justify the existence of agent forwarding. SSH agent forwarding does have subtle security issues. But so does putting a private key on a remote server. If you're the only one who has access to the remote server, neither option is problematic. If someone else has root, and you don't trust that person, then both are problematic (and which is worse is debatable).

snowwrestler 6y ago

Ah. I don't use forwarding so didn't consider that. Thanks.