Hacker News Reader

Comment by pritambaral | Hacker News Reader

Does it work with the `ssh(1)` client? I'd be okay with using this as long as it replaced _only_ the network-connectivity and authentication parts. I do use many of the other features made possible by SSH:

1. Network forwarding (local-to-remote, remote-to-local, dynamic, and unix socket support). The link you supplied mentions only local-to-remote.

2. Agent-forwarding (don't worry, I have confirmation-on-every-use, see my other comment: https://news.ycombinator.com/item?id=22753590). This I use all the time to be able to authenticate to other SSH servers and git hosts. This is a must-have for me now for remote development and pair-programming.

3. sshfs, sftp, and rsync. Again, absolute beauties at the job of managing files remotely.

This is just off the top of my head, because I use these features day-to-day, but there's many other nice things ssh does that have nothing to do with the underlying connection or authentication method.

View on HN

Agent forwarding is powerful but dangerous. Prefer ProxyJump where applicable.

With Agent forwarding any authorised machine you connect to (and thus anyone who controls that machine) gets to use your credentials for the duration, to my knowledge no general purpose clients give you feedback on this usage, so you won't know if this happened - if Agent forwarding is enabled it can be used even if you never use it. With ProxyJump the intermediate doesn't get any view of your credentials, not even whether those are the same credentials you used for that intermediate host, or different. It is only enabling you to connect to a host it can reach that you can't reach directly and nothing more.

Indeed, my first thought when I read “agent-forwarding” is “scary”.

My agent asks for confirmation on every use. No need to be scared. See my other comment for more details: https://news.ycombinator.com/item?id=22753590

> ... to my knowledge no general purpose clients give you feedback on this usage, so you won't know if this happened

I'm afraid you're mistaken here.

ssh-add(1) and ssh-askpass(1) support confirmation per-use: https://man.openbsd.org/ssh-add.1#c

The agent I personally use — gpg-agent — also respects this protocol and asks me to confirm each use: https://www.gnupg.org/documentation/manuals/gnupg/Agent-Conf...

Even if it did not, I can always configure gpg-agent to never cache the passphrase, thus making it ask me for the passphrase every time. This would also adequately serve as a means of confirmation, but thankfully this tedious option is not necessary, because of the above.

> Prefer ProxyJump where applicable.

I already do, but it's pretty orthogonal to agent-forwarding. The uses of agent-forwarding I mention in my original comment simply cannot be served by ProxyJump.

Today I Learned. Seems like a key component (AddKeysToAgent Confirm) was in OpenSSH 7.2 in 2016, but I felt like I checked this wasn't an option more recently. Happy to be proven wrong, thank you.

The way this works is that the SSM module just implements a general-purpose TCP tunnel. The interactive session with ssm start-session --target is a specialization of that, as is the ssh-over-ssm functionality. If you marshal the CLI tool or libraries correctly, you can tunnel anything. If at all, you can ssh over ssm and then use the native SSH port forwarding/proxying capabilities to get the rest of your tools to work.

Yes, using a ProxyCommand in the ssh configuration allows using the SSH client to connect over SSM. In that case - you do need an SSH keypair in addition to the IAM authentication. No need to expose the management interface to the internet.

Reply on news.ycombinator.com