SSH Keys Explained: Public Keys, Private Keys, and Modern Key Generation Techniques
Learn how SSH uses public and private keys to securely authenticate with Linux and AWS servers. This guide also covers modern key-generation methods, Ed25519, EC2 Instance Connect, and hardware-backed SSH keys.
What is SSH?
SSH (Secure Shell) is a protocol used to securely connect to remote systems over a network.
For example, we can connect to an Ubuntu EC2 instance using:
1
ssh -i my-key.pem ubuntu@<EC2-PUBLIC-IP>
The command tells SSH:
ssh→ use the SSH client-i my-key.pem→ use this private key for authenticationubuntu→ connect as the Ubuntu user<EC2-PUBLIC-IP>→ connect to the remote server
SSH provides encrypted communication between the client and the server.
It is commonly used for:
- Linux server administration
- AWS EC2 access
- DevOps and cloud infrastructure
- Git operations
- Kubernetes administration
- Automation and deployment
Public Key vs Private Key
SSH authentication uses a key pair.
A key pair contains:
1
2
3
Private Key
+
Public Key
The two keys are mathematically related, but they have different purposes.
Private Key
The private key is the secret part of the key pair.
For example:
1
my-key
or an AWS-generated key might be:
1
my-key.pem
The private key should remain on your computer and should never be shared publicly.
Think of the private key as your personal secret credential.
If someone obtains your private key and the server accepts it, they may be able to authenticate as you.
Public Key
The public key is designed to be shared.
It normally has a
.pub extension:1
my-key.pub
The public key can be placed on the server inside:
1
~/.ssh/authorized_keys
The server uses this public key to verify that the person connecting actually possesses the corresponding private key.
The important rule is:
Share the public key. Protect the private key.
How Does SSH Key Authentication Work?
Let's simplify the process.
Imagine that your laptop wants to connect to an EC2 instance.
1
2
3
4
5
6
7
8
9
10
11
Your Laptop EC2 Server
----------- ----------
Private Key Public Key
| |
| -------- SSH Connection --------> |
| |
| <------ Authentication Challenge |
| |
| ---- Proof using Private Key ---> |
| |
| <--------- Access Granted ------- |
The private key is not simply sent to the server.
Instead, SSH uses cryptographic operations to prove that you possess the private key corresponding to the public key stored on the server.
This is one reason public-key authentication is much safer than sending a password over the network.
Generating an SSH Key Pair
One of the most common tools for generating SSH keys is:
1
ssh-keygen
A modern option for many Linux and development environments is Ed25519.
For example:
1
ssh-keygen -t ed25519 -C "my-aws-key"
You may see something like:
1
2
3
4
Generating public/private ed25519 key pair.
Enter file in which to save the key:
Enter passphrase:
Enter same passphrase again:
After generation, you will typically have:
1
2
~/.ssh/my-key
~/.ssh/my-key.pub
The files represent:
1
2
my-key → Private key
my-key.pub → Public key
Why Use Ed25519?
Older SSH tutorials often use RSA:
1
ssh-keygen -t rsa -b 4096
RSA is still widely supported and remains useful, especially where compatibility requires it.
However, Ed25519 is a modern SSH key type supported by OpenSSH and Amazon EC2 for Linux instances. AWS documentation currently lists RSA and ED25519 as supported EC2 key-pair types for Linux.
For a new Linux project, Ed25519 is often a good default when the environment supports it.
Example:
1
ssh-keygen -t ed25519 -C "devops-lab"
The
-C option adds a comment to help identify the key.Protecting the Private Key
Generating a strong key is only part of SSH security.
The private key itself must also be protected.
On Linux or macOS, we can restrict its permissions:
1
chmod 600 ~/.ssh/my-key
or:
1
chmod 400 ~/.ssh/my-key
AWS documentation also recommends restricting permissions on private key files used for EC2 SSH connections.
We should also avoid:
1
2
3
4
5
Uploading private keys to GitHub
Sending private keys through chat
Putting private keys inside Docker images
Committing private keys into source code
Sharing private keys with teammates
Instead, each developer should normally have their own key pair.
SSH Key with AWS EC2
When launching an EC2 instance, AWS allows us to associate an SSH key pair with the instance.
For example:
1
2
3
4
5
6
AWS EC2
|
+--- Public Key
|
v
Linux instance
The corresponding private key is stored by the user.
AWS does not give you another copy of the private key later, so losing it can create an access problem. AWS specifically notes that the private key file is available to save when the key pair is created.
A traditional SSH connection may look like:
1
ssh -i my-key.pem ubuntu@203.0.113.10
A More Modern AWS Approach: EC2 Instance Connect
Traditional SSH key management can become difficult when an organization has many EC2 instances and many engineers.
For example:
1
2
3
4
5
6
7
100 EC2 instances
+
20 engineers
+
multiple SSH keys
=
difficult key management
AWS provides EC2 Instance Connect as another approach.
Instead of permanently placing a user's public key on the instance, EC2 Instance Connect can push a public key to the instance for a short period.
AWS documentation states that the public key remains available for 60 seconds.
The simplified workflow is:
1
2
3
4
5
6
7
8
9
10
11
12
13
Developer
|
| IAM authorization
v
AWS EC2 Instance Connect
|
| Temporary public key
v
EC2 Instance
|
| SSH authentication
v
Developer gets access
This is interesting because SSH authentication is combined with AWS IAM-based authorization.
AWS also states that EC2 Instance Connect connection requests can be logged through AWS CloudTrail, providing an audit trail.
This can reduce the need to permanently distribute and manage SSH public keys across instances.
Using the AWS CLI with EC2 Instance Connect
For example, a public key can be pushed to an EC2 instance using:
1
2
3
4
5
aws ec2-instance-connect send-ssh-public-key \
--instance-id i-xxxxxxxxxxxxxxxxx \
--instance-os-user ubuntu \
--availability-zone ap-southeast-1a \
--ssh-public-key file://my-key.pub
AWS then allows a short window to establish the SSH connection. The public key is removed from the instance metadata after 60 seconds.
The important point is that we are still using SSH cryptography, but AWS is helping manage the authorization and temporary public-key delivery.
An Even Newer Technique: Hardware-Backed SSH Keys
SSH key generation has also evolved beyond storing all key material on a normal filesystem.
Modern OpenSSH supports FIDO/U2F security-key-backed SSH keys.
For example:
1
ssh-keygen -t ed25519-sk
or:
1
ssh-keygen -t ecdsa-sk
The
-sk means the key uses a FIDO security key.According to the OpenSSH documentation, FIDO-backed SSH keys can use a hardware authenticator, and the device-specific private key material cannot be exported from the authenticator. Authentication can also require the user to physically touch or tap the security key.
This creates an interesting security model:
1
2
3
4
5
6
7
8
9
Laptop
|
| SSH
v
SSH Security Key
|
| Hardware-backed signing
v
Remote Server
Instead of keeping the complete private key in ordinary software storage, part of the cryptographic protection is provided by the hardware authenticator.
This can be particularly useful for protecting high-value administrative access.
Traditional SSH vs Modern Approaches
We can think about the evolution like this:
| Approach | Main Idea |
|---|---|
| Password authentication | Authenticate using a password |
| Traditional SSH keys | Long-lived private/public key pair |
| Ed25519 | Modern efficient SSH key type |
| EC2 Instance Connect | Temporarily push public keys using AWS authorization |
| FIDO-backed SSH keys | Hardware-backed authentication |
| IAM + short-lived access | Reduce dependence on permanent credentials |
The goal is not simply to generate a stronger key.
The larger security goal is:
Reduce long-lived credentials, protect private keys, and make access easier to control and audit.
Practical SSH Security Checklist
When using SSH in cloud environments, I follow a few basic principles:
1. Never share private keys
A private key should remain private.
2. Use a passphrase
When generating an SSH key:
1
ssh-keygen -t ed25519
choose a strong passphrase when appropriate.
3. Use modern key types
For new Linux environments, consider Ed25519 when supported.
4. Use separate keys
Avoid using one private key for every server and every purpose.
For example:
1
2
3
4
AWS-Lab-Key
GitHub-Key
Production-Key
Personal-Server-Key
5. Do not store private keys in Git
Never commit:
1
2
3
*.pem
id_rsa
id_ed25519
or other private credentials into a repository.
6. Consider temporary access
For AWS environments, investigate services such as EC2 Instance Connect instead of relying only on permanently installed SSH keys.
7. Consider hardware-backed keys
For sensitive environments, FIDO-backed SSH keys can provide an additional layer of protection.
What I Learned
SSH keys initially looked like just two files:
1
2
private key
public key
But there is much more behind them.
The important concept is not simply:
"Generate an SSH key and use it."
It is understanding the complete authentication model:
1
2
3
4
5
6
7
8
9
Identity
↓
Public/Private Key
↓
Cryptographic Authentication
↓
SSH
↓
Server Access
And in modern cloud environments:
1
2
3
4
5
6
7
8
9
IAM
↓
Temporary Authorization
↓
EC2 Instance Connect
↓
SSH
↓
EC2
As cloud infrastructure grows, secure access is becoming less about keeping one permanent SSH key on every server and more about strong identity, short-lived access, auditing, and hardware-backed authentication.
For anyone learning AWS, Linux, or DevOps, understanding SSH keys is a small but very important step toward understanding cloud security.
Final Thoughts
SSH is still a fundamental technology in cloud and DevOps environments. Learning how public and private keys work gives us a foundation for understanding EC2 access, Git authentication, automation, and infrastructure security.
At the same time, modern approaches such as Ed25519 keys, EC2 Instance Connect, and FIDO-backed SSH keys show how SSH authentication is continuing to evolve.
The technology may change, but the security principle remains simple:
Protect what is secret, minimize long-lived access, and make authentication easy to control and audit.
#AWS #AWSBuilder #AWSCloud #SSH #Linux #DevOps #CloudSecurity #CyberSecurity #EC2 #CloudComputing
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article