Bug#242119: ssh - password authentication never uses pam
I'm having the same problem.
there's no output from this process in auth.log (since I'm using -ddd, I
guess)
debug1: PAM: initializing for "cg2v"
debug3: Trying to reverse map address 205.201.7.143.
debug1: PAM: setting PAM_RHOST to "dhcp-7-143.dsl.telerama.com"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: input_userauth_request: try method none
Failed none for cg2v from 205.201.7.143 port 54343 ssh2
debug1: userauth-request for user cg2v service ssh-connection method
password
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method password
debug3: auth_shadow_pwexpired: today 12516 sp_lstchg 11439 sp_max 99999
Failed password for cg2v from 205.201.7.143 port 54343 ssh2
debug1: userauth-request for user cg2v service ssh-connection method
password
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method password
Failed password for cg2v from 205.201.7.143 port 54343 ssh2
debug1: userauth-request for user cg2v service ssh-connection method
password
debug1: attempt 3 failures 3
debug2: input_userauth_request: try method password
Failed password for cg2v from 205.201.7.143 port 54343 ssh2
Connection closed by 205.201.7.143
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering
Here's strace output from one password verification attempt (this is a
sparc, so some of the syscall names are wrong...):
Process 6897 attached - interrupt to quit
select(5, [4], NULL, NULL, NULL) = 1 (in [4])
read(4, "\327\2102\363\303F\202\342\37\344\375\266\1771\0Q\222\206"...,
8192) = 144
write(2, "debug1: userauth-request for use"..., 79) = 79
write(2, "debug1: attempt 1 failures 1\r\n", 30) = 30
write(2, "debug2: input_userauth_request: "..., 53) = 53
open("/etc/shadow", O_RDONLY) = 3
nfssvc(0x3) = 0
nfssvc(0x3) = 0
_llseek(3, 0, [0], SEEK_CUR) = 0
fstat64(3, {st_mode=S_IFREG|0640, st_size=4621, ...}) = 0
SYS_56(0, 0x120d, 0x1) = 1879162880
_llseek(3, 4621, [4621], SEEK_SET) = 0
munmap(0x7001c000, 4621) = 0
close(3) = 0
time(NULL) = 1081396889
write(2, "debug3: auth_shadow_pwexpired: t"..., 73) = 73
open("/etc/shadow", O_RDONLY) = 3
nfssvc(0x3) = 0
nfssvc(0x3) = 0
_llseek(3, 0, [0], SEEK_CUR) = 0
fstat64(3, {st_mode=S_IFREG|0640, st_size=4621, ...}) = 0
SYS_56(0, 0x120d, 0x1) = 1879162880
_llseek(3, 4621, [4621], SEEK_SET) = 0
munmap(0x7001c000, 4621) = 0
close(3) = 0
getpeername(4, {sa_family=AF_INET, sin_port=htons(54343),
sin_addr=inet_addr("205.201.7.143")}, [16]) = 0
write(2, "Failed password for cg2v from 20"..., 61) = 61
write(4, "\216\3764i`\17{\306,i~\1\322\344\357\3725\245\n\n\t\364"..., 80)
= 80
select(5, [4], NULL, NULL, NULL
I do have UsePAM turned on, and lsof does indicate that the modules that
are specified by /etc/pam.d/ssh are being loaded. This configuration does
work with the sshd in ssh-krb5. (I only installed this version because I
encountered a variant of bug 240953 and didn't remember if 3.6 had the bug
or if it had been fixed upstream in time for 3.8. since 3.6 (and thus
ssh-krb5) isn't supposed to have that problem, I guess I'm going to switch
back before this machine goes back into production)
Reply to: