I have SFTP server with many users connecting with different usernames. One user requested the name change. Since I thought that is pretty straightforward procedure, I did typical

usermod --login new_username old_username

After that I was not able to login with new name anymore. Since I have multiple users, I was comparing permissions and everything looked fine. Moreover, when I check logfiles, I see that password for that user is accepted. The service is restarted, but is still the same.

  • OS: Centos7.
  • No LDAP server has been used.
  • All users are local.
  • After rename, I don't have access with old username either.
  • No reboot tried, just service restart.
  • sshd_config has rules for group, not user. Group remained same.

The /etc/passwd entry after name change looks like this:


However, even if I change manually the passwd entry to this (desperate try):


the login is not possible.

When I execute the usermod command again and I revert username, I am able to login.

What should I do so that I am able to login with the new username?

  • 2
    do you have specified users set in the /etc/ssh/sshd_config file to be able to ssh/sftp? so now user is changed and they are not able to login Feb 23 at 15:54
  • 1
    Have you looked to confirm the username was changed in /etc/shadow as well as /etc/passwd?
    – Sotto Voce
    Feb 23 at 16:38
  • What actually happens when the user tries to connect? What ssh or sftp command are they actually running, and what specific error are they getting? You say their password is accepted, so I presume it's failing in some way other than an authentication failure?
    – Kenster
    Feb 23 at 21:42
  • @Kenster WinScp is producing the following error: network error: software caused connection abort Feb 23 at 22:00

1 Answer 1


After checking sshd_config for fifth time, I found the group rule that is preventing the login.

Match Group ftp
        ChrootDirectory /opt/ftp/%u
        ForceCommand internal-sftp -u 0002
        X11Forwarding no
        AllowTcpForwarding no

The ChrootDirectory is basically telling that after login, the users root directory is changed to the specified directory which has to have the same name like the login username (%u).Since that was not the case, the login was rejected. When I renamed directory to match the username, I was able to login.

Too bad that there is no any hints or errors in logfiles regarding this issue.

  • What level of logging is your sshd running? At a heightened logging level the standard openssh daemon will complain about things like missing home directories and/or target directories of ChrootDirectory directives. You don't want to have heightened logging all the time, but you do want to raise it while troubleshooting a mystery login problem like this one.
    – Sotto Voce
    Feb 24 at 10:54
  • @SottoVoce DEBUG3 LogLevel is activated, which should give me the most details, but I still didn't get any hints of what might be wrong. Feb 26 at 9:48

You must log in to answer this question.

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