Re: Confusion on SSH and PAM
Replying to myself to fix my error. Vinny wrote: Rakhesh Sasidharan wrote: [snip] Here's another oddity I encountered today. If PermitRootLogin is set to forced-commands-only, my understanding is the SSHD will permit root logins if a command to be executed is given. But that doesn't seem to be the case in practice! I have keys setup for root to login, but instead of letting me in with those keys, SSHD ignores them, passes me to PAM for password prompting (three times) and the denies me out! Very strange. PermitRootLogin forced-commands-only This requires that a command be present in the authorized_keys file for a given key. For example, root's authorized_keys file might look like this for an rsync command: command=/root/.ssh/cron/validate-rsync,from=10.10.10.2,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss B3N_more_public_key_data comment The entire text above should be only one line in the file. The command shown in: command=/root/.ssh/cron/validate-rsync I.e. /root/.ssh/cron/validate-rsync This: must be the command submitted on the ssh command line, loosely: $ ssh -i private_key_matching_public_key_in_authorized_keys [EMAIL PROTECTED] \ /root/.ssh/cron/validate-rsync is incorrect. The command shown is the command that is executed when the root user is authenticated via the key in question. It does not need to appear on any ssh command line. The root user cannot otherwise login to the system using ssh unless further keys with corresponding commands exist. Sorry about the error. Vinny ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Confusion on SSH and PAM
Rakhesh Sasidharan wrote: [snip] Here's another oddity I encountered today. If PermitRootLogin is set to forced-commands-only, my understanding is the SSHD will permit root logins if a command to be executed is given. But that doesn't seem to be the case in practice! I have keys setup for root to login, but instead of letting me in with those keys, SSHD ignores them, passes me to PAM for password prompting (three times) and the denies me out! Very strange. PermitRootLogin forced-commands-only This requires that a command be present in the authorized_keys file for a given key. For example, root's authorized_keys file might look like this for an rsync command: command=/root/.ssh/cron/validate-rsync,from=10.10.10.2,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss B3N_more_public_key_data comment The entire text above should be only one line in the file. The command shown in: command=/root/.ssh/cron/validate-rsync I.e. /root/.ssh/cron/validate-rsync must be the command submitted on the ssh command line, loosely: $ ssh -i private_key_matching_public_key_in_authorized_keys [EMAIL PROTECTED] \ /root/.ssh/cron/validate-rsync The root user cannot otherwise login to the system using ssh unless further keys with corresponding commands exist. Vinny ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Confusion on SSH and PAM
CyberLeo Kitsana wrote: Rakhesh Sasidharan wrote: Any ideas or nudges in the right direction as to why this is happening? Looks like I've understood the interaction between SSH and PAM wrong here, so would appreciate some enlightenment. According to my understanding of the SSH protocol, you're continually asked because an authentication failure is not a fatal error. When authenticating an SSH session, a list of mutually supported methods is compiled (public-key, challenge-response, S/Key, keyboard-interactive, plaintext) and the client cycles through the list based on what it thinks is most likely to work. It's perfectly acceptable for a client to attempt password authentication before public-key, or even interleave them. All the server can do is say yay or nay to an attempt with a restricted method, because it cannot know if the next attempt may utilize an allowed method. After the requisite three or five failed attempts (depending on the server config), it may send a general failure code (too many failed attempts) and disconnect the client at it's discretion. Here's another oddity I encountered today. If PermitRootLogin is set to forced-commands-only, my understanding is the SSHD will permit root logins if a command to be executed is given. But that doesn't seem to be the case in practice! I have keys setup for root to login, but instead of letting me in with those keys, SSHD ignores them, passes me to PAM for password prompting (three times) and the denies me out! Very strange. I even setup a Match User clause for root and specified a command to run. Still, SSHD refuses to let me in with/ without key and for a specific command. Regards, - Rakhesh http://rakhesh.net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Confusion on SSH and PAM
On Wednesday 26 September 2007 11:02:26 Rakhesh Sasidharan wrote: CyberLeo Kitsana wrote: Rakhesh Sasidharan wrote: Any ideas or nudges in the right direction as to why this is happening? Looks like I've understood the interaction between SSH and PAM wrong here, so would appreciate some enlightenment. According to my understanding of the SSH protocol, you're continually asked because an authentication failure is not a fatal error. When authenticating an SSH session, a list of mutually supported methods is compiled (public-key, challenge-response, S/Key, keyboard-interactive, plaintext) and the client cycles through the list based on what it thinks is most likely to work. It's perfectly acceptable for a client to attempt password authentication before public-key, or even interleave them. All the server can do is say yay or nay to an attempt with a restricted method, because it cannot know if the next attempt may utilize an allowed method. After the requisite three or five failed attempts (depending on the server config), it may send a general failure code (too many failed attempts) and disconnect the client at it's discretion. Here's another oddity I encountered today. If PermitRootLogin is set to forced-commands-only, my understanding is the SSHD will permit root logins if a command to be executed is given. But that doesn't seem to be the case in practice! I have keys setup for root to login, but instead of letting me in with those keys, SSHD ignores them, passes me to PAM for password prompting (three times) and the denies me out! Very strange. I even setup a Match User clause for root and specified a command to run. Still, SSHD refuses to let me in with/ without key and for a specific command. PermitRootLogin without-password won't allow what you want to do? To use it, you have to set up a passphrase (public key). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Confusion on SSH and PAM
On Tue, 25 Sep 2007 15:56:22 +0400 (GST) Rakhesh Sasidharan wrote: Any ideas or nudges in the right direction as to why this is happening? Looks like I've understood the interaction between SSH and PAM wrong here, so would appreciate some enlightenment. I'm not sure if I can offer any enlightenment here, but you can have my 2 cents. :-) When you authenticate yourself with you private key, everything works as you expect. If I understand you correctly, you are confused as to why you still get prompted for a password when you don't supply a key and then even the right password doesn't get you in. This is one of these things with computer logic. :-) You have told the sshd that a root login vai PAM is not ok, only via private key. PAM is activated just the same (and probably works for other users). The login follows a certain order... 1 Ask for username 2 Did we get a key? If not, goto 5 3 Is the key ok? If not, goto 5 4 Let user login, exit authentification 5 Is PAM globally on? If not exit 6 Ask for password 7 Is the password ok? If not goto 6 max 2 times, after that exit 8 Let user login, exit I know, crappy algorithem that remindes of BASIC a bit. In this case it should do the job, though. Please forget that the word goto exists in other languages too (even Java). :-) Your problem seems to be from steps 5 to 7. After the authentification by key fails, the sshd just goes to the next step, which is the password. For security reasons, the communication inside is a bit brief. PAM only gets the answer not authenticated and because the reason isn't an issue, the user is asked for the password again. The point is that the sshd just refuses your login each time, because a password just isn't enough. I have already made up a little something to put this situation into another context (access to an underground club for parties) to maybe make it a little clearer but I think the world has had quite enough of my little stories aready. :-) Regards Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Confusion on SSH and PAM
Christian Baer wrote: On Tue, 25 Sep 2007 15:56:22 +0400 (GST) Rakhesh Sasidharan wrote: Any ideas or nudges in the right direction as to why this is happening? Looks like I've understood the interaction between SSH and PAM wrong here, so would appreciate some enlightenment. I'm not sure if I can offer any enlightenment here, but you can have my 2 cents. :-) I don't mind enlightenment that can be got for 2 cents! :-) This is one of these things with computer logic. :-) You have told the sshd that a root login vai PAM is not ok, only via private key. PAM is activated just the same (and probably works for other users). The login follows a certain order... 1 Ask for username 2 Did we get a key? If not, goto 5 3 Is the key ok? If not, goto 5 4 Let user login, exit authentification 5 Is PAM globally on? If not exit 6 Ask for password 7 Is the password ok? If not goto 6 max 2 times, after that exit 8 Let user login, exit ... snip ... Your problem seems to be from steps 5 to 7. After the authentification by key fails, the sshd just goes to the next step, which is the password. For security reasons, the communication inside is a bit brief. PAM only gets the answer not authenticated and because the reason isn't an issue, the user is asked for the password again. The point is that the sshd just refuses your login each time, because a password just isn't enough. I see. I thought the interaction between SSHD and PAM was that SSHD tells PAM to authenticate on its behalf, PAM replies with a PASS/ FAIL depending on the final result of its modules, and SSHD allows/ disallows based on this result. But from what you say, I get the impression that SSHD can ask PAM to re-try even if PAM replies with a PASS ... that's kind of futile, isn't it? Why doesn't SSHD just take the PASS result and deny the user straightaway instead of making PAM retry twice? Here's something else that I tried. There's a PAM module for CAPTCHA. (http://www.semicomplete.com/projects/pam_captcha/ in case someone's interested). I modified my PAM config to include that too before the pam_unix module. -8- auth required pam_nologin.so no_warn auth requisite /usr/local/lib/pam_captcha.so math randomstring auth required pam_unix.so try_first_pass account required pam_login_access.so account required pam_unix.so session required pam_permit.so password required pam_unix.so -8- Following our previous logic, shouldn't pam_captcha get invoked, verify through CAPTCHA, pass onto pam_unix to get password, pass result to SSH, fail, and restart with pam_captcha and pam_unix for 2 more times? But it does not happen that way! Instead, now, pam_captcha does the looping for 2 more times, and even after successfully entering the CAPTCHA strings root login is denied. Strange. pam_unix is not even called for the password! When PAM is used to authenticate for SSHD, is it not that PAM goes through all its modules and *then* passes the result to SSH? Or are there any subtler interactions ... each module passes its result to SSH and their behaviour is influenced by SSHD's reply? I know, crappy algorithem that remindes of BASIC a bit. In this case it should do the job, though. Please forget that the word goto exists in other languages too (even Java). :-) :-) Regards, - Rakhesh http://rakhesh.net/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Confusion on SSH and PAM
Rakhesh Sasidharan wrote: Any ideas or nudges in the right direction as to why this is happening? Looks like I've understood the interaction between SSH and PAM wrong here, so would appreciate some enlightenment. According to my understanding of the SSH protocol, you're continually asked because an authentication failure is not a fatal error. When authenticating an SSH session, a list of mutually supported methods is compiled (public-key, challenge-response, S/Key, keyboard-interactive, plaintext) and the client cycles through the list based on what it thinks is most likely to work. It's perfectly acceptable for a client to attempt password authentication before public-key, or even interleave them. All the server can do is say yay or nay to an attempt with a restricted method, because it cannot know if the next attempt may utilize an allowed method. After the requisite three or five failed attempts (depending on the server config), it may send a general failure code (too many failed attempts) and disconnect the client at it's discretion. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net [EMAIL PROTECTED] Furry Peace! - http://.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
