Guide PHP & Development

How to set up SSH keys for your hosting

Generate a key pair, add the public half to your hosting account, and connect over SSH without a password from then on.

Updated 6 min read Beginner

SSH keys let you connect to your hosting account without typing a password every time, and they are also more secure than a password on its own — a key pair cannot be guessed or brute-forced the way a password can. Deployment tools such as Git and rsync, and Composer running over SSH, all rely on the same key-based connection, so setting this up once tends to unlock several other things at the same time.

How the pair works

A key pair is two mathematically related files: a private key, which never leaves your own computer, and a public key, which you can share freely — its whole purpose is to be given to servers you want to connect to. The server checks that whoever is connecting holds the matching private key, and if the match is correct, lets the connection through without asking for a password at all.

Step 1: generate the key pair

On macOS, Linux, or Windows using a recent OpenSSH client, run:

ssh-keygen -t ed25519 -C "your-email@example.com"

ed25519 is a modern key type that is both smaller and faster to compute than the older RSA default, and is the recommended choice unless something specific you connect to has not caught up and still requires RSA. The -C comment is just a label to help you tell keys apart later; it has no effect on how the key works.

Accept the default file location unless you already have a reason to choose another, and set a passphrase when prompted. The passphrase encrypts the private key file itself, so if that file is ever copied by someone else, it is still useless to them without also knowing the passphrase.

This creates two files, typically:

~/.ssh/id_ed25519       (private — never shared)
~/.ssh/id_ed25519.pub   (public — this is the one you copy elsewhere)

Step 2: add the public key to your hosting account

Display the public key's contents:

cat ~/.ssh/id_ed25519.pub

Copy the entire output — it is one long line starting with ssh-ed25519 — and paste it into the SSH keys area of your control panel. Do not edit or wrap the line; a key pasted with a line break in the middle of it will not match and the connection will be refused.

Only ever copy the .pub file

The private key file has no extension, or no .pub, and must never be pasted anywhere, emailed, or committed to a repository. If a private key is ever exposed this way, generate a new pair and remove the old public key from every account it was added to — treat exposure of a private key the same way you would treat a leaked password.

Step 3: connect

ssh youraccount@yourserver.example.com

If you generated the key in a non-default location, or you are managing several keys for different accounts, point the connection at the specific one explicitly:

ssh -i ~/.ssh/id_ed25519_hosting youraccount@yourserver.example.com

A successful connection using a key skips the password prompt entirely, other than asking for your key's passphrase if you set one — which your system's SSH agent will typically remember for the rest of your session so you are not retyping it constantly.

Using the same key with Git, rsync and Composer

Once a key is set up and working for a plain SSH connection, the same key is what Git uses for a Git-based remote over SSH, what rsync uses when copying files with -e ssh, and what lets Composer run smoothly if a private package repository also requires SSH authentication. See deploying from Git and deploying with rsync for how each builds on exactly this setup.

If the connection still asks for a password

  • Check the public key was pasted correctly — no missing characters, no accidental line break, and confirm it saved in the control panel.
  • Check file permissions on your own machine. SSH refuses to use a private key file that is readable by other users on the system; run chmod 600 ~/.ssh/id_ed25519 to correct this.
  • Confirm you are connecting to the right account and hostname — a key added to one hosting account will not authenticate a connection to a different one.

Once key-based access is working reliably, it is worth disabling password authentication for SSH entirely wherever your platform allows it, removing an entire category of brute-force attempt against the account. On shared hosting that setting is usually controlled by your host rather than something you toggle yourself, but the key pair itself is entirely yours to manage, reuse across every tool that supports it, and revoke by simply removing the public key from your account if it is ever no longer needed.

Related reading