What's the fastest way to get the SSH keys on my Nitrokey Pro recognized on a foreign computer?

Okay, so I have a Nitrokey Pro, and one of my primary uses for it is as a SSH key provider. I am around a lot of computers that I occasionally need to SSH into remote servers from, and instead of generating SSH keys for every single one of them, I like the idea of just pluggin my Nitrokey Pro in, and immediately having the correct SSH keys (based on the OpenPGP key on there).

I have already generated the SSH key, and have succesfully managed to get the above to work on an office PC running Arch Linux. However, I cannot for the life of me get it to work on, for example, my home iMac. I have read and re-read the documentation again and again, but it is way too sparse. For example:

  • It says: “Make sure ~/.gnupg/gpg.conf contains ‘use-agent’” but there is no ~/.gnupg/gpg.conf on my iMac
  • It says: “Add ssh support to gnupg-agent by adding ‘enable-ssh-support’ to ~/.gnupg/gpg-agent.conf” but there is no ~/.gnupg/gpg-agent.conf on my iMac
  • It says: “Add the following code to your ~/.bashrc”, but I’m using zsh

I have GnuPG installed (via brew install gpg), but it didn’t generate any of the .conf-files mentioned, and I am stuck trying to figure out how to get them to appear.

Is there any chance of expanding the documentation a bit? It seems really sparse at the moment.

Hi,

I did not test this setup on a macOS. If the config files does not exist, you may just create them. It is totally fine to only have the one option in there.

Using zsh is fine (I am using it too). Just use the zshrc instead.

I try to extend the instructions in this regard.

Kind regards
Alex

Okay, maybe the conf-files aren’t the problem, then, because I’ve added it all now, but still, when I plug in the Nitrokey and try to SSH to somewhere, I get

sign_and_send_pubkey: signing failed: agent refused operation
sign_and_send_pubkey: signing failed: agent refused operation
mautic@x.x.x.x: Permission denied (publickey).

More specifically, with verbosity turned on, these are probably the relevant debug messages:

debug1: Host '[x.x.x.x]:2242' is known and matches the ECDSA host key.
debug1: Found key in /Users/mp/.ssh/known_hosts:9
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:pISonlafkEqBTdsy+nrkUhO9H3vtoEm1GFQMpiN7BG0 cardno:000500006A8E
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
sign_and_send_pubkey: signing failed: agent refused operation
debug1: Offering public key: RSA SHA256:pISonlafkEqBTdsy+nrkUhO9H3vtoEm1GFQMpiN7BG0 (none)
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
sign_and_send_pubkey: signing failed: agent refused operation

Why is the agent refusing? I already did gpg --card-status, which shows the Nitrokey, so I know gpg-agent is running

By the way, gpg -k doesn’t list any keys, so I’m wondering if the problem is occuring because gpg doesn’t know the public key on the Nitrokey? However, I’ve been searching high and low on the internet, but can’t find any instructions showing how to add the public key from a Nitrokey to the locan GPG keychain…

Hey,

may have a look at this page. It is about the Yubikey, but because of the OpenPGP Card specs it should work the same for both.

Disclaimer: I did not test this approach.

Kind regards
Alex

Yay, after hours of fernagling, I finally got past the frustrating sign_and_send_pubkey: signing failed: agent refused operation errors for SSH operations.

It turns out what helped me was doing echo UPDATESTARTUPTTY | gpg-connect-agent as mentioned in this post. I assume the problem was related to pinentry never firing, so I was never prompted to enter the PIN for my Nitrokey.

I’ve no idea where the bug came from, but I’m glad I got through it :slight_smile:

2 Likes

I am glad you got it working!

Hey, after switching to a different computer (running Arch Linux) and ran into the same problem, namely the sign_and_send_pubkey: signing failed: agent refused operation error whenever I tried to use the NitroKey GPG key to SSH into a remote server.

After even more frustration, I found that, again, the problem was with getting gpg-agent to work correctly, and since the official NitroKey docs for using it to SSH are pretty sparse, I have some recommendations for hanges (courtesy of the Arch Wiki)

I think the main two things that are missing from the NitroKey docs (for both MacOS and GNU/Linux since they use mostly the same stuff in this case) are:

  1. You need to have a pinentry program installed and when on the step for adding the enable-ssh-support to ~/.gnupg/gpg-agent.conf, also add a line pointing to your pinentry program, like this:
    pinentry-program /usr/bin/pinentry (or whereever your pinentry is).
  2. You need to point gpg-agent to the correct TTY. In the step when you edit your ~/.bashrc to add the $SSH_AUTH_SOCK stuff, you should also add two additional lines:
    export GPG_TTY=$(tty)
    gpg-connect-agent updatestartuptty /bye >/dev/null
    (I also would recommend adding a comment about instead using .zshrc instead for zsh or whatever else depending on your shell. You’d be surprised how many people will accidentally edit .bashrc while running zsh :stuck_out_tongue:
4 Likes

Thanks for sharing ! I also think the descriptions could be a bit more loaded and NK would also have a chance to be “the go-to” place to get some security knowledge together with the hardware you buy.

I also miss a change description: in case you already have ssh up and running, what need to be changed to ensure the new way with NK hardware is used and not the old ones ?! I think that would also make life a bit easier.

What do you mean by ‘old ones’? Do you mean if you have e.g. a local .ssh/id_rsa key, how to prioritize using NK over that? I’m fairly sure that SSH just tries all available keys. But leaving gpg-agent in charge of SSH keys might mean it doesn’t check .ssh folder at all, not sure

Exactly, I want to ensure that the .ssh/id_ keys are no longer (and never) used again. In case you used them e.g. for mail, you also want to revoke these keys. So the description should remind to what else need to be done ( beside deleting old private keys )

I try to add some more notes to the instructions, thanks!

You either has changed all authorized_keys files on your server and thus your old key has no use anymore or you forgot one - than you don’t want to have touched the key. One might rename the original key.

When writing these instructions I had experienced users in mind as general users won’t log in via SSH. Therefore, I did not include hints about zsh etc. and kept it short and simple. But I may could add some more Troubleshooting notes :thinking:

I think you also have to re-think who are your customers: while in the past maybe only a few experts are looking for HSM, RSA , DH , certificates and other buzzwords, nowadays also end user are looking for ways how the could secure their identities. NK keys are a smart and logical way for people thinking about keys and locks.

So I think NK could extend/grow their web-page to be one of these go-to places for such topics. But this also means: don’t make assumptions about the knowledge of your user ! IMHO you don’t need to go in one step to “Dummies …” book or chapters, but “How-to’s” could be very helpfull - expieriences users will jump over them, while growing learners might find the one or other tip they have forgotten.

Back to above: how about /etc/ssh_config and ssh-agent forwarding ? :smiley:

Offtopic a bit, but I think What's the fastest way to get the SSH keys on my Nitrokey Pro recognized on a foreign computer? could be automatically checked / troubleshooted by a Python tool. What do you think?

Hmm, I like what we often said in the past : " a fool with a tool is still a fool" - I would not recommend to use a tool as there could be a lot of different scenarios. I think a check-list ( which is also a “tool” ) could be good enough to remind the user, what to check ( e.g. the 10 or 1050 server he/she has with a ssh-login. Also I have just read a nice article about a ssh-based automatic server monitoring/visualisation - so also use your key on the master controller … )
Therefor I would not “program” a tool that need to be maintained only by a few experts. A checklist could be maintained by lot more people/resources - just IMHO :wink:

1 Like