Developers Start Debating Whether To Block Password-Based Root SSH Logins For Fedora 31

[zamadatix]

*wifi network

ethernet isn't encrypted.

Most consumer hardware doesn't support MACsec hardware offloading but wpasupplicant will gladly configure software based MACsec (which has been in kernel since 4.6) all the same.

[EarthMind]

Aside from disabling root logins, there's also the option of 2FA: https://tutorials.ubuntu.com/tutorial/configure-ssh-2fa

[MrMorden]

One of the first things I do is check sshd_config when I bring up a new box, or get a new server, to make sure root logins are not permitted, and password logins are permitted. (Yep, I've seen such anal defaults).

Why the heck would you permit password logins? If the system isn't in a Kerberos realm, there's always SSH keys/certificates.

[aht0]

.. I'm going to change the port to something totally different. However, I do think blocking password-based root ssh logins is a very good idea as a default setting.

Even when you set custom SSH port, finding it out is trivial. All it takes is nmap scan on your external IP.

[gens]

I find it... interesting how fedora folk tend to shovel things like flatpack onto others in the name of "security", all the while sacrificing basic security in the name of minor convenience.

PS
I highly recommend to everyone who uses ssh to change the default port (as schmidtbag suggested) and disable root logins.
The "chinese" are scanning the internet and are trying mainly "root", "admin", and such default accounts. This practically stops the bots.

[schmidtbag]

Even when you set custom SSH port, finding it out is trivial. All it takes is nmap scan on your external IP.

True, but that's only if you're trying to hide from someone specifically, in which case you've got worse things to worry about than someone finding your ssh port. When it comes to these bots that try to brute-force hack into your PC, I've found they don't attempt to break in once you change the port.

[Slithery]

Even when you set custom SSH port, finding it out is trivial. All it takes is nmap scan on your external IP.

If it's a targetted attack then yes, it's pointless.

But 99.999% of the script-kiddies only bother to attempt to brute-force port 22, so switching to a different port makes parsing logs for proper attacks much easier.

[starshipeleven]

Even when you set custom SSH port, finding it out is trivial. All it takes is nmap scan on your external IP.

True for targeted attacks, which is why this is not a protection, but only a way to not waste bandwith with botnet scanning your server.

Trying all ports up to 655000 or something requires a significant amount of time if you are mass-scanning all IPs on the Internet, and the most interesting targets are servers set up by noobs. Very likely to be mostly on default configs.

Therefore the vast majority of botnets scanning for ssh access don't bother to look for it in more than 2-3 known ports, and then give up and go scan the next target.

[aht0]

Not 650 000, just 65535+0 (latter is usable with UDP). Attacker does not have to do initially any port scan. Just OS detection, when result is unappealing (some MIPS home router for example), move on to next public IP, repeat until target returns OS fitting wanted parameters (linux box with possibly some known vulnerable software/kernel version) AND then do either limited port scan or full. Even scanning full ports range it's possible to shave off significant time by using different parameters.

[starshipeleven]

Not 650 000, just 65535+0 (latter is usable with UDP).

Whatever, I don't remember by heart the port numbers.

Attacker does not have to do initially any port scan. Just OS detection, when result is unappealing (some MIPS home router for example), move on to next public IP, repeat until target returns OS fitting wanted parameters (linux box with possibly some known vulnerable software/kernel version) AND then do either limited port scan or full. Even scanning full ports range it's possible to shave off significant time by using different parameters.

You are seriously underestimating the amount of shit available online, and how quickly it changes (especially VM farms that are so trendy, you know).

Running OS detection is too long and does generate too much traffic, also decent businness firewalls (which aren't in short supply) can and will react poorly to that, as it's their job https://nmap.org/book/firewall-ids-packet-forgery.html , so while they aren't your target they will still screw up your detection algorithms.

The most effective way that is least likely to give you false results is just brute checking ssh connection on known ports at each IP you can find, even if they don't answer to pings.

You can do full scans of the whole internet's worth of IPs pretty quickly like that if you have a decently sized botnet (thousands of nodes).