An Advanced Server Access (ASA) User is failing to SSH to a particular Linux server after the "Unix Username" attribute is changed for the user. The SSH attempt fails with a generic error:
ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
When checking on the server side, it is observed:
- The user does exist in /etc/passwd, but still shows the original Unix Username
- SSHD logs have errors referencing SSH attempt with the new Unix Username, but failing with "Invalid user"
"MESSAGE" : "Invalid user (New Unix Username) from (client IP) port 57762","MESSAGE" : "Connection closed by invalid user (New Unix Username) (client IP) port 57762 [preauth]",
- SFTD logs have errors referencing the inability to "change unix name" due to the user being in use by a process
"MESSAGE" : "time=\"2024-09-12T12:09:31-07:00\" level=error msg=\"usermod (to change unix name) failed\" args=\"--login (New Unix Username) --home /home/(New Unix Username) --move-home (Old Unix Username)\" err=\"exit status 8\" newUserName=(New Unix Username)oldUserName=(Old Unix Username) output=\"usermod: user (Old Unix Username) is currently used by process 12572\\n\""
- Advanced Server Access (ASA)
In this case, the issue was due to an existing process running on the server from long ago that was preventing sftd from running the "usermod" command to change the Unix Username and move home directories to the new username.
As a result, the server did not recognize ASA's SSH connection attempts using the new username and rejected them with "invalid user."
In this example, the issue was found to be due to an old process from the old Unix Username unexpectedly still running on the server. As this process did not need to be running, killing the process and restarting sftd resolved the issue. This allowed ASA to successfully change the Unix Username on the server, and the subsequent SSH attempt was successful
- Kill the old process (in this case, the PID from the error above was 12572; please verify, as the PID will be different in other scenarios):
- kill -11 <pid>
- systemctl restart sftd
