sshd is working and I can ssh into an additional user account.
sftp to the same account, however, goes through authentication, accepts the password, gives the "sftp>" prompt, and dies--via sshd dying.
(I note, though I don't think this should matter, that everything but the kernel was updated; it's 2.6.34 ... 2.6.36 doesn't quite work with all of my hardware last I tried. If this does somehow matter, then perhaps the issue is that sshd still works for ssh sessions.)
Are there any configs that might account for this? I had it working a few upgrades back, though those configs were removed along the way. I haven't found anything obvious to change.
debug3: Trying to reverse map address 192.168.1.3. debug2: parse_server_config: config reprocess config len 253 debug3: auth_shadow_acctexpired: today 14969 sp_expire -1 days left -14970 debug3: account expiration disabled debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug2: input_userauth_request: setting up authctxt for nettux debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug1: userauth-request for user nettux service ssh-connection method password debug1: attempt 1 failures 0 debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug3: auth_shadow_pwexpired: today 14969 sp_lstchg 14968 sp_max 99999 debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send entering: type 11 Accepted password for nettux from 192.168.1.3 port 44606 ssh2 debug1: monitor_child_preauth: nettux has been authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 24 debug3: mm_request_receive entering debug3: mm_auth_password: user authenticated debug1: Enabling compression at level 6. debug3: mm_send_keystate: Sending new keys: 0x80af2d0 0x80afb18 debug3: mm_newkeys_to_blob: converting 0x80af2d0 debug3: mm_newkeys_to_blob: converting 0x80afb18 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 24 debug3: mm_send_keystate: Finished sending state debug3: mm_newkeys_from_blob: 0x80b84a8(138) debug2: mac_setup: found hmac-sha1-96 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 0x80b84a8(138) debug2: mac_setup: found hmac-sha1-96 debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end User child is on pid 5415 debug3: mm_request_receive entering debug1: permanently_set_uid: 1008/1008 debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 5 setting O_NONBLOCK debug2: fd 6 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 24576 max 32768 debug1: input_session_request debug1: channel 0: new [server-session] debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request subsystem reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req subsystem subsystem request for sftp by user nettux debug1: subsystem: exec() /usr/sbin/sftp-server debug2: fd 3 setting TCP_NODELAY debug2: fd 9 setting O_NONBLOCK debug2: fd 8 setting O_NONBLOCK debug2: fd 11 setting O_NONBLOCK debug2: channel 0: read 13 from efd 11 debug3: channel 0: discard efd debug2: channel 0: read 14 from efd 11 debug3: channel 0: discard efd debug2: channel 0: read 17 from efd 11 debug3: channel 0: discard efd debug2: channel 0: read 20 from efd 11 debug3: channel 0: discard efd debug2: channel 0: read 37 from efd 11 debug3: channel 0: discard efd debug2: channel 0: read 24 from efd 11 debug3: channel 0: discard efd debug2: channel 0: read 16 from efd 11 debug3: channel 0: discard efd debug2: channel 0: read 9 from efd 11 debug3: channel 0: discard efd debug2: channel 0: read 34 from efd 11 debug3: channel 0: discard efd debug2: channel 0: read 50 from efd 11 debug3: channel 0: discard efd debug2: channel 0: read 45 from efd 11 debug3: channel 0: discard efd debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 5416 debug1: session_close_by_channel: channel 0: has child debug1: Received SIGCHLD. debug1: session_by_pid: pid 5416 debug1: session_exit_message: session 0 channel 0 pid 5416 debug2: channel 0: request exit-status confirm 0 debug1: session_exit_message: release channel 0 debug2: channel 0: read 0 from efd 11 debug2: channel 0: closing read-efd 11 debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: gc: notify user debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 0 debug1: session_close: session 0 pid 0 debug3: session_unused: session id 0 unused debug2: channel 0: gc: user detached debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: server-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)
debug3: channel 0: close_fds r -1 w -1 e -1 debug2: notify_done: reading Connection closed by 192.168.1.3 debug1: do_cleanup Transferred: sent 1840, received 992 bytes Closing connection to 192.168.1.3 port 44606 debug3: mm_request_send entering: type 58 debug3: monitor_read: checking request 58 debug3: mm_answer_term: tearing down sessions
The core-undigest of 2010-Dec-26 has the problem fixed.
So, do you know what the bug was/which changes fixed the problem?
Aside: I didn't really get what you meant by "such a long post" (netiquette aside, under 12kB stopped being large with the advent of the 80286 PC-AT... :/ ) until I tried opening this thread with midori (in core-undigest of 2010-Dec-26.) Compare by opening in firefox. Midori seems to have a rendering problem with it (guess some sort of recursive load-render loop...it kept going till I lost patiecnce and closed it. HTH. But I'll bear pastebin in mind....