How to Set Up SSH Key Authentication with a Shared .pem File for Ubuntu Servers on DigitalOcean


2 views

When managing multiple Ubuntu servers on DigitalOcean, password-based authentication poses security risks. A more secure approach is using SSH key authentication with a shared identity file (like AWS's .pem system). This eliminates the need to manage individual public keys for each team member.

First, generate a key pair on your local machine:

ssh-keygen -t rsa -b 4096 -f team_identity -C "Team shared key"

This creates two files:

  • team_identity (private key)
  • team_identity.pub (public key)

On your DigitalOcean droplet, create the SSH directory if it doesn't exist:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

Add the public key to authorized_keys:

cat team_identity.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Distribute the team_identity file to your team members securely. They should:

  1. Place it in their ~/.ssh/ directory
  2. Set proper permissions: chmod 600 ~/.ssh/team_identity

Team members can now connect using:

ssh -i ~/.ssh/team_identity username@server_ip

For convenience, they can add the key to their SSH agent:

ssh-add ~/.ssh/team_identity

Once confirmed working, disable password authentication in /etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no

Then restart SSH: sudo systemctl restart sshd

For better security, consider these additional measures:

# Limit users who can SSH
AllowUsers webuser

# Disable root login
PermitRootLogin no

Common issues and solutions:

  • Permission denied: Verify key permissions (600) and ownership
  • Connection refused: Check if SSH port (22) is open in DigitalOcean firewall
  • Agent admitted failure: Run ssh-add to load the key

While password-based authentication works for initial server setup, it creates significant security and management challenges for teams:

  • Password rotation becomes cumbersome
  • Brute force attacks remain a threat
  • No individual accountability (shared credentials)
  • No easy way to revoke access

Your proposed solution using a shared identity.pem file offers several advantages:

# Example of desired login flow:
ssh-add ~/path/to/team_identity.pem
ssh webuser@server_ip

1. Generate the Key Pair

On your local machine (not the server):

ssh-keygen -t rsa -b 4096 -f team_identity -C "Team shared access key"
# This creates:
# - team_identity (private key)
# - team_identity.pub (public key)

2. Configure Server Access

On your DigitalOcean droplet:

# Create the webuser account
sudo adduser webuser
sudo usermod -aG sudo webuser

# Set up SSH directory
sudo mkdir -p /home/webuser/.ssh
sudo touch /home/webuser/.ssh/authorized_keys

# Add public key
echo "PASTE_PUBLIC_KEY_HERE" | sudo tee -a /home/webuser/.ssh/authorized_keys

# Set permissions
sudo chown -R webuser:webuser /home/webuser/.ssh
sudo chmod 700 /home/webuser/.ssh
sudo chmod 600 /home/webuser/.ssh/authorized_keys

3. Distribute the Private Key Securely

Share the team_identity file (private key) with team members using:

  • Encrypted file sharing (ProtonMail, Signal, etc.)
  • Physical USB drives for local teams
  • Password-protected ZIP files via email

4. Harden Server Security

# Disable password authentication
sudo nano /etc/ssh/sshd_config
# Change these lines:
PasswordAuthentication no
PubkeyAuthentication yes

# Restart SSH service
sudo systemctl restart sshd

Using SSH Config for Simplicity

Create ~/.ssh/config on developer machines:

Host do-team-server
    HostName server_ip
    User webuser
    IdentityFile ~/.ssh/team_identity
    IdentitiesOnly yes

Now developers can simply use:

ssh do-team-server

Key Rotation Strategy

To rotate keys without downtime:

  1. Generate new key pair
  2. Add new public key to authorized_keys
  3. Distribute new private key
  4. Remove old public key after confirmation

Monitoring Access

Check authentication logs:

sudo grep 'sshd.*Accepted' /var/log/auth.log
  • Set strict file permissions (chmod 600) for the private key
  • Never commit private keys to version control
  • Consider using a secrets management tool for larger teams
  • Implement IP whitelisting if possible
# Debug SSH connection
ssh -vvv webuser@server_ip

# Check key permissions
ls -la ~/.ssh/

# Verify server configuration
sudo sshd -T | grep "passwordauthentication"