7.3 Configuring SSH

Kali Linux Certified Professional KLCP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 How to Use This Guide & Study Strategy 1.3 PEN-103 Syllabus & Study Path

2 About Kali Linux

2.1 A Bit of History: From BackTrack to Kali 2.2 Kali's Relationship with Debian 2.3 Purpose and Use Cases 2.4 Main Features and Design Policies

3 Getting Started with Kali Linux

3.1 Downloading and Verifying a Kali ISO 3.2 Booting Kali in Live Mode 3.3 Installation Options Overview 3.4 Troubleshooting Installations

4 Linux Fundamentals

4.1 What Linux Is and What It Does 4.2 The Command Line 4.3 The Filesystem Hierarchy Standard 4.4 Useful Commands: Files, Search, Environment

5 Permissions and Process Management

5.1 File Permissions and Ownership 5.2 Managing Processes 5.3 Shells, Variables, and the Environment

6 Installing Kali Linux

6.1 Minimal Installation Requirements 6.2 Step-by-Step Installation on a Hard Drive 6.3 Unattended Installations with Preseeding 6.4 ARM Installations

7 Configuring the Network, Users, and SSH

7.1 Configuring the Network 7.2 Managing Unix Users and Groups 7.3 Configuring SSH

8 Configuring Services

8.1 Apache Web Server 8.2 PostgreSQL Database 8.3 Managing Services with systemd

9 Helping Yourself and Getting Help

9.1 Documentation Sources 9.2 Kali Linux Communities 9.3 Filing Good Bug Reports

10 Security Policy and Network Services

10.1 Defining a Security Policy 10.2 Possible Security Measures 10.3 Securing Network Services

11 Firewalling and Monitoring

11.1 Netfilter and iptables Behavior 11.2 Writing iptables Rules and NAT 11.3 Monitoring and Logging

12 Debian Package Management: APT

12.1 Introduction to APT 12.2 The sources.list File 12.3 Kali Repositories 12.4 Basic Package Interaction with apt

13 dpkg and Advanced Package Management

13.1 dpkg Fundamentals 13.2 Inspecting .deb Files and Package State 13.3 Maintainer Scripts and Conffiles 13.4 APT Pinning and Package Authenticity

14 Advanced Usage

14.1 Modifying and Rebuilding Kali Packages 14.2 Recompiling the Kernel 14.3 Building Custom Kali Live ISO Images 14.4 USB Persistence with LUKS Encryption

15 Kali Linux in the Enterprise

15.1 Network Installation with PXE Boot 15.2 Configuration Management with SaltStack 15.3 Metapackages and Custom Repositories 15.4 Configuration Packages and Forking

16 Introduction to Security Assessments

16.1 Kali Linux in an Assessment 16.2 Types of Assessments 16.3 Types of Attacks 16.4 Formalization and the Road Ahead

7.3 Configuring SSH

Key Takeaways Explain This Topic AI

The openssh-server package is already installed on Kali — only the service is off; start and persist it with systemctl enable --now ssh , and use apt install openssh-server only on minimal images that lack it

The daemon is configured in /etc/ssh/sshd_config; the most-tested directives are PermitRootLogin, PasswordAuthentication, and Port

Kali disables SSH (and other network services) by default because a security distro should not expose attack surface unless the operator explicitly asks for it

Key-based auth: generate a pair with ssh-keygen on the client, then append the public key to ~/.ssh/authorized_keys on the server (ssh-copy-id automates this)

Systems deployed by copying a full disk image (ARM images, prebuilt VMs) can carry pre-generated host keys shared by every copy; regenerate them in order — rm /etc/ssh/ssh_host_*, then dpkg-reconfigure openssh-server, then systemctl restart ssh — while a normal installer-based install already generates its own unique keys

Last updated: July 2026

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:

Directive Typical value Meaning
Port Port 2222 TCP port sshd listens on; default 22
PermitRootLogin prohibit-password / no Controls direct root login; prohibit-password allows root by key only
PasswordAuthentication no Disables password logins entirely, forcing keys
PubkeyAuthentication yes Enables key-based login (default)
AllowUsers AllowUsers alice bob Whitelist of accounts permitted to log in
ListenAddress ListenAddress 192.168.1.50 Bind sshd to a specific interface

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:

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.

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.

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).

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)