Support ssh-agent forwared keys for connection

[notnooblord]

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?

[Eugeny]

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.

[inkvizitor68sl]

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.

[notnooblord]

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

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]

@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 :(.

[Eugeny]

Not yet - I've added support for agent channels in Eugeny/russh#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 Eugeny/russh#89 (comment)), 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

[technologicalMayhem]

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.

[notnooblord]

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?

[Eugeny]

@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]

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

[z-image]

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.

[Eugeny]

@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]

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

[technologicalMayhem]

Has there been any progress on this since? Going by what @z-image wrote it seems like this is possible to implement without much difficulty?

I would love to be able to assist in getting this to work, but I must admit that I am completely lost on how to actually accomplish this. I don't really understand the structure of this project or the ssh protocol.

[z-image]

Has there been any progress on this since? Going by what @z-image wrote it seems like this is possible to implement without much difficulty?

You can see usage here: https://github.com/z-image/mpssh-rstp/blob/5cf371c3da838cff33370c88eca05906f9a5956c/src/ssh.rs#L220

The data() callback. I don't know if this is the best way to do it, but it works for me.

[samtoxie]

@Eugeny Is there a way I can help get this implemented in warpgate? I've been trying to wrap my head around russh/warpgate, but I'm kinda lost on how to proxy the agent from the ssh server to the ssh client.

I think this would be a major +1 to the featureset of warpgate, as then admins can allow users to use their own SSH keys to for example pull a git repo on a remote server behind warpgate.

--edit--
I realise that the original topic is a bit different from what I had in my head when I wrote this comment. What I mean is a scenario where Warpgate still uses the original masterkeys like it does right now, but also allows the user to forward their local SSH agent to the target server. So that would mean warpgate underwater proxies the agent channel from the user to the target server.

[Eugeny]

I haven't had a chance to look at this yet, so if you want to give it a try, go for it!

You can use this PR that adds support for remote unix socket forwarding as a base: 14e3f9d

Agent forwarding is technically the exact same thing as this (streamlocal-forward) and remote port forwarding (tcpip-forward), except the client doesn't need to tell the server where to place the socket.
So all Warpgate has to do is just pipe agent forwarding request from the client to server, pipe agent channel open requests from server to client and handle channel data flow (which it already does)

[Eugeny]

That commit also contains a bit of traffic recorder rework which is not relevant here, the main parts are:

• 14e3f9d#diff-4dfbefe92e40f194d71290c81c68d345c626e18eaba57269aaa1dd51623b18f0R151
• 14e3f9d
• 14e3f9d#diff-caa546540bb1c0c9303c07a3818c0fc0de464a4db3890f481485db634aa5dd5eR663
• 14e3f9d#diff-01fca278b9a270bc99a751691cbff8abdeec8ea0b8e2a007e585ceaea4f1af91R483
• 14e3f9d#diff-98b84a019f8564dd8369ac37fa16dcf5005d45ee4395d1b56b979eaf0e618875R840
• 14e3f9d#diff-98b84a019f8564dd8369ac37fa16dcf5005d45ee4395d1b56b979eaf0e618875R1234

Agent forwarding is also a bit simpler in the sense that there can be only a single agent forward request per shell channel, and it always happens before the shell is requested.

[samtoxie]

Cool thanks! Very helpful indeed, I'm gonna take a look and see if I can get it working.

[Eugeny]

Appreciate it 🎉

[samtoxie]

I've implemented it in the following PR: #1249 works like a charm for me. Thanks again!