Master SSH: Asymmetric Encryption, Key Management, and Advanced Usage Explained

1.1 Basics of Asymmetric Encryption

Symmetric encryption uses the same algorithm for encryption and decryption; examples include QQ login passwords and bank card passwords.

Asymmetric encryption relies on a public key and a private key. The public key encrypts data that the private key can decrypt, and vice versa. While public‑key encryption with private‑key decryption is typical, the reverse is also possible (e.g., CA signing). In SSH, public‑key distribution is preferred, though private‑key distribution can be used.

Four theoretical session scenarios exist between two hosts A and B, but SSH only supports two practical methods: the client generates a key pair and distributes the public key to the server, or the server generates a key pair and distributes the private key to the client.

1.2 SSH Overview

SSH is a secure protocol that operates on the transport and application layers, establishing an encrypted session after a successful connection. The daemon sshd listens on port 22 by default. All SSH client tools (ssh, scp, sftp, ssh‑copy‑id, etc.) rely on this encrypted channel.

SSH uses two configuration files: the server‑side /etc/ssh/sshd_config and the client‑side /etc/ssh/ssh_config (global) or ~/.ssh/config (user). The client configuration has higher precedence than the global one.

SSH supports two verification stages: host verification and user authentication. Host verification confirms the remote host’s identity, while user authentication validates the connecting user. Common authentication methods include password and public‑key mechanisms, ordered by default as

gssapi-with-mic,hostbased,publickey,keyboard-interactive,password

. The order can be altered via the PreferredAuthentications directive.

1.3 SSH Authentication Process Analysis

1.3.1 Host Verification

When client A connects to server B, it first checks whether B’s host key is present in ~/.ssh/known_hosts or /etc/ssh/known_hosts. If absent, the user is prompted to accept and store the host key; if present, the fingerprint is compared. The host key fingerprint is derived from the host’s private key (e.g., /etc/ssh/ssh_host_rsa_key).

# Example of checking known_hosts
cat ~/.ssh/known_hosts

Host verification stores the server’s public host key; the client retains the public key, while the server retains the private key.

1.3.2 User Authentication

After host verification, SSH proceeds to user authentication. If public‑key authentication is configured, the client sends its public key (e.g., ~/.ssh/id_rsa.pub) to the server, which checks ~/.ssh/authorized_keys. If the key matches, authentication succeeds; otherwise, password authentication is attempted.

# Example of password prompt
ssh user@host
Password:

1.3.3 Authentication Success

When both verification stages succeed, the session is established. The user can either obtain an interactive shell or execute a remote command directly.

# Interactive login
ssh user@host
# Remote command execution
ssh user@host "echo \"hello\""

1.4 File Distribution Overview

Key files are located as follows:

Server side: /etc/ssh/sshd_config, /etc/ssh/ssh_host_* (host keys), ~/.ssh/authorized_keys (authorized public keys).

Client side: /etc/ssh/ssh_config, ~/.ssh/config, ~/.ssh/known_hosts, ~/.ssh/id_rsa (private key), ~/.ssh/id_rsa.pub (public key).

1.5 SSH Command Basics

The basic syntax is ssh [options] [user@]hostname [command]. Common options include -b (bind address), -E (log file), -F (custom config), -f (background), -i (identity file), -l (login name), -N (no remote command), -p (port), -q (quiet), -T (disable pseudo‑terminal), -t (force pseudo‑terminal), -v (verbose), and -o (extra options).

# Example: login as longshuai to 172.16.10.6
ssh [email protected]

1.6 SCP Command and Process

scp is a remote copy utility built on SSH. It supports local‑to‑local, local‑to‑remote, remote‑to‑local, and remote‑to‑remote transfers. The syntax is scp [options] src dest. Common options: -1 / -2 (protocol version), -C (compression), -l (limit bandwidth), -P (port), -p (preserve attributes), -r (recursive), -v (verbose).

# Copy /etc/fstab to remote host
scp /etc/fstab 172.16.10.6:/tmp/fstab

When copying between two remote hosts, scp runs on the source host, which then initiates an SSH connection to the destination host.

1.7 Public‑Key Authentication for Mutual Trust

To enable password‑less login, generate a key pair on the client with ssh-keygen -t rsa, ensure the private key has permission 600, and copy the public key to the server’s ~/.ssh/authorized_keys using ssh-copy-id or a custom script.

# Generate key pair without passphrase
ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''
# Distribute public key
ssh-copy-id user@remote

1.8 Automating Key Distribution with Scripts

A Bash script can check for existing keys, create them if missing, and invoke ssh-copy-id with -o StrictHostKeyChecking=no to avoid interactive prompts.

#!/bin/bash
privkey="$HOME/.ssh/id_rsa"
pubkey="$HOME/.ssh/id_rsa.pub"
if [ ! -f "$privkey" ] || [ ! -f "$pubkey" ]; then
  ssh-keygen -t rsa -f "$privkey" -N ''
fi
ssh-copy-id -o StrictHostKeyChecking=no "$1"

1.9 Non‑Interactive Trust with ssh‑keyscan and sshpass

ssh-keyscan

can pre‑populate ~/.ssh/known_hosts to skip host‑key prompts, while sshpass can supply passwords automatically, enabling fully non‑interactive key distribution across many hosts.

# Populate known_hosts for a range of hosts
for host in 192.168.100.{23..33}; do
  ssh-keyscan $host >> ~/.ssh/known_hosts 2>/dev/null
  sshpass -p '123456' ssh-copy-id root@$host >/dev/null
done

1.10 Expect Scripts for Fully Non‑Interactive SSH/SCP

Expect scripts can automatically answer host‑key and password prompts for both scp and ssh-copy-id. Example autoscp.exp accepts the (yes/no) question and supplies the password when required.

#!/usr/bin/expect
set timeout 10
set user_host [lindex $argv 0]
set src [lindex $argv 1]
set dest [lindex $argv 2]
set pwd [lindex $argv 3]
spawn scp $src $user_host:$dest
expect {
  "(yes/no)?" { send "yes\r"; exp_continue }
  "*assword:" { send "$pwd\r" }
}
expect eof

1.11 SSH Connection Speed Issues

SSH slowdown can occur during host verification (often due to DNS lookups) or user authentication (slow GSSAPI). Setting UseDNS no in sshd_config and disabling GSSAPI or reordering PreferredAuthentications to prioritize publickey and password can improve performance.

# In /etc/ssh/sshd_config
UseDNS no
# In client config (~/.ssh/config)
GSSAPIAuthentication no
PreferredAuthentications publickey,password