guardian-agent VS ssh-agent

https://github.com/StanfordSNR/guardian-agent

The problem basically is the current agent forwarding protocol doesn't have a way to reliably identify the source and remote host that can't be spoofed. guardian-agent tries to do that using some extra software, this linked SSH proposal is to add that to SSH but it will require software upgrades even to the sshd of the intermediate and remote hosts - it's not ideal that it can't just work out of the box - but I welcome this we just need to get it done now for later.

I frequently finding myself thinking about adding useful things to software I want to use now and go well it will be years before its on every host I use and can be used reliably. I have had this thought on and off for more than a decade. Ship some new stuff, it'l be great later :D

ObPlug for Guardian Agent, which is basically "safe" ssh-agent forwarding (and works with Mosh and SSH): https://github.com/StanfordSNR/guardian-agent

The basic story is that ssh-agent really just exposes a primitive of "please sign this challenge," which is useful locally, but the protocol wasn't designed to be forwarded. If requests are coming from a semi-trusted intermediary host, the protocol doesn't tell the agent (a) what remote server is being authenticated to [i.e., who generated the challenge?], or (b) what command is going to be executed. It doesn't even really know (c) what (semi-trusted) host has forwarded the challenge?

Guardian Agent is a sort of hack that allows the agent to know (a), (b), and (c) before deciding whether to grant or deny the request, and you can set up policies like, "I'd like to allow `jump host x` to use to run "git pull" when talking to `git server y`, but that's it." The basic ssh-agent protocol just doesn't have enough info to be able to do something like that.

there is a fork with port forwarding support https://github.com/rinne/mosh and a PR with a long discussion https://github.com/mobile-shell/mosh/pull/696 on why it's not merged

you can compile them yourself or if you want to skip the step I recently set up GitHub actions to compile linux binaries of this [1][2], tested by a sample of 1 so no guarantees it works, was planning on doing a tap PR/tap of it at some point

also the official developers have been involved a project to solve this while improving the whole-agent approval things also https://github.com/StanfordSNR/guardian-agent , but I couldn't get it to work which is why I tried the fork and got that working

[1] https://github.com/gnyman/mosh/actions/runs/1068715036

‘mosh’ is amazing for this, although I had to stop using it years ago because it didn’t support key forwarding. Apparently, there’s now a solution for that: https://github.com/StanfordSNR/guardian-agent

Once the image has been built and pushed, you only need to trigger the deployment using Kamal. We use the webfactory/ssh-agent to establish a connection to our production server. After installing the required Ruby dependencies, it’s only a matter of running Kamal. As the image is already built and pushed, we use the --skip-push flag.

When using Github Actions, to build projects I have been using the ssh-agent approach (https://github.com/webfactory/ssh-agent), with this means the Cargo.toml looks like this:

Thankfully when I reached out on Twitter, Jonathan Carter on the Codespaces team, seemed to suggest they may be working on a native SSH integration one day. Till then, here is the solution I came up with. This process address some sequencing issues around devcontainer.json's Lifecycle Scripts and when your Dotfiles are installed. Credit to VS Codes Using SSH Keys guide. Also, some things here are pulled directly from the GitHub Action to setup SSH. Again, thanks to Johnathan Carter for the ideas.