How to check SSH authorized keys in Linux

Unexpected public keys in authorized_keys can leave SSH access open after password changes, laptop replacement, or staff offboarding, so checking the exact keys that sshd still accepts is the quickest way to confirm who can still open a shell on a Linux host.

OpenSSH usually checks user keys in ~/.ssh/authorized_keys, but the effective lookup path can change when AuthorizedKeysFile or AuthorizedKeysCommand is set in sshd_config or inside a matching Match block. Each non-comment line can also include options such as from=, command=, and restrict that limit where a key works or what it is allowed to run after login.

The commands below are read-only and use Ubuntu 24.04 style output from a current OpenSSH package, but the same checks apply on other modern Linux systems. Keep console or other break-glass access available before making follow-up changes, because StrictModes rejects insecure paths and removing the wrong key line can lock out administrators, automation, or backup jobs.

1. Resolve the target account and confirm its home directory before checking any key file paths.

   $ getent passwd user
   user:x:1001:1001::/home/user:/bin/bash

   Replace user with the account being audited. The sixth field is the home directory, which is the base path for relative AuthorizedKeysFile entries such as .ssh/authorized_keys.

2. Print the effective sshd key lookup settings for that account.

   $ sudo sshd -T -C user=user,host=localhost,addr=127.0.0.1,laddr=127.0.0.1,lport=22 | grep -E '^(strictmodes|authorizedkeys)'
   strictmodes yes
   authorizedkeyscommand none
   authorizedkeyscommanduser none
   authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

   The -C context applies matching Match rules before printing the final result. If AuthorizedKeysCommand is not none, inspect that command or backing directory service as well because sshd checks it after the listed AuthorizedKeysFile paths when no earlier key matches.

3. Check the ownership and permissions of the home directory, .ssh directory, and authorized_keys file.

   $ sudo ls -ld /home/user /home/user/.ssh
   drwxr-x--- 3 user user 4096 Apr 14 12:10 /home/user
   drwx------ 2 user user 4096 Apr 14 12:10 /home/user/.ssh
   $ sudo ls -l /home/user/.ssh/authorized_keys
   -rw------- 1 user user 636 Apr 14 12:10 /home/user/.ssh/authorized_keys

   With StrictModes yes, the home directory should not be writable by group or others, while .ssh is usually 700 and authorized_keys is usually 600.

4. Read the key file and review each allowed key line.

   $ sudo cat /home/user/.ssh/authorized_keys
   from="192.0.2.10",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPqLnmXvA+cxRLoHI6sAqz9q5C3g9LGQhRVjM2TJtk1v laptop-admin
   command="/usr/local/bin/backup-run",permitopen="127.0.0.1:5432" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQ... backup-job

   Each non-comment line contains optional key restrictions, the key type, the public key data, and an optional comment. Comments help label a device or job, but the fingerprint is the stronger identifier for matching a key to inventory.

5. Generate fingerprints for the listed keys and compare them with the expected inventory.

   $ sudo ssh-keygen -lf /home/user/.ssh/authorized_keys
   256 SHA256:MZKPX9SE5tpyX2bmekcIDX/0EbiTnJ4pn/1JpyuTgV0 laptop-admin (ED25519)
   3072 SHA256:sV/qxw1rggwAUniUnkxoCSnsbmfNepyJaWICQZZwfLk backup-job (RSA)

   Fingerprints make it easier to match a key against onboarding records, configuration management data, or incident notes without comparing the full base64 text line by line.

6. Check when the file last changed if an entry looks unfamiliar or unexpected.

   $ sudo stat /home/user/.ssh/authorized_keys
     File: /home/user/.ssh/authorized_keys
     Size: 636        Blocks: 8          IO Block: 4096   regular file
   Access: (0600/-rw-------)  Uid: ( 1001/    user)   Gid: ( 1001/    user)
   Access: 2026-04-14 12:10:52.298020013 +0000
   Modify: 2026-04-14 12:10:52.284020013 +0000
   Change: 2026-04-14 12:10:52.285020013 +0000
    Birth: 2026-04-14 12:10:52.284020013 +0000

   Unexpected modification times should be correlated with recent login, privilege-escalation, or account-management activity. Related: How to check authentication logs in Linux