“I cannot log in” describes a symptom, not an account state. The same message can come from a wrong password, expired account, unavailable directory, rejected SSH key, invalid shell, full filesystem, broken home directory or a session that exists but cannot be resumed.

Changing the password before identifying the layer can make the incident harder to understand—and it may not affect the authentication method in use.

Confirm authority and preserve another route

Before recovery, verify who owns the system and data, which person/account should have access, and who may change authentication. A cloud console or physical boot path can grant total control; availability is not authorisation.

Keep one known-good administrative session open while investigating, if possible. Do not close the only working route or edit authentication policy without a tested rollback. For remote systems, confirm an out-of-band or provider console before restarting SSH, networking or identity services.

If compromise is suspected, preserve authentication logs and active-session details before resetting credentials. Work from a trusted administration device.

Identify the account’s source

Linux can resolve users from local files and from services connected through the Name Service Switch, such as LDAP, Active Directory or other identity components. Use a targeted lookup such as:

getent passwd <user>
id <user>

getent shows the account as the system currently resolves it; it does not prove the source is healthy or the credentials are valid. Compare local /etc/passwd presence with the configured NSS/identity service and its health.

Record the numerical UID/GID, groups, home directory and login shell. Do not create a new local account with the same name to work around a failed directory. It can produce conflicting identities and wrong file ownership when the directory returns.

Separate account, password and authentication method

For a local shadow-utils account, inspect rather than change first:

passwd -S <user>
chage -l <user>

These can reveal password lock and aging/expiry state. Account expiry, password expiry and password lock are separate conditions.

Then identify how the failed login was attempted:

  • local console or desktop display manager;
  • SSH password;
  • SSH public key or certificate;
  • directory/SSO authentication;
  • sudo privilege elevation; or
  • application-specific authentication.

Ubuntu notes that locking a local password does not revoke an existing SSH public key. Resetting a password likewise does not repair a missing authorized_keys, invalid certificate, failed identity provider or SSH policy that disables password authentication.

Check the relevant logs around the exact attempt and use the system’s time zone. Avoid repeated guesses that trigger rate limiting or account protection.

Check the session and system boundary

A valid account can fail to start a usable session when:

  • its shell is missing or set to a non-login program;
  • the home directory is unavailable, wrongly owned or out of capacity;
  • the root or temporary filesystem is full or read-only;
  • PAM policy, MFA or directory access fails;
  • the desktop/display manager is broken while SSH still works; or
  • a resource limit or service failure prevents session creation.

Test these layers separately. Do not recursively change ownership or permissions on a home directory without first identifying the intended UID/GID and special application files. A directory account can resolve to different numeric IDs when integration is misconfigured.

Use loginctl list-sessions and loginctl session-status <id> on systemd-logind systems to identify live sessions. Also check the processes and terminals associated with the user. An entry can represent a local console, SSH connection, desktop, background user manager or stale state; “user appears logged in” does not explain its purpose.

Recover through an existing authorised administrator

When another trusted sudo administrator is available, correct the proven layer with the smallest change:

  • restore directory/identity connectivity rather than create a duplicate local identity;
  • set a new local password only when the local password is the failed credential;
  • correct an expired account/password deliberately and apply the organisation’s current policy;
  • restore the intended shell or home ownership from verified account data;
  • restore an authorised SSH key from its owner-approved source; or
  • repair the applicable PAM/SSH configuration with syntax validation and a working rollback session.

Ubuntu disables direct root password login by default and favours sudo by authorised users, which provides accountability. Do not enable a permanent root password as the generic solution to one locked account.

Never edit /etc/shadow by hand merely to obtain access. Use supported account tools, preserve file ownership/mode and document the reason. Do not paste password hashes or private keys into tickets, chats or shell histories.

When no administrator can sign in

Use the distribution, appliance, cloud or hosting provider’s supported recovery mechanism and verified ownership process. That might be an authorised rescue console, recovery environment, attached rescue disk or vendor workflow.

Before proceeding, establish:

  • the correct root filesystem and installed distribution/version;
  • whether full-disk or home encryption requires a separate key;
  • whether the account is local or externally authoritative;
  • a backup/snapshot and its consistency limits; and
  • the exact change and rollback.

A recovery console can allow an owner to repair a local account; it cannot decrypt data without the required key or legitimately override another party’s ownership. Commands vary across distributions and filesystems, so do not apply an Ubuntu/GRUB recipe blindly to an appliance, immutable image or cloud-managed host.

After recovery, rotate any credential exposed during the process, remove temporary access and verify normal boot and authentication.

Terminate sessions deliberately

Ending a session may discard unsaved work, interrupt jobs or damage an application transaction. First identify the session ID, user, terminal, start time, remote address where available and processes. Contact the user or application owner when feasible.

On systemd-logind, loginctl terminate-session <id> terminates all processes in that session; loginctl terminate-user <user> is broader and terminates all of the user’s sessions. Prefer the narrowest correct target and record why it is being ended.

For a compromised account, password reset or lock does not remove existing sessions, SSH keys, tokens, scheduled jobs or processes. Coordinate session termination with key removal, identity-provider revocation, service-account ownership and incident evidence.

Do not kill processes by a loose text match. It can target the wrong user, terminal or business workload.

Prove access and security after the change

Verify from a new session that:

  • the intended identity resolves with the correct UID/GID and groups;
  • the approved authentication method succeeds and rejected methods remain rejected;
  • home, shell, storage and required services work;
  • sudo grants only intended privileges and records the action;
  • old credentials, keys and sessions no longer work where they were revoked;
  • logs and monitoring show the expected source and no continuing failures; and
  • temporary recovery mounts, accounts, keys and configuration are removed.

Close the working emergency session only after a fresh normal path succeeds. The goal is not merely a shell prompt; it is restored, accountable access without leaving a second hidden route behind.