10 SSH Tricks That Make Remote Linux Work Much Easier

Raja ishaq Nabi Khan

9 min read

·

Oct 24, 2026

--

Listen

Share

Go beyond ssh user@server. Learn host aliases, key-based authentication, connection multiplexing, port forwarding, remote commands, and other techniques that make working on Linux servers faster and more reliable.

If you work with Linux servers, you probably use SSH regularly.

You type something like:

ssh user@192.168.1.100

You enter your credentials, connect to the machine, and start working.

That is fine for basic remote access. But SSH can do much more than open a remote terminal.

You can connect to multiple servers using short aliases, execute commands without opening an interactive session, transfer files securely, forward ports, reuse existing connections, and troubleshoot network problems without installing additional software.

The difference is not about memorizing more commands. It is about learning how to configure SSH so that routine work requires fewer steps.

Here are 10 SSH techniques worth learning if you work with remote Linux machines.

1. Stop Typing Long SSH Commands: Use Host Aliases

Suppose you regularly connect to three servers:

ssh raja@192.168.1.100
ssh raja@192.168.1.101
ssh admin@10.0.0.25

You must remember each address and username. If a server requires a particular key or port, the command becomes even longer.

SSH configuration solves this problem.

Open your SSH configuration file:

nano ~/.ssh/config

Add entries like these:

Host workserver
    HostName 192.168.1.100
    User raja

Host testserver
    HostName 192.168.1.101
    User rajaHost production
    HostName 10.0.0.25
    User admin
    Port 2222

Now connect using:

ssh workserver

Or:

ssh testserver

Or:

ssh production

SSH reads the configuration and fills in the appropriate connection details.

You can also specify a private key:

Host workserver
    HostName 192.168.1.100
    User raja
    IdentityFile ~/.ssh/work_key
    IdentitiesOnly yes

This is particularly useful when managing several servers with different accounts and authentication requirements.

Power-user takeaway: Put recurring connection settings in ~/.ssh/config instead of repeatedly typing them at the command line.

The IP addresses and usernames above are examples. Replace them with your actual server details.

2. Use SSH Keys Instead of Repeated Password Authentication

If you connect to the same server frequently, key-based authentication can simplify the login process and provide strong security when configured correctly.

First, generate an SSH key pair on your local machine:

ssh-keygen -t ed25519

Follow the prompts. A passphrase is recommended to protect the private key if the file is copied or stolen.

This creates two files by default:

~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

The first is your private key. Keep it private.

The second is your public key. It can be installed on the server.

On a system that supports it, run:

ssh-copy-id raja@192.168.1.100

Then connect:

ssh raja@192.168.1.100

After successful setup, SSH can authenticate using the key instead of requiring the account password for every connection. If your private key has a passphrase, you may still need to unlock it unless an agent has already done so.

If ssh-copy-id is unavailable, you can install the public key manually in the remote account's ~/.ssh/authorized_keys file.

A security detail worth remembering

Never copy your private key to the server just to enable authentication.

The public key belongs on the remote machine. The private key should remain under your control.

Key-based authentication also does not automatically disable password authentication on the server. That is a separate server-side security decision.

3. Use ssh-agent to Avoid Repeatedly Entering Your Key Passphrase

You have generated an SSH key and protected it with a passphrase.

That’s good security, but repeatedly entering the passphrase during a long work session can become tedious.

An SSH agent can hold an unlocked key for you.

Start an agent in environments where one is not already running:

eval "$(ssh-agent -s)"

Add your key:

ssh-add ~/.ssh/id_ed25519

Enter the passphrase when prompted.

You can inspect the identities currently available to the agent:

ssh-add -l

Now SSH can use the loaded key for subsequent connections supported by that agent.

Modern desktop environments often start and manage an agent automatically, so you may not need to run these commands manually.

Why this matters

You retain the protection of an encrypted private key without having to unlock it for every connection.

For shared or untrusted machines, be careful about how long keys remain loaded and which processes can access the agent.

Press enter or click to view image in full size

4. Execute Commands on a Remote Server Without Opening a Shell

Sometimes you don’t need an interactive terminal on the remote machine.

You simply need information or want to perform one operation.

For example:

ssh workserver "uptime"

This connects to the remote host, executes uptime, and returns the output.

Check disk space:

ssh workserver "df -h"

Check memory:

ssh workserver "free -h"

Check whether a particular service is active:

ssh workserver "systemctl is-active nginx"

The remote account must have permission to run the requested command.

You can also execute several commands:

ssh workserver "cd /var/log && ls -lh"

The commands inside the quotes are interpreted by the remote shell.

Run the same check on multiple servers

If your SSH configuration contains several host aliases:

for host in workserver testserver; do
    echo "Checking $host"
    ssh "$host" "uptime"
done

This is a simple way to collect information from several machines.

For larger deployments, monitoring systems or configuration-management tools may be more appropriate. But for a small number of servers, SSH loops are often sufficient.

5. Keep Long-Running Work Alive With tmux

You SSH into a server, start a lengthy task, and then your internet connection drops.

What happens?

If the task is running directly in your interactive shell, the disconnection may cause the session and its processes to terminate. The exact behavior depends on the shell, process, and session configuration.

A useful solution is tmux.

On the remote server, start a session:

tmux new -s work

Run your command inside it:

./long_running_task.sh

To detach from the session while leaving it running, press:

Ctrl+B, then D

You return to the remote shell without closing the tmux session.

Later, reconnect to the server:

ssh workserver

List available sessions:

tmux ls

Reattach:

tmux attach -t work

Your terminal session, including its running foreground program, remains available.

Important distinction

tmux is not an SSH option. It is a terminal multiplexer that runs on the remote machine.

SSH provides the connection. tmux preserves the terminal session independently of that connection.

If the remote machine reboots or the process crashes, tmux cannot preserve the lost process.

6. Transfer Files Securely With scp

SSH is not limited to interactive sessions. You can use it to transfer files between computers.

To copy a local file to a remote server:

scp report.txt workserver:/home/raja/

To copy a remote file to your local machine:

scp workserver:/home/raja/report.txt .

To copy a directory recursively:

scp -r project/ workserver:/home/raja/

You can also specify a non-default port:

scp -P 2222 report.txt production:/home/admin/

Notice that scp uses uppercase -P for the port option.

When should you use scp?

Use it for straightforward file transfers.

If you regularly synchronize large directories, preserve metadata, or transfer only changed files, rsync may be more suitable.

For example:

rsync -avh --progress project/ workserver:/home/raja/project/

Both tools can use SSH for secure transport.

One practical distinction is that scp copies files, while rsync is designed to synchronize files and directory trees efficiently.

7. Forward a Remote Port to Your Local Machine

This is one of SSH’s most useful features for developers and administrators.

Suppose a web application is running on a remote server and listening on port 3000.

The service is not exposed directly to the public internet, but you want to access it from your own browser.

You can create a local port forward:

ssh -L 8080:localhost:3000 workserver

Leave this SSH session open.

Then open the following address on your local machine:

http://localhost:8080

The connection follows this path:

Your browser
     |
     | localhost:8080
     v
Local SSH listener
     |
     | encrypted SSH connection
     v
Remote server
     |
     | localhost:3000
     v
Web application

The important detail is that localhost:3000 in this command refers to the remote server's network environment, not your local computer.

This technique is called local port forwarding.

When is this useful?

• Accessing a development server on a remote machine
• Inspecting an internal web dashboard
• Connecting to a database that should not be publicly exposed
• Testing services bound to the remote loopback interface

Only forward services you are authorized to access. Keep the SSH connection protected, and avoid exposing the local forwarded port to other machines unless that is intentional.

8. Reuse SSH Connections to Reduce Repeated Connection Overhead

If you repeatedly run remote commands against the same server, SSH may spend time establishing a new connection for each command.

OpenSSH supports connection multiplexing, which allows multiple sessions to reuse an existing authenticated connection.

Add the following to ~/.ssh/config:

Host workserver
    HostName 192.168.1.100
    User raja
    ControlMaster auto
    ControlPath ~/.ssh/cm-%C
    ControlPersist 10m

Now run:

ssh workserver

Additional SSH connections to the same configured host can reuse the master connection while it remains available.

The settings mean:

• ControlMaster auto: Reuse or establish a master connection when appropriate.
• ControlPath: Specify where the local control socket is stored.
• ControlPersist 10m: Keep the master connection available for up to ten minutes after its original session closes, subject to the connection's state.

This can reduce repeated connection setup overhead, especially when running scripts that issue many SSH commands.

A security consideration

The control socket is sensitive because it can allow access to an authenticated connection. Keep it in a directory with appropriate permissions, and avoid placing it in a shared location.

You can close a master connection explicitly:

ssh -O exit workserver

This works when a corresponding master connection is active and the configuration matches.

9. Use SSH Configuration to Handle Different Ports and Connection Options

Some servers listen on the default SSH port 22. Others use a different port or require a jump host.

You can specify a port directly:

ssh -p 2222 raja@192.168.1.100

Remember that SSH uses lowercase -p for the connection port.

For recurring connections, store the setting:

Host production
    HostName 10.0.0.25
    User admin
    Port 2222

Then:

ssh production

What if the server is reachable only through another machine?

OpenSSH supports jump hosts.

For example:

Host bastion
    HostName bastion.example.com
    User raja

Host internal
    HostName 10.0.0.25
    User admin
    ProxyJump bastion

Now:

ssh internal

SSH connects through the configured bastion host to reach the internal machine.

This is useful in environments where servers are isolated from direct public access.

The jump host must itself be reachable, and the network and SSH policies must permit the onward connection.

10. Debug SSH Connections Instead of Guessing

SSH failures can come from several places:

• Incorrect usernames or hostnames
• Network connectivity problems
• Wrong ports
• Missing or incorrect private keys
• Server-side authentication settings
• Host key verification failures
• File permission problems involving SSH keys

Instead of repeatedly changing settings, increase the verbosity of the SSH client.

Run:

ssh -v workserver

For more diagnostic detail:

ssh -vv workserver

And, when needed:

ssh -vvv workserver

These options reveal more information about connection setup, key selection, authentication attempts, and protocol negotiation.

You can also test whether a TCP connection can be established to a particular SSH port:

nc -vz 192.168.1.100 22

This requires nc (netcat) to be installed. It tests basic reachability to the port, not whether SSH authentication will succeed.

Check host key warnings carefully

If SSH reports that a server’s host key has changed, do not blindly disable host key checking or delete the old key.

The change may be legitimate, such as after a server rebuild, but it can also indicate a security problem.

Verify the new host key through a trusted channel before accepting it.

Good troubleshooting begins with evidence, not with disabling security checks.

The Bigger Picture: Turn SSH Into a Workflow

These techniques become especially useful when combined.

For example, you could configure a host alias, connect using a key, run a remote command, and capture its output:

ssh workserver "df -h" > disk_report.txt

Or use SSH with a remote session that survives a dropped connection:

SSH
 |
 v
Remote Linux server
 |
 v
tmux session
 |
 v
Long-running task

Or access a private application through a local tunnel:

Browser
   |
   v
localhost:8080
   |
   v
SSH tunnel
   |
   v
Remote localhost:3000

The goal is not to use every SSH feature. It is to recognize which feature solves the problem in front of you.

Final Thoughts

SSH is much more than a command for opening a remote terminal.

With a well-configured SSH client, you can simplify server access, automate remote checks, transfer files, maintain long-running terminal sessions, reach private services, and diagnose connection failures.

Start with these habits:

• Use ~/.ssh/config for recurring hosts.
• Prefer key-based authentication with a protected private key.
• Use ssh-agent when appropriate.
• Execute remote commands directly when an interactive shell isn’t needed.
• Use tmux for terminal sessions that should survive disconnections.
• Choose scp or rsync based on your transfer needs.
• Use port forwarding for authorized access to private services.
• Consider connection multiplexing for repeated SSH operations.
• Configure jump hosts when network architecture requires them.
• Use verbose diagnostics instead of disabling security protections.

The real advantage comes from reducing repetitive work while maintaining control over access and security.

The next time you type ssh user@server, consider whether you could make that connection simpler, more secure, or easier to troubleshoot.

That’s how you turn SSH from a basic remote-login tool into a practical part of your everyday Linux workflow.