SSH Basics for Developers

If you've ever pushed to GitHub, deployed to a VPS, or jumped onto a production box to read a log, you've used SSH. It's the protocol that replaced telnet and rlogin in the late 90s and has been the default way developers reach remote machines ever since.

This post covers what you actually need in 2026: generating an ed25519 key pair, disabling password authentication on the server, using ~/.ssh/config and ProxyJump so you stop typing long commands, and the handful of sshd_config settings that matter for security. Nothing fancy — just the workflow most senior engineers settle into and then forget to write down.

What is SSH?

SSH (Secure Shell) is a protocol for running a shell — and tunneling arbitrary TCP traffic — over an authenticated, encrypted channel. It runs on TCP port 22 by default and is specified in RFCs 4250-4254.

Under the hood it uses three primitives:

• Asymmetric crypto during the handshake to authenticate the server and the user. In modern OpenSSH that's typically Ed25519 (Curve25519) or ECDSA; RSA still works but is no longer the default.
• Symmetric crypto for the bulk session traffic, usually chacha20-poly1305@openssh.com or AES-GCM. The session key is derived from an ECDH key exchange.
• MACs / AEAD to detect tampering — most modern ciphers (chacha20-poly1305, AES-GCM) bundle this in.

You rarely have to think about any of this. OpenSSH picks sane defaults; you just need to keep your client and server reasonably current.

How Does SSH Work?

Here's a simple breakdown of what happens when you use SSH to connect to another computer:

• Your SSH program reaches out to the server on the other side.
• The server shows its ID to prove it's the one you're expecting to talk to.
• Both sides agree on a secret handshake to lock their conversation.
• You prove who you are, maybe with a password or a special key.
• Once the server knows you're you, it lets you in, and your secure chat can start.
• Everything you type or send is locked up before it goes through the internet, and only the server can unlock it.

SSH Encryption Techniques

We talked about the secret codes SSH uses, but let’s make it simpler:

• Symmetric encryption is like a secret handshake. It's fast and locks everything after you've said hello.
• Asymmetric encryption involves sending a locked box that only the receiver can open with their unique key. This helps make sure the server you're connecting to is the right one.
• Hashing is like sending your message with a unique seal. If the seal is broken, you know someone messed with your message.

Together, these methods keep your remote chats safe from eavesdroppers, making sure no one can sneak a peek or mess with your data.

Setting Up SSH

Generating SSH Key Pairs

Use Ed25519. In 2026 there's no good reason to generate a new RSA key for SSH — Ed25519 keys are 256 bits, much shorter to paste around, faster to verify, and resistant to the side-channel weaknesses that have plagued RSA implementations. The only time you should reach for RSA is when you're forced to interoperate with an ancient OpenSSH server (pre-6.5) that doesn't speak Ed25519.

ssh-keygen -t ed25519 -C "you@hostname"

A few notes on what that does:

• It writes ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public). Accept the default path unless you're juggling multiple identities.
• It prompts for a passphrase. Set one. A passphrase-less key on disk is a credential anyone who gets your laptop can use; with a passphrase, an attacker also needs to crack the KDF.
• Permissions matter: the private key must be 600 and ~/.ssh must be 700, or OpenSSH will refuse to use it.

Load the key into ssh-agent once per session so you're not retyping the passphrase:

ssh-add ~/.ssh/id_ed25519

Then copy the public half to a server with ssh-copy-id user@host, which appends it to ~/.ssh/authorized_keys with the right permissions.

SSH Authentication Methods

OpenSSH supports passwords, public keys, host-based auth, GSSAPI/Kerberos, and keyboard-interactive (used for 2FA prompts). For day-to-day developer work, only two of those matter — and you should be using one of them.

Don't use password authentication. It's still on by default on many cloud images, and within hours of booting a public-IP host you'll see thousands of brute-force attempts in /var/log/auth.log. Set PasswordAuthentication no in /etc/ssh/sshd_config and reload sshd. Once you've confirmed key-based login works, there's no upside to leaving passwords enabled.

Use public key authentication, ideally fronted by ssh-agent. The server holds your public key in ~/.ssh/authorized_keys; the client proves possession of the matching private key during the handshake. The private key never crosses the wire. Combine this with a passphrase on the key and an agent that caches the unlocked key for your session, and you get the convenience of a password-less login without leaving an unprotected credential on disk.

SSH Usage and Applications

Essential SSH Commands

SSH lets you control another computer from far away as if you were right there. Here are some easy-to-use SSH commands that help you do a lot of things:

• ls - Shows you what files and folders are there
• cd - Lets you move to a different folder
• mkdir - Creates a new folder
• rm - Removes files or folders
• cat - Shows what's inside a file
• vim/nano - Lets you edit files
• top - Shows what your computer is busy with
• df - Tells you how much space is left on your computer
• du - Shows how much space a folder takes
• ping/traceroute - Helps figure out network issues

These commands are the basics for moving around and working on servers from anywhere using SSH.

Customizing SSH Configuration

You can change settings for both the SSH server (the computer you're connecting to) and the SSH client (your computer). Here's what you can tweak:

Server-Side

• Port - Use a different door (port) instead of the usual one (22)
• PermitRootLogin - Decide if the main user (root) can log in
• PasswordAuthentication - Choose if passwords are allowed
• AllowUsers - Pick which users can access

Client-Side

• Host - Create shortcuts for servers
• User - Set a default username
• Compression - Make data smaller so it sends faster
• ForwardAgent - Carry your SSH keys with you when connecting

Adjusting these settings can make your connection safer and easier to use, especially for things like setting up SSH tunnels.

SSH for Developers

Developers use SSH for important tasks all the time:

• Remote work - SSH lets you work on code or use tools on a server as if you were right there.
• Deployment - You can use SSH to send commands that set up your apps on servers.
• Port forwarding - SSH can make a private path so you can reach databases or interfaces on the server.
• Automation - SSH keys help your computer log in without needing a password, great for automatic tasks.

For coding from home or automating your work, SSH is a key tool for safe and easy remote access.

Security Best Practices

Hardening SSH Security

A reasonable baseline for /etc/ssh/sshd_config on a server you actually care about:

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes
KbdInteractiveAuthentication no
AllowUsers deploy alice
MaxAuthTries 3
LoginGraceTime 20
X11Forwarding no

Reload with sudo systemctl reload ssh (or sshd). A few things worth saying plainly:

• Don't change the port. Moving sshd to port 2222 doesn't make you safer — anyone scanning for SSH will find it in seconds. It just makes your own tooling more annoying. Spend the energy on key-only auth instead.
• Reach internal hosts via ProxyJump, not nested ssh commands. Put ProxyJump bastion.example.com in your ~/.ssh/config block for the internal host. The agent handles auth at each hop; you don't have to forward it, which is the safer default.
• Avoid ForwardAgent yes on hosts you don't fully trust. It exposes your local agent socket to anyone with root on the remote machine. Use ProxyJump for multi-hop access and reserve agent forwarding for the rare case you genuinely need it.
• Install fail2ban or rely on your cloud provider's network ACLs to drop repeated failed connections. With password auth disabled this is mostly noise reduction, but the logs get unreadable without it.
• Keep OpenSSH current. The protocol is stable, but specific cipher suites and key types get deprecated — for example, OpenSSH 8.8 disabled ssh-rsa with SHA-1 by default. Running an old client against a new server (or vice versa) is the most common source of mysterious "no matching host key type" errors.

Troubleshooting Common SSH Issues

Running into trouble? Here are some quick fixes:

• Can't connect - Check if your firewall is blocking the connection, if the SSH service is running, if you're using the right SSH port, and if your account is set up correctly. Make sure your SSH key or password works.
• Connection times out - This might be because of network problems, the SSH server being too slow, or a setup issue with how data is sent to and from your computer.
• Permission denied - Make sure your SSH keys are set up right (private key should be 400, public key should be 644). Check if you have the right permissions to log in.
• Command not found - You might have made a typo, or there could be a problem with where your computer looks for programs. Double-check for mistakes and your system's settings.
• Text formatting issues - If text looks weird, it might be because of the server's language and text settings. You can fix this by adjusting the locale settings.

If you're still stuck, try testing your SSH connection with a different account or on another computer to see if the problem is with your setup.

Conclusion

Most developers learn SSH by copy-pasting one ssh-keygen command in a tutorial and never revisiting it. The result is a ~/.ssh folder full of old RSA keys, password auth still enabled on a side-project server somewhere, and three terminal tabs open because nobody set up ProxyJump.

The upgrade path is small: generate an Ed25519 key, put it behind a passphrase and ssh-agent, turn off password auth on every server you control, and write a ~/.ssh/config block for the hosts you touch weekly. That's roughly an afternoon of work and it's the version of SSH you'll keep using for the next decade.

Related Blog Posts

• Setup Node.js Express Project: A Beginner's Guide
• Execute Code Online: Best Practices
• CLI Basics for Developers
• Apache Basics for Beginners