[sam_lowry_]

> I'm having hard time imagining those "anywhere" scenarios

Hold my beer.

You ski in the Alps, its noon, and you get an alert that your DB is down.

You know this may happen because of invasive bots, and you know what to do, so you just find a calm spot at the high-altitude cafe, ssh from the phone, find the infringing bot's IPs, block them with ipset and send yourself an email to deal with the problem properly later.

Then you ski happily until dusk, knowing that users won't be affected.

[saurik]

I think "anywhere" here has to mean "any random device you come across", not merely "any strange location", as the premise is being able to log in with just a password rather than a key... I often use my phone to do tasks, but I do it with an ssh key on my phone.

[kenhwang]

Back when I worked from my phone while in the ski lift line, the solution really is to keep an SSH key on the phone if I intended to do any work from it.

If I really had to access work resources from any random device, I'd go through the ordeal of logging into the SSO to log in to the web console to open a temporary cloud SSH session with the multiple layers of 2FA and probably even SecOps manual approvals that's likely required.

[commandersaki]

For some reason I don't mind an ephemeral SSH session on a random device but I'm less likely to do webmail/email.

[doorsopen]

As someone who works with SREs every day, this breaks my heart.

1 - Don't be on-call while going to ski

2 - fail2ban and other automated systems can do this for you

3 - Passwords suck and are typically not regularly rotated unless you're using some centralized IdP

If you're in this situation you have already failed. If you use password auth use 2FA as well, and then I don't cry, it's just toil though.

[sam_lowry_]

1. It breaks my heart to see indie dev spirit die even on HN.

2. it's brittle and too automated to my taste. There may be false positives that I'd fait to review if it was too automated.

3. There should be a very limited set of passwords for your main assets. For instance, one for infrastructure, one for a password manager, one for the safe at home. And they should never be rotated. They are meant to be ingrained in muscle memory and stay with you for many years.

[rstuart4133]

> There may be false positives that I'd fait to review if it was too automated.

On my little vps fail2ban has added over 23,000 ipv4's to it's f2b-ssh ipset. There is no way I'm reviewing that manually.

For what it's worth I don't allow passwords, so there is not a lot of additional security to be gained from fail2ban. I don't use it for that reason. I use it because 100's of login attempts brings my very cheap vps with bugger all RAM to it's knees. I don't particularly care that it runs like a dog when it's on its knees, but the OOM killer taking out the services I actually use it for is a step too far.

> it's brittle and too automated to my taste.

That problem largely disappears when you get rid of passwords. Fail2ban triggers on failures, and allowing passwords means you must tolerate some failures. People don't mistype public keys.

[xorcist]

> ssh from the phone

That strengthens the previous commenters point. That personal phone is not an "anywhere" device but one that already carries the necessary software and can both interface your yubikey or carry your encrypted keys.

A better example would be the same ski trip but where the data connection is bad on nonexistent so you borrow the hotel's computer to make the emergency fix.

We used to do things like that, complete with post trip password rotations. I carried a laminated card in my wallet with the important key fingerprints. But with devices like the yubikey and cheap international data roaming, that has gotten less common.

[sam_lowry_]

A Google or Apple phone carrying encryption keys to my precious servers? Hm... I feel already pwned.

Jokes aside, I can not be bothered installing ssh keys on my phone. Phones change, get broken or stolen. Ssh clients on phones change as well and can not always be relied upon. I want to be 100% sure I can have ssh access to my servers in whatever improbable situation.

As for Yubikey... I used it for a while as a keyboard emulator to generate a string to prepend to my corporate laptop password that had insane strength requirements.

For personal and small business auth... it is too complex and brittle.

And frankly, what's the problem with a strong password? Like... a quote from Netzsche translated in a mix of French and Dutch with a couple special chars thrown in?

[gregjor]

We can all dream up improbable scenarios that will neuter reasonable planning and precautions.

I travel full-time and work remotely, for over a decade. I have lost my phone once. Both Apple and Android phones sync passwords and ssh keys (if you set it up) to their encrypted cloud services. If you get a new phone everything comes back.

I put my most crucial keys and backup codes on a biometric-locked USB key that I protect along with my passport. I have never needed to use it, but in case I lose my phone and can’t get into my cloud account I have that.

I use a Yubikey for 2FA where supported, I have two, one handy and one secured with my passport.

[ycombinatrix]

Yubikey with libfido works beautifully.

>As for Yubikey... I used it for a while as a keyboard emulator to generate a string to prepend to my corporate laptop password that had insane strength requirements.

Wtf? Tell me you don't know how to use a yubikey without telling me you don't know how to use a yubikey.

[sam_lowry_]

I bet you did not know Yubikeys have keyboard emulation mode )

[ycombinatrix]

Lol. I'm pretty sure everyone has a coworker that has accidentally "keyboard emulated" their OTP into a public slack message.

[sam_lowry_]

Another one: you sold an online business and forgot about it until the moment the buyer contacts you asking for a meeting exactly when you decide whether you want to go to the bomb shelter or risk staying in the appartment building so conveniently located next to a damb that protects Kyiv from flooding.

You decide that staying on the 9th floor on the path of cruise missiles to the damb is too risky, pick your good old Toughbook that has enough juice to last until dawn, and go downstairs, asking the buyer over phone to reset the root password and send it over whatsapp.

Once installed in the shelter, you quickly realize the disk is full, clean the logs and give furter instructions to the buyer to pass on to his IT.

[teruakohatu]

Instead: you WhatsApp your public ssh key to the buyer and login once they confirm your key has been added.

I have had to send my ssh pub key over all sorts of messaging platforms.

[sam_lowry_]

No way this person would understand what I want him to do. And if he would not understand, he would grow suspicious. No, no and and no again.

[Volundr]

Just making sure I understand.

You have sold your business but are still responsible for IT support.

You are responsible for IT support but don't already have a defined access path.

The new buyer knows what a root password is and how to gain access to a Linux machine and reset it, but does not know what an SSH key is, or how to check for a full disk.

Despite clearly being a (very specific kind of) novice the new owner is suspicious of the person responsible for his IT giving him instructions he doesn't understand?

[sam_lowry_]

Nope.

It happened once and I hope won't happen again. I make myself available out of courtesy and I made a point that I will not be remunerated outside of the long expired knowledge transfer agreement.

Funnily, I got remunerated this one time with a lavish gift card for Neuhaus, but it only proves the point.

Of course the buyer knew the root password, details of the setup and all passwords reset procedures were part of the deal.

And of course they can reset the password when properly guided, people are not dumb even when they are not software engineers.

OTOH, most people are totaly unaware of Diffie-Hellman key exchange, the roles of public and private keys and have limited patience and even less interest in learning new things in a stressful situation.

And yes, people with money and authority have a particular distrust for people with skills and knowledge.

[Volundr]

> It happened once and I hope won't happen again.

I should certainly hope not. I definitely won't be making "I'm providing free IT support while being bombed to someone who apparently thinks I'm some kind of conman instead of trying to help" a priority scenario in my infrastructure planning.

[cyberpunk]

If I’m skiing in the alps there’s no fucking way I am on call, and you shouldn’t accept it either…

[sam_lowry_]

Can you imagine that some people are their own bosses, with no backup whatsoever?

[cyberpunk]

One person isn't enough to run a business with a 24/7 support requirement.

[sam_lowry_]

Peter Levels enters the room )