OpenSSH is typically pre-installed on modern Linux distributions. If the daemon or client utilities are missing, install them using the native package manager:

# Debian/Ubuntu families
sudo apt update && sudo apt install openssh-server openssh-client

# RHEL/CentOS/Fedora families
sudo dnf install openssh-server openssh-clients

Enable and initialize the background service:

sudo systemctl enable sshd
sudo systemctl start sshd
sudo systemctl status sshd

Verify network reachability and daemon responsiveness:

ssh -p 22 sysadmin@10.0.0.50

During the initial connection, the client prompts to verify the remote host's cryptographic fingerprint. Accepting it caches the signature in ~/.ssh/known_hosts, suppressing future warnings for that endpoint.

Generating and Managing Cryptographic Keys

Replace password authentication with asymmetric key pairs for improved security and automation:

ssh-keygen -t ed25519 -C "dev-workstation" -f ~/.ssh/id_ed25519

This generates a private key (id_ed25519) and a public key (id_ed25519.pub). Immediately restrict read/write access to the private component:

chmod 600 ~/.ssh/id_ed25519

If a private key is suspected of being compromised, regenerate the pair immediately and redistribute the new public key. Never transmit or store the private key on untrusted systems.

Deploying Public Keys for Passwordless Access

To enable automatic authentication, append the public key to the target server's ~/.ssh/authorized_keys file. The standard automated approach is:

ssh-copy-id -i ~/.ssh/id_ed25519.pub sysadmin@10.0.0.50

For manual deployment, ensure directory and file permissions are strictly enforced on the remote host to prevent the daemon from rejecting the keys:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA... dev-workstation" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Multiple public keys can coexist in authorized_keys, permitting access from various machines. Remove obsolete entries immediately when access privileges are revoked.

Client-Side Connection Profiles

Streamline repetitive connectiosn by defining host aliases in ~/.ssh/config:

Host prod-db
    HostName 10.0.0.50
    User sysadmin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 60

Connnect using the simplified alias: ssh prod-db. Windows administrators can achieve equivalent functionality using PuTTY by configuring the session hostname, port, and loading the converted private key (.ppk format) under Connection > SSH > Auth > Credentials.

Hardening the SSH Daemon

Modify /etc/ssh/sshd_config to enforce stricter security policies:

Port 2222
ListenAddress 0.0.0.0
Protocol 2
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Apply configuration changes without terminating active sessions:

sudo systemctl reload sshd

Disabling direct root access and password-based logins significant reduces exposure to brute-force attacks and credential stuffing.

Secure File Transfer Operations

Transfer data securely using SCP or SFTP over the established encrypted tunnel.

Recursively copy a local directory to a remote endpoint:

scp -P 2222 -r /var/data/reports/ sysadmin@10.0.0.50:/mnt/backup/archive/

Initiate an interactive SFTP session for granular file management:

sftp -P 2222 sysadmin@10.0.0.50

Within the SFTP prompt, standard commands such as put, get, ls, cd, and lpwd manage remote and local filesystems. Terminate the session with bye or exit.