SSH Keys

1. Concept Overview & Systemic Problem

Traditional authentication using login and password on remote servers has critical architectural flaws: vulnerability to brute-force attacks, interception in case of channel compromise (man-in-the-middle), and human factors (use of weak or reused passwords). Once port 22 is exposed to the public internet, botnets generate thousands of password guessing attempts every minute.

SSH Keys address this problem through asymmetric cryptography. The user generates a pair of mathematically linked keys:

• Private Key: Stored exclusively on the developer's local machine in an encrypted passphrase form and never transmitted over the network.
• Public Key: Placed on the target server in the ~/.ssh/authorized_keys file.

During the handshake, the server generates a random challenge, encrypts it, or requests a signature from the client using the private key. Authentication occurs through mathematical confirmation of possession of the private key without revealing the secret itself.

+------------------+                    +--------------------+
|  Local Client     |                    |  Remote Server     |
|  (~/.ssh/id_ed)  |                    |  (~/.ssh/auth_keys)|
+--------+---------+                    +---------+----------+
         |                                        |
         |  1. Connection Request (User, PubKey)  |
         |--------------------------------------->|
         |                                        | 2. Check for
         |                                        |    Public Key
         |  3. Cryptographic Challenge (Nonce)    |
         |<---------------------------------------|
         |                                        |
         | 4. Sign Nonce with Private Key         |
         |--------------------------------------->|
         |                                        | 5. Validate Signature
         |                                        |    with Public Key
         |  6. Session Opened (Authenticated)     |
         |<---------------------------------------|

2. Architectural Taxonomy & Mental Model

Cryptographic algorithms for SSH have evolved alongside advancements in computational power and cryptanalysis:

1. Ed25519 (Edwards-curve Digital Signature Algorithm):
   • The modern de facto gold standard of the industry.
   • Based on the elliptic curve Curve25519.
   • Key length: 256 bits.
   • High resistance to side-channel and timing attacks, with lightning-fast operation speeds.
2. ECDSA (Elliptic Curve Digital Signature Algorithm):
   • Uses standardized NIST curves (e.g., nistp256 or nistp521).
   • Potential risks of backdoors in the choice of NIST generator parameters and critical sensitivity to the quality of the random number generator (RNG): repeating a random value k fully exposes the private key.
3. RSA (Rivest-Shamir-Adleman):
   • A classic algorithm based on the factorization of large prime numbers.
   • Keys shorter than 2048 bits are considered compromised. A secure minimum is 4096 bits.
   • Large public and private keys, slower generation and signing.
4. FIDO2 / Hardware Security Keys (ed25519-sk / ecdsa-sk):
   • Hardware authentication through physical tokens (YubiKey).
   • The private key is generated and never leaves the secure chip of the token; each SSH session requires a physical touch.

3. Technical Pipeline & Internal Mechanics

Key Generation and Deployment

Generate a production Ed25519 key with an increased number of key derivation function (KDF) rounds to protect against GPU brute-forcing of the passphrase:

# Generate Ed25519 with comment and 100 KDF rounds
ssh-keygen -t ed25519 -a 100 -C "admin@production-cluster" -f ~/.ssh/id_ed25519_prod

Copy the public key to the remote server:

ssh-copy-id -i ~/.ssh/id_ed25519_prod.pub deploy@vps.internal.net

Linux File System Permissions Structure

Incorrect access permissions are the cause of 90% of SSH authentication failures (Permission denied (publickey)):

# Local client machine:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_prod
chmod 644 ~/.ssh/id_ed25519_prod.pub
chmod 600 ~/.ssh/config

# Remote server:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Client Configuration (~/.ssh/config)

To avoid passing long command-line flags, a declarative client config is used:

Host prod-node-01
    HostName 198.51.100.24
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host bastion-jumphost
    HostName 203.0.113.10
    User gatekeeper
    IdentityFile ~/.ssh/id_ed25519_bastion

Host internal-db
    HostName 10.0.4.15
    User postgres
    ProxyJump bastion-jumphost
    IdentityFile ~/.ssh/id_ed25519_db

4. Production Engineering Scenarios

01. Passwordless Access for Automated CI/CD Pipeline

In GitHub Actions or GitLab CI/CD environments, deployment is automated through a dedicated technical SSH key. The private key is stored in the repository's encrypted Secrets, while the public key on the server is tied to a restricted shell or specific command using the command="..." directive in authorized_keys:

command="/usr/local/bin/deploy-webhook.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5... ci-deploy-key

Even if the CI/CD secret is compromised, an attacker can only execute a deterministic deploy script, not arbitrary commands in the terminal.

02. Accessing Isolated Infrastructure Nodes via Bastion (ProxyJump)

In a VPC, private databases or AI agent servers do not have public IP addresses. An engineer connects through an intermediate Bastion host without needing to export the private key to the Bastion:

ssh -J gatekeeper@bastion.example.com deploy@10.0.1.50

SSH tunnels TCP traffic at the socket level through the proxy node, encrypting the session with the target server's final key (ProxyJump does not expose the content of the Bastion's traffic).

03. FIDO2 Hardware Keys for Zero Trust Infrastructure

In high-load or regulated fintech systems, developers are required to use hardware tokens like YubiKey. An ed25519-sk key is created. Each git push action or SSH session requires a physical touch on the token's sensor. This completely mitigates the threat of private key theft by info-stealers or malware on the developer's laptop.

5. Pitfalls, Common Mistakes & Security

1. Generating Keys Without a Passphrase: Storing a private key without a strong password creates a critical threat: any malicious process, script, or physical access to an unlocked laptop allows instant copying of the private key and access to the entire infrastructure. Always protect keys with a password and use ssh-agent.
2. Uncontrolled Sprawl in authorized_keys: Over time, the file accumulates dozens of keys from former developers or temporary contractors. Lack of regular audits opens backdoors. Use centralized key management through Ansible, Teleport, HashiCorp Vault, or SSH Certificate Authority (CA).
3. Using SSH Agent Forwarding (-A): Enabling ForwardAgent yes in the global config allows remote machines to access your local ssh-agent socket. Never enable Agent Forwarding globally; use ProxyJump or ssh-add -c to confirm each use of the key.