It's useful in a corporate environment where you have tens to hundreds of machines you need to use, and all of them are trusted.
EDIT: "a really dangerous feature" is accurate though. For example if all of the staff have root access on a staging machine, then anybody can steal the ssh-agent of another user on the staging machine, and use it to login as that user on production machines.
It'd be kinda nice if you could wrap it with some minimal level of protection through SELinux or something. Still wouldn't be as secure as switching it off, but at least a malicious insider would have to jump through a couple of hoops to get there.
In such an environment you should be using Kerberos. Then you won't need agent forwarding, and you can maintain security.
I would argue that in such an environment you really should be using LDAP+Kerberos, but if you think LDAP is too much effort (it really isn't), plain Kerberos is comparatively trivial to administer, and adding Kerberos (unlike LDAP) doesn't really require any significant changes to your environment.
Just use kerberos. You don't need LDAP to use Kerberos (although you probably should be using LDAP too). Kerberos without LDAP is trivial to set-up and administer, and it's very non-invasive, so you don't need to do any significant changes to your organization.
ssh'ing through the jumphost when the VPN on it wasn't working properly was a use-case for me. Agent forwarding is fine, as long as you use it judiciously.
Comments
Why would you need agent forwarding? It's a really dangerous feature.
It's useful in a corporate environment where you have tens to hundreds of machines you need to use, and all of them are trusted.
EDIT: "a really dangerous feature" is accurate though. For example if all of the staff have root access on a staging machine, then anybody can steal the ssh-agent of another user on the staging machine, and use it to login as that user on production machines.
A better way of solving it is to resolve the issue i raised: https://github.com/mobile-shell/mosh/issues/285
It'd be kinda nice if you could wrap it with some minimal level of protection through SELinux or something. Still wouldn't be as secure as switching it off, but at least a malicious insider would have to jump through a couple of hoops to get there.
In my opinion, it's much safer to do one of two things - use `-oProxyCommand=ssh <gateway> nc %h %p`, or set up different keys on the gateway host.
You risk the security of your SSH key when you use -A.
Yeah, that is what my response above points to.
In such an environment you should be using Kerberos. Then you won't need agent forwarding, and you can maintain security.
I would argue that in such an environment you really should be using LDAP+Kerberos, but if you think LDAP is too much effort (it really isn't), plain Kerberos is comparatively trivial to administer, and adding Kerberos (unlike LDAP) doesn't really require any significant changes to your environment.
Why is Kerberos ticket forwarding better than agent forwarding? Either way, root (or a bad .bashrc) can use your credentials while you're logged in.
Sorry. You are absolutely right. Long day...
I disable Kerberos ticket forwarding here, for this exact same reason. But then you don't have ticket forwarding! I don't know what I was thinking.
How does LDAP solve the problem?
We use LDAP to manage public keys for each user, but they still need to supply a private key at some point.
I was talking about Kerberos, not LDAP. However, that's still not right, see parallel comment.
Extraordinarily useful on an internal corporate network, especially when you're scp'ing remote->remote and so on.
Just use kerberos. You don't need LDAP to use Kerberos (although you probably should be using LDAP too). Kerberos without LDAP is trivial to set-up and administer, and it's very non-invasive, so you don't need to do any significant changes to your organization.
ssh'ing through the jumphost when the VPN on it wasn't working properly was a use-case for me. Agent forwarding is fine, as long as you use it judiciously.