Is it safe to share your SSH public key?

Why sharing your SSH public key is safe

Yes, it is safe to share your SSH public key. It is the half of the pair you paste into servers and into GitHub. The private key is the other half, and it never leaves the machine that generated it. Sharing the public key gives nobody a way in. Sharing the private key gives everybody a way in.

The real risk is pasting the private key by mistake, because the two files sit next to each other in the same directory and have almost the same name. The rest of this guide shows how to tell them apart in ten seconds, what each one can be used for, and how to find or create yours.

How do you tell the public key from the private key?

Two checks, both instant. First, the suffix: the public key ends in .pub and the private key has no suffix. Second, the first line of each file. Run head -n 1 on both:

head -n 1 ~/.ssh/id_ed25519
head -n 1 ~/.ssh/id_ed25519.pub

-----BEGIN OPENSSH PRIVATE KEY-----
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKk... matt@laptop

A private key is easy to recognise. Its first line is -----BEGIN OPENSSH PRIVATE KEY-----, the file runs to many lines, and the last line is -----END OPENSSH PRIVATE KEY-----. An older key may say -----BEGIN RSA PRIVATE KEY----- instead, and the rule is the same. The public key is a single line that starts with the key type, ssh-ed25519 here, followed by the key data and a comment. If the text you are about to paste starts with -----BEGIN, stop. That is the file that stays on your machine.

The file modes tell the same story. ssh-keygen writes the private key readable by you alone and the public key readable by everyone on the machine:

stat -c '%a %A %n' ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

600 -rw------- /home/you/.ssh/id_ed25519
644 -rw-r--r-- /home/you/.ssh/id_ed25519.pub

The 644 on the public key is deliberate. Other users on the box reading it is harmless. The 600 on the private key is enforced, so ssh refuses to use a private key that anyone else can read. Loosen it to 644 and every connection with that key fails with this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/you/.ssh/id_ed25519": bad permissions

That warning is ssh telling you it treats the two files differently, and so should you. chmod 600 ~/.ssh/id_ed25519 puts it back. The mode digits themselves are explained in chmod numeric versus symbolic modes.

How do I find my SSH public key?

ls -l ~/.ssh

Look for a pair of files with the same name, one with .pub and one without. id_ed25519 and id_ed25519.pub is the modern default. Older machines may have id_rsa and id_rsa.pub, and either pair works the same way. Then print the public one:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKk... matt@laptop

That one line is your public key. Copy the whole line, including the type at the front and the comment at the end, and paste it wherever access is being granted. An ls that shows no id_* files, or No such file or directory for ~/.ssh, means you have no key yet.

How do I make an SSH key if I have none?

ssh-keygen -t ed25519 -N '' -C 'matt@laptop' -f ~/.ssh/id_ed25519

Generating public/private ed25519 key pair.
Your identification has been saved in /home/you/.ssh/id_ed25519
Your public key has been saved in /home/you/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:U4qfB5Pk2dxQ3eL0v9wYw1QaZ3cX7mN8RtGhJkLpOeM matt@laptop

The command also prints a randomart box under those lines, which you can ignore. The hash is unique to your key, so yours differs from the one above.

Each flag is there for a reason. -t ed25519 names the key type explicitly. ssh-keygen has defaulted to Ed25519 since OpenSSH 9.5, but passing -t means the result does not depend on which build you have. -N '' sets an empty passphrase, which makes the demonstration non-interactive. On a laptop you should set a real passphrase instead, since a passphrase is the only thing between a stolen laptop and every server that key opens. -C sets the comment. Without it the comment defaults to user@hostname of the machine you ran it on, which is a small leak of your username and hostname that then gets pasted into every server and every GitHub profile. -f names the output. If that file already exists, ssh-keygen asks Overwrite (y/n)?, and answering y destroys the old private key, so pick a new name like ~/.ssh/id_ed25519_vps when you already have one.

Ed25519 keys are short and have no key-size parameter to get wrong, which is why every guide on this site uses them. The server end of this, adding the public key to ~/.ssh/authorized_keys and turning off password login, is covered in hardening SSH on a VPS and in the first ten minutes on a new VPS.

What can someone do with your public key?

Here is what the public key is good for. None of it is logging in.

Grant you access. Add the line to ~/.ssh/authorized_keys on a server and the holder of the matching private key can log in. This is the entire purpose of the file. A public key can only ever admit the person who holds the matching private key.

Verify your signatures. Git commits and files can be signed with an SSH key using ssh-keygen -Y sign, and anyone with the public key can check that signature with ssh-keygen -Y verify. The public key proves a signature came from you. It cannot produce one.

Correlate your identity. This is the one worth knowing about. GitHub publishes every user's public keys at a plain URL:

curl -s https://github.com/torvalds.keys

Swap torvalds for any GitHub login and you get their keys, no authentication needed. That is the proof the public key is public by design. It also means that if you use one key for GitHub and for a client's servers, anyone who can read authorized_keys on the client's machine can match it to your GitHub account. The key data is unique and the comment often carries a hostname. Use separate keys for separate identities if that matters to you, a topic that SSH key management basics goes into.

What they cannot do is log in as you, or work backwards to the private key. Deriving an Ed25519 private key from its public key means solving the elliptic-curve discrete-logarithm problem, which no known computer can do. GitHub could not publish every user's keys at a URL if that were false.

What can someone do with your private key?

Everything. They can log in to every server that lists your public key. They can sign commits as you. Once inside a server, they can add their own key to authorized_keys, so removing yours later does not remove them. They can do all of it from any machine, and the server cannot tell the difference, because the private key is the only identity SSH checks. There is no expiry date on an SSH key and no central revocation. Recovering from a leaked private key means generating a new pair and removing the old public key from authorized_keys on every server it was ever added to, and from every GitHub or GitLab profile, by hand. A missed server stays open.

So the private key stays on the machine that made it. Do not email it, do not paste it into a chat, do not commit it to a repository, and do not copy it to a server so you can hop from there to a second server. For that last case, a ProxyJump entry in ~/.ssh/config does the job without the key ever leaving your laptop.

What is the fingerprint for?

A public key is a long string that is hard to compare by eye. The fingerprint is a SHA256 hash of it, short enough to read out loud:

ssh-keygen -lf ~/.ssh/id_ed25519.pub

256 SHA256:U4qfB5Pk2dxQ3eL0v9wYw1QaZ3cX7mN8RtGhJkLpOeM matt@laptop (ED25519)

The fields are the key size in bits, the hash, the comment, and the key type. The fingerprint is what you compare when you want to confirm that the key in a server's authorized_keys is really yours, or when you check a key someone sent you over a second channel such as a phone call. It is also what GitHub shows next to each key in your account settings, so you can match a line there to a file here. The fingerprint reveals nothing about the private key. It is derived from the public key, which is already public.

Lost the .pub file? Regenerate it from the private key

The public key is a mathematical function of the private key, so ssh-keygen can print it again at any time:

ssh-keygen -y -f ~/.ssh/id_ed25519

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKk...

Save that output as ~/.ssh/id_ed25519.pub and you are back where you started. Prove to yourself that it is the same key by fingerprinting the regenerated copy and the original:

ssh-keygen -y -f ~/.ssh/id_ed25519 > /tmp/regenerated.pub
ssh-keygen -lf /tmp/regenerated.pub
ssh-keygen -lf ~/.ssh/id_ed25519.pub

The SHA256: value is identical on both lines because both come from the same private key. This asymmetry is the whole point of the design. Losing the .pub costs you one command. Losing the private key costs you the key, since nothing can derive the private half from the public half. The private key is the one to back up, with 600 permissions, on media you control.

If the key exists and is correct but the server still answers Permission denied (publickey), the problem is on the server side or in how the key is being offered, and fixing SSH permission denied (publickey) walks through the causes in order. A client that offers too many keys before the right one gets a different error, Too many authentication failures, which has its own fix in the too many authentication failures guide.

FAQ

Is it safe to put my SSH public key on GitHub or in a public repo?

Yes. GitHub already publishes it at the .keys URL shown above for anyone to fetch, so putting it in a README changes nothing. The only information in the file beyond the key itself is the comment, which defaults to user@hostname. Set it with -C to something that does not name your machine if you would rather not share that.

Can someone log in to my server with my public key?

No. The public key in authorized_keys only accepts the matching private key, and the private key cannot be computed from the public key. Someone who has only your public key can add it to their own server, which lets you in, not them.

How do I know which file is the private key?

The private key has no .pub suffix, its first line is -----BEGIN OPENSSH PRIVATE KEY-----, and it is many lines long. The public key is one line starting with the key type, such as ssh-ed25519. Never paste, email, or upload a file that starts with -----BEGIN.

I deleted my .pub file. Do I need a new key?

No. Run ssh-keygen -y -f ~/.ssh/id_ed25519 and it prints the public key from the private key. Save the output as ~/.ssh/id_ed25519.pub. The reverse is impossible: a lost private key means a new pair and a visit to every server that trusted the old one.