I've always disabled root ssh by setting PermitRootLogin to no in /etc/ssh/sshd_config, and executing usermod -aG wheel NotionCommotion.

Now I question what is the point of doing so? If a brute force breach occurs on a user account with such sudo access, they gain full root access. Guess it still provides some value as the villain needs to guess the specific username and can't just use root. Is it recommended to use strong usernames as well?

Root is a known username and if you try to login as any other username then it'll not be confirmed if that user actually exists or not. This makes it a difficult attack vector, even if the username is A. when you ssh, the system won't tell you if user a exists or not, only that there was a credential failure. If you write a brute force script, do you continue to try user A, even tho it most likely does not exist or try user B? So it is not about using stronger usernames so much as it is about not using common usernames.

EDIT: Anyways, there are other reasons not to use Root, if you directly are logging in as root, then you are defaulting into a superuser shell with full privileges which is a bad practice too. Also would advise actually going down to the level of using Allow/Deny users in SSH config so only very specific intended users are actually allowed.

2 members found this post helpful.

I use root (via ssh) to do my backups.
No password, just keys, but it needs to be root. If someone gets on my network, that is probably the least of my problems.

The user-names are up to you, but this is not a black and white issue. On a home network? As syg00 says, if someone penetrates that, you've got other issues.

In a work environment? NEVER, EVER ALLOW ROOT TO DO ANYTHING OVER THE NETWORK, period. I've heard folks over the years say things like "Well, we've got a small office, so...", and it doesn't matter. If the system(s) are compromised, YOU are the person at fault, and it is up to YOU to fix things. Even if you have a dozen people working in your office...do you KNOW you can trust them? Or is someone a wanna-be hacker, or is 'curious' about the system? They've heard good things about that "rm -fR /" command on a Reddit thread, and since they possibly shoulder-surf the password (or copy your key off your machine when you take lunch), it's a GREAT thing to try. Just too much risk.

Even at home, I don't allow root, because there's just no need for it. Just my $0.02 worth.

1 members found this post helpful.

Generally I set PermitRootLogin either to 'no', or to 'without-password'. I don't allow password logins for sudo users as well for the exact reason you've mentioned. So that when using sudoers I log in as a non-sudo user, then su to the sudo user.

1 members found this post helpful.

If you look at login attempts, they are frequently either user=root, pwd=dictionary or they are user=gloria, pwd=12345678 which are credentials stolen from some website. So you are definitely NOT secure if you allow root password login, or if you have username password combos that are the same as your login anywhere else.

If that is using something simple like rsync then you can set up sudo on the remote machine to handle the very specific request needed. In order to find out what is needed in /etc/sudoers, do the transfer manually with loose settings in sudoers and an unprivileged user account, but use the verbose mode ( -v ) with the SSH client. It will show you exactly what is getting passed, then you can go back into sudoers and tighten it down with the right strings or patterns.

I also disable root SSH login. The reason I do so is that I never have any reason to use root SSH login. Disabling root SSH login simply plugs a potential security breach without causing me any inconvenience. If I had a use for root SSH login then I would enable it.

--------------------------
Steve Stites

Yes, you are correct. This is why replacing root with "admin" users that have full sudo privileges is a step in the wrong direction. Root has special protections in place to prevent unauthorized users from compromising the machine, including but not limited to restricted remote SSH access. Regular user accounts do not have these protections, switching from the classic dumb user + dedicated and protected root account for admin, to the Ubuntu-style "admin" user who can do anything they want is, in my opinion, a move that compromises security in order to make Linux more "Windows-like", and is a mistake.

Sudo has its place, it was created and should be used to grant SPECIFIC users access to run SPECIFIC tasks without requiring the long and complicated root password. Ubuntu's approach to using sudo to create "admin" (aka: god-mode) users is an abuse of what was a good idea, and ultimately compromises security for the sake of convenience.

For a single user home system, you may find that this approach is "good enough". For a work environment, you should ABSOLUTELY enable the root account with a strong password, disable remote root SSH access, and remove unlimited sudo privileges from all users, restricting sudo access to only what's required for the job, if anything.

1 members found this post helpful.

As I have said elsewhere: (IMHO) "ssh," in any and every form whatsoever, should never be directly exposed to the Internet!"

From a security point-of-view, ssh is actually no more "secure" than telnet, because, at the end of the day, both of them offer "the general public": a login: prompt!!

This is equivalent to putting a terminal outside your company's buildings, connected to your company's most-vital internal networks, with a gigantic sign put on top of it: "Hack Me!!"

"C'mon ... what's that thingy that's mounted next to every doorway of every company building?!" Uh huh ... "a badge reader!"

So, "go and do the same thing" – as I have posted here extensively, and now referenced on my Blog: implement OpenVPN with tls-auth! Issue unique digital certificates to your small-handful of authorized users. Then, reconfigure sshd (and, anything and everything else) to listen only to the IP-address that represents OpenVPN, using firewalls to "make damn sure" that no one, other than a valid OpenVPN user, can proceed any further.

(As I discuss in the blog posts ...) Now, not only is your system inaccessible to "anyone but the small handful of users to whom you have issued 'unique, revokable(!), certificates,'" but it is actually invisible!

"Wanna connect to my system?" Sure ... "open the OpenVPN tunnel, and then" ... you can "have at it." (But, of course, we don't allow "password authentication" at all, so I hope that you have yet another certificate, or you won't get very far ... "Sux to be you.")

Otherwise, "so sorry!" It looks (to you ...) as though you've stumbled upon an IP-address, somewhere/anywhere in the vast expanses of the Internet, that, as far as you can see, "might not even have a digital computer associated with it at all!" (And: "you will never, ever know ...") You find no "open TCP/IP sockets ports." Being "a little smarter than the average bear," you also probe for OpenVPN servers, but receive no replies.

3 members found this post helpful.

Good point, but whouldn't that be an overkill for a relatevely uncritical server? Why not just to allow keys-only ssh connections?

The term "foothold" applies here.

This is *EXACTLY* how security breaches happen. The non-critical system is compromised, and gives the attacker what is (essentially), a workstation on the internal network. Behind ANY firewalls/security, because after all..that is one of YOUR systems. So even doing MAC and/or IP filtering goes right out the window, because that system is already on the "it's safe/allow it" lists.

My recommendations to clients are always to lock things down as much as possible, always. For example, if you have one development team working on one of your servers, then you only allow remote sessions on that server to those on that team. Doesn't take much to implement or administer after the fact, but keeps things happy. The IT auditors/data security folks don't whine, your developers have what they need, and your administrators don't need to worry about someone being 'curious' as to what that device is. Unauthorized attempts stick out like sore thumbs. Security is a process.

1 members found this post helpful.

Echoing TB0ne's sentiments here: If your computer reveals any(!) "open TCP/IP socket port," that port will very-promptly be discovered, and it will very-promptly be attacked. Once discovered, these attacks will never cease.

Even if the attacks have no hope of succeeding (e.g. because you are using certificates with ssh, as you should be), you are still, ex minimis, wasting computer resources. Your servers are engaging with hundreds if not thousands of attackers, each and every minute. Even if 100% of those attacks are being deflected, "why are they even being permitted to get that far?"

Take that terminal of yours out of the parking lot, along with its "Hack Me!" sign, and put it on the other(!) side of that badge reader, where it should be.

- - -

The tls-auth feature is both critical and practical, because it determines who is to be allowed to try(!) to connect. Unless you can show that you probably-possess this digital certificate, the OpenVPN server will completely ignore you. It will drop the packet ... and, since there is no socket, this means that it cannot be discovered.

"Hacker-bots" who are searching for "open sockets ports" will never find you. Those few that might also probe for an OpenVPN server will not find you, either, because your server won't bother to respond. The piranhas will simply keep on swimming – because they will never smell blood.

- - -

Authorized users will possess not only the tls-auth credential (which "lets them get into the parking lot"), but also a unique (and non-revoked) badge, which is issued-to and attributable-to only them. Their request to "open the tunnel" will be granted in a matter of seconds. (After they have correctly provided the password ... the encryption key ... that protects their certificate from unauthorized use, if applicable.) But, to the rest of the world, there is nothing there! So far as they can see, "this IP-address is unoccupied."

Having opened the tunnel, however, your your authorized users – and you know each and every one of them by name – can now reach a designated part of your inner world. They can now issue the ssh command ... to a server that can only be reached – or detected – when the tunnel is established. (But Tom, who left the company last week, can't do this anymore, since his badge has of course been revoked.)

(At that point, it's entirely up to you whether you'll allow "this very-small circle of known friends" to log-in as root. After all, no one else on Earth could even try!")

Number of Unauthorized Access Attempts: Z-E-R-O.

- - -

"Is it hard to do?" Well, of course "everything takes a little bit of getting used to," but the general answer is no.

Trust me on this: "When you embrace OpenVPN and use it properly, you will never look back."

- - -

P.S.: "OpenVPN is universal." Runs on Linux, OS/X, Windows, mainframes, and quite a few router appliances. Supplies the same Goodness™ everywhere. "Don't Leave Home Without It.™"

I agree with suicidaleggroll post #9, although even at home I don't have a sudo user.
I have separate root with separate passwd; no remote access for any user.

Nah, I don't think so - I (briefly) considered adding the command to authorized_keys but figured it would piss me off more than it was worth. This is a little ARM based NAS box I had to hack to get running Arch - every so often I find I need to ssh into it.