SSH from Linux to Linux: Reliable Remote Access

Connecting to a remote Linux instance over SSH is a fundamental workflow for system administrators and engineers. Whether you’re rolling out a microservice, applying emergency patches, or pulling logs for diagnostics, SSH facilitates secure, encrypted terminal sessions between hosts.

Common Scenario

A developer needs to deploy a hotfix directly onto a production node without local KVM access. The lab setup: two Linux systems, typically on the same LAN or reachable via routed networks. What does a minimal, fast, and reliable SSH workflow look like?

Prerequisites Checklist

• Two Linux hosts (test environment: Ubuntu 22.04 LTS and CentOS Stream 9).
• User credentials on the remote system.
• openssh-server (version 8.4p1 or newer) must be active on the target.
• openssh-client (almost always pre-installed) on your source system.
• Network reachability (TCP/22 open between client and server).

Step 1: Confirm and Start the SSH Daemon

Check if the remote system is running the SSH daemon. A typical service status query:

sudo systemctl status sshd

If the daemon isn’t found or the service fails, install and start it:

Note: On minimal installations, firewall rules may default to "deny" for inbound connections.

Step 2: Identify Target Host IP

On the remote node, list interfaces and addresses:

ip -4 addr show

Prefer the primary interface, often eth0 or enp1s0.

Caveat: Wireless adapters can rename unpredictably (e.g., wlx*). Always double-check the active link.

Example output:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 10.10.13.34/24 brd 10.10.13.255 scope global eth0

Step 3: Establish SSH Session

Syntax:

ssh -p PORT username@TARGET_IP

Defaults suffice for most on-prem and cloud setups (i.e., port 22). Specify a numeric IP — DNS on internal enterprise networks is sometimes unreliable. Example:

ssh sysop@10.10.13.34

First-run connection typically triggers host key fingerprint validation:

The authenticity of host '10.10.13.34 (10.10.13.34)' can't be established.
ED25519 key fingerprint is SHA256:a7p....PZs.
Are you sure you want to continue connecting (yes/no)? 

Reply yes only after verifying the fingerprint matches records (known_hosts compromise can lead to MITM).

Critical: Unexpected key fingerprint changes between sessions merit investigation.

Step 4: Useful SSH Operations

• Ad-hoc remote command:

  ssh sysop@10.10.13.34 "uptime && df -h"
  

  Efficient for automation or monitoring scripts.

• Copy files with SCP (Secure Copy):

  scp latest.log sysop@10.10.13.34:/var/log/app/
  

  To retrieve a file:

  scp sysop@10.10.13.34:/etc/nginx/nginx.conf /tmp/
  

Gotcha: SCP will overwrite files silently unless -i is used for interactive prompts.

Step 5: SSH Key Authentication (Preferred)

Passwords invite brute-force attacks; keys reduce friction and increase security.

Generate a 4096-bit RSA key (or use ED25519 for better performance if supported):

ssh-keygen -t ed25519 -C "eng@corp.example"

Leave the passphrase empty only for automated processes with hardened agent forwarding. Next, copy the public key:

ssh-copy-id -p 22 sysop@10.10.13.34

Test passwordless login:

ssh sysop@10.10.13.34

Non-obvious tip: For systems with /home on NFS or custom shells, ensure .ssh/authorized_keys permissions (chmod 600) are correct, or logins can silently fail.

Troubleshooting: Rapid Diagnosis

• Firewall issues:

  • Ubuntu

    sudo ufw allow 22/tcp
    

  • CentOS with firewalld

    sudo firewall-cmd --add-service=ssh --permanent
    sudo firewall-cmd --reload
    

• Daemon not running or misconfigured:
  Check logs immediately:

  sudo journalctl -u sshd
  

  Watch for Failed password or Connection closed by authenticating user messages.

• Key authentication fails:
  Double-check home directory and .ssh permissions (should not be group- or world-writable).

• Port custody conflicts:
  If another daemon binds to port 22, edit /etc/ssh/sshd_config and set a nonstandard port with Port 2222, then restart the daemon.

Summary Table: Core SSH Tasks

Known issue: SCP, while ubiquitous, is deprecated upstream in favor of sftp or rsync over SSH for complex transfers; legacy scripts may not handle symlinks or sparse files robustly.

ASCII Diagram — SSH Connection Path:

[Your_Workstation] ---[TCP 22]---> [Remote_Linux_Server]

SSH between Linux hosts is the backbone of distributed system administration. Fast, robust, and with decades of battle-testing, SSH remains essential — but only when properly configured and understood.

For anything privileged, verify the remote’s host key, and never disable strict host checking except in lab sandboxes.