6 ms·

What has helped me more than fail2ban with reducing login attempts by many orders of magnitude is changing default SSH port from 22 to something in 10000-30000

What has helped me more than fail2ban with reducing login attempts by many orders of magnitude is changing default SSH port from 22 to something in 10000-30000 range.

atoav 5y ago
Additionally it might be a good idea to forbid password logins altogether by adding this line in /etc/ssh/sshd_config: PasswordAuthentication no Of course you should make really sure to actually have a working public key in your users "~/.ssh/authorized_keys" file and/or in "/root/.ssh/authorized_keys" otherwise you might lock yourself out of the server. But the point here is: given the choice, you should never log in regularily with a ssh password if you can also use a key.
- Rygian 5y ago
  Newbie question here: how is a private key stored in a device I can easily lose more secure than a (long and sufficiently random) password that I've memorized and can type down only when intended?
  - hansel_der 5y ago
    passwords are a symetric key, hence if the server is compromised, so is the password. with asymetric keys, a compromise of the public key is no problem. but you are right, key-files on a disk are more vulnerable to theft than secrets in your head. keyfiles with a password ontop are most secure but also most uncomfortable.
    - zamfi 5y ago
      > passwords are a symetric key, hence if the server is compromised, so is the password Pretty sure that’s not how it works, iirc passwords are stored one-way encrypted. And if it were true, then anyone with root access to a box could comprise every other (Unix) user’s key, which seems like a potentially bigger problem…
      - hansel_der 5y ago
        pretty sure passwords are sent to the server in a way that reveals the actual password to the server. any chance you are thinking about key-agent?
      - atoav 5y ago
        Passwords are (or rather should be) indeed stored using crypt. However at login the provided password needs to be compared to the hashed one, which means the clear text password needs to be rehashed. I am not sure this happens on the client.
        wang_li 5y ago
        It definitely doesn’t happen on the client. If it did then the server’s password file would effectively be plaintext.
        zinekeller 5y ago
        > If it did then the server’s password file would effectively be plaintext. Send seed and hashing parameters to the client, then client does hashing, client sends hash, server compares hashes. It's vulnerable to replay attacks, but it's the same with client sending plaintext password to server (assuming that you're not using SSH or similar).
        dsr_ 5y ago
        You two are working your ways towards defining a zero-knowledge password proof: https://en.wikipedia.org/wiki/Zero-knowledge_password_proof https://en.wikipedia.org/wiki/Zero-knowledge_password_proof I think SRP is the most widely implemented version. https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
        throw0101a 5y ago
        Note that SRP is an older protocol, and things have moved on from there. See various PAKE algorithms: * https://en.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
  - SahAssar 5y ago
    For one a key is not transmitted over the network but the bigger reason is that most people don't use sufficiently long, random and unique passwords. If you are running a server where only you SSH in and you use a long random and unique password you are probably fine but for most people it's just easier to use keys at that point since it is not a lot easier to use long random and unique passwords than it is to use keys. One upside to keys is also that since the server does not have your private key you don't need to rotate it if that server is hacked so you can reuse the same key for multiple servers and services. If you reuse the same long random password it only takes one of those servers/services to be hacked for you to be compromised on all of them.
    - Sebb767 5y ago
      Adding to that, some servers might have a secondary user with a weak password that was created by an installer or an admin for testing purposes. Disallowing password login prevents others from exploiting these accounts.
      - SahAssar 5y ago
        Agreed, that's why I put "If you are running a server where only you SSH in" but maybe I should have been more clear about it.
  - Aldipower 5y ago
    If you plan to store your private key on a device you can loose the key itself should have a password too. So the attacker needs still a password to unlock the private key. This is actually a good idea in general. Securing the private key with a password.
    - 3np 5y ago
      Nitpick: passphrase, not password
      - atoav 5y ago
        Nitpick: if you have a password manager it doesn't matter
        3np 5y ago
        Well it kind of does.. A password is validated, and if you lose it there is usually some recourse. Reset or whatnot. It may be a hassle but always possible somehow. If you lose a passphrase, no one can help you even if you hit HN front page and /r/all with a sob story. So backups and availability have a different cruciality. Also if you store a private key on the same medium as a password store with weak encryption or key that contains the passphrase, they key can't be considered as strong anymore. There are practical reasons to make a distinction and mistakes can be expensive.
      - Aldipower 5y ago
        Thanks, yes, passphrase is the correct word. :)
    - makach 5y ago
      if you lose your key, make sure that local (not remote) login is the recovery method. locking yourself out is a real thing.
    - jgalt212 5y ago
      passwords all the way down. /s
  - ahepp 5y ago
    Use one key pair per device. If you lose the device, remove the associated public key from the server's authorized keys. Using a password on they key isn't a bad idea either.
  - nijave 5y ago
    It's a good idea to encrypt devices you could potentially lose anyway. Besides private keys, they probably contain session tokens, API keys, and other things--especially those saved by the web browser (cookies, cache, local storage)
- cube00 5y ago
  Just be aware if you do this and your cloud provider only offers direct terminal (eg. via VNC) as a fail safe you'll be unable to use your certificate in case of some problem with your private key or a firewall issue blocking SSH. A reasonable middle ground might be use a certificate as your daily driver and keep a 100+ long random character password as a "break glass" backup.
  - m4lvin 5y ago
    I think most consoles that cloud providers offer are attached via virtual serial consoles (ttys) and not via SSH. So you can disable passwords for SSH but still use them via the cloud provider remote console. At least for KVM based virtual servers that I have this is the case.
  - phaer 5y ago
    "direct terminal" access, even via VNC, ipmi, whatnot would still allow one to login locally as root, "PasswordAuthentication No" only affects sshd, not pam.
  - willis936 5y ago
    I caution the 100+ character password for this use case. Some VM / VNC combos don't have clipboard integration. Diceware is sufficient and imo the right choice for any password that might have to be entered by hand.
- UI_at_80x24 5y ago
  100% agreed, and it's the first setting I change. In addition to that I have found that using the setting: AllowUsers "example_account@aaa.bbb.ccc.ddd" (If you are connecting from a static IP) Will cut down on log spam and connection initializations by a tremendous amount.
INTPenis 5y ago
I do the same simple trick but I'd suggest 1022 instead. It's barely used, and it's below 1024 range meaning no other non-root actor on your system can listen on it and start harvesting credentials.
cube00 5y ago
Keep in mind the danger that if the SSH server crashes other non-privileged users on that box can launch a fake server on that >1024 port to take its place.
- abdusco 5y ago
  Huh. I wasn't aware of this vector. My servers only have `root` and my own sudo user, (and other default system users). I also run all apps on Docker. I don't think this would be an issue for me.
- nijave 5y ago
  I guess you could probably setup a port rewrite firewall rule? Translate 10000 to 22, for instance and have 22 blocked for external connections
- bell-cot 5y ago
  But unless the non-privileged users have access to the ssh key files - definitely not allowed in any sane set-up - their MITM sshd will be throwing big, obvious error messages at most of the users. (Which is the mechanism protecting you against MITM's via all sorts of "intercept the packets" network attacks.)

What has helped me more than fail2ban with reducing login attempts by many orders of magnitude is changing default SSH port from 22 to something in 10000-30000 range.

atoav 5y ago

Additionally it might be a good idea to forbid password logins altogether by adding this line in /etc/ssh/sshd_config: PasswordAuthentication no Of course you should make really sure to actually have a working public key in your users "~/.ssh/authorized_keys" file and/or in "/root/.ssh/authorized_keys" otherwise you might lock yourself out of the server. But the point here is: given the choice, you should never log in regularily with a ssh password if you can also use a key.

Rygian 5y ago
Newbie question here: how is a private key stored in a device I can easily lose more secure than a (long and sufficiently random) password that I've memorized and can type down only when intended?
- hansel_der 5y ago
  passwords are a symetric key, hence if the server is compromised, so is the password. with asymetric keys, a compromise of the public key is no problem. but you are right, key-files on a disk are more vulnerable to theft than secrets in your head. keyfiles with a password ontop are most secure but also most uncomfortable.
  - zamfi 5y ago
    > passwords are a symetric key, hence if the server is compromised, so is the password Pretty sure that’s not how it works, iirc passwords are stored one-way encrypted. And if it were true, then anyone with root access to a box could comprise every other (Unix) user’s key, which seems like a potentially bigger problem…
    - hansel_der 5y ago
      pretty sure passwords are sent to the server in a way that reveals the actual password to the server. any chance you are thinking about key-agent?
    - atoav 5y ago
      Passwords are (or rather should be) indeed stored using crypt. However at login the provided password needs to be compared to the hashed one, which means the clear text password needs to be rehashed. I am not sure this happens on the client.
      - wang_li 5y ago
        It definitely doesn’t happen on the client. If it did then the server’s password file would effectively be plaintext.
        zinekeller 5y ago
        > If it did then the server’s password file would effectively be plaintext. Send seed and hashing parameters to the client, then client does hashing, client sends hash, server compares hashes. It's vulnerable to replay attacks, but it's the same with client sending plaintext password to server (assuming that you're not using SSH or similar).
        dsr_ 5y ago
        You two are working your ways towards defining a zero-knowledge password proof: https://en.wikipedia.org/wiki/Zero-knowledge_password_proof https://en.wikipedia.org/wiki/Zero-knowledge_password_proof I think SRP is the most widely implemented version. https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
        throw0101a 5y ago
        Note that SRP is an older protocol, and things have moved on from there. See various PAKE algorithms: * https://en.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
- SahAssar 5y ago
  For one a key is not transmitted over the network but the bigger reason is that most people don't use sufficiently long, random and unique passwords. If you are running a server where only you SSH in and you use a long random and unique password you are probably fine but for most people it's just easier to use keys at that point since it is not a lot easier to use long random and unique passwords than it is to use keys. One upside to keys is also that since the server does not have your private key you don't need to rotate it if that server is hacked so you can reuse the same key for multiple servers and services. If you reuse the same long random password it only takes one of those servers/services to be hacked for you to be compromised on all of them.
  - Sebb767 5y ago
    Adding to that, some servers might have a secondary user with a weak password that was created by an installer or an admin for testing purposes. Disallowing password login prevents others from exploiting these accounts.
    - SahAssar 5y ago
      Agreed, that's why I put "If you are running a server where only you SSH in" but maybe I should have been more clear about it.
- Aldipower 5y ago
  If you plan to store your private key on a device you can loose the key itself should have a password too. So the attacker needs still a password to unlock the private key. This is actually a good idea in general. Securing the private key with a password.
  - 3np 5y ago
    Nitpick: passphrase, not password
    - atoav 5y ago
      Nitpick: if you have a password manager it doesn't matter
      - 3np 5y ago
        Well it kind of does.. A password is validated, and if you lose it there is usually some recourse. Reset or whatnot. It may be a hassle but always possible somehow. If you lose a passphrase, no one can help you even if you hit HN front page and /r/all with a sob story. So backups and availability have a different cruciality. Also if you store a private key on the same medium as a password store with weak encryption or key that contains the passphrase, they key can't be considered as strong anymore. There are practical reasons to make a distinction and mistakes can be expensive.
    - Aldipower 5y ago
      Thanks, yes, passphrase is the correct word. :)
  - makach 5y ago
    if you lose your key, make sure that local (not remote) login is the recovery method. locking yourself out is a real thing.
  - jgalt212 5y ago
    passwords all the way down. /s
- ahepp 5y ago
  Use one key pair per device. If you lose the device, remove the associated public key from the server's authorized keys. Using a password on they key isn't a bad idea either.
- nijave 5y ago
  It's a good idea to encrypt devices you could potentially lose anyway. Besides private keys, they probably contain session tokens, API keys, and other things--especially those saved by the web browser (cookies, cache, local storage)
cube00 5y ago
Just be aware if you do this and your cloud provider only offers direct terminal (eg. via VNC) as a fail safe you'll be unable to use your certificate in case of some problem with your private key or a firewall issue blocking SSH. A reasonable middle ground might be use a certificate as your daily driver and keep a 100+ long random character password as a "break glass" backup.
- m4lvin 5y ago
  I think most consoles that cloud providers offer are attached via virtual serial consoles (ttys) and not via SSH. So you can disable passwords for SSH but still use them via the cloud provider remote console. At least for KVM based virtual servers that I have this is the case.
- phaer 5y ago
  "direct terminal" access, even via VNC, ipmi, whatnot would still allow one to login locally as root, "PasswordAuthentication No" only affects sshd, not pam.
- willis936 5y ago
  I caution the 100+ character password for this use case. Some VM / VNC combos don't have clipboard integration. Diceware is sufficient and imo the right choice for any password that might have to be entered by hand.
UI_at_80x24 5y ago
100% agreed, and it's the first setting I change. In addition to that I have found that using the setting: AllowUsers "example_account@aaa.bbb.ccc.ddd" (If you are connecting from a static IP) Will cut down on log spam and connection initializations by a tremendous amount.

INTPenis 5y ago

I do the same simple trick but I'd suggest 1022 instead. It's barely used, and it's below 1024 range meaning no other non-root actor on your system can listen on it and start harvesting credentials.

cube00 5y ago

Keep in mind the danger that if the SSH server crashes other non-privileged users on that box can launch a fake server on that >1024 port to take its place.

abdusco 5y ago
Huh. I wasn't aware of this vector. My servers only have `root` and my own sudo user, (and other default system users). I also run all apps on Docker. I don't think this would be an issue for me.
nijave 5y ago
I guess you could probably setup a port rewrite firewall rule? Translate 10000 to 22, for instance and have 22 blocked for external connections
bell-cot 5y ago
But unless the non-privileged users have access to the ssh key files - definitely not allowed in any sane set-up - their MITM sshd will be throwing big, obvious error messages at most of the users. (Which is the mechanism protecting you against MITM's via all sorts of "intercept the packets" network attacks.)