There is a German aphorism that would translate to "ask someone holes into their stomach." If that were true, Werner should have holes in his stomach from my questions — but at last the SSH login with the Fellowship crypto card is working perfectly fine for me.
And I can’t help but find this extremely cool.
Here is what you need to do to get it running for yourself, but please be warned: This is not for the faint-heartet! If words like "shell" "packages" or "compiling" scare you, you probably want to wait a little longer.
- make sure that you have installed a recent (>=4000svn) gnupg-agent, gnupg2 and gpgsm. The links are to binary packages that were built yesterday and are running on my system right now. They should work for pretty much any recent Debian-based system.
- make sure you have the pinentry program of your choice. Running GNOME myself, pinentry-gtk-2 is my favorite. Debian GNU/Linux packages it in the "pinentry-gtk2" package, so aptitude should do the job for you.
- the gnupg-agent package has installed a 90gpg-agent script in your /etc/X11/Xsession.d which you can modify to use the pinentry program of your choice, select longer PIN caching, and enable SSH support. Here is the version of the 90gpg-agent script that I am using right now.
- make sure your .gnupg/gpg.conf file contains a "use-agent" and restart your X11 session. When loggin in again now, ps should show the gpg-agent running.
Relax. You are pretty much done now.
When plugging in the card and doing a "gpg –card-status", you should see the normal output. The "ssh-add -l" will show you the fingerprint of the keys it knows about. For the Fellowship crypt card, your output should look somewhat similar to this:
1024 1f:6e:b4:40:1d:99:72:64:13:c5:c2:6b:33:d2:e7:79 cardno:000100000210 (RSA)
With "ssh-add -L" you will get your SSH public key for the Fellowship crypto card. Put it into ".ssh/authorized_keys" on some remote host and you will be able to log into that host only with the Fellowship crypto card.
CAVEAT: All this is still somewhat alpha version. This version of the agent is actually the first capable of caching PINs. Below the surface it works by starting a "scdaemon" process that keeps the card open the entire time. When unplugging/replugging the card, that daemon freaks out and things are confused.
Doing a "pkill scdaemon" three times fixes that problem and things work just fine again. Personally I have put this into a script. Calling the script once after plugging in the card makes this setup extremely stable for me. Your mileage may vary.
Enjoy playing with this — I know I do.
Pingback: The Fellowship of FSFE.
Thanks!
> And I can’t help but find this extremely cool.
Amen. Just encryption and signing are cool — but ssh-auth with a crypto card is wicked. Thanks a lot for the writeup, I couldn’t have done it without your pointers.
I’m running Ubuntu Edgy, and although the packages are new enough (gpg2 is version 1.9.21 and there are no problems with unplugging/replugging), there were some packaging errors, which are documented in this thread:
http://www.gossamer-threads.com/lists/gnupg/users/39594#39594
From what I’ve heard, this is fixed in the next release.
i have written a more detailed instruction for ssh logins with smartcards and without on
http://www.programmierecke.net/howto/gpg-ssh.html
Can the script be put back online?
I have SSH working following segler’s instructions. However I’m stuck with the unplugging/replugging issue and have to issue killall -9 scdaemon if I want to see my card back after unplug. I’m running fairly recent version of gnupg & ccid on Archlinux 64-bit:
- gnupg 1.4.10-2
- gnupg2 2.0.16-2
- ccid 1.4.0-2
- pcsclite 1.6.4-2
Thanks
Alphazo
Pingback: Hook’s Humble Homepage :: Getting SmartCard reader working under Gentoo and SSH authentication via OpenPGP