What Is authorized_keys? Security Definition
This page mentions older exam versions. See the Current Exam Context and Legacy Exam Context sections below for the updated mapping.
On This Page
Quick Definition
The authorized_keys file is used by SSH to check if a person trying to log in has permission to do so. Each line in the file contains one public key. If the user’s private key matches a public key in this file, the server grants access without asking for a password. This makes logging in both more secure and faster than using a password.
Commonly Confused With
The known_hosts file is used on the client side to verify the identity of the server you are connecting to. It stores the server's host key. Authorized_keys, on the other hand, is on the server side and stores the user's public keys for authentication. They serve opposite purposes: one authenticates the server to the client, the other authenticates the client to the server.
When you connect to a new SSH server, you see a warning that the host key is not in known_hosts. That file is on your laptop. But to log in without a password, your public key must be in the server's authorized_keys file.
The id_rsa file is the private key stored on the client machine. It must never be shared or placed on the server. The authorized_keys file contains only the matching public key. Confusing these two leads to security risks and authentication failures.
If you accidentally copy your id_rsa private key into the authorized_keys file on the server, not only will authentication fail, but anyone who can read that file can steal your private identity.
ssh-agent is a program that runs in the background and holds your decrypted private keys in memory so you do not have to type your passphrase repeatedly. It does not replace the authorized_keys file. You still need your public key in authorized_keys, but ssh-agent makes it convenient to use the private key without re-entering the passphrase.
If you run ssh-add and enter your passphrase once, ssh-agent remembers your key. Later, when you ssh to a server, the agent provides the key. But the server still checks its authorized_keys file to see if that key is allowed.
Must Know for Exams
The authorized_keys file is a recurring topic in several IT certification exams, especially those focused on Linux administration, security, and network services. In CompTIA Security+ (SY0-601 and SY0-701), the concept falls under domain 2.0 (Architecture and Design) and domain 3.0 (Implementation). Specifically, you need to understand secure protocols (SSH) and authentication methods. Exam questions may ask about the difference between password-based and key-based authentication, or about securing the authorized_keys file with proper permissions.
In the Linux Professional Institute (LPI) exams, such as LPIC-1 (101 and 102), you are expected to configure SSH key-based authentication manually. This includes generating key pairs with ssh-keygen, copying the public key to the remote server, and ensuring correct permissions on ~/.ssh/authorized_keys (600) and ~/.ssh (700). Scenario-based questions might present a situation where a user cannot log in despite having the correct private key, and you must identify that the authorized_keys file permissions are too permissive or that the file is in the wrong location.
For Red Hat Certified System Administrator (RHCSA) and Red Hat Certified Engineer (RHCE) exams, you must be able to configure SSH key-based authentication as part of system access tasks. You may be asked to set up passwordless SSH for a specific user, restrict commands using options in the authorized_keys file, or use an SSH Certificate Authority. The exam environment expects you to know commands like ssh-copy-id, chmod, and chown to set the correct permissions.
Cisco Certified Network Associate (CCNA) and CompTIA Network+ also touch on SSH key exchange, though less deeply. Questions might cover the protocol negotiation phase or the purpose of public-key cryptography. In all cases, the authorized_keys file is the implementation detail that exam candidates must remember. It is not enough to know that SSH uses keys, you must know where the public key is stored, what permissions it needs, and how to troubleshoot access failures. That is why exam simulators and practice tests often include a scenario where you have to fix a broken SSH login by adjusting the authorized_keys file.
Simple Meaning
Think of the authorized_keys file like a guest list at a private club. The club has a strict door policy. Only people whose names are on the guest list can enter without a hassle. If your name is not on that list, you have to call a member, prove who you are, and maybe wait around. In SSH, the authorized_keys file is exactly that guest list. It lives on the server, in a hidden folder called .ssh, inside the home directory of each user.
When you try to connect from your computer to that server, your computer sends a kind of ID card, this is your public key. The server compares your public key to every key in the authorized_keys file. If it finds a match, the server knows you are allowed in. No password needed. If there is no match, the server either asks for a password or rejects the connection entirely, depending on how it is configured.
This setup is much safer than using passwords alone. A password can be guessed, stolen, or intercepted. A private key is a long, random string that is nearly impossible to guess. And because the authorized_keys file only stores public keys, even if someone breaks into the server and steals the file, they cannot reverse-engineer your private key from it. The file is simple text, one key per line, and system administrators often manage it manually or with automation tools. It is a cornerstone of secure remote access in IT and is commonly tested in certifications like CompTIA Security+ and Linux+.
Full Technical Definition
The authorized_keys file is a critical component of the Secure Shell (SSH) public-key authentication mechanism. Located by default at ~/.ssh/authorized_keys on the server, it stores one or more public keys in OpenSSH format. Each line contains the key type (such as ssh-rsa, ssh-ed25519, or ecdsa-sha2-nistp256), the base64-encoded public key data, and an optional comment field. The file must have strict permissions: it should be owned by the user, and its permissions must be set to 600 (read/write for owner only) or more restrictive. The containing .ssh directory should have permissions 700. Any deviation from these permissions can cause SSH to ignore the file for security reasons.
During SSH key-based authentication, the client presents its public key to the server after the transport layer has been established. The server checks the ~/.ssh/authorized_keys file for the corresponding user to see if the presented public key is listed. If a match is found, the server uses the public key to encrypt a random challenge (a nonce) and sends it to the client. The client must decrypt this challenge using its private key and return a hash of the session identifier along with the decrypted challenge. The server verifies the response. If valid, authentication succeeds without any password exchange. This process is defined in the SSH protocol (RFC 4252) and is considered highly secure because the private key never traverses the network.
In multi-user environments, system administrators often manage authorized_keys centrally using tools like Ansible, Puppet, or SSH Certificate Authorities (CAs). With SSH CAs, instead of individual public keys, the file can contain a certificate signed by a trusted CA. This simplifies key rotation and revocation. The authorized_keys file can also include options such as command restrictions (command="/usr/bin/somecommand"), source IP restrictions (from="192.168.1.0/24"), and no-agent-forwarding, which allow fine-grained access control. These options appear before the key type on each line. The file is read by the sshd daemon during authentication, and any errors in file format or permissions will result in authentication failure. Understanding this file is essential for system administrators and is tested in Linux administration and security certification exams.
Real-Life Example
Imagine you live in a large apartment building with a secure entrance. The building manager gives each resident a unique key fob that opens the front door. But the building also has a list of authorized key fob serial numbers stored in the door's computer. When you tap your fob, the computer checks if your fob's serial number is on the list. If it is, the door unlocks. If it is not, you are locked out. You never have to say a password or show an ID.
Now imagine you want to let your friend borrow your apartment while you are on vacation. Instead of giving them your personal key fob (which you might lose or never get back), you could ask the building manager to add your friend's fob serial number to the list. Your friend uses their own fob to enter, and you keep yours. When you return, the manager can remove your friend's serial number from the list. You are in full control without ever sharing your key.
In SSH, the authorized_keys file works the same way. The server is the apartment building, the door computer is the sshd daemon, your public key is your fob's serial number, and your private key is the actual fob itself. The authorized_keys file is the list of allowed serial numbers. You can add or remove keys anytime without changing your own private key. And if someone tries to break in, they cannot get in unless they have a private key that matches one of the public keys on the list. This is exactly why IT professionals prefer key-based authentication over passwords, it is like having a separate, unique key for every person you trust, and you can revoke access instantly by editing one file.
Why This Term Matters
In practical IT, the authorized_keys file is central to managing secure access to hundreds or thousands of servers. Without it, administrators would have to rely on password authentication, which is vulnerable to brute force attacks, SSH keylogging, and phishing. Once a password is compromised, an attacker can access all systems where that password is used. Key-based authentication eliminates this risk because the private key never leaves the client machine and is often protected by a passphrase.
Using authorized_keys also enables automation and scripting. Tools like rsync, scp, and Ansible rely on SSH keys to run commands on remote servers without human intervention. For example, a backup script can connect to a remote server using an SSH key stored in the authorized_keys file, transfer files, and disconnect, all automatically. This would be impossible if the script had to supply a password each time.
From a security compliance perspective, many standards require two-factor authentication or certificate-based access. The authorized_keys file supports both. By adding keys that are signed by an SSH Certificate Authority, administrators can enforce expiry dates and revoke access globally. This is why authorized_keys appears in exam objectives for CompTIA Security+, Linux+, and RHCSA. Understanding how to set up, secure, and troubleshoot this file is a fundamental skill for any IT professional managing Linux servers.
How It Appears in Exam Questions
Exam questions about authorized_keys generally appear in three formats: scenario-based, configuration, and troubleshooting. In scenario-based questions, you are given a situation where a system administrator wants to enable passwordless SSH login for a backup script. Multiple-choice options might include placing the public key in the user's ~/.ssh/authorized_keys file, changing the SSHD configuration, or using ssh-agent. The correct answer is the one that describes placing the public key in the authorized_keys file with proper permissions.
Configuration questions may ask you to order the steps correctly: generate keys, transfer the public key, set permissions, and test the connection. You might be given a set of commands and asked which one copies the public key to the remote server correctly. Options could include scp, ssh-copy-id, or manually editing the file. The exam expects you to know that ssh-copy-id simplifies this process by appending the key and setting the correct permissions automatically.
Troubleshooting questions are among the most common. A user reports they cannot connect to a server using SSH keys. The exam presents logs or permission outputs. You might see that the authorized_keys file has permissions 644 or that the .ssh directory has permissions 755. You must recognize that permissions are too open and that sshd will ignore the file. Another common trap is the file being in the wrong location, for example, the key is placed in /root/.ssh/authorized_keys but the user is connecting as 'john'. The exam expects you to know that each user has their own authorized_keys file in their home directory. Some questions test the format of the file itself: a line missing the key type, or a corrupted base64 string, will cause authentication to fail silently.
Practise authorized_keys Questions
Test your understanding with exam-style practice questions.
Example Scenario
You are a junior IT administrator for a small company with 50 Linux servers. Your manager asks you to set up passwordless SSH access for a new automated backup tool that runs nightly. The backup tool runs on a central management server and needs to connect to each Linux server as the user 'backupops'. Currently, all servers require a password to log in as backupops.
You start on the management server. You switch to the backupops user and run ssh-keygen -t ed25519. This creates a private key in ~/.ssh/id_ed25519 and a public key in ~/.ssh/id_ed25519.pub. The private key must be kept secret. The public key is what you will copy to each server.
Next, you set up passwordless access to the first server, which has the IP 192.168.1.10. You run ssh-copy-id -i ~/.ssh/id_ed25519.pub backupops@192.168.1.10. This command connects to the server, logs in using password (the first time), and appends the public key to the file ~/.ssh/authorized_keys in the home directory of backupops on the remote server. It also sets the correct permissions: ~/.ssh directory to 700 and authorized_keys file to 600.
After copying, you test by running ssh backupops@192.168.1.10. If the setup is correct, the connection succeeds without a password prompt. You repeat this for all 50 servers. Later, a security audit reveals that on one server, the authorized_keys file has permissions 644. The backup tool still works because sshd might still accept it depending on the StrictModes setting, but standard best practice flags this as a risk. You correct it by running chmod 600 ~/.ssh/authorized_keys on that server. This scenario demonstrates exactly how authorized_keys is used in real IT environments and what common issues arise.
Common Mistakes
Setting the authorized_keys file permissions to 644 (readable by group and others)
SSHD is configured by default to reject public key authentication if the authorized_keys file is writable by group or others, or if the file permissions are too permissive. This is a security measure to prevent other users from adding unauthorized keys to your file. A permission of 644 means the file is readable by everyone, which violates the principle of least privilege and can cause authentication to be ignored.
Always set the authorized_keys file permissions to 600 (owner read/write only) using chmod 600 ~/.ssh/authorized_keys. Also ensure the .ssh directory is 700.
Placing the private key in the authorized_keys file instead of the public key
The authorized_keys file is specifically designed to store public keys only. If you put the private key there, anyone who reads the file would have the ability to impersonate the user. SSH authentication uses a challenge-response based on the public key; storing the private key would break the protocol and create a severe security vulnerability.
Always check that the file contains public keys (typically starting with ssh-rsa, ssh-ed25519, etc.) and never copy the private key (id_rsa, id_ed25519) into the authorized_keys file. Use ssh-keygen -y to extract the public key from a private key if needed.
Copying the public key to the wrong user's authorized_keys file
Each user on a system has their own .ssh directory and authorized_keys file. If you copy the public key for user 'alice' into /root/.ssh/authorized_keys, then user 'alice' will still not be able to login using keys. Only the root user would be able to use that key. This leads to broken authentication and confusion.
Always specify the correct remote user when copying the key. Use ssh-copy-id username@remote_host, which automatically places the key in that user's home directory. Alternatively, manually place the key in /home/username/.ssh/authorized_keys.
Forgetting to set the correct ownership of the .ssh directory and authorized_keys file
If the .ssh directory or authorized_keys file is owned by a different user (e.g., root instead of the intended user), SSH will not use them for authentication. SSHD checks ownership to ensure that the user themselves have control over their authentication data. Ownership mismatch causes a silent failure.
After copying or creating the files, run chown -R username:username ~/.ssh to set the correct owner and group. Verify with ls -la ~/.ssh.
Exam Trap — Don't Get Fooled
{"trap":"The question asks: 'Where does SSH store the public key of a user who wants to log in without a password?' The options include /etc/ssh/authorized_keys, /etc/ssh/keys/, and ~/.ssh/authorized_keys.
Many learners pick /etc/ssh/authorized_keys because they think system-wide configuration files are more likely.","why_learners_choose_it":"Learners often confuse system-wide SSH configuration (like /etc/ssh/sshd_config) with user-specific files. They may remember that SSH keys are in /etc/ somewhere but forget that each user has their own file.
This is especially common for those who have not practiced setting up keys manually.","how_to_avoid_it":"Remember that SSH key authentication is user-specific. Each user maintains their own authorized_keys file in their home directory under ~/.
ssh/authorized_keys. The only exception is if you configure sshd to use a global authorized_keys file (AuthorizedKeysFile directive), but that is not the default. Focus on the default path during exams."
Step-by-Step Breakdown
Generate SSH key pair
On the client machine, you use ssh-keygen -t ed25519 to create a pair of keys. A public key (id_ed25519.pub) and a private key (id_ed25519). The private key stays secret on your machine. The public key is what you will copy to the server.
Copy the public key to the server
You need to place the public key into the remote user's ~/.ssh/authorized_keys file. The easiest way is using ssh-copy-id username@remote_host, which appends the key and sets correct permissions. Alternatively, you can manually append the key using ssh and cat.
Set correct permissions on the server
SSHD is very strict about permissions. The ~/.ssh directory must be 700 (owner can read/write/execute, no one else). The authorized_keys file must be 600 (owner can read/write). If permissions are too open, SSHD ignores the file. Use chmod 600 ~/.ssh/authorized_keys and chmod 700 ~/.ssh.
Configure SSHD (optional but common)
Ensure that the SSH daemon is configured to allow public key authentication. In /etc/ssh/sshd_config, the line PubkeyAuthentication yes must be set (default). You may also set PasswordAuthentication no to enforce key-only logins. Restart sshd after changes.
Test the connection
From the client, run ssh username@remote_host. If everything is set up correctly, you should be logged in without a password prompt. If it fails, check the logs on the server (journalctl -u sshd or /var/log/auth.log) for details like 'Authentication refused: bad permissions'.
Practical Mini-Lesson
In practice, the authorized_keys file is not just a static list of public keys. System administrators often use advanced features to enforce restrictions. For example, you can prefix a key with command="/usr/bin/rsync --server --sender" to restrict that key to only run rsync in sender mode. This is useful for backup servers where you want to limit what the key can do. Similarly, you can restrict the source IP address with from="192.168.1.0/24" so that the key only works from a specific network.
Another common practice is using SSH Certificate Authorities (CAs). Instead of adding every developer's public key to every server, you configure the server to trust a CA certificate. Then each developer receives a signed certificate that expires after a set time. The authorized_keys file can contain the CA public key with a cert-authority directive. This simplifies key management tremendously in large organizations.
When things go wrong, the first thing to check is permissions. Run ls -la ~/.ssh and ls -la ~/.ssh/authorized_keys. The directory should be 700 and the file 600. Ownership should match the user. Next, check the file format, each line must start with the key type, then the base64 data, and optionally a comment. Extra whitespace or line breaks can cause failure. You can test the key locally with ssh-keygen -l -f ~/.ssh/authorized_keys to see if the file is parsed correctly.
Finally, always remember that the private key is the real secret. Do not generate keys without a passphrase unless you fully understand the risk. A passphrase adds a layer of protection if the private key is stolen. Use ssh-agent to cache the passphrase so you do not have to type it constantly. The combination of a strong passphrase, proper permissions, and restricted commands in authorized_keys makes for a very secure remote access setup.
Memory Tip
Think of authorized_keys as the 'guest list' on the server: only the keys on this list get in without knocking (password).
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Legacy Exam Context
Older materials may mention these exam versions, but learners should use the current objectives for their target exam.
SY0-601SY0-701(current version)Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
Frequently Asked Questions
Can I have multiple public keys in the authorized_keys file?
Yes, you can add one public key per line. Each key represents a different private key that can authenticate as that user. This is useful when multiple administrators or devices need access.
What happens if the authorized_keys file permissions are 644?
SSHD may still accept the file if StrictModes is set to no, but by default (StrictModes yes) it will ignore the file and authentication will fail using keys. Always set permissions to 600.
Is it safe to share my public key?
Yes, public keys are designed to be shared. They cannot be used to derive the private key. However, you should only add your public key to servers and services you trust.
Can I use authorized_keys on Windows?
Yes, OpenSSH is available on Windows 10 and later. The authorized_keys file is located in %USERPROFILE%\.ssh\authorized_keys and works the same way as on Linux.
How do I remove a key from authorized_keys?
You can manually edit the file with a text editor and delete the line containing the key you want to remove. Alternatively, use sed or a similar command to remove the specific line.
Can I use the same authorized_keys file for multiple users?
Not easily. Each user has their own file in their home directory. A system-wide authorized_keys file can be configured with the AuthorizedKeysFile directive in sshd_config, but the default is per-user.
Summary
The authorized_keys file is a simple but powerful tool for managing secure, passwordless SSH logins. It lives on the server inside each user's .ssh directory and contains the public keys that are allowed to authenticate. By using key pairs instead of passwords, you eliminate the risk of brute force attacks and enable automation scripts to run securely.
In IT certification exams, particularly CompTIA Security+, Linux+, RHCSA, and LPIC-1, you must understand the correct file location, permissions (600 for the file, 700 for the directory), and how to generate and copy keys. You should also be aware of common troubleshooting scenarios, such as incorrect ownership or overly permissive settings. The exam may present a scenario where a user cannot log in with keys, and you must identify the permission problem or the missing public key.
Beyond exams, mastering the authorized_keys file is essential for any systems administrator. It is the foundation of secure remote access in Linux environments. By combining it with SSH Certificate Authorities and restricted command options, you can build a robust and scalable access control system. Remember the analogy of the guest list, only keys on that list get in without a password. Keep your private key safe, your public key on the list, and your permissions strict.