SSH Command in Linux: Connect to Remote Servers

Quick take: The ssh command opens an encrypted shell on a remote server: ssh user@host. Add -p for a non-default port, -i to choose a private key, and append a command to run it remotely without an interactive session.

Introduction

The ssh command (Secure Shell) is how you log in to and run commands on remote Linux servers over an encrypted connection. It replaced insecure tools like telnet and is the foundation of remote administration, deployments, and secure file transfer.

This guide covers connecting with users and ports, key-based authentication, running one-off remote commands, and the tunnelling options that make SSH far more than a remote terminal.

Syntax

The basic syntax of the ssh command is:

ssh [OPTIONS] user@host [COMMAND]

Common Options and Parameters

The most useful options and parameters for the ssh command:

Practical Examples

Real ssh commands you can run today:

# Connect to a server
ssh irfan@203.0.113.10
# Connect on a custom port
ssh -p 2222 irfan@server.example.com
# Use a specific private key
ssh -i ~/.ssh/deploy_key deploy@app01
# Run a single command remotely
ssh irfan@server 'df -h'
# Debug a failing connection
ssh -v irfan@server
# Local port forward: reach remote DB on localhost:5432
ssh -N -L 5432:localhost:5432 irfan@dbhost

The SSH Config File and Key Management

Once you manage more than a couple of servers, typing full connection details every time becomes tedious. The ~/.ssh/config file lets you define named hosts with their user, port, key, and options, so a long command collapses into a short alias.

# ~/.ssh/config
Host app01
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/deploy_key

With that in place, ssh app01 connects with the right user, port, and key automatically. Pair it with key-based authentication — generate a key with ssh-keygen -t ed25519 and install it using ssh-copy-id app01 — to log in securely without passwords.

Troubleshooting SSH Connections

When a connection fails, the verbose flag is your best friend: ssh -v user@host prints each step of the handshake and usually pinpoints the problem — wrong key, refused authentication, or a network block.

Common causes have quick fixes: a permission denied error often means the private key has loose permissions (chmod 600 ~/.ssh/id_rsa) or the public key is not in the server's ~/.ssh/authorized_keys. A connection refused means nothing is listening on the SSH port — check the service with systemctl status ssh and confirm the port with ss -tlnp. A host key changed warning appears after a server rebuild; remove the stale entry with ssh-keygen -R host.

Tips and Best Practices

• Set up key-based login (ssh-keygen then ssh-copy-id user@host) to connect without passwords and improve security.
• Use a ~/.ssh/config file to store hosts, users, ports, and keys so you can just type ssh app01.
• If a key is rejected, check its permissions — SSH refuses private keys that are group- or world-readable (use chmod 600).

Final Thoughts

ssh is the front door to every remote Linux server you manage. Learn to connect with users, ports, and keys, run remote commands inline, and build tunnels with -L and -R, and you can administer infrastructure securely from anywhere. Combine it with scp and rsync for file transfer over the same secure channel.