Hi folks, I came across this issue on both stock CentOS(v6.4) and Ubuntu(14.04 LTS) and was wondering if any of you have seen it. As far as I can tell this seems like a day-1 bug to me. PROBLEM: If I expire a linux user's password (passwd -e <user>) and then log in via ssh, it will prompt you for a password change. On changing the password successfully, sshd will drop the connection and client has to reconnect. ANALYSIS: Looking at sshd debug logs, it would appear that the child process that runs passwd SIGCHLD's to the parent which appears to be treating that signal as a SIGTERM: Dec 3 18:36:17 knasim-ubuntu1 passwd[3152]: pam_unix(passwd:chauthtok): password changed for wrs <<<<<<< Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: Received SIGCHLD. <<<<<<<<<<<<<<<<<< Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: session_by_pid: pid 3152 Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug1: session_exit_message: session 0 channel 0 pid 3152 Dec 3 18:36:17 knasim-ubuntu1 sshd[3151]: debug2: channel 0: request exit-status confirm 0 <<<<<<<<<<< By default, in sshd "Privilege Separation" is enabled. What does this mean? It means that sshd spawns an unprivileged process that does basic authentication and that guy spawns a child process running as root to run passwd (in this case). After password change, the child SIGCHLD's the parent which instead of handling it properly treats it like a SIGTERM and closes the socket. The following process tree should give a better idea of the process nestings: With Privilege Separation: ubuntu@knasim-ubuntu1:~$ pstree init─┬─acpid ├─atd ├─cron ├─dbus-daemon ├─dhclient ├─7*[getty] ├─rsyslogd───3*[{rsyslogd}] ├─sshd───bash───ssh ├─sshd───bash───pstree ├─sshd───sshd───sshd───passwd ├─systemd-logind ├─systemd-udevd ├─upstart-file-br ├─upstart-socket- └─upstart-udev-br Without Privilege Separation: init─┬─acpid ├─atd ├─cron ├─dbus-daemon ├─dhclient ├─7*[getty] ├─rsyslogd───3*[{rsyslogd}] ├─sshd─┬─sshd───bash───ssh │ ├─sshd───bash───pstree │ └─sshd───sshd ├─systemd-logind ├─systemd-udevd ├─upstart-file-br ├─upstart-socket- └─upstart-udev-br If I disable Privilege Seperation ("UsePrivilegeSeperation no") in sshd config then the problem goes away but that opens up a security loophole where the process is running at root privilege even prior to authentication. What do you guys think? Have others come across this? Is there a patch available for this? Thanks, Kam _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev