question about securing root
 

I have been doing some reading and some playing around.
I want to lock root down to only the console and not allow direct logins.

However is I modify the sshd_config and changed this line...
PermitRootLogin no

It works as expected. No ssh root logins allowed.

However in my AIX environment I have a "master server" that I use to ssh to all my systems with keys and if I turn this off on the Linux box it disables this function.

I messed with
PermitRootLogin without-password

This works but I was also reading up on
pam_access module.

So my question how secure is the PermitRootLogin without-password
vs
pam_access

and is it hard to set up the pam stuff? I am still reading up on it. But thought I would ask.

I don't understand why disabling root logins would not allow regular logins. Could you explain how the "master server" works in regard to making ssh connections?

On a Linux or BSD system, read the /etc/ssh/sshd_config file. Pay attention to the comments above the UsePAM Yes line.
You can use PAM for session control but use public key authentication.
I've never allowed root logins on my system. I think that without-password mean the same thing as "PasswordAuthentication no" but only for root. I think that a general "PasswordAuthentication no" would suffice but "PermitRootLogins without-password" allows you to configure root for public key authentication but allow password authentication for regular users.

If you must have root logins, pubkey authentication that you have now would be best.

How are regular user ssh logins handled?

Disabling root longs prevents us (not regular users) from using out "master" as a jumping off point. It will not allow root to ssh from that system.

My master server is an AIX system that is setup as a jumping off point for all my systems. We use it to build all our other AIX system using nim so ssh keys are in place and root can just ssh over from it to any system.

As for regular users they ssh in using putty or ssh command from a U/Linux box. Password is required as it should be.

You share the same private key for all of your servers? Using keys instead of passwords is a good idea, but sharing private keys isn't IMHO. Compromise one server and you have keys for all of them.

In an apartment building I used to live in, an employee of the company managing a number of apartment buildings lost the master key. They didn't want to trouble themselves with having a separate master key for each building and had to replace the locks of all of the apartments in all of the buildings. It cost them $60,000.

Maybe you should provide your sshd_config file. Do the AIX servers use openssh or a commercial product?
If it is openssh (which is bsd) then you could use one of the other servers sshd_config file as a model. Since they use public key authentication. Is there a difference in the Master in how AIX servers are reached versus your Linux host?

It seems to me that if you use public key authentication for root, but allow password authentication for regular users, then you need the "AllowRootLogins --without-password" to prevent challenge/response authentication. Is the Linux host configured to allow root password authentication?

If you know that ssh only comes from the "master" you can lock down from which machine to allow ssh logins.
If only a small number of users are allowed to log in, I would use "AllowUsers" to prevent login attempts from other users or attempts against system users.

Using a from="IP or Host List" in authorized_keys can prevent attempts from unauthorized locations. A person with a stolen key will need to try logging in from a machine with an authorized domain name or IP address. See "man sshd" for info on this. An example from the manpage:
from="*.sales.example.net,!pc.sales.example.net" ssh-rsa

Is the problem at the "master" or refusal to connect at the Linux box? Can you run "ssh -vv" to provide verbose feedback? Is the Linux host using the host key or the key in /root/.ssh/? The verbose debug information should say. It may provide information on why exactly logins fail. Also check the logs you have for the kernel, security, warnings in /var/log/.

We do not share the private key for root. Just the public one.

ie:
aix master server call it AM
Aix client will be client AC
Linux will be LC

I ssh to AM login with my uid then su- root.
I can now ssh (openssh) to any AC system without being asked for a password (keys in place)
If I try to ssh from AM to LC with the PermitRootLogin = no in the sshd_config file I get asked for a pasword. If I supply the password it still wont let me in.

Now if I try to do the same thing with PermitRootLogin=yes I can ssh in as usual like AIx systems do.

If I use the PermitRootLogin without-password I can login like before.

My users all ssh over from putty fine.

What I am trying to learn about is using the pam_access module instead of the PermitRootLogin without-password.

is it more secure than the above method in ssh?

I was reading this link:
http://www.puschitz.com/SecuringLinu...SharedAccounts

You should (normally) disable root login from ssh. If you want to lock it down to root only able to access from the console edit this file http://linux.die.net/man/5/access.conf

I thought you were replicating both key pairs when you created an AIX server from the master.

Do you have the public keys for the Linux servers installed in the AM server? I'm guessing that the root user has copies of the public keys for other servers.

For the Linux server (LC)
Check which key pair is used for root logins. The ones in /root/.ssh/ or the host keys in /etc/ssh/. I'm not actually certain. The public key may need to be modified after installation so the correct host name is listed in the end.

If you need to allow root logins to LC, using PermitRootLogin without-password would be more secure. Root is a known user and an attacker can deploy a dictionary attack against it. As I understand it "PermitRootLogin without-password" uses public key authentication for the root user. It is my guess it is for a situation like yours where regular users don't use public key authentication. One disadvantage of public key ssh authentication in my opinion is that while the clients private key can be protected with a strong passphrase, this policy may not be enforceable.

At home I use pubkey authentication and don't allow root logins. If I need to do something remotely as root, I will use sudo or su after logging in as a regular user. Public key authentication can be used with putty, but the keypairs may not be secure in Windows.

Maybe your question should be if allowing root logins with pubkey authentication is safer than having a user who is a member of the %wheel group log in with username/password credentials, which can be guessed, but for which a password strength measurement can be employed. In your case, only allowing root logins from the AM server helps, compared to having logins from a laptop which can be lost or stolen. I think that if you want to improve security for the Linux server, you should lock down the times and places that root logins are allowed. This will help protect against a admin who knows the root password from stealing the private key for AM.

The best option may be to use public key authentication for everyone. There is still the lost private key problem, but online attacks are eliminated.

Thank you jscihwal for the good info.

If I remove (lets just use my account) my user id from the wheel group then I wont be able to su or sudo to root right?

From what I have read I have to be a member of the wheel group to do root functions.
Root should never login to our system AIX or Linux directly unless on the console (in a secure location). Usually we login with our UID then su to root unless there is something that prevents us then and only then would we use console access.

Can you clue me in on this statement:
"The best option may be to use public key authentication for everyone. There is still the lost private key problem, but online attacks are eliminated."

May be I am missing something but I really dont want users to login without a password.
If their Laptop is stolen etc then its easier for someone to get into the system. Of course they have to bypass the encrypted drive and then get on the vpn or network etc.