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

Sonali DesaiSonali Desai
3 min read

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!

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

0
Subscribe to my newsletter

Read articles from Sonali Desai directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Sonali Desai
Sonali Desai