11 Answers
11

Why allow root ssh access at all? Murphy's law would have it that the time you'll need root access you'll be away from your approved IP address.

This is just my opinion but the better approach to this is to log in as a regular user and then su to root. To gain access to root someone would need both your user password and the root password. So you're regular user account would have to be in the admin or wheel group depending on what Linux distro you're running.

EDIT: For even more improved security only allow pre-shared key authentication for ssh connectivity. This can be a double edged sword though if you're not at a machine that has the necessary private key.

+1 for this, direct root access is completely nonsense. Use sudo/setuid or something like similar instead.
–
pauskaDec 1 '09 at 18:38

5

All fine and well repeating a well-known security principle in terms of root access, but not all situations require it or can even justify it. And I believe the OP had a specific question he needed answered - he wasn't asking for industry best practice advice. IMHO.
–
Zayne S HalsallDec 1 '09 at 19:26

As regards only allowing key auth - do it, but carry the key with you on a USB stick on your keys. Problem solved.
–
David NorthDec 1 '09 at 19:34

If you do carry your key with you on a USB make sure that the key has a password.
–
3dinfluenceDec 1 '09 at 20:46

You're looking for the AllowUsers option to the sshd_config file (generally found in /etc/ssh/). To wit:

AllowUsers root@10.200.0.1

Which will allow only root to login from IP 10.200.0.1 - the default setting is for all users from all hosts to be allowed...

The one drawback I can see is if you do use AllowUsers, you'd then have to list all users you require having access - which would definitely be a pain to manage with a large enough list of users (for example, being pulled from LDAP or other directory).

This should be possible to workaround to some extent as the option does allow for the use of wildcard patterns, per the man page:

This keyword can be followed by a list of user name patterns,
separated by spaces. If specified,
login is allowed only for user
names that match one of the patterns. '*' and '?' can be used as
wildcards in the patterns. Only user
names are valid; a numerical user ID is not recognized. By default, login is
allowed for all users. If the pattern
takes the form USER@HOST then USER and
HOST are separately checked, restricting logins to particular users
from particular hosts.

Strict root access can be necessary for taking backups and so on, but can be very dangerous thing to have. Luckily the direct root access can be secured quite a bit by using ssh keys and authorized_keys file.

First of all, allow the root login in sshd_config but allow it only to execute the predefined set of commands: put PermitRootLogin forced-commands-only to /etc/ssh/sshd_config or wherever your sshd config is stored. This disables password authentication for root, forces it to use ssh keys and even then only allows the commands you defined.

Then login to your client which needs to has this direct root access, and create there a new ssh key: ssh-keygen -t rsa. Make that key passwordless if needed by scripts.

Next, copy this newly created ssh key to your server with ssh-copy-id -i ~/.ssh/id_rsa.pub root@yourserver (if root login is still enabled), if not, just copypaste the contents ~/.ssh/id_rsa.pub to /root/.ssh/authorized_keys file.

Then try to execute from your client something like ssh root@myserver ls - this should fail. Then go on and execute ssh root@myserver /root/bin/startup_skynet.sh - now this should work.

This way direct root logins can be much more secure. As security is a layered thing and not something a single feature would provide, you can still do more. If you have a limited subset of users who need to connect, you might as well use AllowUsers parameter in sshd_config to allow connection from a predefined set of ip addresses, something like AllowUsers root@192.168.1.2 root@192.168.1.3 johndoe would allow root from 192.168.1.2 and 192.168.1.3 and johndoe from everywhere.

I would suggest that you use the Match feature in sshd_config, and match against the IP (or subnet).

This would allow you to also specify allowed functionality. For example: you might say that only users from 'internal' set of subnets may use PasswordAuthentication (and that AllowRoot may only come from a single/small range of IPs that require it).

Note also that authentication via public-key doesn't go through PAM, so pam_access won't work for you if you use public-key authentication.

in sshd_config and then insert the public key from the allowed machine into authorized_keys2 on the target system.
If you don't how to do this - on the "allowed system" do as root (accept the defaults and don't set a password):

Alternatively you could set a password on the ssh key.
This is a simple solution that disallows any password-based auth by root to log in, instead using the public key from only the "allowed" system to access it.

Minds are like parachutes, just because you have lost yours doesn't mean you borrow mine...

I love discussions around security, everyone thinks their way is the only way. Here is what you do, take a step back, look at your infrastructure, consider access points, and then build a model that provides you enough security so you don't really have to worry too much about it.

That being said, my opinion below:

logging in as root frankly, stupid. There is just no reason to do it... so don't do it. For users with sufficient privileges to sudo to root, ensure your system is setup appropriately. Password Authentication, disable it, use SSH Keys only.

From trusted hosts, a limited number of /32 address logging in as your user account should not require anything more than your ssh key... from untrusted hosts, use two-factor authentication. Username/Password... + 6-8 changing number every 30 seconds...

NOTE: This configuration can be accomplished by setting in sshd_config:

PermitRootLogin no
PasswordAuthentication no

Check out Google-Authenticator, its super easy to setup and configure, and does the job just fine. Its just like RSA or any other two factor setup, Google has an app for android and the iphone, so is pretty and easy tot configure. And when connection from untrusted hosts, passwords will be allowed if two factor auth is configured properly.