users can't sftp into my server

I am running a fedora core 13 server and I am having trouble with sftp. My users can connect to the server using SSH both using public key and password authentication. For some reason they are not able to connect using sftp.

I'l not sure what's going on. I ran sshd in debug mode and here's the trace:

debug1: sshd version OpenSSH_5.4p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
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]='-d'
debug1: rexec_argv[2]='-p1234'
Set /proc/self/oom_adj from 0 to -17
debug1: Bind to port 1234 on 0.0.0.0.
Server listening on 0.0.0.0 port 1234.
debug1: Bind to port 1234 on ::.
Server listening on :: port 1234.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 129.171.56.94 port 46607
debug1: Client protocol version 2.0; client software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.4
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user emil service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "emil"
debug1: PAM: setting PAM_RHOST to "129.171.56.94"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user emil service ssh-connection method gssapi-with-mic
debug1: attempt 1 failures 0
debug1: An invalid name was supplied
Hostname cannot be canonicalized

debug1: userauth-request for user emil service ssh-connection method gssapi-with-mic
debug1: attempt 2 failures 0
debug1: userauth-request for user emil service ssh-connection method password
debug1: attempt 3 failures 0
debug1: PAM: password authentication accepted for emil
debug1: do_pam_account: called
Accepted password for emil from 129.171.56.94 port 46607 ssh2
debug1: monitor_child_preauth: emil has been authenticated by privileged process
debug1: temporarily_use_uid: 500/500 (e=0/0)
debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism
debug1: restore_uid: 0/0
debug1: SELinux support disabled
debug1: PAM: establishing credentials
debug1: PAM: establishing credentials
debug1: permanently_set_uid: 500/500
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
User child is on pid 13726
debug1: server_input_channel_open: ctype session rchan 0 win 131072 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
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 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
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 13727
debug1: session_exit_message: session 0 channel 0 pid 13727
debug1: session_exit_message: release channel 0
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 child 0
debug1: session_close: session 0 pid 0
debug1: channel 0: free: server-session, nchannels 1
Connection closed by 129.171.56.94
debug1: do_cleanup
Transferred: sent 2056, received 1336 bytes
Closing connection to 129.171.56.94 port 46607
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials

For some reason the SFTP child process terminates immediately after being started:

subsystem request for sftp
debug1: subsystem: exec() /usr/libexec/openssh/sftp-server
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 13727

Check if the program /usr/libexec/openssh/sftp-server really exists, and is runable by regular users.

The program is in there and it has the following permissions:

-rwxr-xr-x  1 root root  63888 May 31  2010 sftp-server
-rwsr-xr-x  1 root root 228540 May 31  2010 ssh-keysign
-rwxr-xr-x  1 root root  94168 May 31  2010 ssh-pkcs11-helper

I logged in as a regular user ant tried to run the program manually. I get the following error:
Couldn't open /dev/null: Permission denied

but if i run sftp-server as root then it seems to run

That is weird. ls -l /dev/null ?

it looks like /dev/null only had rw for the user. I added rw for group and other and it seems to work now.

I'm not sure why the permissions on /dev/null were so restrictive. I've never seen it like that before.

Thanks all

1 Like

Me neither. 0666 is normal

Can use the configuration items: DenyUsers SSHD, AllowUsers, DenyGroups, AllowGroups

For example:
You hope to ban the use of users use SFTP service to join a group like xyz
And then in/etc/SSH/sshd_config Settings
DenyGroups xyz
So, all belong to the xyz users will not logged in SSH permissions, nature also did not use the SFTP permissions.

Note in sshd_config banned SFTP off just-is not enough, because the server as long as users also can pass
SSH login can use other user of essential tools such as SCP uploads and downloads files, the effect is the same with SFTP actually.