{
  "$type": "site.standard.document",
  "canonicalUrl": "https://rednafi.com/misc/ssh-saga/",
  "description": "Complete SSH setup guide: key pairs, authorized_keys, sshd_config, ssh_config, known_hosts, agent forwarding, and hardening for secure remote access.",
  "path": "/misc/ssh-saga/",
  "publishedAt": "2024-12-17T00:00:00.000Z",
  "site": "at://did:plc:fgtm2c26vfcj74rfmeggbyqj/site.standard.publication/3mnl6f7ob462z",
  "tags": [
    "Shell",
    "Unix",
    "Networking",
    "Security"
  ],
  "textContent": "Setting up SSH access to a new VM usually follows the same routine: generate a key pair,\ncopy it to the VM, tweak some configs, confirm the host's identity, and maybe set up an\nagent to avoid typing passphrases all day. Tools like cloud-init and Ansible handle most of\nthe setup for me now, so I rarely think about it. But I realized I don't fully understand\nhow all the parts work together.\n\nThis post attempts to give an overview of what happens when you type ssh user@host. It\ncovers key pairs, authorized_keys, sshd_config, /.ssh/config, known_hosts, and how\nthey all fit together.\n\nA new VM in the void\n\nYou've provisioned a new VM and need key-based SSH access. This involves generating a key\npair on your local machine, installing the public key on the remote VM, and ensuring the SSH\ndaemon (sshd) on the VM trusts it. Done right, ssh user@host drops you into a shell\nwithout a password prompt.\n\nFirst, generate a key pair on your _local machine_:\n\nThis creates two files: a private key (/.ssh/id_ed25519) and a public key\n(/.ssh/id_ed25519.pub). The private key stays local. The public key is shared.\n\nYour local fortress\n\nYour local private key proves your identity and must be protected (/.ssh/id_ed25519). The\npublic key (/.ssh/id_ed25519.pub) gets copied to the VM.\n\nTo view the public key locally:\n\nCopy this public key to the VM.\n\nThe remote gatekeeper\n\nOn the VM, sshd listens for connections and authenticates users. Its configuration file,\n/etc/ssh/sshd_config, defines policies: whether password logins are allowed, which keys\nare trusted, and which crypto settings to use. A hardened snippet might look like this:\n\nWith PasswordAuthentication no, only keys can unlock access.\n\nAuthorized keys and the handshake\n\nThe /.ssh/authorized_keys file on the VM decides who gets access. Add your public key\nthere to tell sshd that anyone holding the matching private key (you) can connect.\n\nOn the VM, under the user's home directory:\n\nNow when you run ssh user@host, the server matches your key to one in authorized_keys\nand lets you in.\n\nThe client and its configs\n\nYour local SSH client can be configured via /.ssh/config to simplify hostnames, ports,\nand key paths:\n\nNow you can connect with:\n\nKnown hosts and server identity\n\nWhen you connect to the VM for the first time, SSH prompts you to confirm its identity.\nAccepting it adds the server's host key to /.ssh/known_hosts. SSH will detect any\nidentity changes during subsequent connections:\n\nThis prevents man-in-the-middle attacks.\n\nAgent and forwarding\n\nIf your private key has a passphrase, typing it constantly is annoying. ssh-agent caches\nthe key in memory, so you only unlock it once:\n\nFor hopping through multiple servers (local → bastion → internal server), enable agent\nforwarding:\n\nNow, you can connect through intermediary hosts without copying private keys around.\n\nConfiguring and hardening the daemon\n\nOn the VM, refine /etc/ssh/sshd_config to enforce stricter security:\n\nThese settings ensure that only trusted keys with modern crypto algorithms can connect.\n\nBringing it all together\n\nHere's a quick summary of setting up SSH connection to a new machine:\n\n1. Generate a key pair on your local machine.\n2. Copy the public key to the authorized_keys file on the VM.\n3. Configure sshd_config on the VM to allow key-based authentication.\n4. Set up ~/.ssh/config on your local machine to simplify SSH commands (e.g., ssh myvm\n   instead of ssh <vm-ip>).\n5. Confirm the server's identity and save it to known_hosts on your local machine.\n6. Use ssh-agent on your local machine to cache your private key and avoid typing the\n   passphrase repeatedly.\n7. Enable agent forwarding in your SSH config to connect through intermediary servers\n   without copying keys.\n8. Harden sshd_config on the VM to enforce modern crypto algorithms and stricter security\n   policies.",
  "title": "SSH saga"
}