Get AI summaries of any video or article — Sign up free
Linux/Mac Tutorial: SSH Key-Based Authentication - How to SSH Without a Password thumbnail

Linux/Mac Tutorial: SSH Key-Based Authentication - How to SSH Without a Password

Corey Schafer·
4 min read

Based on Corey Schafer's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Generate an RSA key pair with ssh-keygen and treat id_rsa as secret while using id_rsa.pub for remote installation.

Briefing

SSH key-based authentication replaces password prompts with cryptographic login, making remote access both more convenient and more secure. The core workflow is straightforward: generate an RSA key pair on the local machine, copy the public key to the remote account’s ~/.ssh/authorized_keys, lock down permissions, and then SSH in without typing a password.

The tutorial starts with a working baseline: SSH into a remote Linux virtual machine using a username and IP address, but the session requires a password every time. The goal is to eliminate that password step. To do so, it emphasizes a common point of confusion—only the public key needs to be placed on the remote machine. The private key stays on the local machine, where only the user should have access. Using ssh-keygen, the process creates ID_RSA (private) and id_rsa.pub (public). It recommends using RSA with a stronger key size (via options like -rsa-b 4096 instead of the default 2048) and optionally adding a passphrase; leaving the passphrase blank is shown for simplicity.

Next comes the manual “push the public key” method. Before copying anything, the remote account must have a ~/.ssh directory. The tutorial creates it with mkdir -p ~/.ssh, then transfers id_rsa.pub using scp. The key is placed into the remote user’s home directory under ~/.ssh, and then its contents are appended into a new (or existing) file named authorized_keys using cat >> ~/.ssh/authorized_keys. After the key is in place, permissions are tightened to satisfy SSH’s security checks: the ~/.ssh directory should be 700, and files inside it (including authorized_keys) should be 600 via chmod 700 ~/.ssh and chmod 600 ~/.ssh/*.

With those pieces set, the tutorial demonstrates that an SSH command like ssh corems@192.168.56.100 logs in successfully without prompting for a password. For stronger hardening, it then shows how to disable password authentication entirely. That involves backing up /etc/ssh/sshd_config, editing it (e.g., setting PasswordAuthentication no), and restarting the SSH service (on Ubuntu, using sudo service ssh restart). The result is that only key-based logins will work.

Finally, the tutorial presents an easier automation path using ssh-copy-id. On Linux it’s typically available by default; on macOS it can be installed via Homebrew (brew install ssh-copy-id). Running ssh-copy-id user@host prompts for the remote password once, then automatically creates the remote ~/.ssh directory, sets correct permissions, and installs the public key into authorized_keys. Even then, the SSH server configuration change to disable password logins still needs to be done separately if desired.

Cornell Notes

SSH key-based authentication lets users log into a remote machine over SSH without typing a password each time. The method hinges on keeping the private key on the local machine while placing the public key on the remote account in ~/.ssh/authorized_keys. After generating keys with ssh-keygen, the public key can be copied manually with scp and appended into authorized_keys, or installed automatically with ssh-copy-id. Correct permissions matter: ~/.ssh must be 700 and authorized_keys (and other files inside) must be 600. For maximum security, password login can be disabled by editing /etc/ssh/sshd_config (PasswordAuthentication no) and restarting the SSH service.

Why does the public key go on the remote machine, while the private key stays local?

The private key remains on the local machine because it must be kept secret. The remote machine only needs the public key so it can verify that an incoming SSH connection is authorized. In practice, the tutorial generates id_rsa (private) and id_rsa.pub (public) with ssh-keygen, then copies id_rsa.pub to the remote user’s ~/.ssh/authorized_keys. That placement is what enables passwordless login.

What exact remote files and directories must exist for key-based SSH to work?

On the remote account, the tutorial ensures a ~/.ssh directory exists (created with mkdir -p ~/.ssh). It then installs the public key into ~/.ssh/authorized_keys. If authorized_keys doesn’t exist yet, appending with cat >> ~/.ssh/authorized_keys creates it automatically. Without the correct directory and authorized_keys file, SSH won’t find the key to authenticate the user.

How do permissions affect SSH key authentication?

SSH enforces strict permission checks. The tutorial sets ~/.ssh to 700 (chmod 700 ~/.ssh) and sets files inside that directory to 600 (chmod 600 ~/.ssh/*). These settings prevent other users from reading or modifying key material. If permissions are too open, SSH may refuse to use the keys.

What’s the difference between the manual key-copy method and ssh-copy-id?

The manual method uses scp to copy id_rsa.pub to the remote machine, then uses cat >> ~/.ssh/authorized_keys to append it, followed by explicit chmod commands for 700 and 600. ssh-copy-id automates those steps: it creates ~/.ssh on the remote side, sets permissions correctly, and installs the public key into authorized_keys. However, ssh-copy-id does not automatically change SSH server settings like disabling password authentication.

How is password authentication disabled after key login is working?

Once key-based login succeeds, the tutorial hardens the server by editing /etc/ssh/sshd_config. It backs up the file first, then changes PasswordAuthentication to no (uncommenting if needed). Finally, it restarts the SSH service (on Ubuntu, sudo service ssh restart) so the new policy takes effect.

Review Questions

  1. What are the roles of id_rsa and id_rsa.pub in SSH key-based authentication, and where does each one live?
  2. List the remote path(s) and permission values required for SSH to accept authorized_keys.
  3. Describe how ssh-copy-id changes the setup steps compared with copying the public key manually.

Key Points

  1. 1

    Generate an RSA key pair with ssh-keygen and treat id_rsa as secret while using id_rsa.pub for remote installation.

  2. 2

    Copy only the public key to the remote user’s ~/.ssh/authorized_keys to enable passwordless SSH.

  3. 3

    Ensure the remote ~/.ssh directory is set to 700 and files inside it (including authorized_keys) are set to 600 using chmod.

  4. 4

    Use scp plus cat >> authorized_keys for a manual setup when ssh-copy-id isn’t available.

  5. 5

    Use ssh-copy-id user@host to automate remote directory creation, permission setting, and authorized_keys installation after a one-time password prompt.

  6. 6

    For stronger security, disable password logins by setting PasswordAuthentication no in /etc/ssh/sshd_config and restarting the SSH service.

Highlights

Key-based SSH works because the remote machine stores the public key in ~/.ssh/authorized_keys while the private key never leaves the local machine.
SSH permission checks are strict: ~/.ssh must be 700 and authorized_keys must be 600 (or equivalent for files in that directory).
ssh-copy-id automates the remote setup steps, but it doesn’t disable password authentication—server configuration still needs to be changed separately.

Topics

  • SSH Key Authentication
  • ssh-keygen
  • authorized_keys
  • ssh-copy-id
  • sshd_config Hardening

Mentioned