Non-standard port
No root login
No password
Fail2ban
Banning every IP that connects to port 22 twice in 10 minutes (twice, because I locked myself out once).
Changing the port number never made sense to me. I could easily just port scan the rest of your host to find a open SSH daemon on another port anyways. Unless you take the time to set up a firewall that has port scan blocking enabled.
Cheap dedis are my drug, and I'm too far gone to turn back.
Just be handsome & respectful and you can access all of my „ports“ whenever you like.
But seriously… In my case:
Disabled root login
Key based access only
Fail2Ban
Amitz, a very stable genius (it's true!) and Grand Rectumfier of the official LESLOS® (LES League of Shitposters).
Certified braindead since 1974 and still perfectly happy.
For multi-user/shared access stuff, generally non-standard port & enforcing key-based auth is good enough.
I have some shared hosting setups for friends/family/clients which needs pw auth so I'll do non-standard port + fairly aggressive fail2ban rules.
I've been getting a lot more firewall-happy in my old age though - the less that's exposed, the better, with how often zero days drop and things can get popped in an instant.
My DNS servers only need port 53 exposed publicly, so that's all that's open to the world. SSH, control panel ports, API endpoints, even IMAP/SMTP ports on some mail servers, etc can all be firewalled to a set of IPs I know I'll have access to (2 common IPs like my main VPNs, plus a cheap VM with a reliable provider).
For you guys that use Fail2Ban. I'm intrigued to know if you still see a lot of blocked brute force activity, and by 'a lot' I mean enough to warrant bothering with Fail2Ban.
I used to use it years ago when 'bashing down the door' style probes would actually slow the system noticeably and fill up auth logs, but these days all I see are low and slow probes from multiple IP addresses much of which would evade F2B anyway.
Sure the log files fill up a little bit, but without a performance/disk impact it doesn't seem worth worrying about if you've disabled password authentication.
I suspect a reason for that is modern probe tools probably take better notice of the 'Authentications that can continue: publickey' responses and go elsewhere if 'password' clearly isn't an option.
Just wondering if I'm lucky, as I haven't seen an impactful SSH probe in years, on a number of public facing servers.
@FAT32 said:
Port 22, Root login, Password only, Allow all IPs
#YOLO
not recommended?
who cares! Most people do it this way and don't have backups, then cry bc their data be gone, but once again WHO CARES LOLZ?
This can be considered good, as long as you use a very long and extremely complex password, preferably something generated by random.org or other randomization.
gentlemen, is this script recommended? if you use key-based access, which keys and which bit-lengths should you use? RSA/DSA/ECDSA/EdDSA SSH-1 (RSA)
In this line:
sed -i '/PasswordAuthentication/c\PasswordAuthentication no' $CONF_FILE
This command would match the following snippet in the default sshd_config content:
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
and change it to:
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
PasswordAuthentication no
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
which results in a non (human) readable paragraph.
I usually run this command instead:
sed -i -E '/#?PasswordAuthentication\b/ s|.*|PasswordAuthentication no|' /etc/ssh/sshd_config
My command only matches either a PasswordAuthentication directive or a commented directive starting with #PasswordAuthentication, not other occurrences within a longer comment line.
For now I'm using a jump server not for security propose, but because the logs are full of garbage with failed ssh attempts and it's hard to find anything useful in there.
Eventually I'll find a way to disable this failed attempts logging.
Comments
Setting "UsePAM no" can have undesired effects at least on RH distros
Also, you'd prefer to pick a privileged port (<1024)
Non-standard port
No root login
No password
Fail2ban
Banning every IP that connects to port 22 twice in 10 minutes (twice, because I locked myself out once).
For me:
I find this is usually sufficient for most cases.
Changing the port number never made sense to me. I could easily just port scan the rest of your host to find a open SSH daemon on another port anyways. Unless you take the time to set up a firewall that has port scan blocking enabled.
Cheap dedis are my drug, and I'm too far gone to turn back.
Port 22, IPV4, Allow all IPs , Use Fail2ban to protect my machine.
Just be handsome & respectful and you can access all of my „ports“ whenever you like.
But seriously… In my case:
Disabled root login
Key based access only
Fail2Ban
Amitz, a very stable genius (it's true!) and Grand Rectumfier of the official LESLOS® (LES League of Shitposters).
Certified braindead since 1974 and still perfectly happy.
Depends on the server.
For multi-user/shared access stuff, generally non-standard port & enforcing key-based auth is good enough.
I have some shared hosting setups for friends/family/clients which needs pw auth so I'll do non-standard port + fairly aggressive fail2ban rules.
I've been getting a lot more firewall-happy in my old age though - the less that's exposed, the better, with how often zero days drop and things can get popped in an instant.
My DNS servers only need port 53 exposed publicly, so that's all that's open to the world. SSH, control panel ports, API endpoints, even IMAP/SMTP ports on some mail servers, etc can all be firewalled to a set of IPs I know I'll have access to (2 common IPs like my main VPNs, plus a cheap VM with a reliable provider).
🦍🍌
For you guys that use Fail2Ban. I'm intrigued to know if you still see a lot of blocked brute force activity, and by 'a lot' I mean enough to warrant bothering with Fail2Ban.
I used to use it years ago when 'bashing down the door' style probes would actually slow the system noticeably and fill up auth logs, but these days all I see are low and slow probes from multiple IP addresses much of which would evade F2B anyway.
Sure the log files fill up a little bit, but without a performance/disk impact it doesn't seem worth worrying about if you've disabled password authentication.
I suspect a reason for that is modern probe tools probably take better notice of the 'Authentications that can continue: publickey' responses and go elsewhere if 'password' clearly isn't an option.
Just wondering if I'm lucky, as I haven't seen an impactful SSH probe in years, on a number of public facing servers.
This can be considered good, as long as you use a very long and extremely complex password, preferably something generated by random.org or other randomization.
Non standard port. Pub key only. Disable password. Scanning won't do any harm.
gentlemen, is this script recommended? if you use key-based access, which keys and which bit-lengths should you use? RSA/DSA/ECDSA/EdDSA SSH-1 (RSA)
ED25519
Here is a nice article https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54
Ed448 also good or only for paranoids?
The problem with ed25519 is that not everything supports it and it's annoying to have to support two keys.
how can you undo a key procedure that has been set up?
In this line:
This command would match the following snippet in the default sshd_config content:
and change it to:
which results in a non (human) readable paragraph.
I usually run this command instead:
My command only matches either a
PasswordAuthenticationdirective or a commented directive starting with#PasswordAuthentication, not other occurrences within a longer comment line.From active paranoia to complete carelessness..... This kind of thread is giving each of us a way to "belong"
Default port, root login, nopassword, sshguard.
I simply don't see how getting extra paranoid could get you any safer.
IMO sshd_config is pretty sane by default. All I need to change is:
I don't really care about port scanners anyway because modern cryptography keeps them away. But if you do, check out endlessh.
For now I'm using a jump server not for security propose, but because the logs are full of garbage with failed ssh attempts and it's hard to find anything useful in there.
Eventually I'll find a way to disable this failed attempts logging.