Hi,
We'll need to see a full debug log from the server - it's not possible to
see what is going one from the abridged ones you sent.
-d
On Fri, 4 Dec 2015, Nasim, Kam wrote:
> 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
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
