(Disclaimer: I work for AWS, but opinions are my own and not necessarily those of my employer.)
(Disclaimer: I work for AWS, but opinions are my own and not necessarily those of my employer.)
1. Network forwarding (local-to-remote, remote-to-local, dynamic, and unix socket support). The link you supplied mentions only local-to-remote.
2. Agent-forwarding (don't worry, I have confirmation-on-every-use, see my other comment: https://news.ycombinator.com/item?id=22753590). This I use all the time to be able to authenticate to other SSH servers and git hosts. This is a must-have for me now for remote development and pair-programming.
3. sshfs, sftp, and rsync. Again, absolute beauties at the job of managing files remotely.
This is just off the top of my head, because I use these features day-to-day, but there's many other nice things ssh does that have nothing to do with the underlying connection or authentication method.
With Agent forwarding any authorised machine you connect to (and thus anyone who controls that machine) gets to use your credentials for the duration, to my knowledge no general purpose clients give you feedback on this usage, so you won't know if this happened - if Agent forwarding is enabled it can be used even if you never use it. With ProxyJump the intermediate doesn't get any view of your credentials, not even whether those are the same credentials you used for that intermediate host, or different. It is only enabling you to connect to a host it can reach that you can't reach directly and nothing more.
I'm afraid you're mistaken here.
ssh-add(1) and ssh-askpass(1) support confirmation per-use: https://man.openbsd.org/ssh-add.1#c
The agent I personally use — gpg-agent — also respects this protocol and asks me to confirm each use: https://www.gnupg.org/documentation/manuals/gnupg/Agent-Conf...
Even if it did not, I can always configure gpg-agent to never cache the passphrase, thus making it ask me for the passphrase every time. This would also adequately serve as a means of confirmation, but thankfully this tedious option is not necessary, because of the above.
> Prefer ProxyJump where applicable.
I already do, but it's pretty orthogonal to agent-forwarding. The uses of agent-forwarding I mention in my original comment simply cannot be served by ProxyJump.