Mastering SSH: Asymmetric Encryption, Authentication, and Configuration Explained

1.1 Basics of Asymmetric Encryption

Symmetric encryption uses the same algorithm for encryption and decryption, e.g., QQ passwords. Asymmetric encryption uses a public key and a private key; the public key encrypts data and the private key decrypts it (or vice‑versa). Four possible key‑exchange scenarios are described, but SSH only supports the two cases where the client holds a private key and the server holds a public key.

1.2 SSH Overview

SSH runs as the daemon sshd listening on port 22 by default.

Client tools (ssh, scp, sftp, ssh‑copy‑id) use the SSH protocol to communicate with the server.

Configuration files: global /etc/ssh/ssh_config and user ~/.ssh/config.

Two authentication phases: host verification and user authentication.

Supports password and public‑key authentication; the default order is gssapi‑with‑mic, hostbased, publickey, keyboard‑interactive, password.

Features include port forwarding, proxy authentication, connection sharing, and pseudo‑terminal allocation.

1.3 SSH Authentication Process

1.3.1 Host Verification Process

When a client connects, it checks ~/.ssh/known_hosts (or /etc/ssh/known_hosts) for the server’s host key. If the key is unknown, the client prompts to trust it; if the key differs, the client warns of a possible attack.

[root@client ~]# ssh 172.16.10.6
The authenticity of host '172.16.10.6 (172.16.10.6)' can't be established.
RSA key fingerprint is f3:f8:e2:33:b4:b1:92:0d:5b:3b:97:d9:3a:f0:cf.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.10.6' (RSA) to the list of known hosts.

The server’s host key is stored in /etc/ssh/ssh_host_rsa_key.pub and the client’s known_hosts entry contains the hostname as an index.

1.3.2 User Authentication Process

After host verification, SSH performs user authentication. The default order is gssapi‑with‑mic, hostbased, publickey, keyboard‑interactive, password. Public‑key authentication is preferred; if it fails, password authentication is tried. The order can be changed with the PreferredAuthentications directive in ssh_config.

[root@client ~]# ssh [email protected]
Password: ********
Welcome to ...

1.3.3 Authentication Success

If authentication succeeds, the client either opens an interactive shell (allocating a pseudo‑terminal) or executes a remote command and exits.

# Interactive login
ssh user@host
# Remote command execution
ssh user@host "echo \"hello\""
# Background execution
ssh -f user@host "sleep 5; echo done"

1.4 File Distribution

Key files on the server ( /etc/ssh/sshd_config, /etc/ssh/ssh_host_*) and client ( /etc/ssh/ssh_config, ~/.ssh/*) are listed, noting required permissions (private keys must be 600).

/etc/ssh/sshd_config – SSH daemon configuration.

/etc/ssh/ssh_host_rsa_key & .pub – Server host keys.

~/.ssh/authorized_keys – Public keys authorized for login.

~/.ssh/id_rsa & .pub – Client private/public key pair.

1.5 SSH Configuration Files Overview

1.5.1 sshd_config

Common directives include Port, ListenAddress, Protocol, host key locations, UseDNS, PermitRootLogin, PasswordAuthentication, and limits such as MaxSessions and MaxStartups. For faster host verification, set UseDNS no.

# Example snippet from /etc/ssh/sshd_config
Port 22
ListenAddress 0.0.0.0
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
UseDNS no
PermitRootLogin yes
PasswordAuthentication yes
MaxSessions 10
MaxStartups 10

1.5.2 ssh_config

The client configuration mirrors many server options. Important settings are GSSAPIAuthentication no, StrictHostKeyChecking ask|no, and IdentityFile paths.

# Example snippet from /etc/ssh/ssh_config
Host *
    GSSAPIAuthentication no
    StrictHostKeyChecking ask
    IdentityFile ~/.ssh/id_rsa
    Port 22
    Protocol 2

1.6 SSH Command Simple Functions

Syntax: ssh [options] [user@]hostname [command]. Common options include -b (bind address), -E (log file), -f (background), -i (identity file), -l (login name), -p (port), -T (no pseudo‑terminal), -t (force pseudo‑terminal), -v (debug), and -V (version).

1.7 SCP Command and Process Analysis

SCP copies files over SSH. It supports local‑to‑local, local‑to‑remote, remote‑to‑local, and remote‑to‑remote transfers. Options include -1 / -2 (protocol version), -C (compression), -l (limit bandwidth), -P (port), -p (preserve attributes), and -r (recursive).

# Local to remote
scp /etc/fstab [email protected]:/tmp/a.txt
# Remote to local
scp [email protected]:/etc/fstab /tmp/a.txt
# Remote to remote (via local host)
scp [email protected]:/etc/fstab [email protected]:/tmp/a.txt

1.7.1 SCP Copy Mechanism

When copying from remote A to remote B, the local client invokes SSH to remote A, which then runs its own SCP command to remote B. The local machine never directly contacts remote B.

# Debug output (simplified)
ssh -v [email protected] "scp -v /tmp/file [email protected]:/tmp/"
# A connects to B and transfers the file.

1.8 Public‑Key Authentication for Mutual Trust

1.8.1 Implementation Steps

1. Generate a key pair on the client: ssh-keygen -t rsa -f ~/.ssh/id_rsa -N '' (private key must be 600). 2. Distribute the public key to the server’s ~/.ssh/authorized_keys using ssh-copy-id or a manual cat pipeline. 3. Verify that the server can authenticate the client without a password.

# Generate key pair
ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''
# Copy public key to server
ssh-copy-id user@host

1.8.2 One‑Click Shell Script

A script automates key generation (if missing) and copies the public key to a target host.

#!/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.8.3 Server‑Side Private‑Key Distribution

Alternatively, generate a key pair on the server, add the public key to the server’s own authorized_keys, then securely copy the private key to the client (ensuring correct permissions). This achieves the same trust relationship from the opposite direction.

# On server
ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ''
ssh-copy-id user@server   # add server's public key to its own authorized_keys
# Transfer private key to client
scp -p ~/.ssh/id_rsa user@client:~/.ssh/

1.9 Using ssh‑keyscan and sshpass for Non‑Interactive Trust

ssh-keyscan

fetches a host’s public key and appends it to ~/.ssh/known_hosts, eliminating interactive host‑key prompts. sshpass supplies passwords automatically, allowing scripts to run without manual input.

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

1.10 Automating SSH/SCP with expect

1.10.1 SCP Auto‑Answer Script

An Expect script handles the "yes/no" host‑key prompt and password request.

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

1.10.2 ssh‑copy‑id Auto‑Answer Script

Similar Expect script for non‑interactive ssh-copy-id.

#!/usr/bin/expect -f
set timeout 10
set host [lindex $argv 0]
set pwd [lindex $argv 1]
spawn ssh-copy-id $host
expect {
    "(yes/no)?" { send "yes\r"; exp_continue }
    "*assword:" { send "$pwd\r" }
}
expect eof

These scripts can be wrapped in a shell loop to configure many hosts automatically.

1.11 SSH Connection Speed Issues and Solutions

Slow connections are usually caused by host verification (DNS lookup) or authentication order. To speed up host verification, set UseDNS no in sshd_config. To reduce authentication delay, disable GSSAPI ( GSSAPIAuthentication no) or reorder methods with

PreferredAuthentications publickey,password,gssapi,hostbased,keyboard-interactive

. Debug with ssh -vvv to pinpoint the bottleneck.