The downside is that compatibility in edge cases, while much better than I'd expect, is still not perfect. In particular Windows support outside of Putty gets challenging.
I can initiate connections, keylog, request or hide confirmations, steal all your other data, piggyback on your authorized SSH connections, etc.
Not sure about that, but you can configure it so that it asks you for confirmation before every private key usage, so I suspect you could script a solution around that confirmation mechanism?
> Although I guess that wouldn't protect you from the root problem of a vulnerable OpenSSH client.
Yes – in the end, your SSH client, the terminal emulator it's running in etc. are ultimately software too that could be remotely exploited.
I think in this particular case, there was a certain mismatch of threat expectations between the attack surfaces of ssh (the client, exposed to lots of potentially malicious input) and ssh-agent (mostly accepting input from semi-trusted processes on the same host – except for agent forwarding, of course).
How do you manage ssh chaining then? Unique set of keys per user per machine?
Short of scp'ing your private key over from your starting box, I can't really think of another way. Then again, if it's not your box, (you don't own the hardware have sole monopoly of root), you probably shouldn't be ssh'ing from it anyway. I've always held there are no true secrets on a computer... Until multi-billion dollar companies decide to collude anyway.
Anywho, honest question. I'm a big fan of ssh roaming, never realized that ssh-agent was a thing, but after reading this, if I were to use it, I'd most certainly be doing it witout pkcs11 built in. Shotgunning shared libs for side-effects is absolutely mad. Need to slot that into my source code reading list.
ProxyJump in the .ssh/config file. If your SSH is too old to support ProxyJump, you should probably upgrade, but this works as well:
ProxyCommand ssh -q -W %h:%p jumpostEdit: Nevermind, tried it, not sufficient for my use case.
I tend to do a lot of mesh-y bouncing around between servers, and -J seems to be more intended for a star/hub&spoke topology. Common ssh priv-key to all machines, or alternatively, a unique set of priv_keys per user per dest machine is about the way to go. You still have privilege escalations to worry about, but thems the breaks.
It's a neat trick, I'll give it that.
4 server example (this assumes your client can connect to only host C) with the following topology:
C -> B -> A
\-> D
Host A
ProxyJump B
Host B
ProxyJump C
Host D
ProxyJump C
At times, I've wished for something like uMatrix but for ssh-agent forwarding, so I could have policies for which peer-to-peer authentications should be allowed for which keys and whether these specific uses should require interactive confirmation.
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.
`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.
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.
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.
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).
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.
>yes, but messing up your terminal is not an RCE
It has been, and can be again.
https://www.cyberark.com/resources/threat-research-blog/dont...
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.
(I don't use ssh-agent, I use gpg-agent with an SSH socket - I suppose I'm fine?)
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.