SSH¶

What Is It?¶

SSH (Secure Shell) is a cryptographic network protocol for secure remote login, command execution, and file transfer. It replaces insecure protocols like telnet and rlogin.

Installation¶

dnf install openssh-server openssh-clients

Key Files and Directories¶

Path	Purpose
/etc/ssh/sshd_config	Server configuration
/etc/ssh/ssh_config	Client configuration
~/.ssh/authorized_keys	Per-user authorized public keys
~/.ssh/id_rsa, ~/.ssh/id_rsa.pub	User key pair

Default Ports¶

Port	Protocol	Purpose
22	TCP	SSH — secure remote login and file transfer

Configuration¶

SSH consists of two components: the server (sshd) running on the remote machine and the client (ssh) on your local machine.

Minimal Working Configuration¶

The SSH server is pre-installed and running on CentOS. The default configuration allows key-based and password authentication.

Server config (/etc/ssh/sshd_config) — key settings to harden:

PasswordAuthentication no       # Disable password login (use keys only)
PermitRootLogin prohibit-password  # Allow root login only with keys
PubkeyAuthentication yes        # Enable public key authentication (default)

After changing sshd_config, restart the SSH daemon:

systemctl restart sshd

Key-based authentication setup:

# Generate a key pair (on your local machine)
ssh-keygen -t rsa -b 4096

# Copy the public key to a remote server
ssh-copy-id user@hostname

# Or manually append to authorized_keys
cat ~/.ssh/id_rsa.pub >> /home/user/.ssh/authorized_keys

Required permissions (SSH is strict about these):

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_rsa           # Private key
chmod 644 ~/.ssh/id_rsa.pub       # Public key

Important Directives¶

PasswordAuthentication: yes or no. When no, only key-based authentication is accepted. Strongly recommended to set to no on public-facing servers.
PermitRootLogin: yes, no, or prohibit-password. The latter allows root login only with SSH keys.
PubkeyAuthentication: Enable or disable public key authentication. Default yes.
AuthorizedKeysFile: Path to the authorized keys file. Default .ssh/authorized_keys.
Port: SSH listening port. Default 22. Changing this provides minor security-through-obscurity.
AllowUsers / DenyUsers: Whitelist or blacklist specific users for SSH access.
ClientAliveInterval / ClientAliveCountMax: Keep-alive settings to detect and disconnect dead sessions.

Common Commands¶

# Connect to a remote host
ssh user@hostname
ssh user@172.17.64.X

# Connect with a specific key file
ssh -i ~/.ssh/custom_key user@hostname

# Execute a remote command without interactive shell
ssh user@hostname "uptime"

# Copy files to/from remote host
scp localfile.txt user@hostname:/remote/path/
scp user@hostname:/remote/file.txt ./local/path/

# Recursive copy
scp -r local_dir/ user@hostname:/remote/path/

# SSH tunneling (port forwarding)
ssh -L 8080:localhost:80 user@hostname   # Local forward
ssh -R 8080:localhost:80 user@hostname   # Remote forward

# Generate a key pair
ssh-keygen -t rsa -b 4096
ssh-keygen -t ed25519              # Modern alternative

# Copy public key to remote host
ssh-copy-id user@hostname

# Test SSH connectivity
ssh -v user@hostname               # Verbose output for debugging

Logging and Debugging¶

Client-side verbose mode: ssh -v user@host (use -vv or -vvv for extreme detail). -vvv is useful for debugging connection hangs.
Server logs: journalctl -u sshd or /var/log/secure on CentOS/RHEL.
Failed login attempts: Visible in /var/log/secure with source IP and authentication method.

Troubleshooting checklist:

ssh -v user@host — what does the client report?
Check ~/.ssh/ permissions — 700 for directory, 600 for authorized_keys and private keys
journalctl -u sshd — server-side errors
systemctl status sshd — is the service running?
firewall-cmd --list-all — is port 22 open?
Verify the correct public key is in ~/.ssh/authorized_keys on the target host

Security Considerations¶

Disable password authentication: Set PasswordAuthentication no in sshd_config. Key-based authentication eliminates brute-force password attacks.
Restrict users: Use AllowUsers user1 user2 in sshd_config to strictly limit which accounts can log in.
Protect private keys: Private keys (id_rsa) must have 600 permissions and never be shared. Use a passphrase for additional protection.
Separate keys per purpose: Use different key pairs for different services (personal access, scoring, automation) to limit exposure.
Do not use root for daily operations: Log in as a regular user and use sudo for privileged commands. Set PermitRootLogin prohibit-password or no.
Restart carefully: Restarting sshd does not terminate existing connections, but a misconfigured sshd_config can prevent new connections. Always test from a second session before disconnecting.
Firewall: SSH (port 22) should be allowed in both firewalld and cloud security groups. Consider restricting SSH access to specific source IPs in production.