SSH keys are a crucial security mechanism that enables secure, password-less authentication between your local machine and remote servers. In Ubuntu 24, setting up SSH keys properly can significantly improve your security posture while streamlining your development workflow. This guide will walk you through generating SSH key pairs, configuring them on both client and server sides, and troubleshooting common issues you’re likely to encounter in real-world scenarios.

How SSH Key Authentication Works

SSH keys use asymmetric cryptography to authenticate connections without transmitting passwords over the network. When you generate an SSH key pair, you create two mathematically related keys: a private key that stays on your local machine and a public key that gets installed on remote servers.

The authentication process works like this: when you attempt to connect, the server sends a challenge encrypted with your public key. Only your private key can decrypt this challenge, proving your identity without ever transmitting the private key itself. This makes SSH key authentication significantly more secure than password-based authentication, especially against brute force attacks.

Ubuntu 24 comes with OpenSSH pre-installed, supporting modern key types including Ed25519, RSA, and ECDSA. Ed25519 keys are generally recommended for new implementations due to their smaller size and strong security properties.

Step-by-Step SSH Key Setup Guide

Generating Your SSH Key Pair

First, check if you already have SSH keys on your system:

ls -la ~/.ssh/

If you see files like id_rsa, id_ed25519, or similar, you already have keys. To generate a new Ed25519 key pair (recommended):

ssh-keygen -t ed25519 -C "your_email@example.com"

For systems that don’t support Ed25519, use RSA with 4096 bits:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

The key generation process will prompt you for a file location (press Enter for default) and an optional passphrase. Using a passphrase adds an extra security layer but requires entering it each time you use the key (unless you’re using an SSH agent).

Installing Your Public Key on the Server

The easiest method is using ssh-copy-id:

ssh-copy-id username@server_ip_address

If ssh-copy-id isn’t available or you prefer manual installation:

cat ~/.ssh/id_ed25519.pub | ssh username@server_ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Alternatively, you can manually copy the public key content and append it to the ~/.ssh/authorized_keys file on the server.

Configuring SSH Client Settings

Create or edit ~/.ssh/config to streamline your connections:

Host myserver
    HostName 192.168.1.100
    User ubuntu
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

This configuration allows you to connect simply using ssh myserver instead of typing the full command each time.

Server-Side SSH Configuration

To enhance security, modify the SSH daemon configuration in /etc/ssh/sshd_config:

# Disable password authentication
PasswordAuthentication no

# Disable empty passwords
PermitEmptyPasswords no

# Disable root login
PermitRootLogin no

# Enable public key authentication
PubkeyAuthentication yes

# Specify authorized keys file
AuthorizedKeysFile .ssh/authorized_keys

# Disable challenge-response authentication
ChallengeResponseAuthentication no

After making changes, restart the SSH service:

sudo systemctl restart ssh

Always test your key authentication in a separate terminal session before closing your current connection to avoid locking yourself out.

SSH Key Types Comparison

Key Type	Key Size	Security Level	Performance	Compatibility
Ed25519	256 bits	Very High	Excellent	Modern systems
RSA 4096	4096 bits	High	Good	Universal
RSA 2048	2048 bits	Medium	Good	Universal
ECDSA	256-521 bits	High	Very Good	Good

Real-World Use Cases and Examples

Multi-Server Management

For managing multiple servers, create a comprehensive SSH config:

Host prod-web-*
    User deploy
    Port 2222
    IdentityFile ~/.ssh/production_key

Host dev-*
    User developer
    Port 22
    IdentityFile ~/.ssh/development_key

Host *.mangohost.net
    User admin
    IdentityFile ~/.ssh/mangohost_key

Git Repository Access

Configure SSH keys for Git repositories:

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/github_key

Host gitlab.company.com
    HostName gitlab.company.com
    User git
    IdentityFile ~/.ssh/company_key

Automated Deployment Scripts

SSH keys enable password-less deployments in CI/CD pipelines:

#!/bin/bash
# Deploy script using SSH keys
ssh deploy@prod-server "cd /var/www && git pull origin main"
ssh deploy@prod-server "sudo systemctl restart nginx"

Common Issues and Troubleshooting

Permission Problems

SSH is strict about file permissions. Fix common permission issues:

# Set correct permissions for SSH directory and files
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/config

Debug Connection Issues

Use verbose mode to troubleshoot connection problems:

ssh -vvv username@server_ip

Common issues and solutions:

• Key not being offered: Check if the key is loaded in SSH agent with ssh-add -l
• Wrong key being used: Specify the key explicitly with ssh -i ~/.ssh/specific_key
• Server rejecting key: Verify the public key is correctly added to authorized_keys
• SELinux issues: On systems with SELinux, run restorecon -R ~/.ssh

SSH Agent Management

Start SSH agent and add your keys:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

For automatic SSH agent startup, add this to your ~/.bashrc:

if [ -z "$SSH_AUTH_SOCK" ]; then
    eval "$(ssh-agent -s)"
    ssh-add ~/.ssh/id_ed25519
fi

Best Practices and Security Considerations

Key Management

• Use different keys for different purposes: Separate keys for personal projects, work, and server administration
• Regular key rotation: Rotate keys annually or when team members leave
• Backup your keys: Store private keys securely, preferably encrypted
• Use passphrases: Always protect private keys with strong passphrases

Server Hardening

Additional SSH security measures:

# Limit SSH access to specific users
AllowUsers ubuntu deploy admin

# Change default SSH port
Port 2222

# Limit connection attempts
MaxAuthTries 3
MaxStartups 3

# Set login grace period
LoginGraceTime 30

Monitoring and Logging

Monitor SSH access attempts:

# View SSH authentication logs
sudo journalctl -u ssh
sudo grep "sshd" /var/log/auth.log

Integration with Cloud Infrastructure

When working with cloud platforms, SSH keys integrate seamlessly with services like VPS hosting and dedicated servers. Most cloud providers allow you to inject SSH public keys during instance creation, enabling immediate secure access without password-based authentication.

For infrastructure as code, tools like Terraform and Ansible can manage SSH key deployment across multiple servers automatically. This approach ensures consistent security policies and simplifies server provisioning workflows.

Advanced SSH Key Features

Certificate-Based Authentication

For enterprise environments, SSH certificates provide centralized key management:

# Generate a certificate authority key
ssh-keygen -t ed25519 -f ssh_ca

# Sign a user key with the CA
ssh-keygen -s ssh_ca -I user_id -n ubuntu user_key.pub

Hardware Security Keys

Ubuntu 24 supports FIDO2/U2F hardware keys for SSH authentication:

ssh-keygen -t ecdsa-sk -C "hardware_key@example.com"

This generates a key that requires physical presence on the hardware token for authentication, providing an additional security layer.

For comprehensive documentation on SSH configuration options, refer to the official OpenSSH manual. The Ubuntu Server Guide also provides detailed information specific to Ubuntu implementations.

---

---

This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.

This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.