Linux - NewbieThis 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!
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Unless it's absolutely needed for whatever reason (and even then only on systems within a protected LAN), it's generally best to disable root ssh access in sshd. I certainly wouldn't enable root ssh access on a server with a public IP.
Think of it this way - if root ssh access is not allowed, then for an attacker to brute-force their way into root control of your system, they would need to solve three unknowns: 1) a valid user name on your system, 2) the password for that user, and then once they were on, 3) the root password. If root ssh access is allowed, then all an attacker needs to brute-force is the root password, which unless it's painfully complex, wouldn't be all that difficult if the system didn't have any denyhosts type auto-ban daemon running.
Last edited by suicidaleggroll; 09-23-2014 at 06:01 PM.
as a relative newbie to Debian, I'm wondering if it's secure to connect as Root, via ssh?
It is secure as in "ssh is an acronym for Secure SHell", but it is not good practice.
In general, you want to disable root logins via ssh because they they are a direct path to compromised systems. If disabled, an intruder must first crack the non-root user access, then still crack root access.
I agree with suicidaleggroll. Disable root login via ssh. If the admin(s) have to login as themselves, then SU to root; you get a log of what has taken place in /var/log/secure (on Red Hat & similar distros). This at least provides you the ability to track down who changed what and when.
To give you an idea of why it's a bad idea, here's a little excerpt from my /var/log/secure from this morning:
Sep 23 06:43:03 chef sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=184.108.40.206 user=root
Sep 23 06:43:05 chef sshd: Failed password for root from 220.127.116.11 port 1282 ssh2
Sep 23 06:43:05 chef sshd: Connection closed by 18.104.22.168
Sep 23 06:43:36 chef sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=22.214.171.124 user=root
Sep 23 06:43:38 chef sshd: Failed password for root from 126.96.36.199 port 2263 ssh2
Sep 23 06:43:40 chef sshd: Connection closed by 188.8.131.52
Sep 23 06:43:59 chef sshd: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=184.108.40.206 user=root
Sep 23 06:44:01 chef sshd: Failed password for root from 220.127.116.11 port 4133 ssh2
Sep 23 06:44:02 chef sshd: Connection closed by 18.104.22.168
Sep 23 06:44:04 chef sshd: refused connect from 22.214.171.124 (126.96.36.199)
Sep 23 06:44:13 chef sshd: refused connect from 188.8.131.52 (184.108.40.206)
Sep 23 06:44:20 chef sshd: refused connect from 220.127.116.11 (18.104.22.168)
Sep 23 06:44:26 chef sshd: refused connect from 22.214.171.124 (126.96.36.199)
This script kiddie had three tries, after that denyhosts kicked in and added their IP to hosts.deny, which means they are forever banned from my system. Of course I have root ssh disabled, but if I hadn't, and if I didn't have denyhosts or some other auto-ban system running, this person could just sit there and hammer my server until they managed to crack the root password. Maybe they would never crack it, maybe they would, but it's not a gamble I'm willing to take.
This server just had a new OS installed a hair over a month ago (Aug 16), and denyhosts has already thrown 230 IPs in the ban list for too many failed SSH attempts. The above excerpt is just the most recent one.
Last edited by suicidaleggroll; 09-23-2014 at 06:18 PM.