SSH Explained...

SSH stands for Secure Shell, a network protocol that allows someone to securely connect to and communicate with a remote machine over an unsecured network. Before SSH existed, tools like Telnet existed, but anyone could snoop the network and SSH fixed that by encripting the entire session.

The main parts of SSH

1. Transport Layer — Handles the initial connection, server authentication, and encryption setup. This is where the client confirms it's talking to the right server and both sides agree on an encryption algorithm to protect everything that follows.
2. Authentication Layer — Confirms who is connecting. This is where passwords or, more commonly, key pairs come in.
3. Connection Layer — Once you're authenticated, this layer manages the actual session: running commands, forwarding ports, transferring files, all multiplexed over the single encrypted connection.

How SSH authentication works

The most common and most secure way to authenticate with SSH is public key authentication, and it's worth understanding the flow rather than just trusting it works:

1. You generate a key pair on your machine (ssh-keygen). This produces two files: a private key and a public key.
2. You give the public key to the server or service you want to access — for example, pasting it into GitHub's SSH key settings, or appending it to ~/.ssh/authorized_keys on a remote server.
3. When you connect, the server sends a cryptographic challenge that can only be answered correctly by whoever holds the matching private key.
4. Your SSH client uses your private key to respond to that challenge — without ever sending the private key itself over the network.
5. If the response checks out, the server knows you hold the private key, and grants access.

This is the important part: your private key never leaves your machine, even during authentication. That's fundamentally different from a password, which has to be transmitted (even if encrypted) for the server to check it.

You can also authenticate with a password over SSH, but key-based authentication is standard practice because it's far more resistant to brute-force attacks and doesn't rely on you (or a service) remembering and protecting a secret string.

SSH vs HTTPS

HTTPS is the protocol most people are already familiar with from browsing the web. When used with Git, it authenticates you with a username and a password or personal access token, sent over an encrypted HTTPS connection.

SSH, as covered above, authenticates you with a key pair instead of a password or token.

Neither is objectively "more secure" in a blanket sense — both are strong when configured correctly. The real difference is convenience and threat model. SSH avoids ever transmitting a reusable secret and skips repeated prompts, which is why most developers set it up once and forget about it. HTTPS is faster to get started with and works everywhere, including networks or environments where SSH's port is blocked.