You need to fully trust your target server, so you need to manage your known_hosts diligently and make sure you trust the host you connect to. If you just accept the host key without checking, you allow any host to use your SSH key for authentication. Any SSH server can accept your private key as authentication. Also, if the target host is infiltrated, it can use your private SSH key for authentication elsewhere without your knowledge.
Explanation: IF you use SSH agent and have ssh options set up, you get a channel thru SSH where you could use your SSH agent on remote host.
Good side: You can then chain authenticate and say use same SSH agent to authorize sudo, hence getting sudo without password, just secured with your private key. Add hardware token to store said key and you're pretty secure.
Bad side: .... so can any other process with right permissions on the system, therefore compromised system can try to impersonate you.
One way to mitigate is is to make sure servers can't talk to eachother to via SSH, if user can access A and B but A can't access B and vice versa the escalation is limited.
Other way is to set agent to ask every time something wants to use the key which half-solves it (attacker would need to time the attack to occur right before "valid" use") but from what I remember it still doesn't show you what is trying to use your key (at least for gpg-agent's ssh agent functionality) so it's kinda not that useful of a feature.
The point of ssh-agent is to use the private key to authenticate yourself.
If you forward it to a remote host, you are granting access to the remote to do that (i.e., the remote can authenticate as you), thus, you must trust the remote.
From the docs,
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to
authenticate using the identities loaded into the agent. A safer alternative may be to use a jump host (see -J).
You need -A if you're running ssh on the intermediate host, i.e., on the jump host in this case. But -J doesn't run ssh on the intermediate host, it more or less runs two ssh's on your local host. The first from local to the jump, the second from local to the eventual target, through a tunnel forwarding the connecting through the jump[1]. But because all the SSH processing is always local, it always has access to the local ssh-agent: you don't need -A.
And, as someone points out upthread, you need to fully trust the remote machine to pass -A. You usually shouldn't, in most cases that I think people using jump hosts in corporate settings would be interacting with jump hosts: it permits other employees to impersonate you, by abusing your forwarded ssh-agent, if they have sufficient access on the jump host.
Comments
You need to fully trust your target server, so you need to manage your known_hosts diligently and make sure you trust the host you connect to. If you just accept the host key without checking, you allow any host to use your SSH key for authentication. Any SSH server can accept your private key as authentication. Also, if the target host is infiltrated, it can use your private SSH key for authentication elsewhere without your knowledge.
Also, if the target host is infiltrated, it can use your private SSH key for authentication elsewhere without your knowledge.
Not normally, right? Isn't that the whole point of public-key cryptography?
See e.g. https://www.theregister.com/2016/01/14/openssh_is_wide_open_... for when a vulnerability in the openssh client made this possible back in 2016.
Explanation: IF you use SSH agent and have ssh options set up, you get a channel thru SSH where you could use your SSH agent on remote host.
Good side: You can then chain authenticate and say use same SSH agent to authorize sudo, hence getting sudo without password, just secured with your private key. Add hardware token to store said key and you're pretty secure.
Bad side: .... so can any other process with right permissions on the system, therefore compromised system can try to impersonate you.
One way to mitigate is is to make sure servers can't talk to eachother to via SSH, if user can access A and B but A can't access B and vice versa the escalation is limited.
Other way is to set agent to ask every time something wants to use the key which half-solves it (attacker would need to time the attack to occur right before "valid" use") but from what I remember it still doesn't show you what is trying to use your key (at least for gpg-agent's ssh agent functionality) so it's kinda not that useful of a feature.
Ah, thanks. Missed the agent context.
The point of ssh-agent is to use the private key to authenticate yourself.
If you forward it to a remote host, you are granting access to the remote to do that (i.e., the remote can authenticate as you), thus, you must trust the remote.
From the docs,
If I'm getting host changed violations and I know the infra's not changed, I know there's somethng wrong already? I'm not getting what this provides.
Why even use -A? Isn't -J enough?
Well if you want to pass your keys to the endpoint without keeping them on the jump hosts, yea, it's kinda useful.
You don't need -A with -J.
You need -A if you're running ssh on the intermediate host, i.e., on the jump host in this case. But -J doesn't run ssh on the intermediate host, it more or less runs two ssh's on your local host. The first from local to the jump, the second from local to the eventual target, through a tunnel forwarding the connecting through the jump[1]. But because all the SSH processing is always local, it always has access to the local ssh-agent: you don't need -A.
And, as someone points out upthread, you need to fully trust the remote machine to pass -A. You usually shouldn't, in most cases that I think people using jump hosts in corporate settings would be interacting with jump hosts: it permits other employees to impersonate you, by abusing your forwarded ssh-agent, if they have sufficient access on the jump host.
[1]: -J in ssh(1) documents this
til, cheers :)