Advanced SSH — Key Management, Tunneling, and Config File for Secure Servers

You have five servers to manage, each with a different IP, user, password. Every connection wastes time, risks credential errors, or worse: you still use passwords. At Meteora Web, we see this every day from clients who come to us with servers still accessible via password or SSH keys without a passphrase. It's a huge risk. With a little configuration, you can make SSH access fast, secure, and nearly automatic. Let's dive in.

How to manage SSH keys for secure and passwordless access?

The foundation of secure SSH is asymmetric key pairs. You generate a private key (kept safe) and a public key (placed on servers). No more plain-text passwords, no brute-force against the login.

Generate a strong key pair

Use the Ed25519 algorithm, faster and more secure than RSA 4096. The command is straightforward:

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519

You will be prompted for a passphrase. Do not leave it empty. The passphrase protects the private key if someone steals your computer. Without it, anyone with file access can connect to your servers.

Copy the public key to the server

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

If the server lacks ssh-copy-id, do it manually: append the content of id_ed25519.pub to ~/.ssh/authorized_keys on the server.

Use the SSH agent to avoid typing the passphrase every time

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

Subsequent connections won't require the passphrase for the current terminal session. On macOS the agent starts automatically; on Linux, add those commands to your .bashrc or .zshrc.

Disable password authentication on the server

After testing the keys, edit /etc/ssh/sshd_config on the server:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Restart SSH: sudo systemctl restart sshd. Now the only way in is with a key. Common mistake: disabling passwords before testing the key. Do it only after you have successfully connected with the key.

How to configure SSH tunneling to bypass firewalls and protect data?

Imagine a PostgreSQL database on a server that listens only on localhost. You don't want to expose it to the Internet. With SSH tunneling, you can forward a local port to that remote port and connect as if it were on your machine.

Local port forwarding

ssh -L 5432:localhost:5432 user@server

Now localhost:5432 on your machine points to port 5432 on the server. Run psql -h localhost and you're in. No port exposure, everything encrypted.

Remote port forwarding

Useful to expose a local service on a remote server, e.g., for external testing:

ssh -R 8080:localhost:80 user@server

Now anyone connecting to server:8080 is redirected to your local machine on port 80.

Dynamic port forwarding (SOCKS proxy)

ssh -D 1080 user@server

Configure your browser to use localhost:1080 as a SOCKS5 proxy. All traffic goes through the remote server, encrypted. Perfect for browsing from a public network or accessing internal resources.

Stabilize the tunnel with options

ssh -f -N -L 5432:localhost:5432 user@server

-f goes to background, -N does not execute commands, only port forwarding. For persistent tunnels, consider autossh which reconnects if the tunnel drops.

How to optimize the SSH config file for fast connections and multi-server management?

The ~/.ssh/config file saves you from typing IP, user, port, and key every time. You can define aliases for each server and global options.

Host webserver
    HostName 192.168.1.100
    User deploy
    Port 2222
    IdentityFile ~/.ssh/webserver_key
    ServerAliveInterval 60

Host database
    HostName db.internal
    User admin
    LocalForward 3306 localhost:3306

Host *
    ServerAliveInterval 30
    AddKeysToAgent yes
    ControlMaster auto
    ControlPath ~/.ssh/controlmaster/%r@%h:%p
    ControlPersist 4h

Now you just run ssh webserver. ControlMaster and ControlPersist reuse a connection for multiple sessions, reducing handshake time. Create the directory ~/.ssh/controlmaster/: mkdir -p ~/.ssh/controlmaster.

Host autocompletion

With the config, your shell can complete host names. On Bash, add:

complete -W "$(grep -i '^Host ' ~/.ssh/config | cut -d' ' -f2)" ssh

What to do next

Generate a new Ed25519 key pair with a strong passphrase.
Copy it to your servers and disable password access after verifying the key works.
Set up the SSH agent to load your key at shell startup.
Create a ~/.ssh/config file with aliases for each server, enabling ControlMaster for faster connections.
Try local tunneling for a sensitive service (database, admin panel) instead of exposing it to the Internet.

At Meteora Web, we apply these practices on every server we manage for our clients, from small WordPress sites to multi-server infrastructures. Don't leave your servers at the mercy of weak passwords or slow connections. If you want to automate these configurations with Ansible, check out our comprehensive Linux automation guide.