5 ms·

Yup, and this is explained in detail in the ssh(1) man page. No-one should be using -A. Using a jump host via -J is the way to go.

Arnavion 3y ago
One use of -A, namely using the ssh server as a jumphost, is covered by -J. The general use of -A, namely doing operations on the ssh server that require keys from the ssh client, is not. If I'm on machine foo and I want to connect to bar.example.org and clone a git repo there from baz.example.org, and baz.example.org requires an identity key that is in foo's ssh agent, then -A is the only option.
- GauntletWizard 3y ago
  ssh-askpass is a great tool in these situations. It intercedes and allows you to manually control all key usage attempts.
  - devnullbrain 3y ago
    Ah, a skillful execution of Cunningham's Law
  - Arnavion 3y ago
    I'm not sure what relevance ssh-askpass has to what I wrote.
    - GauntletWizard 3y ago
      Right, this recipe isn't well known. `ssh-add -c` will cause your ssh agent to pop up with ssh-askpass every time it does an authentication. This is fiddly; You need to have configured your ssh-agent right, and there's a slightly different version to use keychains on macos that's equivalent.
      - Arnavion 3y ago
        Once again, I'm not sure what relevance this has to the discussion.
        pritambaral 3y ago
        Some people denounce all use of agent forwarding because, by default, ssh-agent doesn't confirm with the user before signing a request with the users private key. This means, if you ssh into a compromised/malicious host with your agent forwarded, malicious code on that machine can just silently ssh into other servers as you. This trick has been used in the past by blackhats to escalate from a compromised CI environment to full production takeover. GauntletWizard probably meant to respond to your parent in this thread.
- gunapologist99 3y ago
  No, you might as well copy the keys over there for all the security you're getting (actually, that's safer given this RCE which compromises both sides, even given that there's no real way to shred the leaked key, but of course I'm not actually suggesting this! they're both really bad.) Your best option is too easy: just generate a new keypair on foo. Then you can populate baz.example.org with that public key instead of your own.
  - Arnavion 3y ago
    >No, you might as well copy the keys over there Only if the keys are insecure enough to be copied, ie not backed by an HSM, or backed by an HSM but marked exportable. >for all the security you're getting (actually, that's safer given this RCE which compromises both sides, even given that there's no real way to shred the leaked key, but of course I'm not actually suggesting this! they're both really bad.) Connecting to a malicious SSH server is already dangeorous with or without this vulnerability, and with or without agent forwarding. Eg a malicious server can modify the shell to emit VT codes to mess up your terminal. >Your best option is too easy: just generate a new keypair on foo. Sure, but this creates additional identities that baz.example.org must be taught to trust, which is not always desirable or even an option.
    - gunapologist99 3y ago
      > Only if the keys are insecure enough to be copied, ie not backed by an HSM, or backed by an HSM but marked exportable. Agent forwarding forwards the keys insecurely. If you can launch an agent-forwarded connection, then the HSM is already irrelevant. > "Connecting to a malicious SSH server" is already dangeorous with or without this vulnerability, and with or without agent forwarding. Eg a malicious server can modify the shell to emit VT codes to mess up your terminal. yes, but messing up your terminal is not an RCE (and you should be able to fix it with stty sane). It's just an annoyance and just tipped you off that obviously there's something wrong there. :) Obviously you should be checking your host keys etc and ideally you woud never accidentally connect to a malicious server. However, in the unlucky but perhaps inevitable event that you do connect to a malicious server, you shouldn't risk exposing your entire client workstation! (through this or another RCE) or your SSH private keys! (through normal agent forwarding operation) with agent forwarding. > Sure, but this creates additional identities that baz.example.org must be taught to trust, which is not always desirable or even an option. A key is not necessarily an identity. Most platforms permit more than one public key to be associated with a user, including github, gitlab, userify, etc. However, ideally you are correct -- this would result in a new user account that has limited access to only the things it really needs (principle of least privilege).
- drdaeman 3y ago
  Another relatively popular use case is pam_ssh_agent_auth for passwordless-but-authenticated sudo. This, by definition, requires agent forwarding. (I don't use ssh-agent, I use gpg-agent with an SSH socket - I suppose I'm fine?)
pritambaral 3y ago
There are uses for `-A` that aren't just for jumping into hosts. I work on code in ephemeral containers and need to use git against remote git servers. If I had to use a key local to the container, I'd have to constantly add new keys to my git servers. Of course, I have secured by agent from abuse. I use gpg-agent as my ssh agent and make it visually confirm every use of my private key. I even set up those containers to use forwarded GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL} envs. So other people can work on the same container as me and git commits we make are still attributed correctly.

Arnavion 3y ago

One use of -A, namely using the ssh server as a jumphost, is covered by -J. The general use of -A, namely doing operations on the ssh server that require keys from the ssh client, is not. If I'm on machine foo and I want to connect to bar.example.org and clone a git repo there from baz.example.org, and baz.example.org requires an identity key that is in foo's ssh agent, then -A is the only option.

GauntletWizard 3y ago
ssh-askpass is a great tool in these situations. It intercedes and allows you to manually control all key usage attempts.
- devnullbrain 3y ago
  Ah, a skillful execution of Cunningham's Law
- Arnavion 3y ago
  I'm not sure what relevance ssh-askpass has to what I wrote.
  - GauntletWizard 3y ago
    Right, this recipe isn't well known. `ssh-add -c` will cause your ssh agent to pop up with ssh-askpass every time it does an authentication. This is fiddly; You need to have configured your ssh-agent right, and there's a slightly different version to use keychains on macos that's equivalent.
    - Arnavion 3y ago
      Once again, I'm not sure what relevance this has to the discussion.
      - pritambaral 3y ago
        Some people denounce all use of agent forwarding because, by default, ssh-agent doesn't confirm with the user before signing a request with the users private key. This means, if you ssh into a compromised/malicious host with your agent forwarded, malicious code on that machine can just silently ssh into other servers as you. This trick has been used in the past by blackhats to escalate from a compromised CI environment to full production takeover. GauntletWizard probably meant to respond to your parent in this thread.
gunapologist99 3y ago
No, you might as well copy the keys over there for all the security you're getting (actually, that's safer given this RCE which compromises both sides, even given that there's no real way to shred the leaked key, but of course I'm not actually suggesting this! they're both really bad.) Your best option is too easy: just generate a new keypair on foo. Then you can populate baz.example.org with that public key instead of your own.
- Arnavion 3y ago
  >No, you might as well copy the keys over there Only if the keys are insecure enough to be copied, ie not backed by an HSM, or backed by an HSM but marked exportable. >for all the security you're getting (actually, that's safer given this RCE which compromises both sides, even given that there's no real way to shred the leaked key, but of course I'm not actually suggesting this! they're both really bad.) Connecting to a malicious SSH server is already dangeorous with or without this vulnerability, and with or without agent forwarding. Eg a malicious server can modify the shell to emit VT codes to mess up your terminal. >Your best option is too easy: just generate a new keypair on foo. Sure, but this creates additional identities that baz.example.org must be taught to trust, which is not always desirable or even an option.
  - gunapologist99 3y ago
    > Only if the keys are insecure enough to be copied, ie not backed by an HSM, or backed by an HSM but marked exportable. Agent forwarding forwards the keys insecurely. If you can launch an agent-forwarded connection, then the HSM is already irrelevant. > "Connecting to a malicious SSH server" is already dangeorous with or without this vulnerability, and with or without agent forwarding. Eg a malicious server can modify the shell to emit VT codes to mess up your terminal. yes, but messing up your terminal is not an RCE (and you should be able to fix it with stty sane). It's just an annoyance and just tipped you off that obviously there's something wrong there. :) Obviously you should be checking your host keys etc and ideally you woud never accidentally connect to a malicious server. However, in the unlucky but perhaps inevitable event that you do connect to a malicious server, you shouldn't risk exposing your entire client workstation! (through this or another RCE) or your SSH private keys! (through normal agent forwarding operation) with agent forwarding. > Sure, but this creates additional identities that baz.example.org must be taught to trust, which is not always desirable or even an option. A key is not necessarily an identity. Most platforms permit more than one public key to be associated with a user, including github, gitlab, userify, etc. However, ideally you are correct -- this would result in a new user account that has limited access to only the things it really needs (principle of least privilege).
drdaeman 3y ago
Another relatively popular use case is pam_ssh_agent_auth for passwordless-but-authenticated sudo. This, by definition, requires agent forwarding. (I don't use ssh-agent, I use gpg-agent with an SSH socket - I suppose I'm fine?)

pritambaral 3y ago

There are uses for `-A` that aren't just for jumping into hosts. I work on code in ephemeral containers and need to use git against remote git servers. If I had to use a key local to the container, I'd have to constantly add new keys to my git servers. Of course, I have secured by agent from abuse. I use gpg-agent as my ssh agent and make it visually confirm every use of my private key. I even set up those containers to use forwarded GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL} envs. So other people can work on the same container as me and git commits we make are still attributed correctly.