Hacker News Reader

Comment by exabrial | Hacker News Reader

I thought this was pretty obvious.... but ok, so don't ssh places you're not supposed to?

Why is this obvious? I don't know much about crypto but I'd imagine it's possible for an protocol to not reveal the identity of the authenticating party.

For example a server can send a challenge which requires knowledge of the private key to solve but does not reveal anything from the client on failure.

If the server has multiple authorized_keys it could just send multiple challenges and accept a reply for any of them.

Am I missing something? This seems like a nice privacy feature.

If you don't know the identity of the authenticating party, how does the authenticating party log in to their account?

They tell you which account they want to log in as, which isn't necessarily their global identity they'd like to share with you.

Exactly: you wouldn't be able to ssh git@github.com/repo/proj but rather have to use user@github.com/proj/repo and this would be better.

I really don’t think there’s anything obvious about the fact that logging into an SSH server also exposes other login information stored in your computer. Given that creating a Github account is one of the first things beginner devs are guided towards it’s worth keeping such beginners in mind.

And it’s not so much “places you’re not supposed to” as “places you know haven’t been compromised in any way”, which is difficult to know unless you’re the sysadmin.

Well specifically it is sharing the public keys that you have in your SSH folder. It's like trying all your keys in a a keyhole since you don't know which one gets you in. This is really no fault of SSH - the fault lies completely with Github for sharing all their users' public SSH keys.

…but they're public keys.

This. Exactly what are we afraid of here? It's working as designed.

It's not directly a security problem as in your computer is gonna get hacked, but it can ruin your opsec if you don't want people to realize that you're the person controlling a specific key.

I would hope if you're doing serious opsec you're using ephemeral keys or isolated virtual environments for various endeavors.

Yep. I would also hope if you're 'doing opsec' you would know how your tools work.

You are definitely right in that the public keys themselves don’t present a threat. I think on a penetration test this would show up as “Information Revealed” rather than something that is “Exploitable”. By sharing a username - you might be able to correlate this person to other platforms and technically increase your attack surface area.

For example there was an RCE in iTerm2 in October, whenever tmux integration is turned on (https://nvd.nist.gov/vuln/detail/CVE-2019-9535). It's unlikely you have a good reason to believe your terminal stack is secure.

The fact that people are using this tool regularly and fail to grep a basic understanding of what and how the protocol works in mind blowing.

Is it really? It’s what Github recommends for every new user without explaining in real depth what’s going on.

What if you're supposed to ssh to two different places. but you don't want them to know you're the same person?

If that's important, you'll need to generate two sets of keys, explicitly assign one to each place and set IdentitiesOnly in your SSH configuration.

Most people don't care about this and so I'm comfortable with the default not being IdentitiesOnly

It's probably more surprising for any early adopters of FIDO for SSH, since WebAuthn (to do FIDO on the web) and its predecessor U2F both do ensure your identity can't be correlated between sites, but the new SSH support does not provide that.

Oh, wow, that does surprise me. I haven't gotten around to using FIDO for SSH but I didn't realize it works differently from WebAuthn.

Anyway, yes, I'm also comfortable with the default, I'm just pointing out why "don't SSH places you're not supposed to" isn't a relevant argument.

In WebAuthn the remote site is storing typically three facts about each non-resident WebAuthn credential for a user. It has a cookie (an opaque blob of fixed size, which it was given by the remote FIDO authenticator during enrollment - and it must play this back every time it wants you to authenticate) and a public key (which it will use to confirm your signatures during subsequent login to prove you still have the authenticator), and practicality it probably also stores a name or an icon or something so users can remember which of their credentials is which.

When you enroll your authenticator creates random credentials (made easier by using Elliptic Curve crypto so almost any random bits are a valid key unlike RSA) and then (unless you're using a much more expensive/ sophisticated device or a FIDO2 device in its resident credentials mode) it encrypts its own private key and delivers that as the cookie value. The remote server actually has your private key... but encrypted with a symmetric key that only exists inside your FIDO authenticator so it's actually safe.

OpenBSD's approach to using FIDO for SSH keeps this cookie element locally, not on the remote server. So the actual keys used will be constant across multiple servers and thus could be correlated to track you.

The other effect is that (again because that cookie is on your local client not the remote server like for WebAuthn) you can't use a cheap (non-resident enabled) FIDO authenticator from anywhere except the machine you used to enroll it. The authenticator plus a random (new enough) SSH client don't have enough information between them to get you in, they also need that cookie which is on, say, the laptop you left in a hotel room.

If that use case is essential for you, you can apparently use resident credentials. I haven't tried it, but a newer Yubico Security Key (with the numeral 2 printed on it to signify that it implements FIDO2) should be able to store everything, authenticated with a PIN, so then you can use a new enough SSH client plus that Security Key plus your PIN to log in from anywhere.

Alternatively if you have a cheaper FIDO device or choose not to use the resident mode of a newer one, this does have the effect that you can create different cookies from different laptops and then you can approve the resulting different keys for different purposes if that suits you. It could make sense to approve your company laptop's keys for checkin to corporate Git repos while the personal laptop has your GitHub keys while keeping just one FIDO key on your keychain throughout the day...

Edited to add: Residential credentials for SSH is apparently planned for OpenSSH 8.3, not OpenSSH 8.2 and so not available yet.

How do you know whether you're SSHing to a place you're not supposed to or not? There's no CA telling you that it's legit like there is for https. 99% of people don't manually verify the host key fingerprint.

SSH does support CAs, there's just no PKI in place. But you can totally set up an internal SSH CA and sign the host keys of every server in your company.

Would anything stop you just loading let's encrypt onto it?

Will regular HTTPS certificates work?

No, ssh uses ssh keys to sign keys.

There is a PKI: DNSSEC with SSHFP records.

That's principally a PKI for SSH host keys, which aren't the keys people talk about when we talk about SSH CAs.

Is it really that much more common to sign user keys rather than host keys? I've been quite fond of signing hosts, personally.

When people talk about SSH CA's, they're talking about systems where you are granted access to a fleet of servers not by having your id_rsa.pub copied into a bunch of authorized_keys files through some automated process, but rather by having the whole fleet trust a CA key, and then having the CA key sign certificates for users (typically: through an identity provider). The wins are:

* It's a lot easier to provision users because the per-server configuration is static.

* You can issue short-lived keys for users so that a lost laptop won't be carrying lots of dangerous SSH keys.

* You can force users through your standard authentication flow and get things like MFA without requiring the SSH servers to understand MFA individually.

Outside of this use case, it's not common to sign SSH keys at all. SSHFP isn't widely used; in fact, almost nobody uses it (because almost nobody uses DNSSEC in the first place). But even if you were set up to use it, SSHFP wouldn't do the things we're talking about when we talk about SSH CAs. In fact, it'd be hard to come up with a worse place to put user keys than in the DNS, which is public, even (in fact: especially) with DNSSEC.

Yeah, I've done it for users, but it's basically the same for host keys; you sign the host key with the CA, stick `HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub` in your sshd config, and stop getting prompted to manually verify host keys on connection. Would that not still be called a CA?

I remember a few years back someone was on an onion IRC server advertising "free shells". My first thought was "Ohhhh someone found a nice and juicy client-side security hole! No thanks!"

Reply on news.ycombinator.com