Okta Advanced Server Access and Okta Privileged Access SSH Fails After Unix Username Change
Last Updated:
Overview
When attempting to SSH to a Linux server via Okta Advanced Server Access (ASA) or Okta Privileged Access (OPA) after a Unix username change, the connection fails. This occurs because an existing process running under the old username prevents the system from updating the username and home directory. Resolve this issue by terminating the conflicting process and restarting the server daemon.
The user exists in /etc/passwd but displays the original Unix username. The SSH attempt fails with the following errors:
ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
"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]",
"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""
Applies To
- Okta Identity Engine (OIE)
- Okta Classic Engine
- Okta Advanced Server Access (ASA)
- Okta Privileged Access (OPA)
Cause
An existing process running on the server prevents the server daemon (sftd) from executing the usermod command to change the Unix username and move the home directory. Consequently, the server rejects Okta Advanced Server Access or Okta Privileged Access SSH connection attempts that use the new username.
Solution
What resolves the SSH connection failure?
Identify the process ID of the conflicting process, terminate it, and restart the server daemon to allow Okta Advanced Server Access or Okta Privileged Access to update the Unix username successfully.
- Identify the process ID (PID) of the conflicting process from the server daemon logs.
- Terminate the process by running the following command, replacing
<pid>with the actual process ID:kill -11 <pid>
- Restart the server daemon by running the following command:
systemctl restart sftd
- Attempt the SSH connection again.
