SSH-Fu

Intro

SSH isn’t just about logging in remotely — once you’ve got keys, configs, and an agent in place, it opens the door to a whole arsenal of powerful tricks.

You can run commands remotely, mount filesystems, tunnel services, and even bend network paths to your will.

Commander Data from Star Trek in front of a display with the caption: 'It is complicated' — SSH can be mind-bending at times — but only because it’s incredibly powerful
Image © Paramount / CBS

This guide is about the fun stuff — the SSH-Fu that turns everyday tasks into smooth one-liners and clever shortcuts. Nothing arcane, just the practical tricks that make life as an admin easier (and maybe a little cooler).

We’ll cover:

Running commands and scripts over SSH.
Multiplexing and jump hosts.
Local, remote, and dynamic tunnels.
SSHFS mounts and fstab auto-mounts.
File transfers and syncs.
Debugging connections like a pro.

Think of this as an “advanced field manual” — fast, useful, and battle-tested.

If you need help setting up SSH you might want to take a look at my companion post:

SSH Setup Guide

Running Commands Over SSH (and Handling Quotes)

Sometimes you don’t need a full shell — you just want to run one command remotely.
This is one of the most useful (and often confusing) SSH tricks, especially with quoting.

The Basics

ssh new-server 'uptime'

Opens a connection, runs uptime, then exits.
Anything in quotes is executed on the remote host.

With Arguments

ssh new-server 'ls -lah /var/log'

Notice the single quotes — they make sure the remote shell interprets the flags, not your local one.

Mixing Local and Remote Expansion

Good: let remote expand:
```
ssh new-server 'echo $HOME'
```
→ prints the remote user’s home directory.
Bad: if you forget quotes:
```
ssh new-server echo $HOME
```
→ expands $HOME locally, and passes the value to the remote.

Escaping Quotes

If your command needs quotes inside it, escape them:

ssh new-server "echo 'Hello from $(hostname)'"

Outer " let you put ' inside safely.
$(hostname) is expanded on the remote host.

Running a Script Inline

You can pipe a local script to run on the remote side:

cat script.sh | ssh new-server 'bash -s -- arg1 arg2'

bash -s -- tells the remote bash to read from stdin.
arg1 arg2 are passed as $1 $2 to the script.

Copy-and-Run (one-liner deployments)

ssh new-server 'mkdir -p ~/deploy && tar xzf - -C ~/deploy' < site.tar.gz

< site.tar.gz feeds your local tarball into the remote tar command.
Great for quick deployments without scp/rsync.

Pro Tip: Debug Your Quoting

If something looks wrong, echo the command string first:

ssh new-server 'echo "Hello, world"'

Or crank up verbosity:

ssh -v new-server 'echo "debugging quotes"'

Bottom line:

Wrap remote commands in quotes.
Single quotes ' ' prevent local expansion.
Double quotes " " allow mixing variables carefully.
If in doubt, escape inner quotes or just write a quick script and pipe it over.

SSHFS: Mount Remote Files Like They’re Local

Sometimes you don’t want to scp files back and forth — you just want to work in place as if the remote filesystem were part of your machine.
That’s what SSHFS (SSH Filesystem) gives you: a way to mount a remote directory over SSH.

Mount a Remote Directory

sshfs forfaxx@new-server.darkstar.home:/var/www ~/mnt/www

Now ~/mnt/www on your machine shows the contents of /var/www on new-server.
You can ls, cd, vim, or even use GUI apps on those files like they were local.

Unmount It

fusermount -u ~/mnt/www      # Linux
umount ~/mnt/www             # macOS / BSD

Why Use It?

Edit remote config files with your local editor.
Drag-and-drop files in your GUI file manager.
Script against a remote directory without copying.

Performance Notes

It’s built on FUSE, so performance depends on network latency.
Great for light editing, browsing logs, or quick fixes.
Not ideal for heavy I/O workloads (databases, compiles, large builds).

Auto-Mount with `/etc/fstab`

You can make an SSHFS mount persistent by adding an entry in /etc/fstab.
This way it mounts automatically at boot (or on demand with mount).

Example line:

forfaxx@new-server.darkstar.home:/var/www  /mnt/www  fuse.sshfs  defaults,_netdev,IdentityFile=/home/forfaxx/.ssh/id_ed25519,allow_other,uid=1000,gid=1000  0  0

Breakdown:

forfaxx@new-server.darkstar.home:/var/www → remote path.
/mnt/www → local mount point (must exist).
fuse.sshfs → tells fstab to use SSHFS via FUSE.
defaults,_netdev → wait for network before mounting.
IdentityFile=… → path to your private key.
allow_other → let other local users access it (optional).
uid=1000,gid=1000 → map ownership to your local user/group.

Mount/Unmount

After adding it, you can run:

sudo mount /mnt/www
sudo umount /mnt/www

Pro-Tip: test the sshfs command manually first to confirm it works before editing /etc/fstab. A typo there can slow down boot.

Pro-Tip: Combine sshfs with your ~/.ssh/config shortcuts, and you can mount complex paths with one short command.

SSH Tips & Tricks

Once the basics are set — keys, config, agent — you can unlock a bunch of quality-of-life and power-user moves. These are the ones worth knowing.

Multiplexing: Instant SSH

Instead of re-negotiating crypto every time, reuse a single connection.

In ~/.ssh/config:

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

Now:

ssh new-server        # open one shell
scp file new-server:/tmp/   # reuses same connection, no delay

Pro-Tip: If you hit “path too long for UNIX socket,” use %C (a hash of the host/port) instead:



---
### Jump Hosts: Hop Cleanly  

Sometimes the machine you need isn’t directly reachable — it sits on a private subnet — but there’s a “middleman” you *can* reach, often called a **bastion host**. Instead of logging into the bastion and then hopping again manually, `ProxyJump` lets SSH handle it in one clean step.  

It feels a little cinematic — like Elliot in *Mr. Robot* or “Zero Cool” in *Hackers*, bouncing through a box to slip deeper into the network. It’s not an everyday trick, but worth keeping in your back pocket for those tricky environments.  

```bash
ssh -J bastion new-server

Config version:

Host new-server
  HostName new-server.darkstar.home
  User forfaxx
  ProxyJump bastion

And yes, you can chain multiple hops if you are so inclined:

ssh -J bastion1,bastion2 target

Local & Remote Port Forwards

I have used SSH tunnels many times and it still hurts my brain a little.

Think of an SSH tunnel as a teleport pad for TCP: you open a port on one side, step in locally, and come out on the other side.
The confusing part is remembering which side you step into.
Rule of thumb: you always connect to the side you wrote first.

Local forward (-L) — step in here, come out there

ssh -L 8443:127.0.0.1:443 new-server

You connect to localhost:8443 on your machine.
SSH carries it to 127.0.0.1:443 on new-server.
Example: open https://localhost:8443 in your browser → you’re really talking to new-server’s HTTPS service.

Remote forward (-R) — step in there, come out here

ssh -R 9000:127.0.0.1:3000 new-server

On new-server, connect to localhost:9000.
SSH carries it back to 127.0.0.1:3000 on your machine.
Example: from new-server, curl http://127.0.0.1:9000 → hits your app running locally on port 3000.

Why use this?

Because sometimes the door you need is locked:

A service only listens on loopback.
A firewall blocks it.
You want traffic encrypted over SSH.

Port forwarding is your keyhole.

SOCKS Proxy: Poor Man’s VPN

ssh -D 1080 new-server

Then point your browser’s SOCKS proxy to localhost:1080.

Pro-Tip: Pair ssh -D with Firefox’s “Proxy DNS when using SOCKS v5” setting to tunnel DNS lookups too.

File Transfers Over SSH

Copying files is one of the most common SSH tasks. Here are the main tools and when to reach for them:

# Copy local → remote (quick & dirty)
scp -r ./site new-server:~/deploy/

# Copy remote → local
scp new-server:/var/log/nginx/error.log ./error.log

# Efficient sync (resume, skip unchanged files)
rsync -avz --progress -e ssh ./public/ new-server:~/www/public/

scp → simple, built-in, works everywhere. Great for one-offs.
rsync → faster for large trees, resumes interrupted transfers, only sends differences.

Pro-Tip: This feels like a cheat-code but with the -3 switch, you can copy files between two remote machines using yours as a sort of traffic cop to facilitate, all without logging in anywhere.

# Copy from hostA → hostB via your local machine
scp -3 user@hostA:/var/log/syslog user@hostB:/tmp/syslog

Data flows through your client (not directly host-to-host).
Still encrypted end-to-end (since both legs use SSH).
Useful when hosts can’t talk to each other directly, but you can reach both.

Note: This moves files via your local bandwidth. If the file is huge, your network is the bottleneck. But for config snippets, logs, or small dumps, it’s insanely handy.

Using `sftp` (interactive or scripted)

For more controlled transfers, SSH comes with sftp:

sftp new-server
sftp> put site.tar.gz /tmp/
sftp> get /var/log/nginx/access.log ./access.log
sftp> exit

Looks/feels like FTP, but runs over SSH.
Supports tab completion, ls, cd, and pwd.
Batch mode makes it scriptable:

sftp -b - new-server <<'EOF'
put site.tar.gz /tmp/
get /var/log/nginx/error.log ./error.log
EOF

Pro-Tip: For recurring jobs, use rsync or scripted sftp — they’re more efficient and reliable than scp, which OpenSSH now treats as legacy.

Quick Host Hygiene

# Check fingerprint of a key
ssh-keygen -lf ~/.ssh/id_ed25519.pub

# Derive pubkey from private key
ssh-keygen -y -f ~/.ssh/id_ed25519

# Remove stale known_hosts entry
ssh-keygen -R new-server.darkstar.home

Debug Like a Pro

ssh -v new-server

or crank it up:

ssh -vvv new-server

Tells you exactly why a connection/auth is failing.

Using `-t` to Run Remote Programs Like They’re Local

Normally when you use ssh user@host 'command', SSH treats it like a non-interactive one-shot. That works great for ls or uptime, but it falls apart if the program expects a terminal — like vim, top, or htop.

That’s where the -t flag comes in: it forces SSH to allocate a pseudo-TTY so the remote program thinks it’s running in a real terminal. Suddenly, you can run interactive apps on the remote side as if they were local.

# Edit a config file remotely
ssh -t new-server 'vim /etc/nginx/nginx.conf'

# Run interactive process monitors
ssh -t new-server htop
ssh -t new-server 'sudo journalctl -f'

If you need to hop through sudo or other programs that strip the TTY, you can double up:

ssh -tt new-server 'sudo vim /etc/hosts'

It’s a tiny switch, but it unlocks a ton of everyday tricks. No more half-baked redirections — just straight into your remote Vim, top, or less session like you’re sitting at the machine.

Pro-Tip: Combine -t with ProxyJump or multiplexing and you can pop open an editor on a deep-in-the-network host in a single smooth one-liner.

Using SSH in Scripts (Safe, Non-Interactive Patterns)

Once your logins are safe and seamless (keys + agent), SSH becomes a rock-solid automation primitive. A few rules I’ve found to make it reliable in scripts:

Never prompt: force non-interactive behavior.
Pin host keys: avoid TOFU surprises in CI.
Propagate failures: treat remote errors as errors.

Recommended flags

-o BatchMode=yes → fail immediately if auth would prompt.
-o StrictHostKeyChecking=yes → refuse unknown/changed hosts.
-o ConnectTimeout=5 → don’t hang forever.
(Optional CI) -o UserKnownHostsFile=/path/known_hosts → use a pinned file.

One-liner pattern

ssh -o BatchMode=yes -o StrictHostKeyChecking=yes new-server 'sudo systemctl restart nginx'

Multi-line remote script (here-doc)

ssh -o BatchMode=yes new-server 'bash -s' <<'REMOTE'
set -euo pipefail
echo "Deploying…"
mkdir -p ~/app
tar xzf - -C ~/app
systemctl --user restart app.service
REMOTE
# (feed tar on stdin if needed: tar czf - . | ssh … 'bash -s')

Copy-and-run (fast “deploy without scp”)

tar czf - . | ssh -o BatchMode=yes new-server 'mkdir -p ~/deploy && tar xzf - -C ~/deploy && ~/deploy/install.sh'

iperfer: One-Command iperf3 test over SSH

A concrete example of the copy-and-run pattern is my tool iperfer: it uses SSH to spin up an iperf3 server remotely, runs the client locally, then tears everything down in one go.

🚀 iperfer: one-command iperf3 over SSH

Conclusion

SSH is more than ssh user@host. With a few well-placed tricks, you’ll connect faster, hop cleanly through networks, tunnel like a pro, and stop tripping over key headaches.

Got a sweet SSH tip, trick, or hack to share?
I’d love to hear it: feedback@adminjitsu.com

SSH Setup Guide

Intro#

Running Commands Over SSH (and Handling Quotes)#

The Basics#

With Arguments#

Mixing Local and Remote Expansion#

Escaping Quotes#

Running a Script Inline#

Copy-and-Run (one-liner deployments)#

Pro Tip: Debug Your Quoting#

SSHFS: Mount Remote Files Like They’re Local#

Mount a Remote Directory#

Unmount It#

Why Use It?#

Performance Notes#

Auto-Mount with /etc/fstab#

Mount/Unmount#

SSH Tips & Tricks#

Multiplexing: Instant SSH#

Local & Remote Port Forwards#

SOCKS Proxy: Poor Man’s VPN#

File Transfers Over SSH#

Using sftp (interactive or scripted)#

Quick Host Hygiene#

Debug Like a Pro#

Using -t to Run Remote Programs Like They’re Local#

Using SSH in Scripts (Safe, Non-Interactive Patterns)#

Recommended flags#

One-liner pattern#

Multi-line remote script (here-doc)#

Copy-and-run (fast “deploy without scp”)#

iperfer: One-Command iperf3 test over SSH#

Conclusion#