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.
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.
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.
> 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).
>Agent forwarding forwards the keys insecurely. If you can launch an agent-forwarded connection, then the HSM is already irrelevant.
No? ssh-agent works fine with keys that are not exportable from the HSM. By the very definition it's not possible for anything to export the key, ssh-agent or otherwise.
As the article describes most Windows terminal emulators just call SetWindowText when they get the set window title escape code. For some reason Windows implements that function very inefficiently so if it ends up being called in a tight loop your computer can freeze.
>I was searching for a bug in ANSI characters that respond to a change of the window’s title. One of the things I did was check how the previous bugs were exploited. One of them, CVE-2015-8971 (found by Nicolas Braud-Santoni), was a bug in Terminology 0.7.0 that didn’t filter new line (\n) escape character when changing the window title. It allowed you to modify the window title and then re-insert it into the terminal’s input buffer, resulting in arbitrary terminal input, which then caused code execution.
That's a vulnerability in your terminal app, not in SSH, like a browser vuln when connecting to a remote website, but you're right, the point is well taken: there is always that possibility and you should be quite careful about choosing your terminal application.
`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.
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.
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.