guardian-agent

I agree this seems to be the currently in vogue practice, but I am confused by it! SSH keys are public-private key pairs, where the private portion can live in a hardware token or software agent that only signs individual challenges and never exposes the private key. (It's possible in theory, although admittedly not common, for the user agent to limit approvals to a particular repository using the techniques in https://github.com/StanfordSNR/guardian-agent . It would be nicer if GitHub would enforce granular permissions on SSH keys!) If I understand right, HTTP access tokens are... bearer tokens where I have to handle the plaintext (so I can transmit it to GitHub) every time I want to use it? I agree it's nice to have GitHub enforcing more granular permissions, but even so the trade really doesn't seem worth it. I may not be getting somet

There is a tool that implements this: 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 forwarded the challenge and is asking to authenticate to the remote server?" (although this one you can approximate today by running lots of agents and giving each local ssh command a different agent to forward requests to). Guardian

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 [2] https://github.com/gnyman/mosh/actions/runs/1068715035

Re: Unicode, please see https://news.ycombinator.com/item?id=28151652. (Mosh really just uses your C library for knowing the width of characters -- if the server's and client's libc support a character, Mosh will too. Unfortunately Apple in particular has historically been not super-great about keeping theirs up-to-date once Unicode went to an annual release cycle. screen and tmux have similar issues and basically ship their own Unicode tables, which has its own problems.) For ssh-agent forwarding, most people are using https://github.com/StanfordSNR/guardian-agent which is more secure than traditional agent forwarding, and works with SSH or Mosh.

Thanks for this. Wanted to put in a pitch for Dima Kogan's more-secure way of doing ssh-agent forwarding: https://github.com/StanfordSNR/guardian-agent It works with SSH and Mosh. The basic idea is that before agreeing to a request, the principal or their agent should know (a) what machine is asking, (b) what remote machine they want to connect to, and (c) what command line they want to run on the principal's behalf. And the principal's authorization should then be limited to that context. The ssh-agent protocol doesn't give the agent any of that information; it's really just intended for local SSH-like processes to ask "please sign this blob so I can connect somewhere" without them having to see the plaintext private key. Forwarding that to untrusted remote machines isn't ideal. It turns out an agent can get access to this information an