> 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.

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.

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

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.

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.

Well yes but headscale?

Attackers attack for a reason. For targets like my servers, they mostly want to install mining software or a DDoS bot. This is detectable via cpu or network monitoring.

I assume if someone wanted to extort money from me after encrypting the disks on my servers, I would also be somehow informed.

why not both? :D

Not sure if this is the best, but I use nftables and this article helped me setup port knocking on a debian server: https://home.regit.org/2017/07/nftables-port-knocking/

Then I added a tripwire feature to make it less likely that a random port traversal would be successful. Here's a snippet of my nftables.conf:

    define KNOCK_PORT1 = 20000
    define KNOCK_PORT2 = 30000
    define KNOCK_PORT3 = 10000
    define TRIPWIRE_PORT1 = 15000
    define TRIPWIRE_PORT2 = 25000
    
    table inet filter {
    
        .
        .
    
        set allowed_ssh {
            type ipv4_addr
            flags timeout
            elements = { $HOME_IP, $OTHER_SERVER_IP }
        }
    
        # track port knocking
        set knock1 {
            type ipv4_addr
            timeout 5s
        }
        set knock2 {
            type ipv4_addr
            timeout 5s
        }
        set banned {
            type ipv4_addr
            timeout 1m
        }
    
        # handle port knocking
        chain raw {
            type filter hook prerouting priority raw;
            policy accept;
    
            ip saddr @banned tcp dport { $KNOCK_PORT1, $KNOCK_PORT2, $KNOCK_PORT3} log prefix "nft banned: " drop
    
            tcp dport $KNOCK_PORT1 set add ip saddr @knock1 log prefix "nft knock1: " drop
            ip saddr @knock1 tcp dport $TRIPWIRE_PORT1 set add ip saddr @banned log prefix "nft tripwire1: " drop
            ip saddr @knock1 tcp dport $KNOCK_PORT2 set add ip saddr @knock2 log prefix "nft knock2: " drop
            ip saddr @knock2 tcp dport $TRIPWIRE_PORT2 set add ip saddr @banned log prefix "nft tripwire2: " drop
            ip saddr @knock2 tcp dport $KNOCK_PORT3 set add ip saddr @allowed_ssh log prefix "nft knock3: " drop
        }
    }

Up to date systems should support it since about 2021

To get started you’ll need OpenSSH version 8.2 or later, and you’ll also need libfido2 installed. Windows users may need to use Cygwin for this.

https://www.yubico.com/blog/github-now-supports-ssh-security...

>Great now you moved the target from sshd to wireguard

I definitely agree with your general sentiment, but in this case wireguard has a much better designed protocol. No response to scans, waaaaay smaller attack surface, no deep integration with a shell that needs to be explicitly disabled depending on use case, no pile of obscure authentication options that you need to make sure to disable...

Sure, but have you heard of reducing the attack surface? If you need to have to be able to log in at all times then youre probably at a scale that you have oncall processes and multiple people that can respond to incidents at a moments notice and having pub key auth enabled only makes sense. If you dont need that then youre probably small enough that that enablig only public key auth or putting it behind a vpn suffices. And having something like wireguard is much better than having something like password login enabled.

Anyone who sacrifices security for convenience is asking for trouble.