Linux / Advanced: boundaries, security, and recovery / Lesson 16

Secure identities and reason about SSH

Apply least privilege and understand SSH host identity, user authentication, effective configuration, and safe access changes.

About 4 min readContent reviewed 2026-10-23

On this page

Lesson goals

Separate host authentication from user authentication.
Inspect SSH configuration without initiating a connection.
Plan access changes with validation and recovery.

Security is an explicit access design

Start with assets, actors, and required operations. An application that only reads reports does not need broad filesystem write access or an interactive administrative account. Keep software supported, separate service identities, and review file ownership alongside process privileges. Linux capabilities divide some traditional root powers into named units, but a capability can still be highly sensitive and may interact with namespaces. Mandatory policies provide additional boundaries rather than replacing ordinary permissions. Diagnose denied actions within the intended design instead of disabling a security mechanism merely because it exposed an incorrect assumption.

SSH verifies two different identities

The client first needs confidence that it reached the intended server. Host keys and trusted host-certificate authorities support that server identity; known_hosts records prior trust decisions. User authentication then proves that the connecting account is authorized, using a key, certificate, password, or another configured mechanism. A changed-host-key warning concerns server identity and must not be solved by blindly discarding the old record. Verify the expected key through an independent trusted channel. A successfully authenticated user can still lack permission to access a particular file or administrative action.

Protect private keys and scope authorization

A private key is secret material; its public counterpart may be distributed to the systems that should recognize it. A passphrase protects a stored key against some offline exposure, while an agent can hold usable credentials during a session. Agent forwarding and shared sockets extend where those credentials may be exercised, so use them deliberately. authorized_keys can include restrictions appropriate to automation rather than granting an unrestricted interactive session. Key algorithms and policy defaults evolve; follow the installed OpenSSH and organization requirements instead of copying old instructions that disable verification or re-enable deprecated algorithms.

bash Inspect client settings without connecting

ssh -G -F /dev/null -o HostName=192.0.2.20 -o User=learner lab-example

ssh -G prints evaluated client configuration and exits. /dev/null supplies an empty user configuration, and the documentation address is not contacted. Review hostname, user, port, and identity settings.

Review effective server policy

sshd_config may include other files and conditional Match blocks. For many directives the first obtained value wins, so appending a line does not necessarily override an earlier setting. sshd -t validates configuration syntax and required key sanity; sshd -T prints effective settings, and connection context can be supplied for Match evaluation. These administrative inspection commands require an appropriate prepared lab and do not guarantee that authentication will succeed. Review the installed manual because available directives and defaults differ by OpenSSH release and distribution packaging. Preserve a known-working access path before any authorized change.

bash Study syntax and conditional effective policy

# Prepared disposable SSH-server lab only; no reload is performed.
sshd -t -f ./lab-sshd_config
sshd -T -f ./lab-sshd_config -C user=learner,host=lab.example,addr=192.0.2.30

The lab configuration and host keys must already be prepared. Both invocations inspect configuration; they do not start, restart, or reload the host SSH service.

Access changes need a verified second path

Before restricting authentication, confirm that the intended replacement works for the correct account and source context. Review Include files, Match conditions, key permissions, and server logs. Keep an authorized recovery console or a working session available during a planned lab rollout, and test a separate new session before ending the original. Client verbose output can help locate negotiation or authentication failure but can reveal sensitive paths and identities. Share only the necessary excerpt. Record exactly which policy changed and how success and denial were both verified.

Common errors and fixes

Deleting a host-key warning without verification

Why it happens: Server identity was mistaken for an inconvenient cache.
How to fix it: Verify the expected fingerprint through trusted evidence.
Prevent it next time: Plan host-key rotations and communicate trusted fingerprints.

Appending a directive fails to override policy

Why it happens: Earlier values or Match context determine the effective result.
How to fix it: Inspect effective configuration for the intended connection.
Prevent it next time: Review include order and directive semantics.

Authentication is disabled before replacement is tested

Why it happens: A configuration intention was treated as a working login.
How to fix it: Use the prepared recovery path and validate a separate session.
Prevent it next time: Require verified access and rollback before restriction.

Check your understanding

1. A key authenticates successfully but reading a report fails. Which policy should be checked next?

Show worked solution

Inspect the authenticated account’s numeric identity, directory traversal, file permissions, ACLs, mount state, and mandatory controls. SSH authentication grants a session according to policy; it does not bypass filesystem authorization. Keep the host-identity decision separate from this access failure.

2. What should an SSH access-change acceptance test include?