Disable SSH Root Login For Improved Security DistroTube
video description
Date: 2022-03-30
Related videos
Comments and reviews: 8
Peter
I work in Linux server security hardening, it's a requirement in benchmarks like NIST and CIS that direct root login is disabled, except for directly on the designated system console (usually the computer screen in the server rack itself). So when I am hardening customer servers, it is always turned off.
With that said, there are some huge administration advantages to being able to run scripts over an SSH connection, and sometimes these need to be run as root. In my home environment, I allow SSH root login but only using private and public key authentication, no passwords and therefore nothing to -brute force- or -dictionary attack-.
I am sure may Linux people use this already but for those that don't, if you SSH to a remote server using keys, there is no login and password prompt, you drop straight into a shell on that remote server if you run -ssh user-remote_host-. SSH also allows you to run commands on that remote server just by adding the path to the command or scipt at the end of that ssh string - so you could use it to run a script or cron job that can do a system check on multiple servers at regular intervals.
For example, in my home environment I exclusively run Gentoo Linux with one server designated as my primary machine. If I make changes to config files on that machine, then all the others have a cron job to rsync those changes over to themselves using an SSH connection with key authentication. (I may change that to using Git repositories having seen Derek's great video on how to set that up.)
There are definitely advantages to having direct root access via SSH but I would always tell people to only use it with keys, and turn of password authentication for access - and then make sure your private keys are protected with strong permissions.
And do bear in mind that if you set this up on a server or two in your work environment, you may contravene security requirements within your business, so you should check with your IT security team first before you set up direct ssh root login with keys.
reply
I work in Linux server security hardening, it's a requirement in benchmarks like NIST and CIS that direct root login is disabled, except for directly on the designated system console (usually the computer screen in the server rack itself). So when I am hardening customer servers, it is always turned off.
With that said, there are some huge administration advantages to being able to run scripts over an SSH connection, and sometimes these need to be run as root. In my home environment, I allow SSH root login but only using private and public key authentication, no passwords and therefore nothing to -brute force- or -dictionary attack-.
I am sure may Linux people use this already but for those that don't, if you SSH to a remote server using keys, there is no login and password prompt, you drop straight into a shell on that remote server if you run -ssh user-remote_host-. SSH also allows you to run commands on that remote server just by adding the path to the command or scipt at the end of that ssh string - so you could use it to run a script or cron job that can do a system check on multiple servers at regular intervals.
For example, in my home environment I exclusively run Gentoo Linux with one server designated as my primary machine. If I make changes to config files on that machine, then all the others have a cron job to rsync those changes over to themselves using an SSH connection with key authentication. (I may change that to using Git repositories having seen Derek's great video on how to set that up.)
There are definitely advantages to having direct root access via SSH but I would always tell people to only use it with keys, and turn of password authentication for access - and then make sure your private keys are protected with strong permissions.
And do bear in mind that if you set this up on a server or two in your work environment, you may contravene security requirements within your business, so you should check with your IT security team first before you set up direct ssh root login with keys.
reply
Chulito
Hey distrohuggers.
Congratulations to the Rawhide Xfce team. Their huge update today works great. 1268 packages, with all the major components getting updates. However. My boot up time is about 3 minutes. Just a black screen. Kind of scary. But once in my Xfce session, things are butter-smooth with Mesa 20.0.0-rc2, and kernel 5.6.0-rc1, and systemd 245-rc1, etc. Wow ! I doubt any other distros have all that today. I doubt many of you have ever used Xfce on Rawhide. It is about as vanilla Xfce as you are going to find. But you get updates on almost a weekly basis of things, that generally do not get pushed in other distros until a new fixed version comes out. Anyways, in early May the upcoming release of Fedora Version 32 ( Xfce spin ), will be almost identical to this set-up on my box, with the main difference being, things that are not rc-versions will be stable and tested by dozens if not hundreds of Fedorans. Once version 32 is out in the wild for a while, things are going to get tweaked and it will be an awesome distro ( if you like the Fedora way of doing things, that is ). I will say this from experience. The Xfce spin of Fedora is like a totally different distro from their Workstation ( Gnome 3.34 ) version. The Xfce version requires more knowledge of Linux and the Fedora way of doing things. Most Linux users may not like that. Microsoft-transients would not have a clue what I am talking about, nor why.
reply
Hey distrohuggers.
Congratulations to the Rawhide Xfce team. Their huge update today works great. 1268 packages, with all the major components getting updates. However. My boot up time is about 3 minutes. Just a black screen. Kind of scary. But once in my Xfce session, things are butter-smooth with Mesa 20.0.0-rc2, and kernel 5.6.0-rc1, and systemd 245-rc1, etc. Wow ! I doubt any other distros have all that today. I doubt many of you have ever used Xfce on Rawhide. It is about as vanilla Xfce as you are going to find. But you get updates on almost a weekly basis of things, that generally do not get pushed in other distros until a new fixed version comes out. Anyways, in early May the upcoming release of Fedora Version 32 ( Xfce spin ), will be almost identical to this set-up on my box, with the main difference being, things that are not rc-versions will be stable and tested by dozens if not hundreds of Fedorans. Once version 32 is out in the wild for a while, things are going to get tweaked and it will be an awesome distro ( if you like the Fedora way of doing things, that is ). I will say this from experience. The Xfce spin of Fedora is like a totally different distro from their Workstation ( Gnome 3.34 ) version. The Xfce version requires more knowledge of Linux and the Fedora way of doing things. Most Linux users may not like that. Microsoft-transients would not have a clue what I am talking about, nor why.
reply
Elio
You should probably disable sshd on your desktop machine: sudo systemctl disable sshd
Once disabled, you can temporarily start sshd when needed: sudo systemctl start sshd
Disabling sshd won't prevent you from using ssh to connect to other machines, so there is no downside to disabling sshd. You should only run sshd when you want to connect to your desktop from another machine.
reply
You should probably disable sshd on your desktop machine: sudo systemctl disable sshd
Once disabled, you can temporarily start sshd when needed: sudo systemctl start sshd
Disabling sshd won't prevent you from using ssh to connect to other machines, so there is no downside to disabling sshd. You should only run sshd when you want to connect to your desktop from another machine.
reply
MinePro120
After many days (and nights), I finished my arch installation (in which I had grub installed). I had everything (including eye-candy) set up. Today, grub failed. It turned out there was a filesystem error. After fsck, there was nothing left. I just wanted to share my pain -.
reply
After many days (and nights), I finished my arch installation (in which I had grub installed). I had everything (including eye-candy) set up. Today, grub failed. It turned out there was a filesystem error. After fsck, there was nothing left. I just wanted to share my pain -.
reply
Stian
Its default off without having that line on Gentoo, but thanks my arch laptop where wrongly configured. Tested with commenting out the line, and now its not allowed. If I did use ssh on external IP I would use a certificate login, next video ? :p jk
reply
Its default off without having that line on Gentoo, but thanks my arch laptop where wrongly configured. Tested with commenting out the line, and now its not allowed. If I did use ssh on external IP I would use a certificate login, next video ? :p jk
reply
Thim
Great tip Derek, way to go for hardening the SSH daemon a bit. But why are people insisting on using :wq when hitting ZZ saves and quits vim in one sweep (you don't even need to hit enter!) and takes less than a split second?
reply
Great tip Derek, way to go for hardening the SSH daemon a bit. But why are people insisting on using :wq when hitting ZZ saves and quits vim in one sweep (you don't even need to hit enter!) and takes less than a split second?
reply
Midhunraj
On my desktop Arch, the value of allowrootlogin is 'prohibit-password'. I googled it and it says that option will not allow any root login with password. So in that case, do I need to change it to 'no'?
reply
On my desktop Arch, the value of allowrootlogin is 'prohibit-password'. I googled it and it says that option will not allow any root login with password. So in that case, do I need to change it to 'no'?
reply
AlucardNoir
Disabling SSH for root on a server is advisable if you have access to the server itself, but I'm not so certain if you're renting the server - as most would be.
reply
Disabling SSH for root on a server is advisable if you have access to the server itself, but I'm not so certain if you're renting the server - as most would be.
reply
Add a review, comment
Other channel videos
24:38
25:39
20:28
14:49
15:58
16:16
16:51