3

I can ssh to my EC2 instance (amazon linux) (same user, from same machine, same certificate) however I can no longer use sftp.

Logging in via WinScp (via my windows7 box) for SFTP used to work, but now it gives me "exit code 128, is sftp running" , the error log just shows me 'subsystem request for sftp'

How can I get it to work?

debugging delivers this:

    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 [email protected] reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req [email protected]
debug1: server_input_channel_req: channel 0 request [email protected] reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req [email protected]
debug1: temporarily_use_uid: 222/500 (e=222/500)
debug1: restore_uid: (unprivileged)
debug2: fd 8 setting O_NONBLOCK
debug1: channel 1: new [auth socket]
debug1: server_input_channel_req: channel 0 request subsystem reply 1
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/libexec/openssh/sftp-server
debug2: fd 5 setting TCP_NODELAY
debug2: fd 11 setting O_NONBLOCK
debug2: fd 10 setting O_NONBLOCK
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 10940
debug1: session_exit_message: session 0 channel 0 pid 10940
debug2: channel 0: request exit-signal confirm 0
debug1: session_exit_message: release channel 0
debug2: channel 0: write failed
debug2: channel 0: close_write
debug2: channel 0: send eow
debug2: channel 0: output open -> closed
debug2: channel 0: read<=0 rfd 11 len 0
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
debug2: channel 0: send close
debug2: notify_done: reading
debug2: channel 0: rcvd 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 2
Connection closed by 1.2.3.4
debug1: channel 1: free: auth socket, nchannels 1
debug1: do_cleanup
debug1: temporarily_use_uid: 222/500 (e=222/500)
debug1: restore_uid: (unprivileged)
Transferred: sent 2472, received 2224 bytes
Closing connection to 1.2.3.4 port 42647
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials

update: problem was I edited my .bashrc which outputted something to stdout. Since sftp starts up a new shell for the user and does not like that.... it fails with a exit code 128.

edelwater
  • 133
  • 1
  • 6
  • I found this question as I had a very similar problem and same solution. I edited the .bashrc file (to add tab cycle autocomplete as suggested in this [question](http://unix.stackexchange.com/questions/24419/terminal-autocomplete-cycle-through-suggestions)). But then winscp would not work for me. However, when I removed the line that I added to the .bashrc file, then winscp would work. This was an obscure bug, I don't understand why winscp could not adapt to the modified .bashrc file. I'm happy to have a solution but I would still like to be able to edit the .bashrc file... – dbjohn Dec 16 '12 at 23:51

1 Answers1

3

Look for Subsystem sftp <path> in the sshd configuration, /etc/ssh/sshd_config. Make sure <path> points to the SFTP server (path varies, but usually ends with openssh/sftp-server). Make sure said server is executable.

$ grep sftp /etc/ssh/sshd_config
Subsystem sftp /usr/lib/openssh/sftp-server

$ /usr/lib/openssh/sftp-server -h
usage: sftp-server [-ehR] [-f log_facility] [-l log_level] [-u umask]

Try running sshd in debug mode, on an alternate port:

# sshd -rddp 1234

It should show why exactly the subsystem request is failing.

u1686_grawity
  • 4,580
  • 20
  • 27
  • tnx I included the debug output. The only thing I can see is "channel 0: write failed" but I'm not sure that is it. Maybe some write permissions on some folder? Update:: hmmmm wait... – edelwater Apr 27 '11 at 20:13
  • 4
    i made a change in .bashrc ... maybe i made a mistake and the sftp starts a new shell... and something is outputted... testing... yep... that was the problem. – edelwater Apr 27 '11 at 20:18