In Git, how do https:// and ssh:// remote URLs differ in how they authenticate?

## The transports Git speaks A remote URL's scheme selects a transport, and each transport has its own authentication story. **HTTPS** — `https://host/org/repo.git`. Git makes HTTP requests to the server's Git endpoints over TLS. TLS authenticates the *server* and encrypts the channel; the *client* proves who it is with an HTTP credential, conventionally a username plus a secret. Most hosts have stopped accepting an account password here and expect a personal access token instead — a separately issued secret with its own permissions and expiry, revocable without changing your login. **SSH** — `ssh://git@host/org/repo.git`, or the older scp-like shorthand `git@host:org/repo.git` (note the colon, and that it takes no port; use the full `ssh://` form when you need `-p`-style port selection). Git does not implement SSH itself; it executes the system `ssh` binary, which performs public-key authentication using a key from `~/.ssh` or from a running `ssh-agent`. Once authenticated, the client asks the server to run `git-upload-pack` (for fetch) or `git-receive-pack` (for push), and the Git protocol flows over that channel. **git://** — the daemon protocol on port 9418. It has no authentication and no encryption. It exists for fast anonymous public mirrors and is unsuitable for anything private. **file://** and a plain local path also work, useful for local mirrors and tests. ## Where the secret lives in each case For SSH, the secret is a private key file on disk, usually protected by a passphrase and unlocked once into `ssh-agent`. Git itself never sees it. You can point Git at a specific key or ssh invocation with `core.sshCommand` or the `GIT_SSH_COMMAND` environment variable — useful when one machine must use different identities for different hosts. For HTTPS, the secret reaches Git through the credential-helper mechanism (`credential.helper`), which may store it in an OS keychain, in memory for a while, or in a plaintext file. Without a helper Git prompts on the terminal every time. ## Practical differences that decide the choice - **Firewalls and proxies.** HTTPS uses port 443 and passes through corporate proxies that block port 22. This is often the deciding factor. - **Container and CI ergonomics.** HTTPS needs one secret in an environment variable and a helper or askpass hook. SSH needs a key file with correct permissions, a known-hosts entry, and usually an agent — more moving parts inside a minimal image. - **Host verification.** SSH verifies the server by its host key against `known_hosts`; a first connection to an unknown host either prompts or, in a non-interactive job, fails. HTTPS verifies the server via the TLS certificate chain, which needs no per-user setup. - **Rotation.** Tokens usually carry an expiry and can be scoped narrowly; SSH keys typically live until someone removes them. ## Mixing them A repository can have several remotes with different transports, and `url.<base>.insteadOf` can rewrite one form into the other globally — handy when a `.gitmodules` file hardcodes SSH URLs but a CI job only has an HTTPS token. `git remote -v` shows what each remote currently uses, and `git remote set-url origin <new>` switches it.