LiveChat 
Support 
SSH Command: How to Connect to a Remote Server (Complete Guide)
The `ssh` command is the single most important tool for managing a Linux server. It opens a secure, encrypted connection from your local machine to a remote host, dropping you into a shell where you can run any command as if you were sitting in front of the server. Whether you manage one VPS or fifty production boxes, learning to use the `ssh` command well is the foundation of all remote server administration.
This guide walks through the `ssh` command from the most basic connection to the configuration tricks that experienced administrators rely on every day.
Key Takeaways
• The basic syntax is `ssh user@host` — that single line is enough to connect to most servers.
• Use `-p` for a non-standard port, `-i` to point at a specific private key, and `-v` to debug a failing connection.
• The first connection prompts you to verify the host’s fingerprint; accepting it saves the key to `~/.ssh/known_hosts`.
• The `~/.ssh/config` file lets you collapse long commands into a memorable alias — `ssh myserver` instead of a wall of flags.
• Most SSH errors fall into three buckets: connection refused (wrong port/host/firewall), permission denied (auth/key), and host key changed (a security warning worth reading).
What Is the Basic SSH Command?
The simplest form of the `ssh` command is a username and a hostname (or IP address) joined by an `@` symbol:
“`bash ssh user@host “`
For example, to connect to a server at `203.0.113.10` as the user `deploy`:
“`bash ssh [email protected] “`
Or using a domain name instead of an IP:
“`bash ssh [email protected] “`
When you run this, SSH connects to the remote machine on the default port (22), asks for authentication (a password or, ideally, a key), and — if everything checks out — drops you into a remote shell. From there, every command you type runs *on the server*, not on your local machine.
If your local username matches the remote username, you can even omit the `user@` part:
“`bash ssh server.example.com “`
For a plain-English explanation of what SSH actually is and how the protocol works, see .
How Do You Connect to a Specific Port?
By default, SSH listens on port 22. Many administrators move SSH to a non-standard port to reduce automated login noise. To tell the `ssh` command which port to use, pass the `-p` flag:
“`bash ssh -p 2222 [email protected] “`
Note the lowercase `-p`. (Uppercase `-P` is used by `scp` for the same purpose, which trips people up.) If you get a “Connection refused” error, the wrong port is one of the first things to check — more on that below. To learn how to choose and secure a port, see .
How Do You Connect Using a Specific Key File?
When you authenticate with an SSH key instead of a password, SSH normally looks in `~/.ssh/` for default key names (`id_rsa`, `id_ed25519`, and so on). If your private key lives somewhere else, or has a custom name, point at it explicitly with `-i` (for “identity”):
“`bash ssh -i ~/.ssh/special_key [email protected] “`
You can combine flags freely. A connection that uses a custom port *and* a custom key looks like this:
“`bash ssh -p 2222 -i ~/.ssh/special_key [email protected] “`
Make sure the private key has tight permissions, or SSH will refuse to use it:
“`bash chmod 600 ~/.ssh/special_key “`
For a full walkthrough of generating keys and setting up passwordless login, see .
How Do You Debug a Connection with Verbose Mode?
When a connection fails for no obvious reason, the `-v` (verbose) flag is your best friend. It prints a running log of exactly what SSH is doing — which keys it offers, which port it dials, where the negotiation breaks down:
“`bash ssh -v [email protected] “`
For even more detail, stack the flag up to three times:
“`bash ssh -vvv [email protected] “`
Reading the verbose output is often faster than guessing. Lines like `Connecting to server.example.com port 22` confirm the target, and `Offering public key: ~/.ssh/id_ed25519` tells you which key SSH tried — invaluable when authentication silently fails.
How Do You Run a Single Command Remotely?
You don’t always need an interactive session. The `ssh` command can run one command on the remote host and return immediately. Put the command in quotes after the destination:
“`bash ssh [email protected] ‘uptime’ “`
This is perfect for quick checks or scripting. A few practical examples:
“`bash
ssh [email protected] ‘df -h’
ssh [email protected] ‘tail -n 50 /var/log/nginx/error.log’
ssh [email protected] ‘sudo systemctl restart nginx’ “`
Because the command runs and exits, you can pipe its output into local tools or loop over many servers in a shell script.
What Happens on the First Connection?
The first time you connect to a new host, the `ssh` command shows a prompt like this:
“`text The authenticity of host ‘server.example.com (203.0.113.10)’ can’t be established. ED25519 key fingerprint is SHA256:abcd1234…EXAMPLE…wxyz. Are you sure you want to continue connecting (yes/no/[fingerprint])? “`
This is SSH asking you to verify the server’s host key fingerprint. The fingerprint uniquely identifies the server. In a perfect world, you’d compare it against a fingerprint your hosting provider gave you out-of-band. In practice, on a fresh server you control, you type `yes`.
Once you accept, SSH saves the server’s public key to a file called `~/.ssh/known_hosts`. On every future connection, SSH silently checks the server against that stored key. You won’t be prompted again — unless the key changes, which triggers a loud warning (covered in the errors section).
The one feature that makes SSH genuinely pleasant. Most people type the full `ssh` command over and over — `ssh -p 2222 -i ~/.ssh/special_key [email protected]` — and never discover the `~/.ssh/config` file. By defining a host block *once*, you collapse all of that into a memorable alias, and forever after you just type `ssh myserver`. This isn’t mere convenience: it eliminates the errors that come from retyping ports and key paths, it documents your connection details in one place, it lets `scp`/`sftp`/`rsync` reuse the same aliases automatically, and it scales to dozens of servers without you memorizing anything. The raw `ssh` command with its flags is the *manual* way; the *expert* way is to configure once and forget. Your `~/.ssh/config` becomes a personal address book of servers, and the flags you’d otherwise retype every time live there instead. The rule of thumb: if you’re typing `ssh` with `-p` and `-i` flags regularly, that’s the signal to move them into `~/.ssh/config`. The command line is for one-offs; the config file is for the servers you actually use.
How Do You Set Up SSH Config Shortcuts?
The `~/.ssh/config` file lets you define named shortcuts for the servers you connect to. Create or edit the file:
“`bash nano ~/.ssh/config “`
Then add a host block. Each block names an alias and the connection details that go with it:
“`text Host myserver HostName some-long-hostname.example.com User deploy Port 2222 IdentityFile ~/.ssh/special_key “`
Save the file and set its permissions:
“`bash chmod 600 ~/.ssh/config “`
Now this long, flag-heavy command:
“`bash ssh -p 2222 -i ~/.ssh/special_key [email protected] “`
…becomes simply:
“`bash ssh myserver “`
You can define as many host blocks as you like, and even use wildcards and default settings that apply to all hosts:
“`text Host web1 HostName 203.0.113.10 User deploy IdentityFile ~/.ssh/special_key
Host web2 HostName 203.0.113.20 User deploy IdentityFile ~/.ssh/special_key
Host * ServerAliveInterval 60 AddKeysToAgent yes “`
The bonus: `scp`, `sftp`, and `rsync` all read this same file, so `scp file.txt myserver:/tmp/` just works with no extra flags.
What Are the Most Common SSH Command Options?
A handful of options cover the vast majority of day-to-day SSH usage. Keep this table handy:
| Option | What it does | Example |
|---|---|---|
| `-p |
Connect to a non-default port | `ssh -p 2222 user@host` |
| `-i |
Use a specific private key (identity) | `ssh -i ~/.ssh/key user@host` |
| `-v` / `-vvv` | Verbose output for debugging | `ssh -vvv user@host` |
| `-L` | Local port forwarding (tunnel) | `ssh -L 8080:localhost:80 user@host` |
| `-R` | Remote port forwarding (reverse tunnel) | `ssh -R 9090:localhost:3000 user@host` |
| `-D` | Dynamic SOCKS proxy | `ssh -D 1080 user@host` |
| `-X` | Enable X11 forwarding (GUI apps) | `ssh -X user@host` |
| `-C` | Compress data in transit | `ssh -C user@host` |
| `-N` | Don’t run a remote command (tunnel only) | `ssh -N -L 8080:localhost:80 user@host` |
The forwarding options (`-L`, `-R`, `-D`) turn SSH into a secure tunnel for other traffic — a deep topic in its own right. See for a full guide.
Connection options at a glance
| Option | Default | When you’d change it |
|---|---|---|
| Port | 22 | Server moved SSH to a custom port |
| Identity file | `~/.ssh/id_*` | Key has a non-standard name or location |
| User | local username | Remote account differs from your local one |
| Host key check | enabled | Almost never disable; it protects you |
How Do You Copy Files Over SSH?
The same SSH machinery powers two file-transfer tools you’ll use constantly.
`scp` copies files over SSH, much like `cp` but across machines:
“`bash
scp report.pdf [email protected]:/home/deploy/
scp [email protected]:/var/log/app.log ./ “`
`sftp` opens an interactive file-transfer session, like an FTP client running over the secure SSH connection:
“`bash sftp [email protected] “`
Both honor your `~/.ssh/config` aliases, so `scp report.pdf myserver:/tmp/` works without any flags. For a deeper comparison and more examples, see .
Manage your server with full SSH access from DarazHost. DarazHost VPS and dedicated servers give you full SSH access — connect with the `ssh` command, set up key-based login and `~/.ssh/config` shortcuts, and manage your server securely from anywhere. With guaranteed resources and 24/7 support to help with your first connection, you get root-level control without the guesswork. Explore the complete Linux server administration guide to see how the `ssh` command fits into the bigger picture of managing a server.
What Are the Most Common SSH Errors and How Do You Fix Them?
Most failed connections come down to one of three messages.
1. Connection refused
“`text ssh: connect to host server.example.com port 22: Connection refused “`
This means SSH reached the server but nothing answered on that port. Common causes:
- You’re using the wrong port — try `-p` with the correct number.
- The SSH service isn’t running on the server.
- A firewall is blocking the port.
Quick checks:
“`bash
ssh -p 2222 [email protected]
ssh -v [email protected] “`
2. Permission denied
“`text [email protected]: Permission denied (publickey). “`
This is an *authentication* failure — SSH connected fine but rejected your credentials. Common causes:
- The wrong key is being offered, or the server doesn’t have your public key.
- File permissions on your key are too open (use `chmod 600`).
- You’re using the wrong username.
Use verbose mode to see which key SSH tried:
“`bash ssh -v [email protected]
“`
3. Host key changed warning
“`text @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ “`
SSH is warning that the server’s host key no longer matches the one saved in `~/.ssh/known_hosts`. This *can* mean a man-in-the-middle attack — but it usually means the server was rebuilt or reinstalled. If you’re certain the change is legitimate, remove the old key and reconnect:
“`bash ssh-keygen -R server.example.com ssh [email protected] “`
Never ignore this warning blindly. Verify *why* the key changed before you accept the new one.
Frequently Asked Questions
What is the basic ssh command to connect to a server?
The basic syntax is `ssh user@host`, for example `ssh [email protected]`. SSH connects on port 22 by default, authenticates you, and opens a remote shell.
How do I connect to SSH on a different port?
Use the lowercase `-p` flag: `ssh -p 2222 user@host`. Better yet, set the `Port` in a `~/.ssh/config` host block so you never have to type it again.
How do I tell ssh which private key to use?
Use the `-i` flag followed by the path to the key: `ssh -i ~/.ssh/special_key user@host`. Ensure the key has `chmod 600` permissions, or SSH will refuse to use it.
Why do I get “Permission denied (publickey)”?
SSH connected but rejected your credentials. The usual causes are an unregistered or wrong key, overly open key file permissions, or the wrong username. Run `ssh -v` to see which key SSH offered.
What does the ~/.ssh/config file do?
It stores named shortcuts for your servers. Define `Host`, `HostName`, `User`, `Port`, and `IdentityFile` once, then connect with a simple alias like `ssh myserver`. `scp`, `sftp`, and `rsync` reuse the same aliases automatically.
