I've managed to get U2F SSH authentication working. After some research online I've found a patch to the OpenSSH server that enables U2F authentication.

However there are 2 major caveats that would stop me from using this in a production enviroment:

• Security - the patch for OpenSSH has not yet been accepted/merged and currently works on an older version of OpenSSH
• Currently doesn't work on Mac OS, though maybe possible once Homebrew/legacy-homebrew#43676 is resolved

Setup

If anyones interested in trying it out here's how I set it up:

1. Download and install:
   1. VirtualBox
   2. VirtualBox Extension Pack
   3. Ubuntu Desktop (at the time of writing I used 15.04)

First SSH client VM

1. In VirtualBox create a new machine, but before starting it make sure that the USB Controller has been enabled for USB 2.0 or USB 3.0 and that the machine has enough RAM and video memory to operate. Enable the second network adapter and connect to your current network. Then attach the Ubuntu install ISO to it's virtual CD drive
2. Start the VM and follow the Ubuntu install, once at the Ubuntu desktop in VirtualBox click Devices > Insert Guest Additions CD image and allow the script on the CD to run and install
3. Following the guidance to setup Linux for use with U2F: create a: /etc/udev/rules.d/70-u2f.rules file with the following from Yubico/libu2f-host/70-u2f.rules
4. Run: sudo apt-get update && sudo apt-get install u2f-host autoconf zlib1g-dev libu2f-host-dev libssl-dev
5. Download openssh-6.7p1.tar.gz and extract: tar xzf openssh-6.7p1.tar.gz
6. From Bug 2319 - [PATCH REVIEW] U2F authentication download the attached Raw Unified Diff (dated 2014-12-25 05:52 EST)
7. Apply the patch via: patch -p1 < your-downloaded-diff-attachment.patch
8. Build via: rm configure && autoconf -i && ./configure --with-u2f && make && sudo make install (there might be an error about 'check-config' failed, but that seems to be ok)
9. Shutdown

Second SSH server VM

1. Right click the VM and clone it calling it Ubuntu SSH server and reinitialise the network addresses (I used a linked clone as it's faster and uses less memory)
2. Boot up the clone and edit the /etc/hostname and /etc/hosts files appending -2 to the hostname
3. Add sshd user via: sudo useradd -U -r -c 'openssh daemon' -d /usr/local/sbin -s /bin/false sshd
4. Edit /usr/local/etc/sshd_config adding:

U2FAuthentication yes
AuthenticationMethods password,u2f # or publickey,u2f

1. Reboot the SSH server
2. Type ifconfig making a note of it's local network IP
3. Start the ssh daemon via: sudo /usr/local/sbin/sshd -D and it'll wait for connections

First SSH client VM

1. Boot the first machine back up
2. Connect your U2F key your computer, then attach it to the VM by clicking the USB icon (bottom right) and clicking Yubico Security Key
3. Run ssh -o U2FMode=registration <ip-address-of-your-new-ssh-server> and enter your password, your U2F USB key should be flashing and it'll prompt you to press it
4. If successful it will output your U2F public key, copy the output (e.g. ssh-u2f ... my security key)

Second SSH server VM

1. Paste this public key into ~/.ssh/authorized_keys and save
2. Restart the sshd server (e.g. sudo /usr/local/sbin/sshd -D)

First SSH client VM

1. Run ssh <ip-address-of-your-new-ssh-server> and enter your password, you'll now be prompted to press your U2F key, then you should be logged in!

Seems to be a good working prototype 👍, thought it would be good to get the patch merged into OpenSSH to avoid having to build and deploy manually or if anyone knows a more stable/secure way of setting this up let me know!

from pam-u2f.

There's a more fundamental issue. U2F is designed to be used for second factor authentication only; you are supposed to provide your username and password first.

U2F has no concept of a "device ID". It's up to the server to provide a challenge for the keyhandle of whichever device it thinks the user might be holding (possibly more than one), so it already has to have a reasonable idea of which user is logging in.

The risk is that if I were to connect to an ssh server with username=brian, and get back a U2F challenge, I would know that I had located a valid username. (Perhaps the server could synthesis a fake keyhandle and challenge for any non-existent user?)

To use U2F in the way it was designed to be used would mean doing password authentication followed by U2F. I don't think that's a problem for SSH; the logic for requiring two types of authentication would have to be included in sshd.

For a SASL-aware application like IMAP that would mean running two SASL exchanges one after the other (e.g. PLAIN followed by XU2F) which I don't think is possible, unless you define combined protocols like X-PLAIN-U2F

from pam-u2f.

Updating this old issue for people who find it in Google. There's a good description of the FIDO2 (aka WebAuthn) data flow for session authentication at https://developers.yubico.com/FIDO2/Libraries/Using_a_library.html. WebAuthn was designed to also be able to be transported over SASL or EAP, so it would also be able to be transported as a new authentication mechanism in SSH (what is lacking as I write is such a patch for SSH). FIDO2/WebaAuthn is also designed to allow authentication proxying: that is, the application server seeking authentication can forward the session with the client to an authentication server. Microsoft have a beta deployment to do this for FIDO2-key Windows login against their Windows Hello could-based Active Directory offering. Something similar for Linux would require a PAM module to be written (to say forward within an EAP encapsulation to a RADIUS-style server, but there are many encapsulation/server possibilities and it is not yet clear which will become popular in the Unix ecosystem). pam_u2f isn't that PAM module, as it deals with a local key and local authentication.

from pam-u2f.

There's also pam_rssh which I can use (I think?) if I'm fine with using ssh-agent, but honestly I'm not sold on that yet.

from pam-u2f.

Ah, those are helpful, but I was also hoping to be able to do remote authentication via ssh too. I guess that'll need special client/server support, which the patch I linked to above will provide. It doesn't seem like the PAM mechanism is powerful enough to allow this sort of thing natively. Am I correct?

Thanks!

from pam-u2f.

@phoeagon would love to know what you did to make this work! really want to set up SSH auth over U2F. :)

from pam-u2f.

u2f is supported as of openssh 8.2

from pam-u2f.

Is it possible to authenticate with sudo over ssh with pam-u2f when the u2f hardware is connected to the client and not the guest?

from pam-u2f.

This module should be usable where other PAM modules are useful, console login, screensaver etc. Right now the module talks USB directly (through libu2f-host), so it is likely not useful on a SSH server unless you count 'ssh localhost'. What kind of functionality were you looking for?

from pam-u2f.

What if we add a "manual" mode where the challenge is printed out and waits for response input as plaintext? This should mitigate the problem as well as facilitates debugging/development.

from pam-u2f.

oops. I was fiddling with the code in https://github.com/phoeagon/pam-u2f/tree/manual
but now it works locally by manually pasting responses but not over SSH :-(

from pam-u2f.

:-D changed to make it work using pam_get_item and now it works

from pam-u2f.

Would be awesome if @phoeagon could document how to get this working with SSH

from pam-u2f.

+1

from pam-u2f.

I've only been able to get pam-u2f working when I've physically attached my Yubico U2F key to the target host VM machine I'm trying to SSHing into. So this doesn't seem to work for remote client SSH access, which is what I was hoping to setup. As I was looking to see if I could swap public/private key SSH authentication for U2F.

My setup was 2 identical Ubuntu 15.04 VMs both with the pam-u2f module installed & setup, when I SSH from one machine to the other with the Yubico U2F key attached to the remote client it fails with Permission denied (publickey,password)., but when I attach it to the target host machine the key flashes and when touched it successfully logs me in.

The docs should be updated to make it clear that this currently only works for local SSH connections (e.g. SSHing into machine you're already on!)

@phoeagon does using pam_get_item allow you to remotely SSH into a machine with U2F key plugged into the local client, rather than having to plug the key into the remote SSH servers USB port?

from pam-u2f.

Have you tried to set up the module in manual mode and use the u2f-host application on the client?

from pam-u2f.

@sebflipper, nice investigation, cheers!

from pam-u2f.

@sebflipper, hooray! THANKS!!! +1

from pam-u2f.

FWIW see comments in upstream OpenSSH bug report for updated/rebased patches too.

from pam-u2f.

Is a patch to make the server talk to a usb-dongle on the server really the way to do it? Shouldn't one rather patch ssh-agent to be able to talk to a u2f device on the client, and relay any necessary communication between the client-side device and the server?

from pam-u2f.

The good approach should be augmenting ssh-server to work like a U2F device
to the host environment, relaying challenges and responses to and fro,
which I'm afraid is beyond the scope of this project. (In this way, u2f can
work over the ssh for anything, not just PAM authentication. Let's say wget
decided to support U2F tomorrow...)

On Wed, Dec 9, 2015 at 7:30 AM larsr [email protected] wrote:

Is a patch to make the server talk to a usb-dongle on the server really
the way to do it? Shouldn't one rather patch ssh-agent to be able to talk
to a u2f device on the client, and relay any necessary communication
between the client-side device and the server?

—
Reply to this email directly or view it on GitHub
#12 (comment).

from pam-u2f.

Or:

• define a SASL mechanism for U2F
• add SASL authentication to the SSH protocol.

I think that would be the generic way to solve this. In principle you could then use U2F to authenticate random protocols like IMAP - although quite how you'd register the token I'm not sure.

Apparently telnet with TLS and SASL is an already-defined standard - just nobody bothered to implement it :-(

from pam-u2f.

The mechanism is documented here.

As far as I can see, it's regular public key authentication, but the private key structure contains the "key handle" (which in most U2F tokens is the private key encrypted with some token-specific internal key). The key selection proceeds as normal: the client presents one or more public keys that it would like to authenticate with, and the server selects one or more of them to try. If it's a U2F key then the client code passes the key handle to the device.

So it's not a "normal" web U2F exchange where:

1. the server would be responsible for storing the key handle
2. each server would have a different key handle for the same token

Rather, it's a way to generate and wrap a single private key in a U2F token, and use the same private key to authenticate to multiple servers.

Unfortunately, Ubuntu 20.04 is about to be released with OpenSSH 8.1, so this may not see widespread adoption for a while.

from pam-u2f.

wow, that really sucks, i just tried to add my secure.pub file to my github and well...

(note i am using a Thetis Key )

from pam-u2f.

OpenSSH 8.2 is pretty new, I'm not surprised if github hasn't integrated it yet. Also they may rely on some third-party ssh library which needs modifying to accept the new key types.

from pam-u2f.

wouldnt surprise me honestly,

from pam-u2f.

I would expect so, in manual mode as described here. However, what would happen is the PAM module prints a challenge in text; you have to paste that into a helper program on the client (which talks to the U2F key); the helper spits out a response; and you have to paste that back into the ssh session as the response.

So it's not very user-friendly :-(

Other options for sudo PAM authentication include:

• yubico OTP (with full-feature Yubikeys rather than U2F-only keys)
• TOTP
• certificate in client's ssh-agent with pam-ussh

In each case, you're trying to confirm the presence of an authorized human at the client side. This requires either them typing something, or talking to their ssh-agent socket.

from pam-u2f.

I am fine with confirming presence and entering pin on the client. I'd like to avoid OTP/TOTP. I sort of was looking for a way to forward the U2F token so it's recognized by the server's PAM. Also, I don't use ssh-agent.

from pam-u2f.

Yes, but once you've logged into a remote host, the ssh session is really just streams of text in and out. You can't insert a message saying "oh by the way, please can you send this data to the client-side U2F key" without modifying the SSH protocol itself.

If you want to have something that's actually deployable, I'd suggest one of the options I listed before.

Regular yubico OTP is the simplest to use and has a drop-in PAM module that works very well. You can also use it as a second-factor on SSH logins, by requiring both public-key and challenge-response authentication.

from pam-u2f.