Mastering SSH from Linux: Modern Workflow and Security Considerations

SSH is fundamental for secure Linux administration, but default usage leaves productivity—and security—on the table. Instead of the usual "ssh user@host", leverage SSH as a tool for robust, efficient infrastructure access. Below, an engineer’s rundown: hardening access, customizing connections, multiplexing sessions, tunneling internal services, securing remote daemons, and automating multi-hop connectivity.

SSH Keys: Drop Passwords, Increase Security

Relying on password authentication isn’t just inconvenient; it’s shortsighted from a security perspective. Automated scanners will hammer TCP/22, looking for weak logins. Key-based authentication is best practice. ED25519 is recommended for new deployments (OpenSSH >= 6.5).

ssh-keygen -t ed25519 -C "your_email@example.com"

Result:

Private key: ~/.ssh/id_ed25519
Public key: ~/.ssh/id_ed25519.pub

Copy your public key to the server:

ssh-copy-id user@remote-host

Prefer no ssh-copy-id? Manually append your key to ~user/.ssh/authorized_keys with strict permissions (chmod 600 authorized_keys). Permissions mistakes commonly break SSH key auth.

Disable passwords:

Edit /etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password

Then reload:

sudo systemctl reload sshd

If you lose your key after disabling passwords, you’re locked out. Maintain out-of-band access (e.g., KVM or cloud console).

SSH Configuration File: Centralize and Streamline Connections

Hardcoding user, port, and host each time is error-prone. Instead, use ~/.ssh/config:

Host staging-web
    HostName 10.20.30.40
    User deploy
    Port 3222
    IdentityFile ~/.ssh/id_ed25519_staging
    ServerAliveInterval 60

Host infra-vpn
    HostName vpn.internal.corp
    User ops
    ProxyJump bastion.company.com

Now ssh staging-web just works, with all options preset. For dozens of hosts, this is survival. Consider Include statements for further modularity.

Gotcha: Wildcards (Host *.example.com) ease maintenance, but always test for accidental credential leaks.

Multiplexed Sessions: Eliminate SSH Handshake Latency

Repeated SSH connections can become noticeably slow with GSSAPI or two-factor enabled. ControlMaster (OpenSSH >= 5.6) reuses TCP sessions per host, reducing latency.

In ~/.ssh/config:

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

ControlPersist 10m: keeps the session open for 10 minutes idle.
ControlPath path must be writable, short (108 bytes max), and unique per connection; use /tmp for multi-user boxes.

Open your first session:

ssh user@host.example.com

All subsequent SSH or SCP commands reuse the connection—particularly useful for scripting or rsync.

Known issue: If the master socket gets corrupted or you forcibly terminate the first session, ongoing multiplexed connections will error:

mux_client_request_session: read from master failed: Broken pipe

Clean up socket files as needed.

Port Forwarding: Transparent Access to Remote/Internal Services

SSH tunnels are invaluable for ad-hoc secure access through firewalls or to test internal services.

Local port forward: Access remote internal service via your localhost.

ssh -L 8080:db.intra:5432 admin@bastion.example.com

This exposes the remote PostgreSQL on local port 8080.

Remote port forward: Expose a local service to a remote network.

ssh -R 9000:localhost:5000 dev@demo.company.com

Remote users at demo.company.com see your local port 5000 as remote port 9000.

Tip: For persistent tunnels, use autossh to handle reconnections (sudo apt install autossh).

Port forwarding introduces risk: only open precise ports to known hosts, and disable unused forwarding methods in sshd_config if not required:

AllowTcpForwarding no
GatewayPorts no

Hardening SSH Daemon: Mitigating Common Attack Vectors

A stock SSH server is a ripe target. Beyond key auth:

Non-standard port: Not security per se, but will filter low-effort scans. Change Port 22 to, e.g., Port 2222.
User allowlist:
```
AllowUsers alice deploy infraadmin
```
Disable password and root logins: (see above)
Use Fail2Ban: Lock out brute force by monitoring /var/log/auth.log.

sudo apt install fail2ban
# Edit /etc/fail2ban/jail.local to customize thresholds and actions.
# Default jails cover sshd under [sshd].

Audit logins regularly:

journalctl -u sshd | grep 'Failed password'

Most attacks target Port 22 using default usernames; these simple mitigations significantly reduce your threat surface.

Multi-Hop Access: ProxyJump and SSH Chains

Environments with true defense-in-depth often require jumping through bastion/inventory hosts to reach production. ProxyJump, available in OpenSSH >= 7.3, simplifies the classic -J multi-hop pattern.

Host prod-app
    HostName 172.16.1.100
    User paula
    ProxyJump jump1.corp.net:2222

Now,

ssh prod-app

routes seamlessly via the proxy, carrying agent forwarding and ControlMaster behavior if configured. For longer chains, chain ProxyJump or revert to ProxyCommand with nc for legacy systems—but performance degrades with each hop.

Practical Example: Automated Deployment over SSH

CI runners (e.g. GitLab CI) sometimes need to deploy to remote servers with strict security. Example job snippet:

deploy_staging:
  script:
    - |
      eval $(ssh-agent -s)
      ssh-add <(echo "$SSH_KEY")
      ssh -o StrictHostKeyChecking=no deployment@staging.example.com "bash /opt/scripts/deploy.sh"

Always bind CI agent keys to least-privilege, rotate regularly, and pre-load ~/.ssh/known_hosts for target hosts to avoid MITM.

Key Details and Non-obvious Tips

Mixing RSA and ED25519: Some legacy systems require RSA; if using, generate with at least 3072 bits (-b 3072).
ForwardAgent only where required—compromised server with agent forwarding leaks all client identities currently loaded.
SSH configs can be shared within teams, but never distribute private keys or add sensitive data in comments.
Permissions matter: ~/.ssh/config (600), private keys (600), authorized_keys on remote (600 or 644). Loose permissions will trigger errors like:
```
Permissions 0644 for 'id_ed25519' are too open.
```

Summary

Effective SSH usage is more than memorizing connection strings. Hardened authentication, clean configuration, multiplexing, and controlled tunneling enable both security and operational efficiency. Don’t leave your infrastructure exposed—or your own workflow bogged down—by default behaviors.

Further reading: Review your organization’s SSH audit and key rotation policies. For more on advanced SSH certificates or hardware tokens, see OpenSSH docs (man ssh-keygen, man sshd_config).

Note: For additional workflows—like SSH certificate-based auth or agent socket forwarding—custom solutions and tooling may be required depending on your Linux distribution and organization’s threat model.

How To Ssh From Linux