3 ms·

Don't worry, they are usually Russian/Chinese ips scanning for 5 year old php exploits. I've been exposing ports to the internet for decades with no issues. Alw

Don't worry, they are usually Russian/Chinese ips scanning for 5 year old php exploits. I've been exposing ports to the internet for decades with no issues. Always block ssh password and keep software relatively up to date. If you are very paranoid, make a vps beacon and remotely tunnel ports from your lab to it. That way you only expose the beacon.

zelphirkalt 2y ago
I wonder, what is the issue with authenticating by password. If you choose a password of lets say 64 random chars, shouldn't it be pretty safe? Or is there something in the password method itself, that is inherently weak?
- cess11 2y ago
  Sure, they probably won't crack that, but there are other things to consider as well. A sshd on IPv4 port 22 that accepts password auth attracts attention, and you'll spend CPU cycles constantly checking credentials from very large database dumps that float around. In my experience it leads to more log noise too, it seems many bots will discard your IP and stop pestering it if passwords aren't accepted. So in practice you'll probably also use something like fail2ban, firewall rules that only allow connections from certain IP blocks, things like that.
- KAMSPioneer 2y ago
  There are still advantages to public key auth. Sibling comment mentioned resource use, but also consider ease of use: are you setting a random 64-character password on every machine that has SSH server installed? Would it not be easier to generate one ed25519 keypair, apply a reasonable passphrase (and/or use disk encryption), and then you have secure auth on all your machines without a password manager? If you're _not_ setting unique 64-character passwords per server, then you should consider what happens if your super strong password is discovered -- an attacker would have access to all your boxes. Compromising a key is harder than compromising a password.
- denton-scratch 2y ago
  > Or is there something in the password method itself, that is inherently weak? Your 64-character high-entropy password might be safe; other users on your system might baulk at memorising/typing in 64 random chars, and choose a less-secure password instead. With SSH keys, that can't happen.
- a_dabbler 2y ago
  The first benefit is some bots won't bother testing passwords as the SSH error message tells them the server doesn't use password auth. The second benefit is if your server is compromised it's quite easy for a rootkit to hijack SSH and steal your password when you login (and then abuse that on other servers you use it), the same is not true with a key and it is much harder for a rootkit to abuse as long as you only use the key on your local machine (there are strong protections against SSH handshake MITM attacks afaik)
- Hendrikto 2y ago
  > Or is there something in the password method itself, that is inherently weak? You have to send your password/hash. With PKC, your private key never leaves your device. It can even live on a separate security key. All you ever send are signed messages, never your key.

zelphirkalt 2y ago

I wonder, what is the issue with authenticating by password. If you choose a password of lets say 64 random chars, shouldn't it be pretty safe? Or is there something in the password method itself, that is inherently weak?

cess11 2y ago
Sure, they probably won't crack that, but there are other things to consider as well. A sshd on IPv4 port 22 that accepts password auth attracts attention, and you'll spend CPU cycles constantly checking credentials from very large database dumps that float around. In my experience it leads to more log noise too, it seems many bots will discard your IP and stop pestering it if passwords aren't accepted. So in practice you'll probably also use something like fail2ban, firewall rules that only allow connections from certain IP blocks, things like that.
KAMSPioneer 2y ago
There are still advantages to public key auth. Sibling comment mentioned resource use, but also consider ease of use: are you setting a random 64-character password on every machine that has SSH server installed? Would it not be easier to generate one ed25519 keypair, apply a reasonable passphrase (and/or use disk encryption), and then you have secure auth on all your machines without a password manager? If you're _not_ setting unique 64-character passwords per server, then you should consider what happens if your super strong password is discovered -- an attacker would have access to all your boxes. Compromising a key is harder than compromising a password.
denton-scratch 2y ago
> Or is there something in the password method itself, that is inherently weak? Your 64-character high-entropy password might be safe; other users on your system might baulk at memorising/typing in 64 random chars, and choose a less-secure password instead. With SSH keys, that can't happen.
a_dabbler 2y ago
The first benefit is some bots won't bother testing passwords as the SSH error message tells them the server doesn't use password auth. The second benefit is if your server is compromised it's quite easy for a rootkit to hijack SSH and steal your password when you login (and then abuse that on other servers you use it), the same is not true with a key and it is much harder for a rootkit to abuse as long as you only use the key on your local machine (there are strong protections against SSH handshake MITM attacks afaik)
Hendrikto 2y ago
> Or is there something in the password method itself, that is inherently weak? You have to send your password/hash. With PKC, your private key never leaves your device. It can even live on a separate security key. All you ever send are signed messages, never your key.