# Public key authentication

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/public-key-authentication

## Quick definition

Public key authentication is a way to prove who you are without sending a password. It uses two keys: a public key that anyone can see and a private key that only you have. When you log in, the system checks that you hold the private key that matches the public key. This makes it much harder for attackers to steal your credentials.

## Simple meaning

Imagine you own a special mailbox with two different locks. One lock can be opened by anyone who has a copy of the public key-you give copies to everyone you know. The other lock can only be opened by your private key, which you keep on your keychain and never share. When someone wants to send you a secret message, they lock it with your public key. Because only your private key can unlock it, the message stays safe. But public key authentication works in reverse for proving identity: you prove you are you by showing you have the private key, without ever revealing it.

In the digital world, this is used every time you connect to a server using SSH or when you visit a website that uses TLS. The server sends a challenge-a random piece of data-and your client signs it with your private key. The server then uses your public key to verify the signature. If the signature matches, the server knows you are the legitimate user. This process eliminates the need to send a password over the network, which is a common target for attackers.

Think of it like a wax seal on a medieval letter. Your private key is your personal seal ring. You press it into hot wax, leaving an imprint that is unique. Everyone who has seen your seal before can recognize the imprint. But no one can forge a new letter with your exact seal unless they have your ring. In public key authentication, you never give away the ring-you only show the imprint (the signature) when asked. This way, even if the internet eavesdrops on the entire conversation, they never learn your private key. They only see the signature, which is useless for impersonating you later.

## Technical definition

Public key authentication is an asymmetric cryptographic technique that relies on a mathematically linked key pair: a public key and a private key. The public key can be freely distributed, while the private key must remain confidential to the owner. The core mechanism is based on one-way functions, typically involving prime number factorization (RSA) or elliptic curve discrete logarithm problems (ECDSA). These functions are computationally easy to compute in one direction but infeasible to reverse without the private key.

In practice, public key authentication is implemented in several protocols. Secure Shell (SSH) is the most common example for remote server access. The process begins with key generation, often using tools like ssh-keygen. The public key is appended to the server’s authorized_keys file. During authentication, the server sends a random challenge message encrypted with the user’s public key. Only the holder of the corresponding private key can decrypt it. The user’s client then sends back the decrypted challenge, proving possession of the private key. Alternatively, the client can sign the challenge with the private key, and the server verifies the signature using the public key.

Another major protocol is Transport Layer Security (TLS), which underpins HTTPS. In TLS 1.3, public key authentication occurs during the handshake. The server presents its certificate, which contains its public key, signed by a trusted Certificate Authority (CA). The client verifies the certificate chain, then generates a pre-master secret, encrypts it with the server’s public key, and sends it to the server. Only the server can decrypt it, establishing a shared symmetric key for the session. Client certificates are also possible, where the client authenticates itself with its own public key and certificate.

The standards governing public key authentication include the Public Key Infrastructure (PKI) as defined by X.509, and the cryptographic algorithms standardized by NIST (e.g., FIPS 186-4 for DSA). Real IT implementations use hardware security modules (HSMs) or Trusted Platform Modules (TPMs) to store private keys securely, preventing extraction even if the operating system is compromised. Configurations on SSH servers involve settings like PubkeyAuthentication yes in sshd_config, and the choice of key type (RSA, ECDSA, Ed25519) affects security and performance. Attackers may attempt to compromise public key authentication through methods like brute-forcing weak private keys, stealing the private key file (often from ~/.ssh/id_rsa), or exploiting poor passphrase protection. Best practices include using strong key types (Ed25519 or 4096-bit RSA), protecting private keys with strong passphrases, and regularly rotating keys.

## Real-life example

Imagine you are the owner of a popular nightclub. Instead of a typical membership card, you give your trusted VIPs a special stamp that changes each night. The stamp is your public key. At the door, the bouncer has a blacklight that reveals the stamp. But the VIP also carries a small device that displays a unique, glowing number that changes every minute. That device is the private key. When a VIP arrives, the bouncer asks for the number on the device. The device computes a new number based on the current time and the VIP’s secret. The bouncer checks this number against a list of expected numbers derived from the stamps he has. If the number matches, the VIP is let in. The bouncer never sees the secret inside the device, and the VIP never shares the device itself.

Now map this to the IT concept. The nightclub is the server you want to access. The stamp is your public key, stored on the server in the authorized_keys file. The glowing device 

 is your private key, kept on your local computer. The bouncer is the SSH daemon process. The changing number is the cryptographic signature generated from the challenge (the time in this analogy) using your private key. The bouncer verifies this signature using the public key stamp. If it verifies, access is granted. The critical security property is that even if a thief steals the stamp (the public key), they cannot compute the next number without the device (the private key). The only way to impersonate a VIP is to physically steal the device, which would immediately be noticed and deactivated.

## Why it matters

Public key authentication matters because it solves the fundamental problem of securely proving identity over an insecure network. Passwords are vulnerable to interception (e.g., packet sniffing), phishing, credential stuffing, and brute-force attacks. Public key authentication eliminates these risks by never transmitting the secret itself. Instead, only a cryptographic proof is sent, which is useless to an eavesdropper for future impersonation.

In practical IT administration, public key authentication is the standard for managing large fleets of servers. Systems administrators can disable password-based SSH logins entirely, significantly reducing the attack surface. Automation tools like Ansible, Puppet, and Chef rely on SSH keys to connect to managed nodes without human intervention. Cloud platforms such as AWS and Azure require public key authentication for EC2 instances and virtual machines, because it scales securely across thousands of machines.

public key authentication enables non-repudiation in digital signatures. Because the private key is uniquely tied to an individual (or device), a signed document can be legally binding. This is essential for code signing, email encryption (S/MIME), and secure software distribution. Without public key authentication, the trust models of the internet-HTTPS, email encryption, software updates-would collapse. Understanding this term is foundational for any IT professional responsible for security, as misconfigurations can lead to devastating breaches. For example, leaving private keys on a shared drive or using weak passphrases can allow an attacker to pivot across an entire infrastructure.

## Why it matters in exams

Public key authentication is a core objective across multiple IT certification exams. In CompTIA Security+ (SY0-601/701), it appears under Domain 3 (Implementation) and Domain 4 (Operations and Incident Response). Candidates must understand the difference between symmetric and asymmetric encryption, and how public key authentication supports secure protocols like SSH, TLS, and IPsec. Questions often ask to identify the correct step in the SSL/TLS handshake or to diagnose why SSH key authentication failed.

For the CISSP exam, public key authentication is deeply embedded in the Cryptography domain (Domain 3). Candidates must know the mathematical principles (RSA, ECDSA), key management lifecycle, and PKI. Expect scenario-based questions where you need to choose the appropriate authentication method for a given risk profile. For example, you might be asked which method provides perfect forward secrecy when combined with public key authentication.

For the CCNA (200-301), public key authentication appears in the context of secure device access, specifically SSH configuration. You need to know how to generate RSA keys on a Cisco IOS device, configure SSH version 2, and troubleshoot SSH authentication failures. The exam may present a configuration output and ask why users cannot SSH in, with possible causes like missing host key or incorrect public key.

For the AWS Certified Solutions Architect Associate, public key authentication is critical for EC2 key pairs. You must understand how key pairs are used to encrypt the administrator password for Windows instances, and how to securely store private keys in AWS Secrets Manager. Questions might ask what happens if the private key is lost, or how to rotate key pairs without downtime.

Finally, for the ISC² SSCP, public key authentication is part of the Access Controls domain. Candidates must distinguish between something you know (password), something you have (private key), and something you are (biometric). The exam will test your ability to design multi-factor authentication that includes a public-key-based token.

## How it appears in exam questions

Exam questions on public key authentication fall into several patterns. The most common is the configuration scenario: “A network administrator has disabled password authentication on an SSH server. Users are reporting they cannot log in anymore. What is the most likely cause?” The answer typically involves checking that the users’ public keys are correctly placed in the ~/.ssh/authorized_keys file on the server. Another frequent variant: “An administrator runs ssh-keygen -t rsa -b 4096. Which file contains the private key?” The answer is ~/.ssh/id_rsa (or id_rsa by default).

Another pattern is the protocol sequence question: “During an SSH key exchange, what does the server send to the client after receiving the client’s public key?” The correct answer is a challenge encrypted with the client’s public key, and the expected response is the decrypted challenge. For TLS, questions might ask: “In TLS 1.3, which party authenticates itself first using public key authentication?” The answer is the server, via its certificate.

Troubleshooting questions often present a log snippet. For example: “The log shows ‘Permission denied (publickey).’ What are three possible reasons?” Answers include: the public key is not in authorized_keys, the permissions on the .ssh directory are incorrect (must be 700), or the private key file has incorrect permissions (must be 600). Another troubleshooting pattern: “A user is able to SSH from their laptop but not from a company workstation. What is the likely issue?” The answer: the private key is not present on the workstation.

Finally, there are conceptual comparison questions: “Which of the following best describes the difference between public key authentication and password authentication?” The correct answer highlights that public key authentication proves possession of a secret without transmitting it, while password authentication transmits the secret over the network. Some exams will ask about the security properties: “Which attack is public key authentication specifically designed to prevent?” The answer is man-in-the-middle (when used with a known host key) and password sniffing.

## Example scenario

You are a junior IT administrator at a small company. The senior admin has just configured the SSH server on a Linux machine to use public key authentication only, disabling password logins. He tells you to connect from your workstation. You sit down and open your terminal. You type ssh admin@192.168.1.100. Instead of a password prompt, you get an error: Permission denied (publickey).

You check your own machine. You remember the senior admin gave you a file called id_rsa with instructions to place it in the ~/.ssh/ directory. You navigate there and see the file. But the error persists. You think about the permissions. You run ls -l on the .ssh folder and see that it has permissions 755 (drwxr-xr-x). You then remember that the SSH server is very strict about folder permissions. The .ssh directory should be 700 (only accessible by the owner). You run chmod 700 ~/.ssh. You try again and still get the error.

Now you check the authorized_keys file on the server. You log in via the console (physical access) and look at /home/admin/.ssh/authorized_keys. It is empty! The senior admin had not yet added your public key. He gave you the private key but forgot to install the corresponding public key. You generate a new key pair with ssh-keygen -t ed25519, then copy the contents of id_ed25519.pub into the authorized_keys file on the server. You set the file permissions to 600. Now you try SSH from your workstation again. It works without a password. This scenario shows that public key authentication fails not only due to missing private keys, but also due to missing public keys on the server, incorrect permissions, or mismatched key pairs.

## Common mistakes

- **Mistake:** Thinking that the public key must be kept secret.
  - Why it is wrong: The entire point of public key authentication is that the public key can be shared freely without compromising security. The security relies on the private key being secret.
  - Fix: Always share your public key with anyone who needs to authenticate you. Keep your private key encrypted and never email it or upload it to a server.
- **Mistake:** Copying the private key to the server's authorized_keys file.
  - Why it is wrong: The authorized_keys file only contains public keys. If you copy the private key there, the authentication will fail because the server will try to verify with the private key, which cannot decrypt or verify signatures made with itself.
  - Fix: Always copy the contents of the .pub file (e.g., id_rsa.pub) into authorized_keys, never the private key file.
- **Mistake:** Setting incorrect file permissions on the .ssh directory or private key.
  - Why it is wrong: SSH is designed to refuse to use a private key if it is readable by anyone else (e.g., group or world-readable). Permissions like 644 or 755 on the private key will cause the SSH client to ignore the key and fall back to other methods or fail.
  - Fix: Run chmod 700 ~/.ssh and chmod 600 ~/.ssh/id_rsa (or your private key file). Ensure the .ssh directory and private key are owned by you.
- **Mistake:** Sharing the same key pair across multiple users.
  - Why it is wrong: If multiple users share the same private key, no one can be held accountable for actions performed using that key. If the key is compromised, all users are affected. This also violates the principle of least privilege and audibility.
  - Fix: Each user should generate their own key pair. The public keys should be added separately to the server's authorized_keys file for each user.

## Exam trap

{"trap":"The exam shows an SSH configuration with PubkeyAuthentication yes and PasswordAuthentication no. A user cannot log in. The candidate assumes the issue is that the user's private key is missing.","why_learners_choose_it":"Learners see the error message “Permission denied (publickey)” and think the problem must be on the client side-the private key is missing or incorrect.","how_to_avoid_it":"Remember that the error message is generic. The most common cause is that the public key is not present in the server's authorized_keys file, or the file permissions on the server side are wrong. Always check the server side first. Also verify that the private key is in the correct default location or explicitly specified with the -i flag."}

## Commonly confused with

- **Public key authentication vs Symmetric key authentication:** Symmetric key authentication uses a single shared secret key for both encryption and decryption. Both parties already know the key. Public key authentication uses separate keys: a public key for encryption and a private key for decryption, eliminating the need to share a secret beforehand. (Example: Symmetric key is like a shared safe combination you give to a friend. Public key is like a mailbox with a slot: anyone can drop a letter in, but only you have the key to open it.)
- **Public key authentication vs Certificate-based authentication:** Certificate-based authentication is an extension of public key authentication where the public key is embedded in a digital certificate signed by a trusted Certificate Authority. While public key authentication can work without certificates (like SSH keys), certificates add trust through a chain of authority. (Example: Public key without certificate: you give your public key to a friend directly. Certificate: a trusted notary verifies your identity and issues an ID card that contains your public key.)
- **Public key authentication vs Password authentication:** Password authentication relies on a shared secret that is transmitted over the network. Public key authentication never transmits the secret itself; it only transmits a cryptographic challenge response. Passwords are vulnerable to sniffing, brute-force, and replay attacks, while public key authentication is resistant to these. (Example: Password is like whispering a secret code in a crowded room. Public key is like showing a unique stamp that proves you own a special ring without ever taking the ring off.)

## Step-by-step breakdown

1. **Key Generation** — The user runs a tool like ssh-keygen to create a public-private key pair. The private key is stored locally, often encrypted with a passphrase. The public key is a file ending in .pub. The algorithm (RSA, ECDSA, Ed25519) determines key strength and performance.
2. **Public Key Installation** — The user copies the public key contents (the .pub file) to the server's authorized_keys file, typically located at ~/.ssh/authorized_keys on the server. This file can contain multiple public keys, one per line.
3. **Connection Initiation** — The user runs an SSH client command to connect to the server. The client reads the private key from its default location or the one specified with the -i flag. The client and server negotiate SSH protocol version and algorithms.
4. **Server Challenge** — The server reads the public key from authorized_keys. It generates a random challenge, encrypts it with the user's public key, and sends it to the client. Alternatively, the server sends a random string and asks the client to sign it with the private key.
5. **Client Response** — The client uses the private key to decrypt the challenge, or to sign the server's random string. The decrypted value (or the signature) is sent back to the server. The client never sends the private key itself.
6. **Server Verification** — The server compares the client's response with the original challenge. If the decrypted challenge matches exactly, or if the signature verifies correctly using the public key, authentication succeeds. The server then allows the session to begin.

## Practical mini-lesson

Public key authentication is not just about SSH. In a professional IT environment, you will encounter it in many forms. For example, when you set up a CI/CD pipeline, the pipeline agent needs to authenticate to the source code repository (e.g., GitHub) and to the deployment servers. Instead of using a bot account password, you generate a key pair specifically for the pipeline. You add the public key as a deploy key to the repository and also add it to the target servers’ authorized_keys. This way, even if the pipeline machine is compromised, the attacker can only access the specific repositories and servers, not your personal account.

Another common use: secure file transfers with SFTP. The SFTP subsystem runs over SSH, so the same public key authentication applies. This is widely used in financial services for batch file transfers.

What can go wrong? Key management is the biggest challenge. A company may have thousands of keys spread across servers. If an employee leaves, you must remove their public key from all servers. This is often overlooked, leading to security gaps. The solution is to use a centralized authentication system like LDAP or Active Directory integrated with SSH, or use SSH certificates (ssh-ca) that have short expiration times. 

Also, private key passphrases are often a point of friction. If you use a passphrase, you need to enter it every time you use the key. To avoid this, IT professionals use SSH agents (like ssh-agent on Linux or Pageant on Windows) that cache the decrypted private key in memory. You enter the passphrase once when you start the agent. This is more secure than an unencrypted private key because the key file is still encrypted on disk.

Finally, remember that public key authentication does not protect against a compromised private key. If an attacker copies your private key file (e.g., from a backup or by exploiting a vulnerability), they can log in as you. Therefore, protect private keys with strong file permissions, encryption, and hardware tokens like YubiKeys when possible.

## Memory tip

Think “Public is for sharing, Private is for caring”, the public key is shared everywhere, the private key is guarded like a treasure.

## FAQ

**Can I use the same public key on multiple servers?**

Yes, you can add your public key to the authorized_keys file on many servers. This is convenient, but if one server is compromised, the attacker could also access the other servers. It is safer to use separate keys for separate security domains.

**What happens if I lose my private key?**

You will not be able to authenticate to any server that has your public key. You must generate a new key pair and replace the public key on each server. There is no way to recover the private key.

**Is public key authentication better than passwords?**

Yes, for most remote access scenarios. It is resistant to brute-force, phishing, and replay attacks. However, it requires careful key management. Many organizations use multi-factor authentication that combines public key authentication with a password or biometric.

**What is the difference between SSH key authentication and using a password?**

In key authentication, you prove you own a private key without sending it over the network. The server only sees a cryptographic proof. With a password, the actual password is transmitted (even if encrypted), making it vulnerable to interception if the encryption is broken.

**How do I ensure my private key is safe?**

Store it in a secure location with permissions set to 600. Use a strong passphrase. Consider using a hardware security key like a YubiKey that generates and stores the key. Never copy it to a shared drive or email it.

**Can public key authentication be intercepted?**

The proof (signature or decrypted challenge) is sent over the network, but it is only valid for that specific session. An attacker cannot reuse it because the server's challenge changes each time. This prevents replay attacks.

## Summary

Public key authentication is a fundamental security mechanism that allows users to prove their identity without transmitting a secret. Using a mathematically linked pair of keys, it underpins secure protocols like SSH, TLS, and SFTP. For IT certification learners, understanding the difference between public and private keys, the authentication flow, and common pitfalls like permission errors or mismatched keys is essential for both exams and real-world administration.

On exams, expect configuration scenarios, troubleshooting logs, and conceptual comparisons with passwords and certificates. Mastery of this topic will help you answer questions about secure access, encryption protocols, and key management. In practice, public key authentication is non-negotiable for modern IT security. It reduces attack surfaces, enables automation, and provides non-repudiation. However, it is only as secure as the protection of the private key. Always use strong passphrases, proper file permissions, and consider hardware-backed keys.

Remember the key principle: the public key can be distributed freely, but the private key must never leave your control. This simple rule will guide you through both exam questions and on-the-job decisions.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/public-key-authentication