7.3 Configuring SSH

Installing and Enabling the OpenSSH Server

SSH (Secure Shell) is the standard encrypted remote-administration protocol, and Kali implements it with the OpenSSH suite. The server half may not be installed on minimal images, so the first step is:

sudo apt update
sudo apt install openssh-server

The package creates the ssh.service systemd unit and generates host keys on first install. Managing the service uses the standard systemctl verbs:

sudo systemctl start ssh        # start now, this boot only
sudo systemctl enable ssh       # start automatically at every boot
sudo systemctl enable --now ssh # both, in one command
sudo systemctl status ssh       # verify it is listening

enable --now is the idiom the exam favors: --now applies the start/stop immediately while enable creates the boot-time symlink. The SysV-era command for boot persistence alone is update-rc.d ssh enable; note that it only manipulates boot-time links and never starts the service. On Kali update-rc.d matters for a different reason: Kali ships a patched /usr/sbin/update-rc.d whose blocklist (apache2, ssh, postgresql, cups, bluetooth, avahi-daemon, dictd and others) — plus a fallback rule that disables any unlisted init script declaring a $network dependency — is what stops newly installed network services from persisting across reboots. Confirm the daemon is up with ss -tlnp | grep :22 — you should see sshd listening on TCP port 22.

Why SSH Is Disabled by Default on Kali

This is deliberate policy, and it generalizes: on Kali, network services such as SSH, Apache, and PostgreSQL are disabled by default. A distribution whose entire purpose is probing other machines should present the smallest possible attack surface itself. Every enabled service is a potential entry point — and SSH specifically has a long history of brute-force attempts, and Kali systems often run with weak or well-known default credentials (the kali/kali pair on live images is public knowledge). An always-on sshd on a default-credential box would be trivially hijacked on a hostile network. So Kali's stance is: services stay off until the operator explicitly starts and, if desired, enables them. During a live session, starting SSH does not persist across reboots unless you also enable it — a common exam trap phrased as "the admin ran systemctl start ssh but SSH was dead after reboot."

Server Configuration: /etc/ssh/sshd_config

The daemon reads /etc/ssh/sshd_config (do not confuse it with /etc/ssh/ssh_config, the client defaults file — the extra d is for daemon). After editing, apply changes with sudo systemctl reload ssh (or restart). Directives you must know:

A sensible hardening sequence for an internet-facing Kali box: set PermitRootLogin no, set PasswordAuthentication no once key auth works, optionally move to a non-standard port (security through obscurity only — it cuts log noise, not real risk), and restrict with AllowUsers. Lines beginning with # are commented defaults; uncommenting and changing them overrides the built-in value. Drop-in files in /etc/ssh/sshd_config.d/ are read before the main file on modern OpenSSH, so check there when a setting seems ignored.

Host Keys and the Default-Key Warning

When a client first connects, the server proves its identity with host keys stored in /etc/ssh/: pairs like ssh_host_rsa_key / ssh_host_rsa_key.pub, ssh_host_ecdsa_key, and ssh_host_ed25519_key. The private halves are root-only; clients cache the public fingerprint in ~/.ssh/known_hosts and scream if it ever changes (protection against man-in-the-middle attacks).

Kali-specific caveat, straight from Kali Linux Revealed: systems deployed by copying a full disk image — ARM images, prebuilt VMs — can carry pre-generated host keys that are identical on every copy of that image, whereas an installer-based install generates its own unique keys at package-configuration time (and since Kali 2022.1 the regenerate-ssh-host-keys service creates them on first boot if they are missing). Anyone holding those keys can impersonate your server. On any system that came from a pre-generated image, regenerate them:

sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server
sudo systemctl restart ssh

dpkg-reconfigure openssh-server re-runs the package's post-install key generation. Clients that previously connected will see a host-key mismatch warning afterward — expected, and you clear the stale entry with ssh-keygen -R <host>.

Key-Based Authentication

Password login over SSH is vulnerable to brute force; key-based login is the recommended pattern:

1. On the client, generate a pair: ssh-keygen -t ed25519 (modern default; -t rsa -b 4096 for compatibility). The private key stays in ~/.ssh/id_ed25519, the public key in ~/.ssh/id_ed25519.pub. Protect the private key with a passphrase.
2. Copy the public key to the server: ssh-copy-id kali@192.168.1.50, or manually append it to /home/kali/.ssh/authorized_keys on the server.
3. Permissions are enforced strictly: ~/.ssh must be 700, authorized_keys must be 600, and the home directory must not be group-writable — sshd silently refuses keys otherwise (set StrictModes no to bypass, but do not).
4. Log in with ssh kali@192.168.1.50; use -i to select a specific key and -p 2222 for a non-standard port.

Once key login is verified, flip PasswordAuthentication no in sshd_config and reload. Agents (ssh-agent plus ssh-add) cache decrypted keys so you type the passphrase once per session.

Quick reference of file locations:

• /etc/ssh/sshd_config — server config; /etc/ssh/ssh_config — client defaults
• /etc/ssh/ssh_host_* — server host key pairs
• ~/.ssh/authorized_keys — public keys allowed to log in as this user
• ~/.ssh/known_hosts — servers this client has verified
• ~/.ssh/config — per-user client shortcuts (Host aliases, ports, identity files)