Hacker News Reader

Comment by traceroute66 | Hacker News Reader

Nice article and all that. Except for one bit.

The lengthly part that talks about defeating SSH dictionary attacks through some fancy PF rules.

Why, in 2021, is anybody still writing articles talking about using passwords with SSH and saying the way to counter password attacks on SSH is to write firewall rules ?

SSH Certificates are the only method anybody should be implementing these days. Its not difficult to setup or maintain, its nothing put pure laziness that people don't do it.

I would have thought someone writing on an APNIC blog would know better.

View on HN

Maybe one day I'll need access from somewhere without my key.

Worth the risk? Probably not.

Two possible answers to that:

     (a) Since you should be storing your private key on a Yubikey/Nitrokey type device, take it with you wherever you go. To be clear, I'm not advocating doing remote admin tasks from an untrusted computer, but in a desperate situation you could do it from a semi-trusted device with a Yubikey/Nitrokey since it won't be possible to extract the private key (and you can set mandatory Touch + PIN policy on the key to prevent malicious software using the hardware token in the background without your explicit consent).  and/or 
     (b) Implement an SSH CA and use that to generate short-lived emergency keys (e.g. https://smallstep.com/blog/ssh-emergency-access/), someone "back home" could send you a short-lived key in a secure manner.

good point, seems the risk IS worth it for a lot of ppl

does a bot know or care your ssh server instance accepts no usernames/passwords? trapping abusive clients that make too many connections for whatever reason is good practice and pf makes it ridiculously easy.

SSH keys are just long passwords.

An SSH password is sent to the server, the server will get the exact password. An SSH private key is not sent to the server.

Exactly, so even if the server is compromised you're not giving it the means to authenticate as you. I think this is a huge plus.

Maybe, but it conceptually it doesn't have to be like that. Often, the password is not sent directly, but its hash is sent (sometimes hashed multiple times), so that the same property is true.

If you send a hash, the hash itself effectively becomes the password. If the server is compromised or the hash is intercepted, the attacker has everything they need to authenticate as you.

With private/public key pairs, the same scenario would result in the attacker only obtaining your public key, which is useless without the private key.

You are correct and I was sloppy in explaining it properly.

In general however, I believe that there is no inherit advantage of certificates over passwords, except for the key-size obviously. Everything else is just convention/standards.

Please see the following page that explains better what I meant when I said that the password should be hashed: https://en.wikipedia.org/wiki/Hash_chain

Using such a mechanism (including salts / challenges) will prevent an attacker using the hash as the password.

> SSH keys are just long passwords.

They're really not, they are private/public key pairs.

Now, sure, if you have a public key, and a guess at a private key - you can check if said guessed private key can derive the public key - but unless you know something no one else does - there's no practical way to enumerate and guess the key space.

But a password may be arbitrarily short and eg a random password of 8 mixed-case letters, numbers and some symbol is "just" log2((26*2+10+10)^8) ~ 50 bits (rounded up). Now that's probably not feasible to brute force on-line (without anyone noticing) - but quite feasible off line (if you're patient - but you don't have to be immortal).

That is why I said "long password". Once it takes over 1000 years to brute force a password, you should have much bigger problems to worry about. On average someone will click on a link in a spam e-mail, or fall for another phishing attack much more frequently than once a 1000 years.

If you "click on a link" you won't type in your secret key (barring insecure ssh-agent set up) - but you might type in your password - for example sending it to a proxying ssh daemon despite a warning about changed host keys.

You "might" upload your private key as well.

He’s not talking about ssh keys, but ssh certs. As provided off the shelf by bless (Netflix), vault, step-ca, etc. they remove the burden of managing keys. For example you can give a single command a short-lived ssh cert that is only valid as long as the command takes to run and then expires.

For clarity, yes I did say certs. But even good old SSH keys are a million miles better than passwords.

I guess I should have said "Public Key Authentication" since that would be more reflective of a desirable baseline SSHD configuration.

SSH certificates can sign a key with an expiration, thats a bit different to a password.

Reply on news.ycombinator.com