Yubico Ssh



At ClueTrust we’re constantly re-evaluating our security posture basedon both perceived threat and what level of effort it takes toimplement various security technologies. In short, being a small shopwe're always conscious of the 'effort' component of the effort/rewardratio.

Protect your digital world with YubiKey Stop account takeovers, go passwordless and modernize your multi-factor authentication. Get the world’s leading security key for superior security, user experience and return on investment.

  1. The Yubico Software referenced in this document is licensed to you under the terms and conditions accompanying the software or as. SSH in Short The main.
  2. The Yubico PAM module for SSH can be downloaded from here. The Yubico PAM module support two factor authentication for SSH. The two factor authentication module verifies the user name and password for the user and the One-Time Password (OTP) generated by YubiKey assigned to the user. Build yubico-c-client and pamyubico.
  3. If you have changed the management key, add -key to the yubico-piv-tool -a import-certificate command below. Confirm that the ssh-agent finds the.
  4. Then restart the server with the ssh command: sudo service ssh restart. Now, the user will be asked for the YubiKey code when authorizing.
Github

Yubikey Ssh Windows

Here in the future in 2020 it has finally become possible to do alittle bit better with ssh than just requiring keys. OpenSSH 8.2included support for Universal Two-Factor (U2F/FIDO) tokens. For theuninitiated, this is an open standard for strong crypto-basedchallenge/response that was championed by a consortium that includesall the folks you might expect to seethere . Note thattoday’s FIDO is called FIDO2. Gaige has done some cursoryinvestigation in the backward compatibility department to quantify theconstraints you’ll get from a FIDO-not-FIDO2 key (enumerated below).

If you got this far and said 'yeah, we've using Yubikeys for yearswith ssh, you push the button on the key and a 35 character stringcomes out; why is this news', let me stop you right there and say'this is not that'. Saying “yubikey” is like saying “car” withoutspecifying how many doors or what kind of roof it has. The Yubikey 5family, for instance, will do the following authentication methods:Secure Static Passwords, Yubico OTP, OATH – HOTP (Event), OATH – TOTP(Time), Smart Card (PIV-Compatible), OpenPGP, FIDO U2F, FIDO2. I’veconfigured ssh with PIV keys. It works. A friend of mine swears byssh with OpenPGP - that is good and spits out keys that are plain ’olssh-rsa from a user perspective which is nice for backwardcompatibility. This is about the way that FIDO2 support is implementedin OpenSSH.

Still got your attention? Great. Until recently, we felt /FIDO.*/was interesting-but-impractical for general use since the only thingthat seemed to support them was Chrome. But over the past year,Safari (on both macOS and iOS) and OpenSSH 8.2 (released inmid-February 2020) have added support. The latter raises it to thepoint where the cost both in terms of dollars (as low $20 for aFIDO2-only Yubikey token via Amazon) and effort required to make thissomething we wanted to pilot. And we did.

A little note about the sub-$30 Yubikeys - the full name of the modelin question is “Security Key by Yubico” (or its slightly moreexpensive sibling, 'Security Key NFC by Yubico”). You might thinkthese names are purely descriptive since Yubikey’s products might allbe described as “security keys” (note lowercase). They're not - thoseare the actual model identifiers. Yubikey has kindly published a full historical list of Yubikeymodels. Ofparticular note,FIDO and FIDO2 aren’t the same thing and any of theolder models that you might have lying around from earlier experimentsor hacker conference door prizes years ago - in fact anything thatdoesn’t show FIDO2 or FIDO on that list - will end in frustration. From Gaige’s junk drawer, we know the following:

  • The 4C is not listed as FIDO2, but is FIDO U2F and can be used with ecdsa-sk, but not ed25519-sk. Since the 4C self-describes as a 4, it appears series 4 keys will likely work, but don’t go searching out bargains on NOS.• The 5ci works fine with either.
  • The “Legacy” products, such as the Standard (2014-2016) do not work at all in this mode.
  • Note that if you got a freebie from Ars Technica a couple of years back, it’s likely a 4, which is at least capable of doing ecdsa-sk.

I'm a Mac user. If you use something else for your unix-like desktop applications (say, WSL2 or or some Linux flavor) you’re on your own but you can probably figure this one out since it’s just a matter of compiling openssh-portable from source and exposing a USB device to userland. I am unaware of any non-Unix ssh implementations that support the FIDO2 token on the client side (yet, maybe PuTTY will do this some day soon), though I’ll be super excited when Prompt or Blink support it via NFC the iPad.

Here are the steps for playing with it:

  1. Buy a Security Key by Yubico or perhaps you want to pay an extra $7 to be baller and roll with NFC. It works on relatively modern iDevices - I think you need an iPhone 7 or newer. If you already have one that’s up to the task (see the historical list of Yubikey models above), good on ya - you’re already ahead of the (adoption, not crypto) curve. Of course you can always buy one of the spendy ones too if the spirit moves ya.

  2. You’re probably aware that Amazon has a big supply chain contamination problem.Can’t hurt to test the token you get out by going to Yubico's test site. I haven’t tested with a non-Yubico FIDO2 token, but my guess is that testing devices with baked-in PKI attestation certs for legitimacy is pretty darned easy - in fact that's the whole point of the attestation cert.

  3. You’re already running Homebrew right? Splendid. brew update ; brew upgrade ; brew install openssh. Hopefully you have your $PATH set properly so that stuff that you install with Homebrew (/usr/local/bin, /usr/local/sbin, etc) is listed first so it takes precedence over stock stuff that’s installed in /usr/bin. If not, you probably should do this. Congratulations, now you have a working OpenSSH that does all the right things and is linked to the libfido2 libraries (which it autoinstalls as a dependency). Note: if you weren’t previously using the homebrew version of ssh, you may need to rehash your paths to get the latest ssh and ssh-keygen (rehash under /bin/csh and derivatives, hash -r under bash and similar). This was tested with latest Homebrew on:

  4. macOS High Sierra (version 10.13) on a 13” Late 2011 MacBook Pro
  5. macOS Mojave (version 10.14) on a 15” Late 2015 MacBook Pro
  6. macOS Catalina (version 10.15) on a 2019 Mac Pro

  7. Stick the Yubikey in a port. This should go without saying but you can go no further without said key.

  8. Create yourself a new key. There are some instructions here that I disagree with a bit (on the basis of proper identification of the key (the Security Key by Yubico apparently does not have a serial number) and failure to choose a variant of the One True Collection of Mutually Compatible Date Formats (iso-8601)) but read it anyway before you instead do this:

or perhaps if you’re all about the djb curves:

Of course your email address is not yourname@example.com but you probably already picked up on the need to modify that. Keen and readers will notice that I’ve used the '8601 Basic” format which is specifically not supposed to be used where it will be exposed to humans due to missing syntactic sugar. To appeal to your pedantry, we will refer to this missing symbol as the “hyphen (minus)” glyph, as it is described in ANSI X3.4-1968.

  1. Now that you've got a key generated, you unfortunately can't use it just anywhere. On the remote host that you propose to ssh into, you'll need to either get lucky and pick up OpenSSH 8.2 via a package update on your target system or install it by building OpenSSH-portable from source. Note that this will get easier over time; the difficulties stem from the fact that it has barely been out for a month.

  2. copy the new PUBLIC key over to the destination host. The private part stays on your laptop, as always.

  1. ssh to jumphost.example.com via the normal way with your existing keys and append the key to ~/.ssh/authorized_keys
  1. Back on your laptop, you’re probably running ssh-agent. Later when everything is normalized can still forward the keys in ssh-agent, but you can’t put an “sk” key in ssh-agent (for obvious reasons) and you don’t want to know anything about existing unlocked keys if you have preferences recorded in .ssh/config, so in the interests of avoiding confusion during testing do this:

Gaige was able to get this working just by specifying the -i, but if you have a lot of keys loaded by default, you might need -o IdentitiesOnly=yes. A good recipe for rs (without unsetting SSH_AUTH_SOCK) ended up being:

With that said, by using -i with the SK paired with -A one can mix in ssh-agent and forward unlocked keys that aren’t used for this login, to ssh into another machine with a non-sk key (say, from the jumphost to some protected server ona backnet, for instance). More on the slightly confusing behavior in prioritization of keys on Gaige’s blog.

  1. Let's give it a try!

It should prompt you for a password (the same password you used when creating the key) and then a press on the Yubikey to confirm your presence. Note that without the Yubikey present, all of the crypto necessary to unlock the ssh key is not present, and you're outta luck. If all went according to plan, you should be in via 2FA. Isn’t that special…

  1. You probably want to set some definitions for what key to use in .ssh/config on your laptop. For instance, my shortcuts entries look like so:

Lastly, please send along any useful feedback including the fine points of getting this working on other platforms, grammatical fixes, clarifications, etc!

SSH is the default method for systems administrators to log into remote Linus systems. Traditionally, [SSH keys] are secured with a password. This situation can be improved upon by enforcing a second authentication factor - a Yubikey.

After you do this then only someone with both the password and the Yubikey will be able to use the SSH key pair to log into your Linus system.

This guide is a quick start to using a Yubikey with SSH.

Software Versions

You must have SSH version 8.2 or greater on the client (your laptop) and the server (the remote Linux system).

You will also need Yubikey firmware of 5.2.3 if you want to use a ed25519-sk key. If you version is older then use an ecdsa-sk key.

Yubikey ssh github

You can check your Yubikey’s firmware version with the following command:

Configure The SSH Server

You will need to configure the SSH server to use the sk (Security Key) that you will create later. Open your SSH server’s configuration in a text editor:

Then add this line that includes both of the ed25519-sk and ecdsa-sk keys:

Finally, restart SSH

Create A Key pair

Create an ecdsa key pair with the following command:

Use this command to create an ed25519 key pair:

If you get this error Key enrollment failed: requested feature not supported then your Yubikey’s firmware is too old and does not support ed25519-sk keys. Create an ecdsa-sk key pair instead.

This command will place the new key pair into ~/.ssh/ as either:

Or:

Load the public key on your server

You need to place the contents of your public key into the ~/.ssh/authorized_keys file on your server.

Get the contents of your public key:

Yubico Ssh Key

Then log into your server and open the authorized_keys file:

Yubikey Ssh 2fa

and past the public key line into the file, save and exit.

Then restart SSH:

Using the SSH key with your Yubikey

You can now either use the key directly with the -i switch e.g.:

Or load it into your SSH agent:

Yubikey Ssh Certificate

Then SSH directly:

Yubikey Ssh Github

Before you can log into the remote system your Yubikey will start to flash its LED prompting you to tap it. After you tap your key you will be able to log in.