Linux · Systems fluency

How does SSH work and how do you use it safely?

Mediumsshremote-accesssecurityUpdated Oct 2026
Quiz this track

Short answer

SSH provides an encrypted remote shell and tunnel over an untrusted network. The client verifies the server host key, authenticates the user, and then multiplexes channels for shells, commands, and port forwarding.

The server presents a host key, which the client checks against known_hosts. User authentication can use passwords, public keys, certificates, or other mechanisms. After authentication, the connection carries encrypted channels for interactive sessions and forwarded ports.

sh
ssh -p 2222 deploy@example.com
ssh -v deploy@example.com
ssh -J bastion.example.com deploy@internal.example.com

Client configuration

  • ~/.ssh/config stores per-host aliases, users, ports, and keys
  • Host key verification protects against impersonation
  • ProxyJump routes through a bastion without exposing internal hosts
  • ServerAliveInterval helps detect dead connections
  • Agent forwarding exposes your local agent to the remote host and should be used sparingly

In production, restrict SSH to key authentication, disable direct root login, limit source addresses, and log authentication failures. A break-glass path matters because a bad SSH change can lock everyone out.

The first connection warning about an unknown host key is a trust decision. Verify the fingerprint through a trusted channel instead of blindly accepting it.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1What is host key verification protecting against?
  2. 2What does ProxyJump do?
  3. 3Why is agent forwarding risky?
  4. 4How would you recover from a bad sshd configuration?

Say it in the interview

SSH gives an encrypted channel after verifying the server host key and authenticating the user. I use key-based auth, a client config for host aliases, and ProxyJump through a bastion. I verify host fingerprints instead of accepting them blindly. For production I disable root login and keep a break-glass path so a bad sshd change does not lock us out.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Linux mock interview and get scored feedback on depth, clarity and confidence.