sshd: fatal: mm_request_send: write

[Jeff_Traigle]

I just installed patch bundles on a system. Upgraded Secure Shell to 4.00. Now I get the following in syslog when I try to run a script to open an ssh tunnel.

sshd: fatal: mm_request_send: write

This was working fine before the patches and updated SSH. It worked fine after installing the patches and updated Secure Shell on an identical system. A Google search of the error didn't yield any clues about what this means.

I reinstalled Secure Shell fresh on the off chance that was a problem, but that didn't help. SSH otherwise seems to work on the system so it's something specific to this tunnel. Anyone know what this error means and can enlighten me?

[Michael Selvesteen_2]

Please try disabling privilege Separation in sshd_config (UsePrivilegeSeparation no).
This error message might be due to the sshd monitor process failure.

Also post us the detailed sshd debug messages and possibly the script you are using to setup the tunnel.

Does the new SSHD (ssh 4.0) works if path bundles are reinstalled?

[Olivier Masse]

I get a ton of these. I don't bother with them as long as the tunnels continue to work.

[Florian Heigl (new acc)]

I think Your priviledge separation user is missing.

[Jeff_Traigle]

Unfortunately, the tunnel isn't working as a result of the error. :(

Here's the relevant portion of the debug info from sshd:

debug1: do_pam_account: called
Failed publickey for stunnel from 192.168.246.5 port 52447 ssh2
Access denied for user stunnel by PAM account configuration
debug1: Entering record_failed_login uid 0
debug1: do_cleanup
mm_request_send: write
debug1: PAM: cleanup
debug1: do_cleanup
debug1: PAM: cleanup

The command that sets up the tunnel is:

nohup /usr/bin/ssh -l stunnel -n -N ${HOST} -g -L ${FPORT}:${IPORT}:${RPORT}

(The variables are set correctly and haven't changed since it was working.)

The Privilege Separation did nothing.

Something with PAM? No idea what would have changed there. pam.conf is the same as another server that's working.

[Olivier Masse · Accepted solution]

Jeff, I had the same problem (on a trusted system), and the solution was changing the way the account is locked.

Until last summer we absolutely had to have a "*" as the password to lock our accounts. An admin lock (passwd -l) didn't work.

Now since a newer patch bundle we installed in June, the rule has changed, the account needs an admin lock and must NOT have a "*" in the password field.

Olivier.

[Jeff_Traigle]

Good catch, Olivier. It seems the password for the account wasn't set on this system as it had been on the other two that have the tunnel setup so the password was *. Set the password and it worked right away. Thanks a bunch!