12 ms·

Security keys are now supported for SSH Git operations

215 points by Androider 5y ago

cakoose 5y ago
This looks like an SSH client feature that is invisible to the server. Does the server operator (GitHub) even have to do anything?
- Kipters 5y ago
  They need to support that kind of key, i.e. you can't use it to login on your servers unless they are running OpenSSH 8.1+
RcouF1uZ4gsC 5y ago
Does anyone know if there is a way to have ssh just use the security key without having to have the key files on disk? I work from several computers and VMs. It is somewhat of a pain to have to generate and register keys for each computer and VM. It would be nice if I could just generate the ssh key once on my security key and use that everywhere.
- OminousWeapons 5y ago
  https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide
- kiallmacinnes 5y ago
  Yes, you can use gpg-agent to handle this - I've been doing it for years... Every machine does need to be setup to use gpg-agent in place of ssh-agent, which frankly is a little annoying - but once it's setup your key is entirely on the YubiKey or similar. Here's[1] the first blog I could find that at a glance appears to provide the right instructions. [1]: https://evilmartians.com/chronicles/stick-with-security-yubikey-ssh-gnupg-macos https://evilmartians.com/chronicles/stick-with-security-yubi...
  - Firehawke 5y ago
    My experience is that the initial setup with gpg-agent is a massive pain, especially on Windows+WSL2 setups, but once you get it working it's great. Well, except when gpg-agent dies out of nowhere and you have to restart it.. It's still better security even if it doesn't go quite as smoothly as I'd hope. A tip to anyone else here who wants to do this: You want gpg-agent, and you absolutely need to use a newer build of OpenSSH than the one that ships with Windows 10 currently. Remove that and go find the official distribution on GitHub or Chcoolatey so you have a version that supports that key type. Then you also need to make sure to set up the environment variable GIT_SSH to point to that version of OpenSSH or else Git for Windows will try to use its own older build and then you will spend a week trying to figure out how to make it work.
- StavrosK 5y ago
  Yes, it's easy, you don't need gpg-agent or anything, just do `ssh-add -K`: https://www.stavros.io/posts/u2f-fido2-with-ssh/ https://www.stavros.io/posts/u2f-fido2-with-ssh/
  - allset_ 5y ago
    You do need a fairly recent version of OpenSSH though.
    - StavrosK 5y ago
      That's true, but it's old enough that you'll probably have it, and I think that's the only way that'll work with this Github feature, since it's U2F support they're adding.
  - RcouF1uZ4gsC 5y ago
    This was exactly what I was looking for
  - OJFord 5y ago
    Does this work with existing keys, including ones generated on the device? (as distinct from 'resident' here which seems to generate on computer and copy to device, anything else special?) Basically wondering if I can drop gpg-agent (for SSH auth purposes anyway) and 'sshcontrol' without changing key.
    - StavrosK 5y ago
      No, if you don't use resident keys you need the files (as the keys need to come from somewhere). The keys aren't copied to the device, they're generated on the device, more or less.
      - OJFord 5y ago
        > No, if you don't use resident keys you need the files (as the keys need to come from somewhere). Right, but I already have it on the device, I'm talking about using an already provisioned device with this new-ish OpenSSH feature; or whether it does something 'special' that means the key needs to be ('resident' or not) generated by this feature? Thinking about it though it's probably not for me, since SSH is not the only and probably the minority of my use, since I also use the encryption key (e.g. with `pass`) and signing (e.g. git commits, for no particular reason). > The keys aren't copied to the device, they're generated on the device, more or less. In your blog post you say it produces two files, the private and public keys. If it generated on device it wouldn't (be able to) have the private key?
- michaelt 5y ago
  Some security keys implement multiple standards, others don't. A $25 blue Yubikey only supports U2F, which requires at least OpenSSH 8.2 on the host you're connecting to. U2F is the standard used for logging into websites with a security key, and there are many vendors other than yubikey. A $45 black Yubikey 5 also supports OpenPGP and Smart Card/PIV which can do SSH without server updates (with a bit of software installation on your end).
  - _trampeltier 5y ago
    Even I have and I use a Yubikey 5, the whole thing still feels a bit like a black box for me. I still have not found a good overview about the different standarts, what do they different and about the many options in the Yubikey software. Also I kind of get, you can't make a backup key. But in the end, if they key is lost, you use also mostly just another password again. But for me, I would much prefer to create a second key somehow.
    - deadbunny 5y ago
      You can create a key and load it into the Yubikey (and thus backup the key) rather than have the yubikey create the key on itself directly.
      - tialaramex 5y ago
        You can't do this with the key underlying FIDO (thus U2F/ WebAuthn and the SSH feature the linked article is discussing) Yubico supply a tool that lets you perform a "factory reset" giving you a random key (effectively: instantly invalidating all credentials you previously used) but not one that would let you pick the key. IIRC The relevant standard is clear that manufacturers should not offer this capability as it's obvious how it would get exploited.
    - loulouxiv 5y ago
      I felt the same at first when I received mine. And since the information is quite scattered in Yubico's documentation, blog and on external websites it was very time consuming to figure everything out... It also seems that a lot of things have evolved in this area so it is not easy to know what is still useful/the best way to do things. When I get the time to, I want to put up a webpage that explains the main state-of-the-art usages of the Yubikey, with step by step instructions for the major platforms
- unixhero 5y ago
  Do you mean the TPM hardware Key?
- bennyp101 5y ago
  Yep, I followed the guide here: https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide Means I can SSH into any box that has that key on it, or push/pull repos from anywhere as long as I have a yubikey with me. I also used https://www.jabberwocky.com/software/paperkey/ https://www.jabberwocky.com/software/paperkey/ to make a backup, and have that and a spare yubikey stored elsewhere securely. (You can create the key on the yubikey directly, but then I think it's not possible to have a backup yubikey)
- teekert 5y ago
  https://www.akamai.com/us/en/products/security/akamai-mfa.jsp https://www.akamai.com/us/en/products/security/akamai-mfa.js... ?
- lxgr 5y ago
  Besides all the suggestions for GnuPG/OpenPGP-based SSH keys, there's also "-O resident" for FIDO2-based keys. This also stores the private key on the security key itself, removing the need for the key handle file. For more details, see the release notes for FIDO2 on OpenSSH: https://www.openssh.com/txt/release-8.2 https://www.openssh.com/txt/release-8.2
- arianvanp 5y ago
  Yes; See the tutorial on Resident keys here: https://www.yubico.com/blog/github-now-supports-ssh-security-keys/ https://www.yubico.com/blog/github-now-supports-ssh-security... With resident keys you can load the ssh key description from the key directly into the ssh-agent. $ ssh-keygen -t ecdsa-sk -O resident $ ssh-add -K $ ssh git@github.com
- brnt 5y ago
  I have my private key in a Keepass database, and with a keypress Keepass(XC) loads it into my agent. After a time that you specify, it unloads it automatically. I use a U2F key now, and that key I just have in ~/.ssh. It's useless without my U2F fob anyway. (Right?)
  - tialaramex 5y ago
    Yes, you are correct that it is useless without your physical Security Key. Technically what's happening is that the valuable private key is in a sense in that file you're not worried about. But, you're safe not worrying about it, because it was encrypted by the Security Key, and only the Security Key knows how to decrypt it, so even though in one sense it's the private key and very important, because it's encrypted it's not a big deal if anybody learns it, as they couldn't possibly decrypt it. The contents of the file are given back to the Security Key when you use SSH to connect to (say) GitHub and in fact it will decrypt them to discover your private key, then use it, and then forget it again immediately, but it could (hypothetically) instead store a library of all credentials and use the random contents of the file to just look up the right credentials in the huge library. That would cost $$$ and Security Keys are (relatively) cheap. It's OK to completely forget that technical description, the designers of Security Keys specifically intended that you needn't care how the magic is done, I have explained it only to reassure anyone puzzling how this could possibly work.
0xbadcafebee 5y ago
PATs are still superior to SSH keys because 1) PATs allow more fine-grained access control 2) HTTPS is more widely available through firewalls and proxies 3) SSH without certificates is more vulnerable to MITM than HTTPS (with certificates) 4) it's easier to specify different PATs for different remote repos than it is different SSH config aliases for different remote repos. Yet people still prefer SSH because........ ? And since the SSH private key used in this way is merely a pointer to a security token, it doesn't matter if it gets compromised. This is an interesting way to continue the status quo of not explaining to users how to create SSH keys using the new SSH key format (which prevents password cracking vulnerabilities in the old key format).
- vbezhenar 5y ago
  I’m surprised that there’s no standard way to get a server SSH public key via HTTPS. I have to google for the gitlab key fingerprint and the expected result is not easily found, just to ensure that my first SSH connection is secure. Something like /.well-known/ssh/ed25519.pub would suffice, I guess.
  - praseodym 5y ago
    There is an SSHFP DNS record for this purpose, which should be just as secure with DNSSEC enabled. https://en.wikipedia.org/wiki/SSHFP_record https://en.wikipedia.org/wiki/SSHFP_record
  - 0xbadcafebee 5y ago
    Well if you could do that, you would just use TLS. The public-key crypto used by SSH is a relic of when it was ridiculously expensive to get an SSL certificate for each of your routers and backend servers, but people still needed something more secure than Telnet.
- c0l0 5y ago
  > 3) SSH without certificates is more vulnerable to MITM than HTTPS (with certificates) Why would you claim that? As long as any CA with its root certificate in your trust store can vouch for any identity, I would argue that TOFU (where you verify the remote resource's key is in control of the identity you intend to connect with) is less prone to having your connection MITM'd, since the attacker would have to either break the underlying cryptography, or exfiltrate the remote's private key. With the CA system in place, you "just" need to get another CA to sign for the identity you would like to spoof. Not saying it's easy, but for the proverbial "nation state"-level attacker (maybe with their own CA root already in your trust store :)), it's certainly easier to do that than to break RSA or EC.
dochtman 5y ago
I use Secretive to authenticate to SSH (including GitHub) with my Mac’s TouchID. Feels like this is (almost) as secure, while being more convenient (no extra hardware required). Of course it is a Mac-only solution.
- viraptor 5y ago
  Other systems allow something similar using TPM. Both Linux and Windows can use a hardware non-exportable key with SSH that way. It doesn't allow for the touch verification on use, but it's still better than having a file in the disk. Security scale would be: - key in a file - TPM - touchid - hardware gpg/SSH key - hardware u2f key
  - mercora 5y ago
    are keys in the TPM really securely stored and accessed? can i trust those to only be used by myself by i.e. providing a password or similar? i also think touchid should rank even lower because its likely somewhat easy to forge.
    - viraptor 5y ago
      TPM keys are not accessible once imported or generated. You only get access to operations like encrypt/decrypt on them. Those are also normally accessible only by the root user, so you use some kind of proxy with an extra step (like a password) to make them available to the user. I'm not sure what you mean by touchid being easy to forge.
      - mercora 5y ago
        so that does mean once i have access to the computer the keys are somewhat free to use. thus i am authenticating the device not the user which is kind of an important distinction... IMHO this is not as secure as storing the key encrypted on a drive where its only accessible using a passphrase. It is just harder or maybe even impossible to exfiltrate the key but you really don't need to do that in order to use it. i might be wrong though. My remark about touchid came from the fact that fingerprint scanning is inherently insecure because it is trivial to fool most devices into thinking you got a matching fingerprint using something that was touched and left a mark and some glue.
useryman 5y ago
Other than being a random untrusted USB device, is there any reason to not use the cheapest generic U2F device you can find? I've been wanting to start using them for a while, but yubikeys are too expensive for me to get a bunch of.
- danieldk 5y ago
  I would try to find a key that supports ed25519, since there are concerns about the NIST curves used in ecdsa: https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n4 https://git.libssh.org/projects/libssh.git/tree/doc/curve255...
  - brnt 5y ago
    Remember that Github U2F key 6 years ago? It just supports the ecdsa keys... I feel a tiny bit grumpy that it took 6 years for me to be actually be able to use the thing for anything important and then to discover it's already outdated. I hope many services will support them nonetheless.
  - darkblackcorner 5y ago
    I've Kickstarted Solo V2: https://www.kickstarter.com/projects/conorpatrick/solo-v2-safety-net-against-phishing https://www.kickstarter.com/projects/conorpatrick/solo-v2-sa... Still in production ATM but will support ed25519, and is open source
- comboy 5y ago
  What problem are you trying to solve? Yes you can get one for $10 instead of yubico's $20, but yubico's have been researched the most and importantly they are very reliable. Many people successfully abuse them and while you always should add a pair of them giving you a backup, it would be a pain if it would stop working. I'm asking because I'm curious about use case where you think you need them (even a bunch), but you think they are too expensive compared to value which you are trying to protect. Reliability would be a good enough reason to me even ignoring all security aspects.
chiph 5y ago
I just made a suggestion to dasKeyboard that they put a place to dock your Yubikey on top of their keyboards, since people will be touching them much more often now.
- kiallmacinnes 5y ago
  By "place to dock", you mean like a USB port or something else? Lots of keyboards obviously have that already - including at least some of the Das Keyboards (mine does...)
  - chiph 5y ago
    Yes, but not on the back like they have (on some models) but on the top. If your key is in one of the rear USB sockets, when you press down to activate it it will stress the port (it acts like a lever). I was thinking on the top, parallel with the surface. Lay the key on the keyboard, slide it to the left to insert into the socket. When you press on the key, the force gets transferred through the key onto the keyboard, and so no flex or stress on the socket.
hnarn 5y ago
I'm going to ask a naive but honest question: what is the security benefit of a piece of "key-hardware" over a passphrase protected key stored on a "normal" storage device? I understand that for someone that moves between multiple physical machines it may be a benefit of convenience, but what threat vector does a physical key eliminate that exists for passphrased "normal" SSH keys?
- krab 5y ago
  Malware shouldn't be able to silently copy the key. Usually you have to touch the device to confirm usage. Even if the malware got your one time password when you thought you confirmed a legitimate operation, the attacker wouldn't get persistent access. Edit: Also, most people don't use them, so some attackers won't bother with more complex target.
  - FranchuFranchu 5y ago
    The first difference can be negated by using an unplugged storage device to store the key. The second one is trickier since you need to do processing to prove that you have a private key, so you'd have to send the key to your own computer which breaks the whole point. You could use a separate "key" computer who owns the keys and that computer is the one that proves that it has the private key, but at that point you'd be better off using a normal security key since it's basically the same thing.
    - deleted 5y ago
      [deleted]
    - gabeio 5y ago
      Unless I am missing something, security keys never send the private key anywhere so the computer can not access it. Unlike an unplugged storage device which can be read by malware once plugged in, and need to be read into memory by the computer for use.
- oprah 5y ago
  One obvious thing would be keyloggers?
hjehoadwei 5y ago
I don't understand - what's the new feature here? Yubikeys have always supported SSH authentication, and you have always been able to use that for git. What is the new functionality that Github has added?
- xur17 5y ago
  Yeah, I'm confused as well. I've been using my yubikey for ssh auth for years now with github and other services.
- andrewnicolalde 5y ago
  I believe this adds support for the new -sk key types, in which the ssh server checks the presence of a U2F token on the client, rather than using something like gpg-agent to effectively store your SSH keys on the Yubikey.
- warhorse10_9 5y ago
  Looks like they added the "-sk" options to Git Bash for windows. That seems to be what they are promoting for the most part with this post. Though the title is a bit deceptive.
- tialaramex 5y ago
  Your Yubikey (but not Yubico's cheaper Security Key product and the dozens of other similar cheaper products) is able to do public key signatures exactly like the ones SSH supports anyway, so GitHub didn't do anything to support those. But modern OpenSSH can do FIDO, the same technology that drives U2F and its replacement WebAuthn, and is in all those cheaper and more popular products. FIDO won't sign arbitrary data with keys, it will only perform a very specific operations and so OpenSSH grew a whole separate set of public key authentication types to support that approach, and GitHub is announcing their support for these extra types. There are some neat features beyond "this makes cheaper devices work" but GitHub mostly does not use them, although they do choose to require that your Security Key verify you are present (typically by touching a sensor or clicking a physical button) whereas your existing Yubikey setup might not be doing that and GitHub can't force you to.
kylehotchkiss 5y ago
I tried this on my macbook pro today - latest OS version. First I installed openssh with brew. Then I found I could barely get the new ssh key working with GitHub, frequently getting `sign_and_send_pubkey: signing failed for ECDSA-SK / invalid format` errors while trying to commit and not actually being prompted to press the Yubikey, despite it being plugged in and ready. I keep my mini Yubikey USB-C in my laptop persistently which I wonder could be the issue. Anybody else having similar issues?
- exabrial 5y ago
  Yubikeys seem to have multiple modes and have trouble switching between them. For instance in GPG mode, It's very difficult to switch back to U2F mode without unplugging. I wonder if this is your issue
  - kylehotchkiss 5y ago
    Interesting! Any ideas of how to log which mode it's in to help debug this further? Would disabling unused modes help prevent this?
- kylehotchkiss 5y ago
  Upon further investigation (Copy-pasting things from random internet webpages like a good HN would do), running the following two commands seemed to help get the Yubikey SSH running a little more reliably with Github for me, including with Tower.app after making sure it has the correct PATH setup: `eval `ssh-agent -s`` `ssh-add` Without the eval ssh-agent command, `ssh-add` fails to add the ECDSA-SK key since Mac OS' SSH implementation doesn't seem to natively support it. I don't understand how running eval ssh-agent resolves it because that shouldn't persist very long with Mac OS' own SSH agent trying to run.
  - beermonster 5y ago
    ssh for macOS has some Keychain integration built into it in lieu of ssh-agent, or something like that IIRC.
Galanwe 5y ago
Maybe I miss something, but I have been using yubikeys (or any pgp key for that matter) for SSH and git since many years already through `gpg-agent --enable-ssh-support`.

215 points by Androider 5y ago

This looks like an SSH client feature that is invisible to the server. Does the server operator (GitHub) even have to do anything?

Kipters 5y ago
They need to support that kind of key, i.e. you can't use it to login on your servers unless they are running OpenSSH 8.1+

RcouF1uZ4gsC 5y ago

Does anyone know if there is a way to have ssh just use the security key without having to have the key files on disk? I work from several computers and VMs. It is somewhat of a pain to have to generate and register keys for each computer and VM. It would be nice if I could just generate the ssh key once on my security key and use that everywhere.

OminousWeapons 5y ago
https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide
kiallmacinnes 5y ago
Yes, you can use gpg-agent to handle this - I've been doing it for years... Every machine does need to be setup to use gpg-agent in place of ssh-agent, which frankly is a little annoying - but once it's setup your key is entirely on the YubiKey or similar. Here's[1] the first blog I could find that at a glance appears to provide the right instructions. [1]: https://evilmartians.com/chronicles/stick-with-security-yubikey-ssh-gnupg-macos https://evilmartians.com/chronicles/stick-with-security-yubi...
- Firehawke 5y ago
  My experience is that the initial setup with gpg-agent is a massive pain, especially on Windows+WSL2 setups, but once you get it working it's great. Well, except when gpg-agent dies out of nowhere and you have to restart it.. It's still better security even if it doesn't go quite as smoothly as I'd hope. A tip to anyone else here who wants to do this: You want gpg-agent, and you absolutely need to use a newer build of OpenSSH than the one that ships with Windows 10 currently. Remove that and go find the official distribution on GitHub or Chcoolatey so you have a version that supports that key type. Then you also need to make sure to set up the environment variable GIT_SSH to point to that version of OpenSSH or else Git for Windows will try to use its own older build and then you will spend a week trying to figure out how to make it work.
StavrosK 5y ago
Yes, it's easy, you don't need gpg-agent or anything, just do `ssh-add -K`: https://www.stavros.io/posts/u2f-fido2-with-ssh/ https://www.stavros.io/posts/u2f-fido2-with-ssh/
- allset_ 5y ago
  You do need a fairly recent version of OpenSSH though.
  - StavrosK 5y ago
    That's true, but it's old enough that you'll probably have it, and I think that's the only way that'll work with this Github feature, since it's U2F support they're adding.
- RcouF1uZ4gsC 5y ago
  This was exactly what I was looking for
- OJFord 5y ago
  Does this work with existing keys, including ones generated on the device? (as distinct from 'resident' here which seems to generate on computer and copy to device, anything else special?) Basically wondering if I can drop gpg-agent (for SSH auth purposes anyway) and 'sshcontrol' without changing key.
  - StavrosK 5y ago
    No, if you don't use resident keys you need the files (as the keys need to come from somewhere). The keys aren't copied to the device, they're generated on the device, more or less.
    - OJFord 5y ago
      > No, if you don't use resident keys you need the files (as the keys need to come from somewhere). Right, but I already have it on the device, I'm talking about using an already provisioned device with this new-ish OpenSSH feature; or whether it does something 'special' that means the key needs to be ('resident' or not) generated by this feature? Thinking about it though it's probably not for me, since SSH is not the only and probably the minority of my use, since I also use the encryption key (e.g. with `pass`) and signing (e.g. git commits, for no particular reason). > The keys aren't copied to the device, they're generated on the device, more or less. In your blog post you say it produces two files, the private and public keys. If it generated on device it wouldn't (be able to) have the private key?
michaelt 5y ago
Some security keys implement multiple standards, others don't. A $25 blue Yubikey only supports U2F, which requires at least OpenSSH 8.2 on the host you're connecting to. U2F is the standard used for logging into websites with a security key, and there are many vendors other than yubikey. A $45 black Yubikey 5 also supports OpenPGP and Smart Card/PIV which can do SSH without server updates (with a bit of software installation on your end).
- _trampeltier 5y ago
  Even I have and I use a Yubikey 5, the whole thing still feels a bit like a black box for me. I still have not found a good overview about the different standarts, what do they different and about the many options in the Yubikey software. Also I kind of get, you can't make a backup key. But in the end, if they key is lost, you use also mostly just another password again. But for me, I would much prefer to create a second key somehow.
  - deadbunny 5y ago
    You can create a key and load it into the Yubikey (and thus backup the key) rather than have the yubikey create the key on itself directly.
    - tialaramex 5y ago
      You can't do this with the key underlying FIDO (thus U2F/ WebAuthn and the SSH feature the linked article is discussing) Yubico supply a tool that lets you perform a "factory reset" giving you a random key (effectively: instantly invalidating all credentials you previously used) but not one that would let you pick the key. IIRC The relevant standard is clear that manufacturers should not offer this capability as it's obvious how it would get exploited.
  - loulouxiv 5y ago
    I felt the same at first when I received mine. And since the information is quite scattered in Yubico's documentation, blog and on external websites it was very time consuming to figure everything out... It also seems that a lot of things have evolved in this area so it is not easy to know what is still useful/the best way to do things. When I get the time to, I want to put up a webpage that explains the main state-of-the-art usages of the Yubikey, with step by step instructions for the major platforms
unixhero 5y ago
Do you mean the TPM hardware Key?
bennyp101 5y ago
Yep, I followed the guide here: https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide Means I can SSH into any box that has that key on it, or push/pull repos from anywhere as long as I have a yubikey with me. I also used https://www.jabberwocky.com/software/paperkey/ https://www.jabberwocky.com/software/paperkey/ to make a backup, and have that and a spare yubikey stored elsewhere securely. (You can create the key on the yubikey directly, but then I think it's not possible to have a backup yubikey)
teekert 5y ago
https://www.akamai.com/us/en/products/security/akamai-mfa.jsp https://www.akamai.com/us/en/products/security/akamai-mfa.js... ?
lxgr 5y ago
Besides all the suggestions for GnuPG/OpenPGP-based SSH keys, there's also "-O resident" for FIDO2-based keys. This also stores the private key on the security key itself, removing the need for the key handle file. For more details, see the release notes for FIDO2 on OpenSSH: https://www.openssh.com/txt/release-8.2 https://www.openssh.com/txt/release-8.2
arianvanp 5y ago
Yes; See the tutorial on Resident keys here: https://www.yubico.com/blog/github-now-supports-ssh-security-keys/ https://www.yubico.com/blog/github-now-supports-ssh-security... With resident keys you can load the ssh key description from the key directly into the ssh-agent. $ ssh-keygen -t ecdsa-sk -O resident $ ssh-add -K $ ssh git@github.com
brnt 5y ago
I have my private key in a Keepass database, and with a keypress Keepass(XC) loads it into my agent. After a time that you specify, it unloads it automatically. I use a U2F key now, and that key I just have in ~/.ssh. It's useless without my U2F fob anyway. (Right?)
- tialaramex 5y ago
  Yes, you are correct that it is useless without your physical Security Key. Technically what's happening is that the valuable private key is in a sense in that file you're not worried about. But, you're safe not worrying about it, because it was encrypted by the Security Key, and only the Security Key knows how to decrypt it, so even though in one sense it's the private key and very important, because it's encrypted it's not a big deal if anybody learns it, as they couldn't possibly decrypt it. The contents of the file are given back to the Security Key when you use SSH to connect to (say) GitHub and in fact it will decrypt them to discover your private key, then use it, and then forget it again immediately, but it could (hypothetically) instead store a library of all credentials and use the random contents of the file to just look up the right credentials in the huge library. That would cost $$$ and Security Keys are (relatively) cheap. It's OK to completely forget that technical description, the designers of Security Keys specifically intended that you needn't care how the magic is done, I have explained it only to reassure anyone puzzling how this could possibly work.

0xbadcafebee 5y ago

PATs are still superior to SSH keys because 1) PATs allow more fine-grained access control 2) HTTPS is more widely available through firewalls and proxies 3) SSH without certificates is more vulnerable to MITM than HTTPS (with certificates) 4) it's easier to specify different PATs for different remote repos than it is different SSH config aliases for different remote repos. Yet people still prefer SSH because........ ? And since the SSH private key used in this way is merely a pointer to a security token, it doesn't matter if it gets compromised. This is an interesting way to continue the status quo of not explaining to users how to create SSH keys using the new SSH key format (which prevents password cracking vulnerabilities in the old key format).

vbezhenar 5y ago
I’m surprised that there’s no standard way to get a server SSH public key via HTTPS. I have to google for the gitlab key fingerprint and the expected result is not easily found, just to ensure that my first SSH connection is secure. Something like /.well-known/ssh/ed25519.pub would suffice, I guess.
- praseodym 5y ago
  There is an SSHFP DNS record for this purpose, which should be just as secure with DNSSEC enabled. https://en.wikipedia.org/wiki/SSHFP_record https://en.wikipedia.org/wiki/SSHFP_record
- 0xbadcafebee 5y ago
  Well if you could do that, you would just use TLS. The public-key crypto used by SSH is a relic of when it was ridiculously expensive to get an SSL certificate for each of your routers and backend servers, but people still needed something more secure than Telnet.
c0l0 5y ago
> 3) SSH without certificates is more vulnerable to MITM than HTTPS (with certificates) Why would you claim that? As long as any CA with its root certificate in your trust store can vouch for any identity, I would argue that TOFU (where you verify the remote resource's key is in control of the identity you intend to connect with) is less prone to having your connection MITM'd, since the attacker would have to either break the underlying cryptography, or exfiltrate the remote's private key. With the CA system in place, you "just" need to get another CA to sign for the identity you would like to spoof. Not saying it's easy, but for the proverbial "nation state"-level attacker (maybe with their own CA root already in your trust store :)), it's certainly easier to do that than to break RSA or EC.

dochtman 5y ago

I use Secretive to authenticate to SSH (including GitHub) with my Mac’s TouchID. Feels like this is (almost) as secure, while being more convenient (no extra hardware required). Of course it is a Mac-only solution.

viraptor 5y ago
Other systems allow something similar using TPM. Both Linux and Windows can use a hardware non-exportable key with SSH that way. It doesn't allow for the touch verification on use, but it's still better than having a file in the disk. Security scale would be: - key in a file - TPM - touchid - hardware gpg/SSH key - hardware u2f key
- mercora 5y ago
  are keys in the TPM really securely stored and accessed? can i trust those to only be used by myself by i.e. providing a password or similar? i also think touchid should rank even lower because its likely somewhat easy to forge.
  - viraptor 5y ago
    TPM keys are not accessible once imported or generated. You only get access to operations like encrypt/decrypt on them. Those are also normally accessible only by the root user, so you use some kind of proxy with an extra step (like a password) to make them available to the user. I'm not sure what you mean by touchid being easy to forge.
    - mercora 5y ago
      so that does mean once i have access to the computer the keys are somewhat free to use. thus i am authenticating the device not the user which is kind of an important distinction... IMHO this is not as secure as storing the key encrypted on a drive where its only accessible using a passphrase. It is just harder or maybe even impossible to exfiltrate the key but you really don't need to do that in order to use it. i might be wrong though. My remark about touchid came from the fact that fingerprint scanning is inherently insecure because it is trivial to fool most devices into thinking you got a matching fingerprint using something that was touched and left a mark and some glue.

useryman 5y ago

Other than being a random untrusted USB device, is there any reason to not use the cheapest generic U2F device you can find? I've been wanting to start using them for a while, but yubikeys are too expensive for me to get a bunch of.

danieldk 5y ago
I would try to find a key that supports ed25519, since there are concerns about the NIST curves used in ecdsa: https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt#n4 https://git.libssh.org/projects/libssh.git/tree/doc/curve255...
- brnt 5y ago
  Remember that Github U2F key 6 years ago? It just supports the ecdsa keys... I feel a tiny bit grumpy that it took 6 years for me to be actually be able to use the thing for anything important and then to discover it's already outdated. I hope many services will support them nonetheless.
- darkblackcorner 5y ago
  I've Kickstarted Solo V2: https://www.kickstarter.com/projects/conorpatrick/solo-v2-safety-net-against-phishing https://www.kickstarter.com/projects/conorpatrick/solo-v2-sa... Still in production ATM but will support ed25519, and is open source
comboy 5y ago
What problem are you trying to solve? Yes you can get one for $10 instead of yubico's $20, but yubico's have been researched the most and importantly they are very reliable. Many people successfully abuse them and while you always should add a pair of them giving you a backup, it would be a pain if it would stop working. I'm asking because I'm curious about use case where you think you need them (even a bunch), but you think they are too expensive compared to value which you are trying to protect. Reliability would be a good enough reason to me even ignoring all security aspects.

chiph 5y ago

I just made a suggestion to dasKeyboard that they put a place to dock your Yubikey on top of their keyboards, since people will be touching them much more often now.

kiallmacinnes 5y ago
By "place to dock", you mean like a USB port or something else? Lots of keyboards obviously have that already - including at least some of the Das Keyboards (mine does...)
- chiph 5y ago
  Yes, but not on the back like they have (on some models) but on the top. If your key is in one of the rear USB sockets, when you press down to activate it it will stress the port (it acts like a lever). I was thinking on the top, parallel with the surface. Lay the key on the keyboard, slide it to the left to insert into the socket. When you press on the key, the force gets transferred through the key onto the keyboard, and so no flex or stress on the socket.

hnarn 5y ago

I'm going to ask a naive but honest question: what is the security benefit of a piece of "key-hardware" over a passphrase protected key stored on a "normal" storage device? I understand that for someone that moves between multiple physical machines it may be a benefit of convenience, but what threat vector does a physical key eliminate that exists for passphrased "normal" SSH keys?

krab 5y ago
Malware shouldn't be able to silently copy the key. Usually you have to touch the device to confirm usage. Even if the malware got your one time password when you thought you confirmed a legitimate operation, the attacker wouldn't get persistent access. Edit: Also, most people don't use them, so some attackers won't bother with more complex target.
- FranchuFranchu 5y ago
  The first difference can be negated by using an unplugged storage device to store the key. The second one is trickier since you need to do processing to prove that you have a private key, so you'd have to send the key to your own computer which breaks the whole point. You could use a separate "key" computer who owns the keys and that computer is the one that proves that it has the private key, but at that point you'd be better off using a normal security key since it's basically the same thing.
  - deleted 5y ago
    [deleted]
  - gabeio 5y ago
    Unless I am missing something, security keys never send the private key anywhere so the computer can not access it. Unlike an unplugged storage device which can be read by malware once plugged in, and need to be read into memory by the computer for use.
oprah 5y ago
One obvious thing would be keyloggers?

hjehoadwei 5y ago

I don't understand - what's the new feature here? Yubikeys have always supported SSH authentication, and you have always been able to use that for git. What is the new functionality that Github has added?

xur17 5y ago
Yeah, I'm confused as well. I've been using my yubikey for ssh auth for years now with github and other services.
andrewnicolalde 5y ago
I believe this adds support for the new -sk key types, in which the ssh server checks the presence of a U2F token on the client, rather than using something like gpg-agent to effectively store your SSH keys on the Yubikey.
warhorse10_9 5y ago
Looks like they added the "-sk" options to Git Bash for windows. That seems to be what they are promoting for the most part with this post. Though the title is a bit deceptive.
tialaramex 5y ago
Your Yubikey (but not Yubico's cheaper Security Key product and the dozens of other similar cheaper products) is able to do public key signatures exactly like the ones SSH supports anyway, so GitHub didn't do anything to support those. But modern OpenSSH can do FIDO, the same technology that drives U2F and its replacement WebAuthn, and is in all those cheaper and more popular products. FIDO won't sign arbitrary data with keys, it will only perform a very specific operations and so OpenSSH grew a whole separate set of public key authentication types to support that approach, and GitHub is announcing their support for these extra types. There are some neat features beyond "this makes cheaper devices work" but GitHub mostly does not use them, although they do choose to require that your Security Key verify you are present (typically by touching a sensor or clicking a physical button) whereas your existing Yubikey setup might not be doing that and GitHub can't force you to.

kylehotchkiss 5y ago

I tried this on my macbook pro today - latest OS version. First I installed openssh with brew. Then I found I could barely get the new ssh key working with GitHub, frequently getting `sign_and_send_pubkey: signing failed for ECDSA-SK / invalid format` errors while trying to commit and not actually being prompted to press the Yubikey, despite it being plugged in and ready. I keep my mini Yubikey USB-C in my laptop persistently which I wonder could be the issue. Anybody else having similar issues?

exabrial 5y ago
Yubikeys seem to have multiple modes and have trouble switching between them. For instance in GPG mode, It's very difficult to switch back to U2F mode without unplugging. I wonder if this is your issue
- kylehotchkiss 5y ago
  Interesting! Any ideas of how to log which mode it's in to help debug this further? Would disabling unused modes help prevent this?
kylehotchkiss 5y ago
Upon further investigation (Copy-pasting things from random internet webpages like a good HN would do), running the following two commands seemed to help get the Yubikey SSH running a little more reliably with Github for me, including with Tower.app after making sure it has the correct PATH setup: `eval `ssh-agent -s`` `ssh-add` Without the eval ssh-agent command, `ssh-add` fails to add the ECDSA-SK key since Mac OS' SSH implementation doesn't seem to natively support it. I don't understand how running eval ssh-agent resolves it because that shouldn't persist very long with Mac OS' own SSH agent trying to run.
- beermonster 5y ago
  ssh for macOS has some Keychain integration built into it in lieu of ssh-agent, or something like that IIRC.

Galanwe 5y ago

Maybe I miss something, but I have been using yubikeys (or any pgp key for that matter) for SSH and git since many years already through `gpg-agent --enable-ssh-support`.