SSH¶

SSH is the standard way to reach remote machines, run commands, move files, and tunnel traffic securely. For data and ML work, it is often the front door to a server, cluster, notebook host, or cloud instance.

This cheat sheet is oriented toward practical daily use: getting in, staying in, moving files, and reaching services that are not directly exposed.

Quick Reference¶

Task	Common command
Connect	`ssh user@host`
With identity file	`ssh -i ~/.ssh/id_ed25519 user@host`
Run a remote command	`ssh user@host 'cmd'`
Copy files	`scp` or `sftp`
Copy a directory	`scp -r`
Forward local port	`ssh -L local:remote user@host`
Forward remote port	`ssh -R remote:local user@host`
Jump host	`ssh -J jump user@target`
SSH config	`~/.ssh/config`
Start agent	`eval "$(ssh-agent -s)"`
Add key	`ssh-add ~/.ssh/id_ed25519`

The Basics¶

A typical login:

ssh alice@192.168.1.10

or with a domain:

ssh alice@example.com

If the username is the same as your local one, you can often omit it.

First connection¶

The first time you connect to a host, SSH asks you to confirm the host key. That prompt is about verifying you are talking to the intended server, not just authenticating yourself.

If the host key changes unexpectedly later, SSH will warn you. That warning is worth paying attention to.

Keys¶

Key-based authentication is usually more convenient and more secure than passwords for regular remote work.

Generate a key¶

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

You can accept the default file location or choose another. A passphrase is recommended for interactive keys.

Copy the public key to the server¶

ssh-copy-id alice@host

If ssh-copy-id is not available, you can manually append the public key to ~/.ssh/authorized_keys on the server.

Common key types¶

ed25519 is widely used for modern client authentication.
rsa keys still work in many environments, though larger key sizes are preferred when RSA is used.

For most everyday use, a modern ed25519 key is a solid default.

Key permissions¶

SSH is picky about permissions.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys

Loose permissions can cause the server to reject a key or config.

SSH Config File¶

The config file makes repetitive connections easier.

~/.ssh/config:

Host lab
    HostName 198.51.100.10
    User alice
    IdentityFile ~/.ssh/id_ed25519
    Port 22

Host gpu1
    HostName 203.0.113.5
    User alice
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent no

Host internal-app
    HostName 10.0.0.5
    User deploy
    ProxyJump lab

Now you can run:

ssh lab
ssh gpu1
ssh internal-app

This is especially useful when you connect to many hosts or use non-default ports and keys.

Running Remote Commands¶

You do not always need an interactive session.

ssh alice@host 'python --version'
ssh alice@host 'ls -la /home/alice/projects'
ssh alice@host 'df -h'

Useful for quick checks, scripted tasks, and remote execution from a local workflow.

For multiline commands, quoting matters:

ssh alice@host 'bash -s' < local_script.sh

or:

ssh alice@host '
python -c "
import torch; print(torch.cuda.is_available())
"
'

Pick the style that keeps the quoting readable.

File Transfer¶

scp¶

scp model.pt alice@host:/home/alice/models/
scp alice@host:/var/log/syslog ./syslog.log
scp -r alice@host:/data/projects ./projects

scp is simple and familiar. It is good for ad-hoc transfers.

sftp¶

sftp alice@host

Then interactive commands like get, put, ls, cd, mkdir.

rsync over SSH¶

For larger or repeated syncs, rsync over SSH is often better:

rsync -avz -e ssh ./data alice@host:/data

It can resume transfers, skip unchanged files, and be more efficient for directories.

Port Forwarding¶

SSH can tunnel TCP traffic. This is one of its most useful features for AI/ML work, because many services are not meant to be exposed publicly.

Local forwarding¶

ssh -L 8888:localhost:8888 alice@host

This forwards your local port 8888 to port 8888 on the remote side. Common for reaching a remote notebook or web UI through an encrypted tunnel.

Remote forwarding¶

ssh -R 9000:localhost:9000 alice@host

This exposes a local port through the remote side. Useful when the remote side needs to reach something on your machine.

Dynamic forwarding¶

ssh -D 1080 alice@host

This creates a SOCKS proxy through the SSH connection. It is useful when you need flexible outbound browsing or proxying through a host, though it requires client support for SOCKS.

Jump Hosts¶

A jump host is an intermediate machine used to reach another host.

Modern syntax:

ssh -J jump_host target_host

Or in config:

Host target
    HostName 10.0.0.5
    User alice
    ProxyJump lab

This keeps access paths clearer than older ssh -W or manual chaining approaches.

Agent Forwarding¶

Agent forwarding lets a remote host use your local SSH keys without copying them there.

ssh -A alice@host

In config:

ForwardAgent yes

Use it carefully. Agent forwarding is convenient, but it also means the remote host can use your agent while the session is active. Only enable it where you trust the host and the session.

If you use agent forwarding often, start an agent and add keys once:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Session Multiplexing¶

SSH can reuse connections, which can make repeated commands to the same host faster and lighter.

In config:

Host lab
    HostName 198.51.100.10
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m

This is helpful when you run many short commands or scripts against the same host.

Tmux and Screen over SSH¶

For long-running work, combining SSH with a terminal session manager is common.

Why: - If the SSH connection drops, the session keeps running. - You can detach and reattach later. - You can run long training jobs or installs without keeping your laptop awake for the whole thing in the same terminal.

Example workflow: 1. SSH into the remote host. 2. Start tmux or screen. 3. Run the long job. 4. Detach and reconnect later.

This is not an SSH feature per se, but it is a very common SSH workflow.

Common SSH Problems¶

Symptom	Likely cause
Connection refused	SSH not running, wrong port, firewall, wrong host
Permission denied	wrong key, bad permissions, wrong user, server config
Host key changed warning	server rebuilt, key rotated, or possible MITM
Slow login	DNS, authentication method negotiation, network
Unprotected key rejected	file permissions too open
Agent not available remotely	agent forwarding not enabled or agent not running

When something fails, check: - Host and port - User - Key and permissions - Server-side SSH config and logs - Network/firewall rules - Whether the host is reachable at all

Debugging¶

ssh -v user@host
ssh -vv user@host

Verbose output shows the negotiation, key offer, and authentication steps. It is often the fastest way to understand why a login is failing.

Security Habits¶

Prefer keys over password authentication where practical.
Use passphrases for interactive keys.
Keep private keys private and permissions tight.
Do not copy secret keys onto machines you do not trust.
Use host verification and pay attention to host key warnings.
Remove old keys from authorized_keys when they are no longer needed.
Prefer specific SSH config entries over copying commands with many flags.
Avoid exposing SSH broadly if it does not need to be.
Do not forward agents casually.

Common Mistakes¶

Using chmod 777 on .ssh or key files.
Copying secret keys to shared or temporary machines "just for a minute."
Forgetting to set the right user or identity file.
Ignoring host key warnings because they are annoying.
Leaving agent forwarding on everywhere.
Assuming scp is always the best transfer tool for large syncs.
Using SSH without reading the remote host's SSH banner or policies when they matter.
Hardcoding passwords in scripts instead of using keys or managed access.

SSH in Data/ML Workflows¶

SSH shows up in many practical places: - Reaching a remote training machine - Tunneling to a remote notebook or dashboard - Moving datasets and model artifacts - Running one-off remote commands or scripts - Accessing services behind a gateway or jump host - Managing cloud instances or on-prem servers

A common pattern is: 1. SSH into the host. 2. Sync data or code. 3. Run the job in a persistent session. 4. Use port forwarding if you need a local view of a remote service. 5. Copy results back.

linux-commands — the everyday command line you may use after SSH-ing in
curl — testing remote services exposed through SSH tunnels
make — wrapping SSH-based deploy or sync commands
linux-security — SSH hardening from the server side
cybersecurity-fundamentals — the broader security mindset around remote access

Official Documentation¶

man ssh, man ssh_config, man ssh-keygen
man scp, man sftp, man rsync
Your server or platform docs for SSH access, key setup, and allowed authentication methods

SSH is small in concept and large in practical use. The core habits are: use keys, keep permissions tight, reach services through tunnels when needed, and pay attention when the host or authentication behaves differently than expected.

Last Updated¶

2026-09-06 — Initial version.