DEV Community

dpm_bush
dpm_bush

Posted on Originally published at sshflow.com

Install an SSH Public Key on a Server from Linux, macOS, or Windows

#security #devops #beginners #productivity

Password prompts on every SSH connection get old quickly. Public-key authentication fixes that, but first the server needs your public key in the right place. On Linux, ssh-copy-id handles the common case. On macOS and Windows, you may need to install or use an alternative.

Before copying a key

You need a key pair and a way to log in to the server already, such as a password or another working key. A key-copy command cannot grant access if it has no way to reach the account.

If you haven't made a key yet, generate an Ed25519 key pair:

ssh-keygen -t ed25519
Enter fullscreen mode Exit fullscreen mode

The public key is the file ending in .pub, commonly ~/.ssh/id_ed25519.pub. The file without .pub is the private key. Only install or send the public key. Never paste your private-key contents into a server or account setting.

Linux: use ssh-copy-id

For a server that accepts your current login method, run:

ssh-copy-id user@host
Enter fullscreen mode Exit fullscreen mode

Replace user and host with the account and hostname or IP address. You'll authenticate using an existing method, often your account password. The command appends your public key to the remote account's ~/.ssh/authorized_keys file.

If you have multiple keys, select the public key explicitly so you don't install the wrong identity:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host
Enter fullscreen mode Exit fullscreen mode

For a server listening on a non-default SSH port, use -p:

ssh-copy-id -p 2222 user@host
Enter fullscreen mode Exit fullscreen mode

By default, ssh-copy-id checks whether the key is already installed. A message saying all keys were skipped because they already exist usually means there was nothing to add. Avoid -f unless you specifically want to append the key again; repeated copies can leave duplicate lines in authorized_keys.

macOS: install the helper or use a manual command

macOS includes OpenSSH, but not the ssh-copy-id script. If you use Homebrew, install it with:

brew install ssh-copy-id
Enter fullscreen mode Exit fullscreen mode

Then use the same commands as on Linux. Alternatively, if you only need to copy your public-key text to the clipboard—for example, to paste it into a service's settings—use:

pbcopy < ~/.ssh/id_ed25519.pub
Enter fullscreen mode Exit fullscreen mode

That only copies text to the clipboard; it does not install the key on a server.

On a Unix-like client without ssh-copy-id, you can append the public key over SSH:

cat ~/.ssh/id_ed25519.pub | ssh user@host \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Enter fullscreen mode Exit fullscreen mode

Change the filename if your public key has a different name. The command assumes the remote account has a Unix-style shell and uses the usual ~/.ssh/authorized_keys location. The directory and file permissions help OpenSSH accept the key; the server-side authorized_keys file is where public keys permitted to log in are stored.

Windows: pipe the public key through PowerShell

The built-in Windows OpenSSH client does not include ssh-copy-id. In PowerShell, use:

Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub" | ssh user@host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
Enter fullscreen mode Exit fullscreen mode

Replace the key filename and user@host as needed. The commands inside the quotes run on the remote server, not in PowerShell. This approach is for a typical Unix-like remote server; it relies on that server's shell understanding commands such as mkdir and chmod.

If you're connecting from WSL or Git Bash, ssh-copy-id may be available if installed in that environment. Be sure you're using the public key from the same environment as the SSH client: WSL and Git Bash can have separate SSH tools and key locations.

Test the new login before closing anything

Open a second terminal and try a fresh connection:

ssh user@host
Enter fullscreen mode Exit fullscreen mode

Keep your original working session open until the test succeeds. If the new connection still asks for a password, check which identity the client offers:

ssh -v user@host
Enter fullscreen mode Exit fullscreen mode

Verbose output can help distinguish a key-selection problem from a server-side permissions or configuration issue. If you have several keys, specifying the intended identity in your SSH configuration can make future connections predictable; see these SSH IdentityFile examples.

When key installation can't work

ssh-copy-id and the PowerShell pipeline both need an existing way to authenticate. If password login is disabled and you have no working key, the client cannot log in to install one. Use an out-of-band route, such as your cloud provider's console, or add the public key through the provider when creating the instance.

One other distinction matters: a Windows computer acting as an SSH client is different from a Windows server accepting SSH connections. A Windows OpenSSH server may use a different key-file arrangement for administrator accounts, so don't assume the Unix authorized_keys instructions apply unchanged.

The safe pattern is straightforward: choose the .pub file, install it for the intended remote account, and test a new connection before ending the session that already works.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.

Top comments (0)