I have encountered a problem in using PAM authentication with Conserver.
If I run the 'console' client from a (non-trusted) system, then console
prompts for a password, as expected, and connects me to the console. That
works, but before the password prompt there is a significant delay (2-4
seconds). And if the client is redirected to another conserver, there is
another delay before the console is connected. Additionally, one gets
their syslogs filled with these false positives:
Nov 26 17:18:40 excelsior0 conserver: (pam_unix) authentication
failure; logname= uid=0 euid=0 tty= ruser= rhost=IHaveNoIdeaHowIGotHere
user=rkirkpat
After some debugging and code tracing, it looks like the client does not
prompt for a password until asked for one by the server. And the server
does not ask for one until it tries and fails to do PAM authentication
with an empty password. Of course, when PAM auth fails, PAM causes a
syslog entry and a timeout, and hence the reason for the delay described
above.
Seems to me that when conserver receives a connection from a non-trusted
host it should simply ask for a password first before trying any PAM
authentication. But I don't know what impact that would have on the rest
of the authentiation logic. Therefore, my quick fix was simply to skip
trying to do PAM auth with empty passwords in
conserver/group.c:CheckPass(), as per the attached patch.
Now connecting to a console with a password and PAM authentication is as
quick as without (e.g., from a trusted host). This is probably not the
best way to fix this problem, but it is a problem that should be fixed.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." --- Phil. 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, CO | rkirkpat.net | twitter.com/rkirkpatnet |
---------------------------------------------------------------------------
If I run the 'console' client from a (non-trusted) system, then console
prompts for a password, as expected, and connects me to the console. That
works, but before the password prompt there is a significant delay (2-4
seconds). And if the client is redirected to another conserver, there is
another delay before the console is connected. Additionally, one gets
their syslogs filled with these false positives:
Nov 26 17:18:40 excelsior0 conserver: (pam_unix) authentication
failure; logname= uid=0 euid=0 tty= ruser= rhost=IHaveNoIdeaHowIGotHere
user=rkirkpat
After some debugging and code tracing, it looks like the client does not
prompt for a password until asked for one by the server. And the server
does not ask for one until it tries and fails to do PAM authentication
with an empty password. Of course, when PAM auth fails, PAM causes a
syslog entry and a timeout, and hence the reason for the delay described
above.
Seems to me that when conserver receives a connection from a non-trusted
host it should simply ask for a password first before trying any PAM
authentication. But I don't know what impact that would have on the rest
of the authentiation logic. Therefore, my quick fix was simply to skip
trying to do PAM auth with empty passwords in
conserver/group.c:CheckPass(), as per the attached patch.
Now connecting to a console with a password and PAM authentication is as
quick as without (e.g., from a trusted host). This is probably not the
best way to fix this problem, but it is a problem that should be fixed.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." --- Phil. 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, CO | rkirkpat.net | twitter.com/rkirkpatnet |
---------------------------------------------------------------------------
Attached Files:
-
conserver-pam-auth.diff (0.53 KB)