3 ms·

> the YK Neo and 4, which have been out for years, were already so good I agree that the keys themselves are good; I just wish that configuring Linux systems t

• xienze 8y ago
  >For example, when I'm in my laptop and I ssh to my desktop and use sudo, I want it to use the key connected to the laptop to authenticate me. At the same time, if I walk over to the desktop and use sudo, I want it to seek the key in the desktop. Same if I use gpg or anything else that wants to use the key. This can easily be done, I do it all the time. You have to set up both YKs to have the same PGP keys and then use gpg as your SSH agent.
  • jolmg 8y ago
    That would be enough, if I would compromise to forego use of sudo and relogin with ssh as root. I really would preper to keep the ability to only sudo the parts of composed commands that need it in my non-root shell session, though, which is why I'm still looking into this. This effort will also allow me to use gpg and the programs that depend on it like my password manager, pass, to use the correct agent.
• lvh 8y ago
  Do you care if the auth is GPG or U2F? Seems like you want -L to forward a socket, and GPG_AGENT_INFO to point to it. I tweeted this series a while ago because it’s hard to find how that works: https://twitter.com/lvh/status/966408198558244864?s=21 https://twitter.com/lvh/status/966408198558244864?s=21
  • jolmg 8y ago
    Not U2F because it requires the systems to always have an internet connection. I could setup an authentication server on each machine to avoid that, but I think that would make replay attacks possible (nevermind, see EDIT). Also, since GPG is an option for this, it means that I can just depend on that for absolutely everything. If I break the key in two, I can use an encrypted backup of the GPG key to keep working (authenticating, decrypting, and signing) until I get a new yubikey and write the backup to it. It's an -R forwarding what I want. -L would require the host I'm logging into to automatically login back to the host I'm at. That's something that raises way to many convoluted issues. By using -R and ControlMaster, and overriding ssh with one that sets up the forwarding first if the corresponding control socket does not exist, I can share the forwarding among all the ssh terminals I've opened to the same host. I saw GPG_AGENT_INFO on the manpage, but it says that it's an obsolete environment variable that's now ignored. In my system, gpg2 is a symlink to gpg. I wondered if maybe gpg decided to ignore or use GPG_AGENT_INFO depending on $0, but from grepping the source I don't think it does. It only appears on documentation and automated tests. Still, it might be a good starting point to check the source of gpg 1.4 to get an idea of how to patch gpg2 to get the agent path from an environment variable. Thanks for the help. EDIT: I made the U2F comment assuming that it works like OTP, but there is some material online referring to it as a protocol using a challenge-response mechanism. If that's the case, what I said would be false. Still, I feel I'm close to an ideal with GPG, so I'm not sure there would be something to gain by using U2F. Unfortunately, most of the material online about it is about using it to login to specific web services like Google. EDIT 2: I was taking a quick look at pam-u2f[1], and I found this piece interesting: > manual: Set to drop to a manual console where challenges are printed on screen and response read from standard input. Useful for debugging and SSH sessions without U2F-support from the SSH client/server. If enabled, interactive mode becomes redundant and has no effect. I imagine this is in consideration with U2F keys that come with a keypad. Otherwise, terminal emulators would have to be extended to support an escape sequence with which it could recognize when a challenge has been presented to automatically pass it on to the key connected. EDIT 3: Extending my terminal emulator like that and using pam-u2f (after extending it to use that escape sequence) would eventually lead to solving the problem of using sudo remotely. However, going the route of forwarding my gpg-agent also allows me to use gpg (and dependents like pass) remotely. It also seems relatively easier since the only step left for me to figure out is how to get gpg to accept the agent socket path via environment variable. EDIT 4: On "U2F-support from the SSH client/server", I don't suppose adding an authentication method like that would work when chaining ssh interactively (calling ssh to another machine from a ssh session), like how you can forward ssh agents with -A. I wonder if it's possible to add U2F support to ssh agents. I imagine the agent works on a challenge-response mechanism too, in a sense. Maybe the agent can be made to work like a proxy to the key. That way, -A can be made to work to forward authentication to the key. [1] https://developers.yubico.com/pam-u2f/ https://developers.yubico.com/pam-u2f/