Blog

To open a terminal session on a Linux server, run ssh [email protected] on your own Linux computer. Replace alice with your account name on the remote machine and server.example with its hostname or IP address. Once connected, commands you type run on the remote machine until you enter exit or press Ctrl+D.

SSH (Secure Shell) encrypts the connection between your client and an SSH server. You can use it to administer machines you own, reach an authorized development environment, or transfer files. Encryption protects the connection, but it does not tell you whether you have reached the right server. You need to check the server’s identity separately.

What you need before connecting

Most Linux distributions include the OpenSSH client. Run ssh -V to check; it prints the client version but does not test a connection. If the command is missing, install the OpenSSH client with your distribution’s package manager. The remote machine must also be running an SSH server, often called sshd, and its firewall must permit connections from your network.

Get these details from the server administrator or your lab setup:

• The remote hostname or IP address and your account name on that machine.
• The SSH port, if it differs from the usual TCP port 22.
• The approved authentication method: a password, an SSH key, or another method required by the organization.
• A trusted way to verify the server’s SSH host-key fingerprint.

Use SSH only on systems you own or have permission to access. If a connection fails, do not start guessing account names or trying credentials from elsewhere.

Make your first connection

For a server on the default port, run ssh [email protected]. For another port, use an uppercase -p: ssh -p 2222 [email protected]. If you leave out the username, SSH generally tries your current local username, which may differ from your remote account.

On a first connection, the client usually says it cannot establish the host’s authenticity and displays a host-key fingerprint. That message is normal for a host you have not connected to before, but do not accept the key without checking it. Compare the fingerprint with one obtained through an independent, trusted channel, such as the administrator’s documented setup or the server console in your own lab. If you cannot verify it, stop and ask.

After you accept a verified host key, SSH saves it in ~/.ssh/known_hosts and checks it on later connections. A changed-key warning might follow a legitimate server rebuild, but it could also mean you have reached the wrong machine or someone is intercepting the connection. Confirm the change independently before altering the saved entry. Do not disable host-key checking just to silence the warning.

The server may then ask for your password. Terminal password prompts normally show nothing as you type. Once logged in, run whoami to check your remote username and hostname to check the machine’s name. Do this before making changes; a shell prompt is easy to misread. End the session with exit.

Use an SSH key for authentication

With public-key authentication, your client keeps a private key and the server stores the matching public key for your account. Keep the private key under your control; the public key is the part you can give to the server. A passphrase helps protect the private key file if someone gains access to your computer’s storage. It is separate from your remote account password.

Create and install a key

On your Linux computer, run ssh-keygen -t ed25519 -C "alice-laptop". The comment is a label to help you identify the key; it does not grant access. Accept the suggested path, typically ~/.ssh/id_ed25519, unless you need a separate named key for this server. Choose a strong, unique passphrase. If a key already exists at the suggested path, do not overwrite it without finding out where it is used.

The resulting id_ed25519 file is private; id_ed25519.pub is public. If the server permits password login and your administrator approves this method, ssh-copy-id [email protected] can append your public key to the remote account’s ~/.ssh/authorized_keys. For a nondefault port, use ssh-copy-id -p 2222 [email protected]. Verify the host fingerprint first, as you would for a normal login. If ssh-copy-id is unavailable or password login is disabled, ask the administrator to install the contents of your .pub file through the approved channel.

Test the key in a new terminal before closing an existing working session: ssh [email protected]. You may be asked for the key’s passphrase. Keep the original session open so you can correct an authorized setup mistake without locking yourself out.

Protect the private key and use an agent carefully

Never paste your private key into chat, a ticket, or a repository. On Linux, your ~/.ssh directory should normally be accessible only to your user. chmod 700 ~/.ssh sets that directory permission, and chmod 600 ~/.ssh/id_ed25519 restricts the private key file. Run these commands only for paths you own, and do not confuse the private key with its shareable .pub counterpart.

An SSH agent can hold an unlocked key for your session, sparing you from entering its passphrase on every connection. Many desktop environments start one automatically. Check loaded keys with ssh-add -l; if an agent is available, add the default key with ssh-add ~/.ssh/id_ed25519. An agent makes access more convenient, but it does not secure an unlocked computer. Lock your screen when you step away. Leave agent forwarding disabled unless you have a specific, trusted need: a remote host could otherwise use your forwarded agent while the connection remains open.

Simplify repeat connections with an SSH config

The client configuration file ~/.ssh/config lets you give an authorized destination a short name:

Host dev-box
    HostName server.example
    User alice
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

After saving that entry, ssh dev-box uses those settings. IdentityFile selects your private key, and IdentitiesOnly yes helps prevent the client from offering unrelated agent keys. If you edit the file yourself, chmod 600 ~/.ssh/config keeps its contents private. The alias saves typing; it does not replace host-key verification.

Run a command or transfer a file

You do not need an interactive shell for every task. ssh dev-box 'uptime' runs uptime remotely and returns its output to your local terminal. Pay attention to quoting: it determines what your local shell processes and what the remote shell receives. Start with simple read-only commands while you get used to the distinction.

To send a local file to your remote home directory, run scp ./notes.txt dev-box:~/notes.txt. To copy it back, run scp dev-box:~/notes.txt ./notes-from-server.txt. Use explicit filenames while learning so it is clear which file might be replaced. With a configured alias, scp uses the alias’s hostname, account, port, and identity settings. Without an alias, a nondefault port requires an uppercase -P for scp, unlike SSH’s lowercase -p.

SSH can also tunnel network connections. A carelessly configured tunnel can expose services or bypass network controls, so use forwarding only when permitted and when you understand which address and port will listen on each side.

Diagnose common connection failures

Read the exact error before changing settings. Each of these messages points to a different part of the connection:

• Could not resolve hostname: Check the hostname’s spelling, your DNS configuration, or the HostName value in your SSH config.
• Connection timed out: The destination may be unreachable, the port may be filtered, or you may need an approved VPN. Confirm the address, port, and network path with the administrator.
• Connection refused: You reached a host, but nothing accepted the connection on that port. Check the documented port and, if you administer the server, whether its SSH service is running.
• Permission denied: Check the remote username, approved authentication method, and selected key. A valid key for a different account will not grant access.
• Host key verification failed: Stop and investigate the server’s identity. Do not delete known_hosts wholesale or turn off verification to make the message disappear.

For more detail during an authorized connection attempt, run ssh -v dev-box. The debug output can show which configuration and authentication methods the client tries. Review it before sharing: logs can reveal account names, hostnames, and local file paths. If a verified server was rebuilt and its key legitimately changed, ssh-keygen -R server.example removes that hostname’s saved entry. Remove it only after confirming the new fingerprint through your trusted channel.

If a key works locally but fails after you copy it to an account you administer, check that its public-key line is intact in the remote ~/.ssh/authorized_keys file and that the remote account owns its SSH files. Keep your working session open while you make corrections. Then test a fresh ssh [email protected] connection before closing it.