I did install sftp on CentOS and did add new group:

groupadd sftp

did create new user:

useradd -m sftp_user_1 -s /sbin/nologin -g sftp

did create password:

passwd sftp_user_1

did change owner:

chown root /home/sftp_user_1

did change rights:

chmod 750 /home/sftp_user_1

did change owner:

chown sftp_user_1:sftp /home/sftp_user_1

did check user and group:

id sftp_user_1

[root@centos-24 home]# id sftp_user_1
uid=1000(sftp_user_1) gid=1000(sftp) groups=1000(sftp)

did make changes in file /etc/ssh/sshd_config

Subsystem sftp /usr/libexec/openssh/sftp-server

did change to

Subsystem sftp internal-sftp

did add in end of file

Match Group sftp
X11Forwarding no
AllowTcpForwarding no
ChrootDirectory /home/%u
ForceCommand internal-sftp

did restart service

systemctl restart sshd

did try to connect to sftp server and returned error:

[root@centos-24 home]# sftp sftp_user_1@localhost
sftp_user_1@localhost's password:
packet_write_wait: Connection to ::1 port 22: Broken pipe
Couldn't read packet: Connection reset by peer

How solve this problem?

  • You've changed the owner of /home/sftp_user_1 to sftp_user_1 only two steps after you changed it to root. Why did you set it to root in the first place? If you're following a set of instructions you found somewhere, please include that in your question.
    – JigglyNaga
    Jun 13, 2018 at 12:15
  • now did returned error: sftp_user_1@localhost's password: Permission denied, please try again. Jun 13, 2018 at 12:22
  • use: 'tail -f /var/log/secure /var/log/audit ' and run your sftp call to check if useful messages come there. (and maybe increas loglevel to verbose in sshd_config...)
    – tonioc
    Jun 16, 2018 at 17:12
  • Possible duplicate of How does ChrootDirectory and a user's home directory work together?
    – telcoM
    Sep 23, 2019 at 12:41

3 Answers 3


In this step

chown root /home/sftp_user_1

I must change and group to sftp

chown root:sftp /home/sftp_user_1

because in file /etc/ssh/sshd_config exist

Match Group sftp
  • Why? /home/sftp_user_1 has no other:r-x access? If you have r-x access why sftp fails?
    – Chameleon
    Sep 4, 2019 at 17:46

Your sftp client is reporting that the remote end just abruptly terminated the connection.

In situations like this, it would be best to read the logs of the server side: if the remote server did in fact terminate the connection, the server's logs should say so - and usually they'll also say why the server did so.

In this specific case, this is what I saw when reproducing the problem:

Sep 23 14:53:52 centos7 sshd[1800]: Accepted password for sftp_user_1 from ::1 port 52166 ssh2
Sep 23 14:53:52 centos7 sshd[1800]: pam_unix(sshd:session): session opened for user sftp_user_1 by (uid=0)
Sep 23 14:53:52 centos7 sshd[1800]: fatal: bad ownership or modes for chroot directory "/home/sftp_user_1" [postauth]
Sep 23 14:53:52 centos7 sshd[1800]: pam_unix(sshd:session): session closed for user sftp_user_1

"Bad ownership or modes for chroot directory /home/sftp_user_1." So sshd is unhappy about the permissions of the ChrootDirectory, which in your case is equal to the home directory of the chrooted user.

According to sshd_config(5) man page, the directory the ChrootDirectory configuration parameter refers to must be owned by root and not writeable by anyone else:


Specifies the pathname of a directory to chroot(2) to after authentication. At session startup sshd(8) checks that all components of the pathname are root-owned directories which are not writable by any other user or group. After the chroot, sshd(8) changes the working directory to the user's home directory.

In other words, the ChrootDirectory must not be the user's home directory, but a directory at least one level above it. This requirement is stricter than with older versions of sshd. It needs to be so, after someone discovered a new way to escape a chroot jail. The new requirement will make that escape method unusable.

See my answer in this other question for two possible solutions: https://unix.stackexchange.com/a/542507/258991


Always check the logs for any errors related to connectivity. Simple way to check it is by using the below commands.

grep -i username /var/log/auth.log
grep -i username /var/log/secure.log

In my case it was the home directory missing logs really helped me to identify the issue.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .