Why Using `.pem` Files Directly Isn't Always Secure — and What You Should Do Instead

When you first deploy a server on cloud platforms like AWS, you're usually given a .pem
file to SSH into your instance. While this works for beginners and short-term use, relying solely on .pem
files can lead to security risks and operational hassles over time.
What’s Risky About .pem
Files?
They're often stored in default folders like Downloads, where they can be easily exposed or deleted.
If the
.pem
file is shared across systems or people, you're increasing the attack surface.If lost, you could lose access to your server unless a backup login method exists.
They require
chmod 400
permissions, and forgetting this often causes login failures.
In this article, I’ll walk you through three safer and smarter ways to SSH into your server and how to fix the common error:
Permission denied (publickey)
Method 1: Using a .pem
File (Only if You Must)
This is the most basic method for SSH login — and the first one most users learn.
ssh -i ~/Downloads/test1.pem sonali@13.203.245.142
🔐 Make sure your .pem
file has the right permission:
chmod 400 ~/Downloads/test1.pem
📌 Use this only:
When logging in for the first time
If you’ve downloaded the
.pem
securely and temporarily
Method 2: Configure SSH for Clean & Reusable Access
You can avoid typing the full path every time by adding your key to an SSH config file.
✅ Step-by-step:
Move your key to a safe location:
mkdir -p ~/.ssh
cp ~/Downloads/test1.pem ~/.ssh/test1.pem
chmod 400 ~/.ssh/test1.pem
Create or edit your SSH config file:
nano ~/.ssh/config
Add this block:
Host myserver
HostName 13.203.245.142
User sonali
IdentityFile ~/.ssh/test1.pem
🎉 Now login is as simple as:
myserver
✅ No need to remember paths or usernames!
Method 3: Use Your Own Local SSH Key (Recommended for Security & Scalability)
This is the most secure and scalable method — no .pem
file needed once set up.
💡 Option 1: Use ssh-copy-id
(Easy & Automated)
If you're able to connect using .pem
at least once, you can run:
ssh-copy-id -i ~/.ssh/id_rsa.pub sonali@13.203.245.142
This command securely copies your local public key to the server and appends it to ~/.ssh/authorized_keys
.
From now on, you can just run:
ssh sonali@13.203.245.142
✅ No more .pem
, no need to remember key paths.
✋ Option 2: Manually Add Your Public Key to the Server
If ssh-copy-id
isn’t available, here’s how to do it manually:
1. On your local machine, display your public key:
cat ~/.ssh/id_rsa.pub
Copy the entire line (starting with ssh-rsa
...).
2. SSH into the server using .pem
:
ssh -i ~/Downloads/test1.pem sonali@13.203.245.142
3. On the server, run:
mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys
Paste the public key inside the file.
Save and exit (Ctrl + X
, then Y
, then Enter
).
4. Set correct permissions:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
✅ Now, from your local system, simply run:
ssh sonali@13.203.245.142
You're in — securely, and without .pem
!
Final Thoughts
Managing SSH keys the right way improves both security and developer productivity. While .pem
files help get started quickly, moving to SSH config files or your own local SSH key setup makes your workflow more secure and professional.
#ssh#devops#cloud#aws#linux#security#beginners
Subscribe to my newsletter
Read articles from Sonali Desai directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
