Linux – Forwarding access to a subset of ssh-agent identitites

linuxSecurityssh

I work for two companies (let's call them RedCorp and BlueCorp). They both trust me but they don't trust each other, and I don't want to expose either's secrets to the other.

My laptop's ssh-agent has two private keys, one for access to each company. I can run:

ssh -A redcorp-server1

and access all of redcorp's other servers from there, by virtue of my forwarded agent connection.

Likewise, I can run:

ssh -A bluecorp-server1

and access all of bluecorp's other servers from there.

The problem is that whenever I'm logged into redcorp-server1, the root user there can set his $SSH_AUTH_SOCK to point at my forwarded agent connection, and abuse my other identity to break into BlueCorp.

How can I prevent that?

ssh's IdentitiesOnly option doesn't do what I want. That only controls which key I offer when authenticating to redcorp-server1; it doesn't change the fact that my forwarded agent connection allows an ssh process on redcorp-server1 to authenticate using any of my identities.

The only solution I've found is to run two separate ssh-agents, and only load one key into each of them. That's a huge pain though: There's no way for an ssh_config stanza to specify which of my agents I should use when connecting to a given host. Instead I've had to make shell aliases on my laptop for each of the two corps which point $SSH_AUTH_SOCK to the right agent before running ssh. Also, I use rsync and a dozen other tools which use ssh as a transport, and each of them has to be configured using a different syntax to make it invoke ssh in this special way.

Is there a better way to do this?

Best Answer

I implemented an ssh-agent-filter for myself, use it with:

$ afssh -c id_bluecorp -- server1.bluecorp.com
$ afssh -c id_bluecorp -- server2.bluecorp.com
$ afssh -c id_redcorp -- server42.redcorp.com

It's already in Debian (and Ubuntu).

Related Solutions

Ssh-agent forwarding and sudo to another user

As you mentioned, the environment variables are removed by sudo, for security reasons.

But fortunately sudo is quite configurable: you can tell it precisely which environment variables you want to keep thanks to the env_keep configuration option in /etc/sudoers.

For agent forwarding, you need to keep the SSH_AUTH_SOCK environment variable. To do so, simply edit your /etc/sudoers configuration file (always using visudo) and set the env_keep option to the appropriate users. If you want this option to be set for all users, use the Defaults line like this:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers for more details.

You should now be able to do something like this (provided user1's public key is present in ~/.ssh/authorized_keys in user1@serverA and user2@serverB, and serverA's /etc/sudoers file is setup as indicated above):

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

Ssh auto-forward

Is the real requirement here that Bob needs ssh access to machine2 but can't get at it directly because it's behind a firewall? If so, the cleanest solution is probably to port-forward a port on server1 to the ssh port (22) on server2, which you can do with iptables, see http://www.debian-administration.org/articles/73. Then the user can

ssh -p <port number> server1

to get into server2.

If you really want to force people logging in to server1 to go straight to server2 it might be possible to set the relevant user's shell on server1 to a script which runs "ssh server2" however the user will end up having to type a password twice (if you're using paswords) - once for server1 and again for server2 - and you'd also need to be careful to lock down the SSH server on server1 to prevent the user doing port forwarding etc through it (which you can do with SSH access regardless of what your shell is set to).

Best Answer

Related Solutions

Ssh-agent forwarding and sudo to another user

Ssh auto-forward

Related Topic