212.3 Secure shell (SSH)

Introduction

SSH is a remote shell, file-transfer transport, and tunneling tool. Because it is also an administrator's recovery path, hardening changes must be validated before the existing connection is closed.

What you should be able to do after this lesson:

• Distinguish host keys from user authentication keys.
• Configure client and server behavior.
• Restrict root, password, and user access.
• Create and deploy keys securely.
• Use local, remote, and dynamic forwarding.
• Test configuration and reload safely.

Big Idea: SSH Establishes Trust in Both Directions

Before opening a shell, the client verifies the server's host key and the server verifies the user's authentication. Keep these identities separate:

known_hosts: client trusts server identity
authorized_keys or another method: server trusts user identity

Deleting a host-key warning without verifying the new fingerprint weakens server authentication even if the user's private key remains secure.

Host Keys and User Keys

Host keys identify the server to clients and normally live below /etc/ssh/. A changed host key can indicate reinstall, legitimate rotation, or interception and should be verified out of band.

User key pairs authenticate a user:

ssh-keygen -t ed25519
ssh-copy-id [email protected]

The private key remains with the client. The public key is added to the server user's ~/.ssh/authorized_keys.

Server Configuration

The daemon file is commonly /etc/ssh/sshd_config, possibly with included fragments.

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
AllowUsers alice deploy

Validate effective configuration:

sshd -t
sshd -T | less

Some directives can vary through Match blocks, so inspect effective behavior for relevant users and connections.

The historical Protocol directive may appear in LPIC objective lists; supported modern OpenSSH deployments use SSH protocol 2. Treat examples enabling protocol 1 as obsolete and insecure.

Client Configuration

~/.ssh/config can define reusable hosts:

Host application
    HostName app.example.test
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    ProxyJump bastion.example.test

Protect private keys and configuration permissions.

Port Forwarding

ssh -L 15432:db.internal:5432 bastion.example.test
ssh -R 8080:localhost:3000 bastion.example.test
ssh -D 1080 bastion.example.test

• -L opens a local listening port and forwards through the server.
• -R opens a remote-side port and forwards back toward the client.
• -D creates a dynamic SOCKS proxy.

Forwarding can bypass network boundaries, so control it with directives such as AllowTcpForwarding and PermitOpen where required.

Key entries in authorized_keys can also carry restrictions such as a forced command, source-address condition, or disabled forwarding. This limits the impact of an automation key without changing permissions for every user.

Safe Hardening

1. Keep the current session open.
2. Validate with sshd -t.
3. Reload rather than abruptly stopping the daemon.
4. Test a second connection using the intended authentication path.
5. Only then close the original session.

Use multiple administrative connections when a network or SSH change risks disconnecting the host.

Guided Practice: Prove Both Trust Directions

On an isolated SSH lab:

1. Record the server host-key fingerprint locally and verify it through a trusted channel.
2. Connect once and inspect the corresponding known_hosts entry.
3. Generate a dedicated Ed25519 user key with a passphrase.
4. Install only the public key in the test account's authorized_keys.
5. Test login with verbose client output.

ssh-keygen -t ed25519 -f ~/.ssh/lpic_lab
ssh -vv -i ~/.ssh/lpic_lab <user>@<lab-server>
sshd -t
sshd -T | grep -E 'permitrootlogin|pubkeyauthentication|passwordauthentication'

Create a local forward to a lab-only service and verify which machine opens the destination connection. Remove the test key and forwarding process after the exercise.

Troubleshooting Scenario

After setting PasswordAuthentication no, key login works for one administrator but fails for the deployment account. The current root session is still open.

Keep that session open, inspect ownership and modes of the deployment account's home, .ssh, and authorized_keys, review effective Match settings and logs, then test a second connection. Re-enabling passwords globally is unnecessary when the fault is isolated to key authorization.

Exam Focus

• Distinguish server host keys, client user keys, known_hosts, and authorized_keys.
• Know ssh, sshd, /etc/ssh/sshd_config, and effective configuration testing.
• Understand PermitRootLogin, PubkeyAuthentication, AllowUsers, and PasswordAuthentication.
• Know local, remote, and dynamic forwarding and preserve multiple sessions during risky changes.

Recap

• Host keys identify servers; user keys authenticate users.
• Validate both syntax and effective settings.
• Disable password or root access only after an alternative path is proven.
• SSH forwarding is powerful and must follow explicit access policy.