Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm new to the linux world and I've been reading a few tutorials on security. I've seen some questions on StackExchange tackling this subject, but from what I've seen, none of the answers clarified things for me.

I keep seeing them (the tutorials) recommending to disable root due to various reasons, the most important being the fact that servers with root users are mostly likely to fall, should a brute force attack occur (from my undersanting, a brute force attack means an automated process which repeatedly tries to authenticate with a username / password combo, until it succeeds)

Now, assuming that I disable username/password authentication and only SSH RSA key authentication is enabled (and also assuming that I'm pretty confident with the security of the device where the private key is located, and that I also have a passphrase for that key) what would be the risk of having root enabled?

Assuming that attackers will never get hold of my private key (and the passphrase), what are their option(s) of getting access of the server?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Yah. It's off by default on FreeBSD.

Part of the reason being is that knowing a username is half the battle for anyone attempting a brute force break-in. 'root' is a user which all unix'like OS contain. Presumably your own username is a bit harder to guess. You can always sudo up as you need it after you're in. Also, sudo logs will show which user is doing bad things when you ~do~ have a break-in.

Wade thru your sshd and/or security logs (depending on how you have your logging set-up). You will be appalled at the sheer number of random attempts to log in.

If this is a server, you probably also want to firewall the machine such that ssh can only connect from certain well known networks.

Also consider some of the nifty pam plug-ins which can add an IP address to your firewall after n failed logins within time span t.

If you really, really have to allow root, you can also specify in /root/.ssh/authorized_keys a list of ip addresses/hostnames from which that key is acceptable.

e.g. (uglified for public viewing):

from="*.foo.bar.isp.net,*NewEngland.bellatlantic.net,333.132.227.*,*.mydomain.net,*.customer.com,177.12.47.2??" ssh-dss AAAA ..[public key].. cas6A== ericx@workstation.com
share|improve this answer
    
A long time ago we allowed root to log into root between servers. They were all cron jobs of one sort or another (rsync backups, I think) with the prohibition from="root@otherserver.foobar.com". The documentation for these clever key restrictions is obscure. If you look in man(8) sshd there is a section entitled "AUTHORIZED_KEYS FILE FORMAT" that provides lots of good stuff. But the "pattern-list" specifics of "From=" have to be found in man(5) ssh_config in a section named "PATTERNS." [sigh] –  ericx Aug 3 at 23:49
    
Thanks for the answer ericx, it does shed some light but I'm still slightly wondering why does those random login attempts matter when this method of authentication is disabled. –  Zubzob Aug 4 at 7:31
1  
um... It's probably almost philosophical. That old joke: "just because your not paranoid doesn't mean they aren't out to get you" comes to mind. Essentially I've been taught that I should always button every hole I know about simply because there are others which I do not know about. Or which simply have not been thought of yet. Every step you take to secure is a step in the right direction. Today, there is no way to get into your machine with a password. That doesn't mean that someone won't find a way around that sometime down the road. –  ericx Aug 4 at 15:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.