This is the old SliTaz forum - Please use the main forum.slitaz.org

[FIXED] recent cooking upgrade breaks sftp-server
  • ultraradultrarad December 2010
    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.



    stderr from:
    /usr/sbin/sshd -ddd 2> /home/tux/sshdebuglog

    attached.

  • ultraradultrarad December 2010
    mmm attachment seems not to upload...so pasting in two parts.


    debug2: load_server_config: filename /etc/ssh/sshd_config
    debug2: load_server_config: done config len = 253
    debug2: parse_server_config: config /etc/ssh/sshd_config len 253
    debug3: /etc/ssh/sshd_config:16 setting ListenAddress 192.168.1.3
    debug3: /etc/ssh/sshd_config:32 setting ServerKeyBits 2048
    debug3: /etc/ssh/sshd_config:67 setting ChallengeResponseAuthentication no
    debug3: /etc/ssh/sshd_config:93 setting X11Forwarding yes
    debug3: /etc/ssh/sshd_config:115 setting Subsystem sftp /usr/sbin/sftp-server
    debug1: sshd version OpenSSH_5.6p1
    debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key.
    debug1: read PEM private key done: type RSA
    debug1: private host key: #0 type 1 RSA
    debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key.
    debug1: read PEM private key done: type DSA
    debug1: private host key: #1 type 2 DSA
    debug1: rexec_argv[0]='/usr/sbin/sshd'
    debug1: rexec_argv[1]='-ddd'
    debug3: oom_adjust_setup
    Set /proc/self/oom_adj from 0 to -17
    debug2: fd 3 setting O_NONBLOCK
    debug1: Bind to port 22 on 192.168.1.3.
    Server listening on 192.168.1.3 port 22.
    debug3: fd 4 is not O_NONBLOCK
    debug1: Server will not fork when running in debugging mode.
    debug3: send_rexec_state: entering fd = 7 config len 253
    debug3: ssh_msg_send: type 0
    debug3: send_rexec_state: done
    debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
    debug1: inetd sockets after dupping: 3, 3
    Connection from 192.168.1.3 port 44606
    debug1: Client protocol version 2.0; client software version dropbear_0.52
    debug1: no match: dropbear_0.52
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_5.6
    debug2: fd 3 setting O_NONBLOCK
    debug2: Network child is on pid 5411
    debug3: preauth child monitor started
    debug3: mm_request_receive entering
    debug3: privsep user:group 99:99
    debug1: permanently_set_uid: 99/99
    debug1: list_hostkey_types: ssh-rsa,ssh-dss
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit: none,zlib@openssh.com
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
    debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
    debug2: kex_parse_kexinit: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc
    debug2: kex_parse_kexinit: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-cbc,twofish128-cbc,blowfish-cbc
    debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
    debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
    debug2: kex_parse_kexinit: zlib,zlib@openssh.com,none
    debug2: kex_parse_kexinit: zlib,zlib@openssh.com,none
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit:
    debug2: kex_parse_kexinit: first_kex_follows 0
    debug2: kex_parse_kexinit: reserved 0
    debug2: mac_setup: found hmac-sha1-96
    debug1: kex: client->server aes128-ctr hmac-sha1-96 zlib@openssh.com
    debug2: mac_setup: found hmac-sha1-96
    debug1: kex: server->client aes128-ctr hmac-sha1-96 zlib@openssh.com
    debug2: dh_gen_key: priv key bits set: 163/320
    debug2: bits set: 509/1024
    debug1: expecting SSH2_MSG_KEXDH_INIT
    debug2: bits set: 511/1024
    debug3: mm_key_sign entering
    debug3: mm_request_send entering: type 4
    debug3: monitor_read: checking request 4
    debug3: mm_answer_sign
    debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN
    debug3: mm_request_receive_expect entering: type 5
    debug3: mm_request_receive entering
    debug3: mm_answer_sign: signature 0x80b84a8(271)
    debug3: mm_request_send entering: type 5
    debug2: kex_derive_keys
    debug2: set_newkeys: mode 1
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug2: monitor_read: 4 used once, disabling now
    debug3: mm_request_receive entering
    debug2: set_newkeys: mode 0
    debug1: SSH2_MSG_NEWKEYS received
    debug1: KEX done
    debug1: userauth-request for user nettux service ssh-connection method none
    debug1: attempt 0 failures 0
    debug3: mm_getpwnamallow entering
    debug3: mm_request_send entering: type 6
    debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM
    debug3: mm_request_receive_expect entering: type 7
    debug3: mm_request_receive entering
    debug3: monitor_read: checking request 6
    debug3: mm_answer_pwnamallow
  • ultraradultrarad December 2010
    [continued]

    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






  • Trixar_zaTrixar_za December 2010
    Maybe give the copy of Slitaz found here a try: http://mirror.slitaz.org/iso/undigest/
    It's the latest build of Slitaz cooking.

    Also next time you could use http://www.pastebin.com for such a long post...
  • ultraradultrarad December 2010
    Thanks for the quick AND USEFUL reply.

    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....

  • Trixar_zaTrixar_za December 2010
    It's actually more the javascript and css that the new Vanilla uses. Many web clients aren't all that compatible with it.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership

SliTaz Social