6 ms·

in my first years I've setup a ssh server behind a nat'd network and installed fail2ban. the outcome was that nobody could access the ssh server... probably the

by merb 9y ago

in my first years I've setup a ssh server behind a nat'd network and installed fail2ban. the outcome was that nobody could access the ssh server... probably the same thing would happen, on ssh I've seen so many login attemts even on the smallest VPS I've ever gotten, it's just ridicoulus and important to use non password authentication with ssh (i.e. rsa keys probably 4096b).

logicallee 9y ago
EDIT: I'm withdrawing the question per the accepted answer below. - original comment: >it's just ridiculous and important to use non password authentication with ssh Does this follow from the assumption (that you did not state) "since I won't bother to create a high-entropy password"? Granted its a fairly safe assumption if you're not trying too hard but SSH supports passwords of arbitrary length so I'm curious if there's any other reason, besides not taking the time to create a high-entropy password. ----- Accepted answer below (esp "Because your users cannot be trusted. I run servers which coworkers, all developers, get access to.")
- tokenizerrr 9y ago
  Because your users cannot be trusted. I run servers which coworkers, all developers, get access to. It's either ssh keys or 2 factor authentication because most don't give a fuck about security and will insist using garbage passwords if not prevented from doing so (and then they will complain), even though the use of a password manager is mandatory.
  - logicallee 9y ago
    Perfect answer actually. Accepted and I've updated my original comment.
  - jlgaddis 9y ago
    > ... will insist using garbage passwords if not prevented from doing so ... /etc/security/pwquality.conf is how I prevent co-workers from doing so (on RHEL and derivatives).
    - tokenizerrr 9y ago
      Good to know. We do our user provisioning through an internal portal which enforces everything. The ssh servers als gets configured to disable password login so the only thing passwords are used for is sudo. All web stuff is behind a SSO gateway with password+2fa.
- Cozumel 9y ago
  Using passwords for ssh is just a bad idea, high entropy or not. Keys are the only way to go. The amount of login attempts you get otherwise is just off the scale, on one server there were over 20,000+ failed attempts from my last login in the space of just 10 minutes, all it takes is one lucky guess.
- spiritguy 9y ago
  One thing i was surprised to learn was that whatever you type as your password is actually transmitted to the server for validation! So if you typed the password for the wrong server in.. then you've just leaked that other password to the server you were trying to connect to! uh oh! if you use keys, this doesn't happen.
- eru 9y ago
  Private keys never leave the place they are born. Passwords not so much.
callesgg 9y ago
Just alter the ssh port, i have never received a ssh connection that i can not personally account for.
- secfirstmd 9y ago
  Yep, big advocate of that.
- pilsetnieks 9y ago
  Security through obscurity is not the solution, though. Sooner or later someone does a port scan and finds that port. I've found that it's more efficient just to whitelist the IPs or subnets you might need and denying the rest. Edit: I didn't mean changing the port is a bad thing. You can and should do it, and it will help a bit - just that it shouldn't be the only thing to rely on for your SSH security.
  - avtar 9y ago
    > Security through obscurity is not the solution, though. It's not the only solution but something that can be used to at least drastically reduce the amount of noise in logs. > I've found that it's more efficient just to whitelist the IPs or subnets you might need and denying the rest. That does sound more efficient but what if someone connecting doesn't have a static IP?
    - pilsetnieks 9y ago
      > what if someone connecting doesn't have a static IP? Whitelist your ISPs subnet then, at the very least - there's much lower probability of an attacker coming from just your ISPs, and, of course, use other measures too - I didn't mean that to be the only solution for the problem.
    - scaryclam 9y ago
      We use a VPN for this reason. It works pretty well and means we can lock things down to a single IP while allowing staff to still get on from home.
Karunamon 9y ago
Only exception I can think of is SSHing into things where you’re not allowed to plug stuff in or put files on, like a public terminal of some kind. Password plus a second factor would be more usable there.
noir_lord 9y ago
Literally the first thing I do on any new machine is disable password logins, disable root logins and then punt the SSH port to the top of the range (usually 47999). Every remote machine gets it's own keypair as well and links between machines also get their own key-pairs (key handling is PITA, I've yet to find a method I really like), Keys for work stuff are back up on multiple LUKS memory sticks (two in separate safes, two offsite). I'm fortunate in that work machines are in the pet category not cattle category so we don't need to change keys that frequently (though I will rotate them out yearly anyway).
- jaytaylor 9y ago
  Friendly advice.. It might be better not to disclose this level of detail about your professional security practices, especially when there is a trail of breadcrumbs in the HN profile on your account..
  - noir_lord 9y ago
    Shrug, given how hostile the internet is I fail to see how this increases the risk at all.
    - rimliu 9y ago
      Yeah, I am not so sure how knowing that keys are rotated helps the wannabe attacker. The only "useful" bit would be to look for SSH port up in the range, not much help though.
      - noir_lord 9y ago
        My attitude is short of you having the SSH keys if I can't tell my entire setup and still be secure then I'm relying on obscurity not security.
  - z29LiTp5qUC30n 9y ago
    If you do it right it doesn't matter. The default ip(6)tables rule: drop all packets For example to access my least secured public facing server you need to do the following: 17 port port-knocking to enable crypto port knocking Which enables ssh Which requires a 16K RSA key and TOTP The only accounts that can be logged in have 18 character randomly generated usernames and 255 character passwords. The login accounts have no access to administrative functions. So you'll need to su to an administrative account and guess the 255 character password or have a zero day exploit that can bypass SELinux and cryptographically signed white-listing of binaries.
z3t4 9y ago
Don't forget about ipv6 if you have that enabled.

by merb 9y ago

logicallee 9y ago

EDIT: I'm withdrawing the question per the accepted answer below. - original comment: >it's just ridiculous and important to use non password authentication with ssh Does this follow from the assumption (that you did not state) "since I won't bother to create a high-entropy password"? Granted its a fairly safe assumption if you're not trying too hard but SSH supports passwords of arbitrary length so I'm curious if there's any other reason, besides not taking the time to create a high-entropy password. ----- Accepted answer below (esp "Because your users cannot be trusted. I run servers which coworkers, all developers, get access to.")

tokenizerrr 9y ago
Because your users cannot be trusted. I run servers which coworkers, all developers, get access to. It's either ssh keys or 2 factor authentication because most don't give a fuck about security and will insist using garbage passwords if not prevented from doing so (and then they will complain), even though the use of a password manager is mandatory.
- logicallee 9y ago
  Perfect answer actually. Accepted and I've updated my original comment.
- jlgaddis 9y ago
  > ... will insist using garbage passwords if not prevented from doing so ... /etc/security/pwquality.conf is how I prevent co-workers from doing so (on RHEL and derivatives).
  - tokenizerrr 9y ago
    Good to know. We do our user provisioning through an internal portal which enforces everything. The ssh servers als gets configured to disable password login so the only thing passwords are used for is sudo. All web stuff is behind a SSO gateway with password+2fa.
Cozumel 9y ago
Using passwords for ssh is just a bad idea, high entropy or not. Keys are the only way to go. The amount of login attempts you get otherwise is just off the scale, on one server there were over 20,000+ failed attempts from my last login in the space of just 10 minutes, all it takes is one lucky guess.
spiritguy 9y ago
One thing i was surprised to learn was that whatever you type as your password is actually transmitted to the server for validation! So if you typed the password for the wrong server in.. then you've just leaked that other password to the server you were trying to connect to! uh oh! if you use keys, this doesn't happen.
eru 9y ago
Private keys never leave the place they are born. Passwords not so much.

callesgg 9y ago

Just alter the ssh port, i have never received a ssh connection that i can not personally account for.

secfirstmd 9y ago
Yep, big advocate of that.
pilsetnieks 9y ago
Security through obscurity is not the solution, though. Sooner or later someone does a port scan and finds that port. I've found that it's more efficient just to whitelist the IPs or subnets you might need and denying the rest. Edit: I didn't mean changing the port is a bad thing. You can and should do it, and it will help a bit - just that it shouldn't be the only thing to rely on for your SSH security.
- avtar 9y ago
  > Security through obscurity is not the solution, though. It's not the only solution but something that can be used to at least drastically reduce the amount of noise in logs. > I've found that it's more efficient just to whitelist the IPs or subnets you might need and denying the rest. That does sound more efficient but what if someone connecting doesn't have a static IP?
  - pilsetnieks 9y ago
    > what if someone connecting doesn't have a static IP? Whitelist your ISPs subnet then, at the very least - there's much lower probability of an attacker coming from just your ISPs, and, of course, use other measures too - I didn't mean that to be the only solution for the problem.
  - scaryclam 9y ago
    We use a VPN for this reason. It works pretty well and means we can lock things down to a single IP while allowing staff to still get on from home.

Karunamon 9y ago

Only exception I can think of is SSHing into things where you’re not allowed to plug stuff in or put files on, like a public terminal of some kind. Password plus a second factor would be more usable there.

noir_lord 9y ago

Literally the first thing I do on any new machine is disable password logins, disable root logins and then punt the SSH port to the top of the range (usually 47999). Every remote machine gets it's own keypair as well and links between machines also get their own key-pairs (key handling is PITA, I've yet to find a method I really like), Keys for work stuff are back up on multiple LUKS memory sticks (two in separate safes, two offsite). I'm fortunate in that work machines are in the pet category not cattle category so we don't need to change keys that frequently (though I will rotate them out yearly anyway).

jaytaylor 9y ago
Friendly advice.. It might be better not to disclose this level of detail about your professional security practices, especially when there is a trail of breadcrumbs in the HN profile on your account..
- noir_lord 9y ago
  Shrug, given how hostile the internet is I fail to see how this increases the risk at all.
  - rimliu 9y ago
    Yeah, I am not so sure how knowing that keys are rotated helps the wannabe attacker. The only "useful" bit would be to look for SSH port up in the range, not much help though.
    - noir_lord 9y ago
      My attitude is short of you having the SSH keys if I can't tell my entire setup and still be secure then I'm relying on obscurity not security.
- z29LiTp5qUC30n 9y ago
  If you do it right it doesn't matter. The default ip(6)tables rule: drop all packets For example to access my least secured public facing server you need to do the following: 17 port port-knocking to enable crypto port knocking Which enables ssh Which requires a 16K RSA key and TOTP The only accounts that can be logged in have 18 character randomly generated usernames and 255 character passwords. The login accounts have no access to administrative functions. So you'll need to su to an administrative account and guess the 255 character password or have a zero day exploit that can bypass SELinux and cryptographically signed white-listing of binaries.

z3t4 9y ago

Don't forget about ipv6 if you have that enabled.