
Public keys are not enough for SSH security - arunc
https://blog.cloudflare.com/public-keys-are-not-enough-for-ssh-security/
======
oefrha
Reading the first paragraph it's not entirely clear to me if the authors
actually understand public key cryptography or SSH public key auth. (I suspect
they do, but they certainly don't make that clear, maybe because FUD is how
you push a product.)

> If your organization uses SSH public keys, it’s entirely possible you have
> already mislaid one. There is a file sitting in a backup or on a former
> employee’s computer which grants the holder access to your infrastructure.

Public keys are public... You mean mislaid a secret key right? And even if an
attacker gets ahold of a secret key file, it's still protected by a passphrase
(unless of course you use an empty passphrase)...

> Should that happen, how would you respond and revoke the lost SSH key?

By removing that public key from authorized_keys.

Edit: To be fair, I missed this qualifier:

> If someone is able to compromise a team member’s laptop, they could use
> _keys on the device that lack password protection_ to reach sensitive
> destinations.

Okay, not using a passphrase is a bad idea, but that doesn't mean "public keys
are not enough for SSH security", right?

~~~
kbenson
You have to draw a line somewhere, otherwise we might as well say "don't run
SSH at all".

If worrying about a private key leaking is that much of a threat, institute
key rotation policies and have people generate a new key pair every month and
push the public key where it needs to go and remove the old public key a month
after that. Agents allow multiple keys, making this easy to handle on the
client side, and if you don't have a way to track and push keys to servers,
you should. The one month overlap should be plenty of time for people to get a
new key generated even allowing for vacations and most extended absences, and
it's not that hard to fix if someone misses the deadline.

~~~
foota
I'm not really convinced that key rotation is an effective mitigation. Sure,
it helps with some classes of threats, but if you're worried about the ones it
does protect from you should imo be worried about the others as well.

Like, it mostly protects against an attacker trying to get access from an old
machine, but doesn't protect from a device with no disk encryption or weak
disk encryption (likewise with key passphrase) being stolen outright within
the month's window, or an old key being found within a month.

~~~
kbenson
> but doesn't protect from a device with no disk encryption or weak disk
> encryption (likewise with key passphrase) being stolen outright within the
> month's window, or an old key being found within a month.

Well, it also doesn't protect against the key being exposed within that month
and used immediately. That's what makes it a mitigation and not a protection.
But against the example class of threats that were presented ("There is a file
sitting in a backup or on a former employee’s computer which grants the holder
access to your infrastructure.") which seems to indicate leaking of private
keys over long periods (and the long period is what makes it non-obvious it's
leaking), I think it works quite well.

The alternative is to move to a centralized authentication system, but that's
got its own set of problems which makes it more of a trade-off than an extra
set of practices which mitigates the problems inherent with the current
choice. For example, there almost always needs to be a way into the server
without network access for network related problems. You're now have the same
problems inherent with managing local logins on servers (albeit a much smaller
set of logins, maybe one), but maybe it isn't through SSH public keys, and is
much harder to change. Will that get rotated? Will that password get changed
after someone leaves if it was shared with them?

------
stock_toaster
Cloudflare trying to inject themselves into the middle of yet another core
infra component. Shameless.

------
gfodor
Other things you can do for smaller teams:

\- When provisioning keys, ensure that team members put a unique, strong pass
phrase on the file

\- Set up two-factor verification via the google Authenticator PAM module

------
manbash
> Should that happen, how would you respond and revoke the lost SSH key? Do
> you have an accounting of the keys which have been generated? Do you rotate
> SSH keys? How do you manage that across an entire organization so consumed
> with serving customers that security has to be effortless to be adopted?

The problem presented above and the solution they offer seem like miles apart.

The number of ssh keys is likely finite in an organization. It shouldn't be
hard to keep track on those.

Instead, you're supposed to integrate a complex process?

Encrypt your data, add a passphrase to the key, have admins keep record.

Does CF have little faith in admins?

~~~
wbl
Diaclosure: I work at Cloydflare. Administering 1 machine easy. 10 machines
with 100 users a bit more effort. 1000 machines and 10,000 users. Hard. That's
on top of integrating with your LDAP source of truth.

~~~
kbenson
No, it's not. I've written multiple key management and push systems over the
last 15 years. It's a 50 line Perl script, if that, and that's with groups and
server roles.

Scales perfectly fine with hundreds of servers and tens of users, but that's
just with a flat text config file, keys separated in their own dir, and no
parallelization.

I've done LDAP auth and querying before, I don't see this being all that hard.

------
PureParadigm
As an alternative solution to the SSH key security concerns raised here, I use
a Yubikey as a smart card for my SSH access. This way, even if my laptop is
compromised, an attacker has to physically steal my Yubikey (and know the PIN
on it).

If interested, I followed this guide to set it up:
[https://github.com/drduh/YubiKey-
Guide/blob/master/README.md](https://github.com/drduh/YubiKey-
Guide/blob/master/README.md)

------
pnako
I was about to joke "Coming soon: SSH through Cloudflare"... but that's in
fact exactly what it is.

You might be able to save money on Cloudflare by literally just mailing all
your keys to the NSA every week.

------
cviecco44
Exposed private keys are are problem. But there are several open source
solutions for this. I recommend keymaster
([https://github.com/Symantec/keymaster](https://github.com/Symantec/keymaster))
as it is designed with madatory 2FA and a user flow that does not require you
to leave the CLI. (I am one of the contributors)

------
regecks
No real mention of key passphrases, except that a team member might forget to
use one.

It seems to me that the title is not really true for individual users or small
teams - modern OpenSSH passphrases are good enough to protect against theft.

~~~
JoeCamel
What is a modern passphrase? Or modern OpenSSH?

------
29athrowaway
[https://en.wikipedia.org/wiki/Tokenization_(data_security)](https://en.wikipedia.org/wiki/Tokenization_\(data_security\))

