Hi,
I am having a strange problem, where I cannot get pam_access to work as intended. I have placed the following line in /etc/pam.d/system-auth
account required /lib/security/pam_access.so
Then, in /etc/security/access.conf, I have put the following line:
-:mok:10.14.44.104
I.e. I should prevent myself from logging on from host 10.14.44.104. However, when I try to log on (using ssh) from the specified host, I get in without a problem. There is nothing in the logs. It does not help restarting sshd, or rebooting. It does not help putting "ALL" instead of the IP number. I happily get in...
Another weird thing is that if I give the argument "debug" to pam_access.so -- as the manual says you can -- it does say something in the log, namely that "debug" is not a recognized option.
The system is CentOS release 4.4.
I hope someone on this list can offer a bit of advice!
Cheers, Morten
On 29/11/06, Morten Kjeldgaard mok@bioxray.dk wrote:
Hi,
I am having a strange problem, where I cannot get pam_access to work as intended. I have placed the following line in /etc/pam.d/system-auth
account required /lib/security/pam_access.so
Then, in /etc/security/access.conf, I have put the following line:
-:mok:10.14.44.104
I.e. I should prevent myself from logging on from host 10.14.44.104. However, when I try to log on (using ssh) from the specified host, I get in without a problem. There is nothing in the logs. It does not help restarting sshd, or rebooting. It does not help putting "ALL" instead of the IP number. I happily get in...
Is UsePAM set in your sshd_config ?
UsePAM Enables the Pluggable Authentication Module interface. If set to "yes" this will enable PAM authentication using ChallengeResponseAuthentication and PAM account and session mod- ule processing for all authentication types.
Because PAM challenge-response authentication usually serves an equivalent role to password authentication, you should disable either PasswordAuthentication or ChallengeResponseAuthentication.
If UsePAM is enabled, you will not be able to run sshd(8) as a non-root user. The default is "no".
Will.
I am having a strange problem, where I cannot get pam_access to work as intended. I have placed the following line in /etc/pam.d/system-auth
account required /lib/security/pam_access.so
Where is this line located in your system-auth? Please provide the entire file. Order is important.
Barry
Hi again,
Big thanks to Barry Brimer and Will McDonald for your suggestions!
I had big hopes for the "UsePAM yes" in sshd_config since I was not aware of that option, and it seemed like THE solution. However, tried it, restarted the sshd daemon but still the same, I can still log on. Totally strange.
Next I would like to consider Barry's suspicion that something is wrong with the order of statements in /etc/pam.d/system-auth. Here is my current file, I simply put the pam_access line just before he other "account" line:
#%PAM-1.0 auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/pam_access.so account required /lib/security/$ISA/pam_unix.so
password required /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow nis password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so
... and, to be sure, system-auth is referenced within /etc/pam.d/sshd:
#%PAM-1.0 auth required pam_stack.so service=system-auth auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth session required pam_loginuid.so
I hope you can spot something wrong in here :-) -- it all seems ok to me.
Cheers, Morten
#%PAM-1.0 auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/pam_access.so account required /lib/security/$ISA/pam_unix.so
password required /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow nis password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so
... and, to be sure, system-auth is referenced within /etc/pam.d/sshd:
#%PAM-1.0 auth required pam_stack.so service=system-auth auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth session required pam_loginuid.so
Is there a reverse DNS entry for the machine you are denying yourself from? Try using the ip address instead of the hostname so we can eliminate that from the equation.
Thanks, Barry
On 30/11/06, Morten Kjeldgaard mok@bioxray.dk wrote:
Big thanks to Barry Brimer and Will McDonald for your suggestions!
No problem.
I had big hopes for the "UsePAM yes" in sshd_config since I was not aware of that option, and it seemed like THE solution. However, tried it, restarted the sshd daemon but still the same, I can still log on. Totally strange.
I've just had a play on a test system and I seem to have it working.
[root@server ~]# grep -v ^# /etc/ssh/sshd_config
Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key SyslogFacility AUTHPRIV PermitRootLogin without-password StrictModes yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys IgnoreRhosts yes PasswordAuthentication no UsePAM yes LogLevel DEBUG X11Forwarding yes Subsystem sftp /usr/libexec/openssh/sftp-server
[root@server ~]# grep -v ^# /etc/security/access.conf
[root@server ~]# grep -v ^# /etc/pam.d/system-auth auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/pam_access.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account required /lib/security/$ISA/pam_permit.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so
So that's nothing in access.conf, all I've added in system-auth is "account required /lib/security/pam_access.so" as in your example, though that was a default setup which has more that yours appears to.
The sshd_config is tailored by my Kickstart and from that I've added
UsePAM yes LogLevel DEBUG
You don't want to run with LogLevel DEBUG under normal circumstances.
Note, the man page states you need either PasswordAuthentication or ChallengeResponseAuthentication disabled, too.
[user@client ~]$ ssh -ltestuser 192.168.24.112 Password: Last login: Thu Nov 30 14:11:58 2006 from client [testuser@server ~]$ exit Connection to 192.168.24.112 closed.
That's me authed and connected, which that SSH configuration typically wouldn't have allowed without PAM enabled since its keys-only.
Now add an entry into access.conf.
[root@server ~]# grep -v ^# /etc/security/access.conf -:testuser:ALL
[user@client ~]$ ssh -ltestuser 192.168.24.112 Password: Password: Password: Permission denied (publickey,keyboard-interactive).
Barry wrote:
Is there a reverse DNS entry for the machine you are denying yourself from? Try using the ip address instead of the hostname so we can eliminate that from the equation.
OK, good point! I changed the entry in /etc/security/access.conf to
-:mok:beast
(instead of -:mok:10.14.44.104)
I've just had a play on a test system and I seem to have it working.
... and setup the sshd with UsePAM yes like suggested by Will, and now the setup WORKS!
We _do_ have reverse IP lookup, but perhaps the reverse lookup and the authentication do not agree on whether to use a FQDN or the short form. Anyhow, using the short form works in our setup. So, now that it works, I could test to see what breaks it again, and it is definitely important to have the "UsePAM yes" line in sshd_config.
[user@client ~]$ ssh -ltestuser 192.168.24.112 Password: Password: Password: Permission denied (publickey,keyboard-interactive).
I get the same (unfriendly) message. It would be nice to be able to print a message to the user, explaining why access is denied. Otherwise we will have users standing in lines demanding an explanation. I guess it is possible with some sneaky pam engineering, I will look into that next.
Thanks for the help! Cheers, Morten
-
Barry Brimer -
Morten Kjeldgaard -
Will McDonald