Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then 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.
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.
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
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.
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:
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.
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.
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.
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.