warpgate icon indicating copy to clipboard operation
warpgate copied to clipboard

Support ssh-agent forwared keys for connection

Open notnooblord opened this issue 3 years ago • 12 comments

Awesome work so far @Eugeny! Currently trying to implement warpgate bastion in our org. Been great!

I'm concerned with two things actually:

  • to use warpgate everywhere, we would have to drop warpgate public key to each user .authorized_keys file, a bit of administrative burden (can be automated)
  • warpgate key or server instance gets hacked (somehow) person holding the keys would be able to ssh everywhere bastion can (can be mitigated by ip address limiting, but wont do much if bastion is compromised).

Both can be mitigated if warpgate can support ssh-forwarded keys. So keys for accessing aren't stored on bastion. Than user can do ssh -A user:host@wg and warpgate will use forwarded key to access destination host.

Would such a thing be possible in future?

notnooblord avatar Jul 11 '22 06:07 notnooblord

I'm considering this, although this means a lot of extra work - instead of having to deploy .authorized_keys once as usual, you now also need to manage an N^2 set of user/server keys. In any case, #11 will have to be done first since agent forwarding relies on these.

Eugeny avatar Jul 11 '22 09:07 Eugeny

a lot of extra work

Not looks like "a lot" of work. Just make ansible/salt/puppet to deploy .ssh/authorized across all hosts (including bastion host), then deny non-bastion ssh to protected host (firewall, hosts.allow, sshd_config, whatever)

User should run 'ssh user@bastion" and "ssh user@protected_host" from bastion (most clients allows transparent "ssh-via-ssh" via .ssh/config) - and that's it, we don't need "bastion super key" anymore.

inkvizitor68sl avatar Sep 12 '22 12:09 inkvizitor68sl

I kinda wish in new UI there would be something like this :)

image

With forwarded keys not only can those keys be used for auth, but actually this allows bastion host usage as jump-host, it would be really nice feature.

notnooblord avatar Sep 16 '22 00:09 notnooblord

@Eugeny hi! Any update on supporting this feature?

I see that tcp forwarding already been implemented in russh, but I think (could be wrong here) we still need to learn how to talk to ssh agent?

// Maybe possible for me to work on supporting this but don't know where to start :(.

notnooblord avatar Dec 09 '22 16:12 notnooblord

Not yet - I've added support for agent channels in https://github.com/warp-tech/russh/pull/48, but to couple it with existing agent protocol implementation that russh inherited from thrussh, it needs a bridge between channels and AsyncRead/AsyncWrite traits (also implemented in that PRs).

That latter work was done to implement the SFTP protocol (see https://github.com/warp-tech/russh/issues/89#issuecomment-1342885587), but it should also work for the agent protocol.

If you've got time for it, you can just give it a quick test and see if you're able to e.g. communicate through a forwarded agent channel from a russh server

Eugeny avatar Dec 09 '22 17:12 Eugeny

Has there been any update on this? I am currently working on a setup where the ability for people to identify themselves using their personal keys instead of the warpgate one would be really useful. I've looked through the (seemingly very out of date) roadmap and could also not find anything similar in the other issues.

This project so far seems really nice and quite promising so I would be sad to have to give this up for a different solution.

technologicalMayhem avatar Nov 15 '23 22:11 technologicalMayhem

Unfortunately didn’t have time to took on issue myself yet :(, but still very much needed.

In my case we have our self-built auth system for distribution of user ssh keys to hosts, we need to forward them instead of using warpgate sort of “master-key”.

Currently working around that using sshd_config shenanigans that allows warpgate key for every user, but is for sure less secure than forwarding.

@Eugeny just a question on current status, Is agent forwarding now completely supported in russh project?

notnooblord avatar Nov 16 '23 10:11 notnooblord

@notnooblord russh includes complete support for agent forwarding channels (call Session::agent_forward and russh will call Handler::server_channel_open_agent_forward for new channels), but connecting these channels to a specific agent is up to the user. For OpenSSH agent, it's pretty much just straightforward piping into the SSH_AUTH_SOCK socket

Eugeny avatar Nov 16 '23 10:11 Eugeny

AsyncRead/AsyncWrite bridging is already implemented in Channel::into_stream() too

Eugeny avatar Nov 16 '23 10:11 Eugeny

First, thank you for your work on this project!

I've been trying to use russh to implement a very simple SSH client with support for agent forwarding, but I'm struggling to access the agent forwarding channel. I'm also new to Rust, so that might be contributing to my difficulty.

When client::Handler::server_channel_open_agent_forward() is called, it receives ChannelId(3) and russh::client::Session. Later, if I execute ssh-add -l on the server, I can see the incoming data packet in client::Handler::data() and even pipe it to the local SSH_AUTH_SOCK to get a response from the local agent. However, I'm unsure how to send data back to the server. Any high-level guidance would be highly appreciated.

z-image avatar Jan 31 '24 20:01 z-image

@z-image once you have the ChannelId for the agent channel, you can use Handle::data to send responses on that channel.

This is currently the only method of working with agent channels as I haven't migrated the agent channel methods to use Channel<Msg> in russh::client yet

Eugeny avatar Jan 31 '24 20:01 Eugeny

But in general, you're on the right track - just pipe the data back and forth between the channel and the agent socket.

Eugeny avatar Jan 31 '24 20:01 Eugeny