What is SSH? Secure Shell remote access explained

SSH, or Secure Shell, is a network protocol that provides an encrypted channel for logging into and running commands on a remote computer over an untrusted network. It replaced older plaintext tools like Telnet by encrypting all traffic, authenticating both ends, and protecting against eavesdropping and tampering. Beyond interactive login, SSH underpins secure file transfer, port forwarding, and the transport layer that Git uses to push and pull over encrypted connections, making it a foundational tool for developers and system administrators.

Key takeaways

• SSH gives an encrypted, authenticated channel for remote login and command execution.
• It defaults to TCP port 22 and follows a client-server model.
• Public-key authentication with an SSH key pair is more secure than passwords.
• The private key stays on your machine; only the public key goes on the server.
• Host keys and the known_hosts file protect against man-in-the-middle attacks.
• SSH also powers scp/sftp file transfer and port forwarding (tunneling).

How does SSH work at a high level?

An SSH session is established in stages. First the client and server negotiate a shared encryption key using a key exchange, so everything afterward is encrypted. Next the server proves its identity with its host key. Finally the user authenticates, typically with a key pair or a password. Only then does the session begin.

The basic command names a user and a host:

ssh alice@server.example.com

On the first connection the client shows the server’s host key fingerprint and asks you to confirm it. Accepting stores the key in ~/.ssh/known_hosts. On later connections the client checks that the presented key matches; a mismatch produces a loud warning because it may indicate an attacker impersonating the server.

Internally the protocol is built from three layers, and knowing them makes its behavior easier to reason about:

• The transport layer establishes the encrypted connection and verifies the server’s host key.
• The authentication layer proves the user’s identity, by key or password.
• The connection layer multiplexes the single encrypted tunnel into logical channels, which is how one SSH connection can carry an interactive shell, a file transfer, and a forwarded port at the same time.

What is public-key authentication and why prefer it?

SSH key authentication uses an asymmetric key pair: a private key you keep secret and a public key you copy to servers. The server challenges the client to prove it holds the private key, and the private key itself never travels across the network.

Generate a modern key pair like this:

ssh-keygen -t ed25519 -C "alice@laptop"

This writes ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public). You then install the public key on the server, most easily with:

ssh-copy-id alice@server.example.com

Keys are preferred over passwords because they cannot be guessed by brute force, are not reused across sites, and let servers disable password login entirely, which shuts down a huge class of automated attacks.

Protecting the private key

• Encrypt it with a passphrase so a stolen key file is unusable.
• Keep file permissions tight; SSH refuses keys that are world-readable.
• Use an SSH agent to hold the decrypted key in memory so you enter the passphrase only once per session.

What can I use the SSH config file for?

Typing long connection strings and flags is tedious and error-prone. The file ~/.ssh/config lets you define named hosts with their settings:

Host prod
    HostName server.example.com
    User alice
    Port 22
    IdentityFile ~/.ssh/id_ed25519

With that in place, ssh prod is enough. The config file is the cleanest place to record per-host users, keys, ports, and forwarding options, and it keeps those details out of your shell history.

How do I transfer files and forward ports over SSH?

Because SSH provides a secure transport, several tools build on it. File transfer uses the same authentication you already set up.

Port forwarding tunnels another connection through the encrypted channel. Local forwarding exposes a remote service on your machine:

ssh -L 5432:localhost:5432 prod

This makes the server’s PostgreSQL port reachable at localhost:5432 on your laptop, encrypted end to end. This is a common safe way to reach a database that is not exposed to the public internet.

There are three forwarding modes, and choosing the right one avoids a lot of confusion:

• Local (-L) maps a port on your machine to a destination reachable from the server. Use it to reach a remote service locally.
• Remote (-R) maps a port on the server to a destination reachable from your machine. Use it to expose a local service to the remote side.
• Dynamic (-D) turns SSH into a SOCKS proxy, routing arbitrary traffic through the server.

Forwarding is powerful, so treat it as a security-sensitive feature. A carelessly exposed remote forward can open a private service to a wider network, and server administrators can disable forwarding entirely when policy requires it.

How does Git use SSH?

One of the most common reasons developers set up SSH is to push and pull with Git hosting services. When a repository’s remote URL is in the SSH form rather than the HTTPS form, Git tunnels its traffic over SSH and authenticates with your key pair, so you never type a password for each operation.

git remote -v
# origin  git@github.example.com:team/project.git (fetch)

The git@host prefix shows Git is using SSH. Setup mirrors any other SSH use: generate a key, add the public key to your account on the hosting service, and confirm it works with a test command that reports the authenticated identity:

ssh -T git@github.example.com

Two points cause repeated confusion. First, the account you authenticate as is determined by the key, not by a username in the URL, which is why the URL literally uses git as the user. Second, if you manage multiple accounts you can define separate Host aliases in ~/.ssh/config, each pointing at a different IdentityFile, and use the alias in the remote URL to select the right key automatically.

What are SSH security best practices?

• Disable password authentication on servers once keys work, to stop brute-force login attempts.
• Disable direct root login and use a normal account with sudo.
• Verify host key fingerprints out of band on first connection rather than blindly accepting them.
• Use a passphrase and an agent so a lost laptop does not hand over a usable key.
• Keep the server software updated and prefer modern key types such as Ed25519.

Moving SSH off port 22 reduces log noise but is not a security control on its own; treat it as cosmetic and rely on keys and access limits for real protection.

What are common SSH errors and their causes?

• Permission denied (publickey). The server did not accept your key; check that the public key is in the server’s authorized_keys and that you are offering the right identity.
• Host key verification failed. The server’s key changed from what is stored in known_hosts. Investigate before removing the old entry, because it can signal an attack.
• Connection refused. No SSH server is listening, or a firewall is blocking the port.
• Bad permissions. SSH ignores keys and config files that are too openly readable; tighten them with chmod.

Frequently asked questions

What port does SSH use?

SSH uses TCP port 22 by default. Administrators sometimes move it to a non-standard port to reduce automated scanning noise, though that is obfuscation rather than real security.

Is SSH the same as SSL/TLS?

No. Both provide encryption, but SSH is a protocol for remote login and command execution, while SSL/TLS secures other protocols such as HTTPS. They are separate designs.

Are SSH keys more secure than passwords?

Yes. Key pairs resist guessing and brute force far better than passwords, and the private key never leaves your machine. Many servers disable password login entirely.

What is the known_hosts file?

It records the host keys of servers you have connected to, so your client can detect if a server’s identity later changes, which may indicate a man-in-the-middle attack.

Can I run a single command over SSH without a shell?

Yes. Append the command after the destination, as in ssh user@host uname -a, and SSH runs it remotely and returns the output without an interactive session.

What is an SSH passphrase?

A passphrase encrypts your private key on disk so a stolen key file is useless without it. An agent can hold the decrypted key in memory so you type the passphrase only once.

Does SSH work on Windows?

Yes. Modern Windows ships with an OpenSSH client, and the same ssh command and key format work across Windows, macOS, and Linux.