Hacker News Reader

Comment by tptacek | Hacker News Reader

The agent process is tricky to set up and persnickety, especially if you use the token for anything else besides SSH. At one point, before I tableflipped and switched back to software keys, I had to switch agent processes any time I used my Y4 to sign into a VPN.

The theater is that you're protecting a key but not the account the key protects. Yes, you'll never lose the actual RSA key bits to an attacker. But that'll be cold comfort after an attacker uses a hijacked SSH process to compromise every account you log into.

There's some value to the Y4 SSH key, don't get me wrong. It's just much less value than you'd expect from all the ceremony.

View on HN

I switched my SSH keys on my Yubikey from using the OpenPGP applet and all the funkiness of gpg-agent over to using X.509 certificates with the PIV applet.

Added bonus is that not only does it work with SSH, but you can use those certificates for TLS mutual authentication in web browsers. Works out of the box on Mac/Windows.

Can you provide a link or reference to this path? I can't find much with basic searches and have given up several times on the gpg-connect-agent path while using Windows or Ubuntu. The path on Mac seems okay but on other platforms is way too difficult.

>Yes, you'll never lose the actual RSA key bits to an attacker. But that'll be cold comfort after an attacker uses a hijacked SSH process to compromise every account you log into.

But if you enable (and require) the touch feature, it'll be pretty obvious if someone's trying to use your agent to authenticate somewhere else, no? I'd certainly notice if I had to press the button twice while I'm logging into a machine that should only request auth once (i.e. I'm not proxying through another box).

They don't have to use your agent to authenticate again. They just feed commands to your SSH client binary that it then sends over the wire in your existing SSH session-context, with the SSH pty temporarily set to not echo input and discard output (or return it over the network to the attacker, but not render it in the local PTY character-buffer.) A hijacked SSH binary can even detect an elevation-requiring command you provided in the terminal and wrap it in a "sudo -c" along with a payload, such that the whole thing happens as one elevated "transaction", only hitting your agent once.

Happily, this won't work if you only ever use SSH with a non-shell command, e.g. as a fancy encrypted netcat(1).

Right, and that's still a problem, but not as much of a problem as if they were able to then use your key to authenticate to every other machine you have access to. The problem is at least contained to a single system at a time.

FWIW, I never had that issue with my NEO on OSX/macOS. I was using my NEO for git signing, SSH, as well as U2F.

tptacek's VPN probably uses PIV applet instead of GPG one and you can't switch them easily (requires stopping and starting agents). If you stay in GPG+U2F land then you don't have these problems.

totally agreed on agent. also on provisioning the keys. my windows users eyes, even the more technical of the bunch, glaze over when teaching intro to your yubi key

Reply on news.ycombinator.com