Re: weird problem with sftp/rssh

Steven Mocking a écrit :
The password is accepted but the connection is closed as soon as it is opened.
Do you understand why from these lines ?
I do not :( :(


This probably means rssh exits with an error. Try running it from the chroot manually to see what goes wrong.
Sorry for the delay. I've been busy elsewhere.
Well... Back to sftp/rssh : what do you mean by "running from the chroot" ?

Should I 'chroot /home/chroot', for example ?
But then, I'll be root, not my rsshuser, and in my rssh.conf, there's only sftp and scp allowed, so I can't even su into rsshuser account...

Or maybe I didn't catch what you said.

BTW, I ran sshd with -dddd option, and the output, after accepting the key was :

....
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req subsystem
subsystem request for sftp
debug1: subsystem: exec() /usr/lib/misc/sftp-server
debug2: fd 8 setting O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug2: channel 0: read<=0 rfd 8 len -1
debug2: channel 0: read failed
debug2: channel 0: close_read
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug2: channel 0: input drain -> closed
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 12608
debug1: session_exit_message: session 0 channel 0 pid 12608
debug2: channel 0: request exit-status confirm 0
debug1: session_exit_message: release channel 0
debug2: channel 0: write failed
debug2: channel 0: close_write
debug2: channel 0: output open -> closed
debug2: channel 0: send close
debug3: channel 0: will not send data after close
debug2: notify_done: reading
debug3: channel 0: will not send data after close
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after 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
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 8/8 cfd -1)

debug3: channel 0: close_fds r 8 w 8 e -1 c -1
Connection closed by 127.0.0.1
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering
Closing connection to 127.0.0.1
debug1: PAM: cleanup
debug3: mm_request_send entering: type 59
debug3: monitor_read: checking request 59
debug3: mm_answer_term: tearing down sessions

Then again, something shown as (above)

debug2: channel 0: read<=0 rfd 8 len -1
debug2: channel 0: read failed

seems to be the origin of the error but I don't understand altogether what it means...


What's really strange is that if I comment out chrootpath="/home/chroot" in rssd.conf, everything works perfectly - except I'm not in a chroot jail any longer...
.

Relevant Pages

  • Another variant of "ssh" working interactively, but "ssh cmd" and "scp" failing
    ... debug1: Connecting to FOO port 22. ... debug3: key_read: missing keytype ... debug2: fd 4 setting O_NONBLOCK ... debug2: channel 0: request exec confirm 0 ...
    (comp.security.ssh)
  • openssh3.7p1 chroot patch not work on solaris 7
    ... debug1: monitor_child_preauth: test has been authenticated by privileged process ... debug3: mm_get_keystate: Waiting for new keys ... debug2: mac_init: found hmac-sha1 ... debug1: channel 0: new ...
    (comp.unix.solaris)
  • openssh3.7p1 chroot patch not work on solaris 7
    ... debug1: monitor_child_preauth: test has been authenticated by privileged process ... debug3: mm_get_keystate: Waiting for new keys ... debug2: mac_init: found hmac-sha1 ... debug1: channel 0: new ...
    (comp.security.ssh)
  • openssh3.7p1 chroot patch not work on solaris 7
    ... debug1: monitor_child_preauth: test has been authenticated by privileged process ... debug3: mm_get_keystate: Waiting for new keys ... debug2: mac_init: found hmac-sha1 ... debug1: channel 0: new ...
    (comp.security.ssh)
  • Re: ssh xterm -> HPUX fails
    ... debug1: read PEM private key done: type RSA ... debug3: preauth child monitor started ... debug2: monitor_read: 0 used once, ... debug2: channel 0: sent ext data 106 ...
    (comp.security.ssh)