Hacker News Reader

Comment by heywire | Hacker News Reader

I've always wanted to disable password based auth, but I am worried that if I need to connect to my machine in a pinch from some random device (wife's phone, borrowed machine from friend, work, etc), that I won't be able to connect. How do people get around this? Keep in mind that I'm talking about home machines and hobby VM instances, I do not manage any production servers or anything.

View on HN

Use a YubiKey Neo keychain dongle: https://www.yubico.com/products/yubikey-hardware/yubikey-neo...

Normally they're used for OTPs or Chrome's FIDO U2F auth scheme, but you can also put them in smartcard mode. If you do this, you can use it as an OpenPGP key, which is also compatible with SSH:

https://www.esev.com/blog/post/2015-01-pgp-ssh-key-on-yubike... https://www.yubico.com/2012/12/yubikey-neo-openpgp/

Just about the only place that won't work is on a phone. Technically it has an independent NFC interface which could probably be made to work with some extra development, but I haven't looked into it.

With newer ssh, you could always switch to two-factor authentication, requiring password and a One Time Password via Google Authenticator or another OTP implementation.

That way a brute force attack would essentially need to gain access to the shared OTP secret in order to be successful (assuming ~few/normal user population. With a 6-digit otp, I suppose the value of otp drops if an attacker can try to log in as ~1 billion users in parallel -- but it's not really a scenario most of us have to worry about).

Another option is to use ssh certificates. As long as you are able to make yourself new user certificates, you can log in. One bonus with certificates is that they can be set to expire, unlike keys.

Put a key on your phone or an USB stick. I make a key for every machine that I have, and that keys never leaves that machine. In addition I keep another key that I can use to get started again if my laptop gets stolen or breaks.

If I lose the phone, there's a pretty good password on that key that should give me ample time to remove access rights for it.

My idea is a USB stick on car keys (my comment) is preferred simply because a phone is a more high value target than your car keys typically. You usually don't leave your car keys "laying around" they are in your pocket although that probably depends on a host of factors. Plus your phone can get snatched out of your hands on the street or taken if you leave it for a second. That's at least the way I view the risk pro and con.

You can put a passphrase on the key and not worry about someone else getting it by stealing your phone, just remove it from authorized keys when you're back at a computer. Unless you're concerned about needing emergency server access while your phone got stolen and hasn't been replaced yet.

But at that point, we're probably also worried about the odds of getting run over by a bus and having amnesia that prevents you from using a password protected key, chance of getting struck by lightning, etc. ;)

Unless you're concerned about needing emergency server access while your phone got stolen and hasn't been replaced yet.

Yes actually. Because it has a copy of my password manager file, which has all the passwords to the various social sites I could use to alert friends that I need a ride home. ;)

definitely always use a passphrase on the key. bonus, if you userify, than you only need to remember your userify console password to get into anywhere, since you can regen a key and replace on all your servers in seconds.

Create a normal user, DON'T add them to the sudo group (or any other special group), and then generate keys for them. Store those keys in some online "cloud" storage (DropBox, Google Drive, OneDrive, et al).

Then if you need to get in, download the key, type in the password, login as that user, and the su up to root by entering the password only you know.

As an additional layer of security you could encrypt the key using AES-256 (e.g. 7Zip archive, Microsoft Office's Word .docx (NOT .doc) format (just drag drop the file into Word, "Encrypt with password") now AES-256 encrypted, others).

Now you have four layers of protection:

- su password.

- Key password.

- AES-256 encryption password.

- "Cloud" storage credentials.

So in short store the keys in some place that you have easy access to by a password. Kind of a version of two factor "something you know and something you have" whereby the "something you have" is the cloud storage device with the key.

While I'm a big believer in defense in depth, I think this adds a lot more complexity on the usability side without really improving the overall security. You'd be better off just protecting the private key with more trials and storing it with whichever cloud storage solution you have the most confidence in.

Use a stepstone. This is really only feasible if you can get a user account some place where they take network security seriously.

(A stepstone is a well-protected server where you can log in with user/pass and use your keys to login to other machines from there.)

Doesn't that have all the problems of password auth, but with one extra step, with it's own failure modes, in between?

I don't think so. A single server sitting behind an advanced firewall/IDS/IPS system and managed by competent IT staff is a much harder target than a multitude of servers I manage myself.

Also note that it's not really an extra step, you put in a ProxyCommand in your .ssh/config file.

ssh keys on USB attached to your physical house and car keys with encryption (say an encrypted volume).

Don't note what machine or where the key has access to either. I know purists will take issue with this but it's a solution to a problem as you have detailed.

Obviously only works from "borrowed machine from friend work etc" unless you can get the key from a machine to "wife's phone".

Don't connect to your servers from machines you don't/shouldn't trust.

Think of it this way. If you created a private key and uploaded it to a public website where everyone could get to it (say you posted it to HN ;-), how exactly is your system less secure than with password based auth?

You still need a passphrase to decrypt the private key. If you bump up the number of trials, you can make decryption even slower. It's going to be harder for someone to crack that than a normal brute force against a password.

Now, if you put that key behind a decently secure storage service that you use TFA to access, that's actually way more secure than just using a password.

Given that, the question ought to be whether you upload the private key to the cloud, or try to manage the private key yourself. Password based authentication shouldn't be one of the options you are considering.

No: An attacker can massively distribute the key cracking effort, and do it offline. That is so many orders of magnitude faster than asking an sshd if the password is correct, even with the flaw discussed here where it isn't rate limited. Without that flaw, you have to start a new TCP connection every three guesses, which is glacially slow compared to cracking the passphrase to decrypt the key.

In general, because you tend to have so much more entropy in a private key phrase (you only need one for multiple logins), and because the private key itself is a nastier nut to crack, the computational effort needed to crack a private key file is just nastier than the password crack. That's the whole point of the design.

Umm... if they are massively distributing the key cracking effort, spawning TCP connections isn't going to be a limiting factor... There is no requirement that the TCP connections be opened sequentially.

They will have to do a session/key exchange hand shake each time, but that shouldn't be more painful than the extra work needed to crack a private key with tons of trials.

Reply on news.ycombinator.com