SSH: Secure Remote Access | Keys, ProxyJump, Port Forwarding & OpenSSH

Introduction

SSH (Secure Shell) is more than an encrypted remote shell: SCP/SFTP, port forwarding, SOCKS, and transport for Git, Ansible, kubectl, … infrastructure and developer workflows orbit SSH. It replaced Telnet and rsh with confidentiality, integrity, and server authentication.

This article pairs protocol concepts (key exchange, host verification, user auth) with OpenSSH practice. Key hygiene, jump hosts, and least privilege matter because one mistake can spread across fleets.

After reading this post

• Describe KEX, host keys, and user authentication order
• Use ssh-keygen, ~/.ssh/config, and ProxyJump
• Apply local and remote port forwarding safely
• Operate a hardening checklist (keys, 2FA, intrusion response)

---

Table of contents

1. Protocol overview
2. How it works
3. Hands-on usage
4. Security considerations
5. Real-world use cases
6. Optimization tips
7. Common problems
8. Wrap-up

---

Protocol overview

History and background

SSH emerged in the 1990s to fix Telnet/rlogin/rsh weaknesses; OpenSSH is the de facto standard. Ed25519, ECDSA, RSA keys and ChaCha20-Poly1305, AES-GCM AEAD suites are common—keep current with security updates.

OSI placement

SSH is application-layer over TCP (default 22). TLS secures the web; SSH secures interactive shells, subsystems (SFTP), and port forwarding in one secure transport.

Core properties

Property	Description
Encrypted session	After KEX, symmetric keys protect payloads.
Server authentication	Host keys mitigate MITM.
User authentication	Password, public key, keyboard-interactive (2FA), …
Channels	Multiplex shell, SFTP, forwards on one connection.

---

How it works

End-to-end flow (concept)

1. TCP connect (default :22).
2. Version and algorithm negotiation (KEX)—derive session keys.
3. Server authentication with host public key vs known_hosts.
4. Encrypted channel—user authentication (public key challenge/response, …).
5. Open shell or subsystem channels.

Roles of keys

• KEX: per-session symmetric keys.
• Host keys: long-term server identity.
• User keys: client private key signs a challenge—passphrase protects the key file.

Authentication modes

Mode	Notes
password	Convenient but weaker to brute force—pair with MFA or avoid.
publickey	Typical production default with ssh-agent + passphrase.
keyboard-interactive	Often used for 2FA tokens.

sequenceDiagram
  participant C as Client
  participant S as SSH Server
  C->>S: TCP connect :22
  C->>S: Algorithm negotiation
  C->>S: Key exchange (KEX)
  S->>C: Host key + proof
  C->>C: Verify known_hosts
  C->>S: User authentication (e.g. public key)
  S->>C: Success → shell / SFTP channel

---

Hands-on usage

ssh-keygen

ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519

ssh-keygen -t rsa -b 4096 -C "[email protected]" -f ~/.ssh/id_rsa

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

Private key permissions: chmod 600 ~/.ssh/id_ed25519

ssh config

~/.ssh/config:

Host bastion
  HostName bastion.example.com
  User deploy
  IdentityFile ~/.ssh/id_ed25519

Host internal-*
  User app
  ProxyJump bastion
  IdentityFile ~/.ssh/id_ed25519

Host db-tunnel
  HostName app.internal
  LocalForward 15432 localhost:5432
  ProxyJump bastion

ssh internal-api
ssh db-tunnel   # local 15432 → remote Postgres

Port forwarding

ssh -L 8080:target.internal:80 user@bastion

ssh -R 9090:localhost:3000 user@public-host

ProxyJump

ssh -J [email protected] [email protected]

SCP / SFTP

scp -i ~/.ssh/id_ed25519 ./build.tar.gz user@host:/var/app/

sftp user@host

---

Security considerations

Key management

• Prefer Ed25519 for new keys; RSA 3072+ when required.
• Separate personal, CI, and deploy keys; document revocation.
• In authorized_keys, use command=, from="IP", … for least privilege.

2FA

TOTP modules or FIDO2/sk- keys* (where supported) reduce password-only risk. Public key + MFA is common.

fail2ban and intrusion

• PasswordAuthentication no
• PermitRootLogin no
• AllowUsers …
• fail2ban on exposed SSH when passwords ever existed

Agent forwarding

ForwardAgent yes is convenient but risky if a host is compromised—enable only on trusted hops and briefly.

---

Real-world use cases

Area	Notes
Server ops	Shell, systemd, log tailing, patching.
Deploy	CI SSH deploy scripts, Docker context over SSH.
Tunneling	Map internal DB/Redis to local ports safely.
Git	[email protected]:... URLs with pinned host keys.
Segmented networks	Jump chains preserve network isolation.

---

Optimization tips

ControlMaster multiplexing

Host *
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 10m

Speeds repeat connections—policy may restrict.

Compression

-C helps slow links; can waste CPU on fast LANs.

Keepalives

Host *
  ServerAliveInterval 30
  ServerAliveCountMax 4

Reduces NAT idle timeouts dropping sessions.

ssh-agent

eval "$(ssh-agent -s)"
ssh-add --apple-use-keychain ~/.ssh/id_ed25519   # macOS example

---

Common problems

Symptom	Check
Permission denied (publickey)	authorized_keys path and permissions (~/.ssh` 700, key file 600), correct key, username.
REMOTE HOST IDENTIFICATION HAS CHANGED	Server reinstall or IP reuse—remove stale known_hosts after verifying new fingerprint.
Connection timeout	Security groups, NAT, IPv4 vs IPv6, missing jump.
Too many authentication failures	Too many keys in agent—IdentitiesOnly yes, explicit IdentityFile.
Forwarding fails	AllowTcpForwarding, GatewayPorts policy.

---

Wrap-up

SSH’s key exchange, encryption, and strong authentication anchor remote access; ProxyJump and port forwarding keep networks simple while exposing minimal surface area. Treat keys and config as code assets—that is the 2026 baseline for ops teams.

Use this guide for team SSH standards, jump host designs, DB tunnels, and secure deploy pipelines.

---

References

• man ssh, man sshd_config, man ssh_config
• OpenSSH release notes (algorithm guidance)
• NIST / ENISA SSH hardening guides