SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'll note here that some people can't help but to self-sabotage, as per this article published merely days after details of the xz vulnerability were publicised: https://linuxconfig.org/enable-ssh-r...n-linux-server
It beggars belief!
Beggars beliief indeed! From that very article after demonstrating denied root access...
Quote:
This is a security measure to prevent unauthorized root access to your server. However, with the right precautions and understanding the risks, you can enable root login over SSH safely.
WHY SSH ROOT LOGIN SHOULD BE AVOIDED
Allowing root to SSH directly into a system poses significant security risks. The root account has unrestricted access to all commands and files on a server, making it a prime target for attackers. If an attacker manages to compromise the root password, they gain complete control over the server...
Juxtaposition of paragraphs, indenting and highlighting is from the article.
So to very, very clear - you can safely expose your system to "significant security risks" and open the door for attackers to "gain complete control over the server".
Oh wait! I guess the "safety" they are referring to is that the successful attacker remains safe from any great inconvenience and possibility of discovery. Silly me!
The problem for the rest of us is that many of the people who write such articles may also be the same who pretend to write code or to manage projects.
Last edited by astrogeek; 04-04-2024 at 08:49 PM.
Reason: Better beggaring
This might be of some help to distro maintainers and Slackware could also figure as supported. It's just bash scripts to be run on automated build environments.
I notice that article says nothing about pam. Most Linux systems have pam set up now as a second line of defence. Even Slackware has embraced it. And default pam permissions are usually set to allow root login only from the local console.
I notice that article says nothing about pam. Most Linux systems have pam set up now as a second line of defence. Even Slackware has embraced it. And default pam permissions are usually set to allow root login only from the local console.
That is not true.
If you make the configuration change described in that article and then restart the ssh service, you'll be able to ssh in as root. PAM has no impact on this at all.
If you make the configuration change described in that article and then restart the ssh service, you'll be able to ssh in as root.
The configuration change only made it possible to log in as root using password (which is not necessarily a good idea). The default '#PermitRootLogin prohibit-password' allows root login using public key authentication. I use that.
The configuration change only made it possible to log in as root using password (which is not necessarily a good idea). The default '#PermitRootLogin prohibit-password' allows root login using public key authentication. I use that.
OK, but you need to have a working password login before you can copy your key to the server... And, once set up, that is potentially worse, because if someone gains access to your local root account, then they automatically gain admin-level access to all of the machines you control.
OK, but you need to have a working password login before you can copy your key to the server...
Yes, an earlier root access of some kind is needed to set it up, but it is also needed when adding password authentication to sshd for root.
Quote:
Originally Posted by rkelsen
And, once set up, that is potentially worse, because if someone gains access to your local root account, then they automatically gain admin-level access to all of the machines you control.
The private key can be protected with a passphrase. To change, add, or remove a passphrase of a pre-existing private key: 'ssh-keygen -p'. Then, to avoid typing the passphrase repeatedly, ssh-agent and ssh-add can be used.
Last edited by Petri Kaukasoina; 04-07-2024 at 03:10 AM.
OK, but you need to have a working password login before you can copy your key to the server... And, once set up, that is potentially worse, because if someone gains access to your local root account, then they automatically gain admin-level access to all of the machines you control.
A local password login might not be that bad. It is possible to use netcat to copy ssh public keys. Just check by eye before appending the key to authorized_keys.
And, once set up, that is potentially worse, because if someone gains access to your local root account, then they automatically gain admin-level access to all of the machines you control.
I would still argue that it is worse to allow root logging in with password using ssh, at least on a system which exposes sshd to internet.
The problem with allowing password for root ssh logins is that it makes your machine vulnerable for long term brute force attempts, something like this:
Code:
Apr 5 20:06:50 igor sshd[16831]: Failed password for root from 115.223.43.229 port 39478 ssh2
Apr 5 20:07:08 igor sshd[16847]: Failed password for root from 115.223.43.229 port 46826 ssh2
Apr 5 20:07:24 igor sshd[16849]: Failed password for root from 115.223.43.229 port 53050 ssh2
Apr 5 20:07:38 igor sshd[16859]: Failed password for root from 115.223.43.229 port 59174 ssh2
Apr 5 20:07:53 igor sshd[16867]: Failed password for root from 115.223.43.229 port 36502 ssh2
Apr 5 20:08:08 igor sshd[16873]: Failed password for root from 115.223.43.229 port 43282 ssh2
Apr 5 20:08:39 igor sshd[16894]: Failed password for root from 115.223.43.229 port 55992 ssh2
Apr 5 20:08:54 igor sshd[16902]: Failed password for root from 115.223.43.229 port 60944 ssh2
Apr 5 20:10:15 igor sshd[16936]: Failed password for root from 115.223.43.229 port 38094 ssh2
Apr 5 20:10:30 igor sshd[16946]: Failed password for root from 115.223.43.229 port 42470 ssh2
Apr 5 20:10:48 igor sshd[16955]: Failed password for root from 115.223.43.229 port 50938 ssh2
Apr 5 20:11:03 igor sshd[16957]: Failed password for root from 115.223.43.229 port 55550 ssh2
Apr 5 20:11:23 igor sshd[16966]: Failed password for root from 115.223.43.229 port 35958 ssh2
Apr 5 20:11:38 igor sshd[16976]: Failed password for root from 115.223.43.229 port 41314 ssh2
Apr 5 20:11:54 igor sshd[16990]: Failed password for root from 115.223.43.229 port 48394 ssh2
Apr 5 20:12:09 igor sshd[16992]: Failed password for root from 115.223.43.229 port 53774 ssh2
Apr 5 20:12:25 igor sshd[17000]: Failed password for root from 115.223.43.229 port 60782 ssh2
Apr 5 20:12:41 igor sshd[17002]: Failed password for root from 115.223.43.229 port 37790 ssh2
Apr 5 20:12:58 igor sshd[17014]: Failed password for root from 115.223.43.229 port 45134 ssh2
Apr 5 20:13:13 igor sshd[17022]: Failed password for root from 115.223.43.229 port 50806 ssh2
Apr 5 20:13:30 igor sshd[17028]: Failed password for root from 115.223.43.229 port 57622 ssh2
Apr 5 20:13:46 igor sshd[17034]: Failed password for root from 115.223.43.229 port 35306 ssh2
Apr 5 20:14:01 igor sshd[17042]: Failed password for root from 115.223.43.229 port 41616 ssh2
Apr 5 20:14:15 igor sshd[17046]: Failed password for root from 115.223.43.229 port 46866 ssh2
Apr 5 20:14:34 igor sshd[17058]: Failed password for root from 115.223.43.229 port 54518 ssh2
Apr 5 20:14:48 igor sshd[17064]: Failed password for root from 115.223.43.229 port 59958 ssh2
Apr 5 20:15:06 igor sshd[17070]: Failed password for root from 115.223.43.229 port 39140 ssh2
Apr 5 20:15:19 igor sshd[17078]: Failed password for root from 115.223.43.229 port 44594 ssh2
Apr 5 20:15:38 igor sshd[17086]: Failed password for root from 115.223.43.229 port 52022 ssh2
Apr 5 20:15:51 igor sshd[17088]: Failed password for root from 115.223.43.229 port 57522 ssh2
Apr 5 20:16:10 igor sshd[17096]: Failed password for root from 115.223.43.229 port 36416 ssh2
Apr 5 20:16:23 igor sshd[17106]: Failed password for root from 115.223.43.229 port 42018 ssh2
Apr 5 20:16:43 igor sshd[17115]: Failed password for root from 115.223.43.229 port 49586 ssh2
Apr 5 20:16:57 igor sshd[17123]: Failed password for root from 115.223.43.229 port 55056 ssh2
Apr 5 20:17:16 igor sshd[17137]: Failed password for root from 115.223.43.229 port 34334 ssh2
Apr 5 20:17:30 igor sshd[19065]: Failed password for root from 115.223.43.229 port 39788 ssh2
Apr 5 20:17:49 igor sshd[22100]: Failed password for root from 115.223.43.229 port 46832 ssh2
Apr 5 20:18:03 igor sshd[24634]: Failed password for root from 115.223.43.229 port 52791 ssh2
Apr 5 20:18:20 igor sshd[27587]: Failed password for root from 115.223.43.229 port 59634 ssh2
Apr 5 20:18:34 igor sshd[30065]: Failed password for root from 115.223.43.229 port 37060 ssh2
The article is kind of scary as it targets Ubuntu users which often are novices when it comes to Linux, networking and security. The claim at the end:
Quote:
By following this guide, you can securely set up root access for your server, ensuring that you maintain the highest security standards.
is directly followed by a disclaimer:
Quote:
Always use strong passwords and consider implementing additional security measures, such as SSH key authentication and two-factor authentication, to protect your server.
Implementing ssh keys is really a good idea, but it does not help much if also password logins are allowed, such a configuration will only give the worst of both worlds security wise.
I would still argue that it is worse to allow root logging in with password using ssh, at least on a system which exposes sshd to internet.
I absolutely agree.
Ideally, you should not expose sshd directly to the Internet. I'd recommend using OpenVPN or WireGuard to enable ssh access to remote machines. But even then, I'd continue to disallow passworded root login.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
