Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

If you wanted OpenPGP to protect SSH, you should consider upgrading clients and servers to a modern OpenSSH which can just speak FIDO (which this and other recent Yubikeys support)


sort by: page size:

Support for openpgp is almost there: https://github.com/solokeys/openpgp

Note that the ed25519 is not as easy as it seems, ssh agent doesn’t support it yet. I wrote a couple notes/details in the somu campaign you linked, towards the end.


For the signing problem, both signify (and its clones) and modern OpenSSH (ssh-keygen -Y) do what you want today without all the baggage of OpenPGP, obviously that would mean explicitly choosing to migrate off OpenPGP signatures, but that does not seem unreasonable.

pam_yubico yes.

You can also use this to secure SSHD on servers by delegating to PAM with keyboard-interactive.

I'm waiting for U2F OpenSSH support to trickle down to stable distros but in the meantime pam_yubico is pretty damn good... not to mention you don't have to worry about terminal support since it relies on the yubikey OTP emulating a keyboard.


> Because AFAIK, (Fido) yubikey support is still missing.

Correct, hopefully Microsoft will provide an updated SSH client soon. It only requires recompiling OpenSSH with the correct flags.

Alternatively, use these build instruction for openssh with FIDO for windows:

https://gist.github.com/martelletto/6a7cf806c6433ac9ce71d66a...

> Using either the PKCS#11 support or the gpg applet requires some extra piece of software

For those wanting to do that, here are some ways:

Using a premade dll:

https://github-wiki-see.page/m/mooltipass/minible/wiki/Setti...

Or with a middleware:

https://github.com/mgbowen/windows-fido-bridge

Using the Hello API:

https://github.com/tavrez/openssh-sk-winhello

Given how many people came with their own ways, I believe there's enough demand for Microsoft to fix that.


FYI, openpgp and ssh are already in progress. The stretch goal is mostly to carve out money for ft development.

https://github.com/solokeys/openpgp


If you just want ssh it's even easier to use u2f/fido now since it's built into openssh.

SSH has included file encryption for a few versions now, and iirc supports yubikeys — probably would be more useful a backend than age.

I use gpg-agent, but I agree it is often a pain. I will probably switch to U2F + SSH once more servers have OpenSSH 8.2.

Do you know if this already works with GitHub?


I might add, you can already do this. OpenSSH has had FIDO support for a while now. I've found it to work better than trying to use PGP or PIV/PKCS#11

OpenSSH 8.4 added support for FIDO2. It's literally the same commands (with some different parameters) to take into use as a normal keypair. And FIDO2 tokens are becoming quite affordable. To me 2FA with SSH became a solved problem with that.

Yes, but that would either be a fork of OpenSSH, private or open source (both are possible since it's BSD-licensed), or a different SSH server (which Github is of course free to use, since the protocol is standardized and their scale absolutely justifies any efforts in protecting their SSH host key). But GPs comment was about OpenSSH.

Edit: Apparently OpenSSH's sshd also supports the SSH agent protocol for host keys, and ssh-agent does support PKCS#11 – so I stand corrected!


You can use yubi's PAM modules in conjunction with SSH PAM auth, no need to patch OpenSSH.

https://developers.yubico.com/yubico-pam/


I looked at using this setup once - but the whole setup looked really precarious.

Using U2F in the browser, you just buy the cheapest yubikey, plug it in and it works - any OS is fine.

But to do the same with SSH you've got to buy a particular yubikey, install five different bits of software, adjust a bunch of config files, restart services, adjust your agent autostart files, upload your 'subkeys' (whatever those are)... and that's just to support one OS.

It just seemed like the kind of second-class-citizen setup that barely anyone else is using or testing against, so it'd be constantly breaking down.


Do we need a replacement for SSH? The OpenSSH team is doing an amazing work. Besides making the tool as secure as possible, they are also improving the protocol. The recently added support for encrypt-then-MAC modes is a great step forward.

I'm very proud that we implemented server-side support for the keystroke timing obfuscation mechanism in golang.org/x/crypto/ssh already.

(I just clicked the Submit button! https://go.dev/cl/524775)

It's a small change, but it's a signal that we're much more on top of x/crypto/ssh maintenance, compared to a year ago when we had to scramble to implement rsa-sha2-256/512 support just hours before GitHub (rightfully) dropped SHA-1 support, potentially breaking every x/crypto/ssh client.

The main reason is that thanks to the funding of my clients (https://words.filippo.io/full-time-maintainer/) I was able to hire Nicola Murino, the maintainer of SFTPGo, to pick up maintenance of x/crypto/ssh. This is benefiting both my clients and the whole ecosystem, and is a little step in growing the professional maintainer model.


AFAIK openssh does not use SSHFP (VerifyHostKeyDNS) by default, for good reason.

Also, SSHFP requires DNSSEC, which Github of course does not support. (amongst other shiny new technologies, such as IPv6... /r).

And even if GH would deploy DNSSEC, it'll still be opening you up to a host of other attack vectors that come with DNS based trust anchors.


From the sshguard site: "Started for SSH, now protects a wide range of services out of the box"

Oh, it's just U2F? You want FIDO2 with resident key support to get the really nice OpenSSH workflow (plug the key in to a new computer, run ssh-add -k, now you can SSH to all your computers).

Use an older version of OpenSSH then.
next

Legal | privacy