SFTP error "Received unexpected end-of-file from SFTP server" on CentOS 6

Question

I'm getting this SFTP error "Received unexpected end-of-file from SFTP server" on CentOS 6.

I've added a new user below

sudo adduser --shell /bin/false paul

sudo passwd paul

Then edited /etc/ssh/ssh_config to contain this and restarted the sshd service

#   $OpenBSD: ssh_config,v 1.25 2009/02/17 01:28:32 djm Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
Host *
    GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
    ForwardX11Trusted yes
# Send locale-related environment variables
    SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
    SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
    SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
    SendEnv XMODIFIERS
UseRoaming no

Subsystem sftp internal-sftp

Match User paul
    ForceCommand internal-sftp
    PasswordAuthentication yes
    ChrootDirectory /var/www/vhosts/****/httpdocs/gold
    PermitTunnel no
    AllowAgentForwarding no
    AllowTcpForwarding no
    X11Forwarding no

I've searched through the similar questions and most just say add

Subsystem sftp internal-sftp

Which I've done but hasn't helped. What could be causing this error?

EDIT:

Here are the log content from /var/log/secure

Oct  4 16:34:45 WEBDB sshd[50124]: Accepted password for paul from *.*.*.* port 7093 ssh2
Oct  4 16:34:45 WEBDB sshd[50124]: pam_unix(sshd:session): session opened for user paul by (uid=0)
Oct  4 16:34:45 WEBDB sshd[50126]: subsystem request for sftp
Oct  4 16:34:45 WEBDB sshd[50124]: pam_unix(sshd:session): session closed for user paul

Solution

I believe you should add the Subsystem sftp internal-sftp to /etc/ssh/sshd_config
(and not to /etc/ssh/ssh_config)

Comments

[Michael Hampton]

Check the server logs.

[Mr J]

unfortunately the logs don't really tell me much, or what I can see anyway

[syserr0r]

The original poster has provided an extract of their /var/log/secure which states Accepted password for paul from [...] so this is not the case. The answer submitted by @gilodo is most likely correct.

[Murad Zeynalli]

Dear @syserr0r, it happened to me while I was researching a solution for this case. Trust me; the solution also causes an expired password. If you glance at his config file, you will be assured that he had already replaced the respective line in the config file with this string Subsystem sftp internal-sftp. The /var/log/secure file presented with limited lines; therefore, you cannot judge me by disliking my solution answer:(

[syserr0r]

The OP says they edited /etc/ssh/ssh_config, when they should edit /etc/ssh/sshd_config (note the d). That pam_unix opened a session indicates pam had no problems with the account.