LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 05-18-2017, 08:06 AM   #1
NotionCommotion
Member
 
Registered: Aug 2012
Posts: 762

Rep: Reputation: Disabled
Should root ssh logon be disabled?


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?
 
Old 05-18-2017, 08:22 AM   #2
r3sistance
Senior Member
 
Registered: Mar 2004
Location: UK
Distribution: CentOS 6/7
Posts: 1,375

Rep: Reputation: 217Reputation: 217Reputation: 217
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.

Last edited by r3sistance; 05-18-2017 at 08:26 AM.
 
2 members found this post helpful.
Old 05-18-2017, 08:27 AM   #3
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 19,705

Rep: Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548
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.
 
Old 05-18-2017, 08:49 AM   #4
TB0ne
LQ Guru
 
Registered: Jul 2003
Location: Birmingham, Alabama
Distribution: SuSE, RedHat, Slack,CentOS
Posts: 23,811

Rep: Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974
Quote:
Originally Posted by NotionCommotion View Post
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?
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.
Old 05-18-2017, 09:22 AM   #5
redfox2807
Member
 
Registered: Jul 2012
Distribution: Debian testing/stable, Gentoo, CentOS 7, Sailfish OS, Android
Posts: 166

Rep: Reputation: 31
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.
Old 05-18-2017, 09:37 AM   #6
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: Fedora 33
Posts: 3,572

Rep: Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006Reputation: 1006
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.
 
Old 05-18-2017, 09:56 AM   #7
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 5,612
Blog Entries: 3

Rep: Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859Reputation: 2859
Quote:
Originally Posted by syg00 View Post
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.
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.
 
Old 05-18-2017, 10:10 AM   #8
jailbait
LQ Guru
 
Registered: Feb 2003
Location: Mineral, Virginia
Distribution: Debian 8
Posts: 7,893

Rep: Reputation: 339Reputation: 339Reputation: 339Reputation: 339
Quote:
Originally Posted by NotionCommotion View Post
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?
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
 
Old 05-18-2017, 10:34 AM   #9
suicidaleggroll
LQ Guru
 
Registered: Nov 2010
Location: Colorado
Distribution: OpenSUSE, CentOS
Posts: 5,573

Rep: Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138
Quote:
Originally Posted by NotionCommotion View Post
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.
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.
Old 05-18-2017, 11:00 AM   #10
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,141
Blog Entries: 4

Rep: Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227
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.

Last edited by sundialsvcs; 05-18-2017 at 11:06 AM.
 
3 members found this post helpful.
Old 05-18-2017, 11:39 AM   #11
redfox2807
Member
 
Registered: Jul 2012
Distribution: Debian testing/stable, Gentoo, CentOS 7, Sailfish OS, Android
Posts: 166

Rep: Reputation: 31
Quote:
Originally Posted by sundialsvcs View Post
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.
Good point, but whouldn't that be an overkill for a relatevely uncritical server? Why not just to allow keys-only ssh connections?
 
Old 05-18-2017, 12:56 PM   #12
TB0ne
LQ Guru
 
Registered: Jul 2003
Location: Birmingham, Alabama
Distribution: SuSE, RedHat, Slack,CentOS
Posts: 23,811

Rep: Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974Reputation: 6974
Quote:
Originally Posted by redfox2807 View Post
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.
Old 05-18-2017, 10:16 PM   #13
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 9,141
Blog Entries: 4

Rep: Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227Reputation: 3227
Echoing TB0ne's sentiments here:
Quote:
"You don't want to give 'The World-Wide Internet' any opportunity ... or even any target!"
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.™"

Last edited by sundialsvcs; 05-18-2017 at 10:28 PM.
 
Old 05-19-2017, 01:11 AM   #14
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 7.7 (?), Centos 8.1
Posts: 17,861

Rep: Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596
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.
 
Old 05-19-2017, 02:06 AM   #15
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 19,705

Rep: Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548Reputation: 3548
Quote:
Originally Posted by Turbocapitalist View Post
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.
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
If root account is removed/disabled, can malware enable root or get just as powerful? Ulysses_ Linux - Security 34 05-08-2017 12:59 PM
Root Account Disabled (not smart) Can not root LOGIN mitchellray Slackware 12 06-30-2009 12:52 PM
Unable to Logon using SSH, something to in /etc therockp10 Linux - Newbie 2 04-26-2008 07:55 PM
ssh logon failure nosbod Linux - Software 2 05-22-2007 07:40 AM
Gentoo Root Issue. Cannot SU or logon to Root Battousai Linux - Distributions 8 11-14-2006 05:54 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 07:25 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration