6

I'm wanting to restrict root ssh login coming from all but a single IP address.

I was under the impression that I just had to add this to /etc/pam.d/sshd:

account required pam_access.so

and this to /etc/security/access.conf:

-:root:ALL EXCEPT IPADDRESS

but that doesn't seem to be working.

11 Answers 11

5

In /etc/ssh/sshd_config

# Disable Root login
PermitRootLogin no
#
# [ . . . ]
#
# At the end of the file, add:
#
# Allow Root Login via Key from Admin Bastion
Match Address 10.9.8.7
        PermitRootLogin without-password
4

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.

4
  • 1
    +1 for this, direct root access is completely nonsense. Use sudo/setuid or something like similar instead.
    – pauska
    Dec 1, 2009 at 18:38
  • 9
    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. Dec 1, 2009 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. Dec 1, 2009 at 19:34
  • If you do carry your key with you on a USB make sure that the key has a password. Dec 1, 2009 at 20:46
1

I assume this is RHEL 5+, and that is which have this issue.. The same steps would work for RHEL 4. The trick to make this work on RHEL 5 is add account required pam_access.so

to /etc/pam.d/sshd at the 2nd or 3rd line. If you just append it at bottom it is not working.

Resulting /etc/pam.d/sshd would look like..

# cat /etc/pam.d/sshd

#%PAM-1.0

auth include system-auth

account required pam_nologin.so

account required pam_access.so

account include system-auth

password include system-auth

session optional pam_keyinit.so force revoke

session include system-auth

session required pam_loginuid.so

1

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.

Now, let's assume your client needs to run /root/bin/startup_skynet.sh as root via ssh. Your existing authorized_keys file looks something like this at this point:

ssh-rsa FASBFAFfasdföjasfABGVEAGUPEGDJfsadnö2314235dfbösadköjsdfösdklf==

Modify it to be

no-pty,no-X11-forwarding,no-agent-forwarding,no-port-forwarding,command="/root/bin/startup_skynet.sh" ssh-rsa FASBFAFfasdföjasfABGVEAGUPEGDJfsadnö2314235dfbösadköjsdfösdklf==

and save it.

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 [email protected] [email protected] johndoe would allow root from 192.168.1.2 and 192.168.1.3 and johndoe from everywhere.

1

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.

0

did you try :

-: ALL EXCEPT root:your_ip_address

?

1
  • That doesn't seem to work either.
    – Chad P
    Dec 1, 2009 at 14:02
0

Did you try two lines:

+:root:<your_ip>
-:root:ALL
0

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

AllowUsers [email protected]

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.

Still, could be quite restrictive, YMMV. Hope this helps.

-1

look at /etc/hosts.allow and /etc/hosts.deny

0
-1

Set

PermitRootLogin without-password

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):

# ssh-keygen -t rsa -b 2048 
# scp /root/.ssh/id_rsa.pub targetsystem:/tmp

On the "target" system do:

cat /tmp/id_rsa.pub >> /root/.ssh/authorized_keys2
rm -f /tmp/id_rsa.pub

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.

-2

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .