Is it completely safe to publish an ssh public key?

Question

I use a RSA key to log into remote servers with ssh. And I keep my dot files under version control in a publicly accessible place so that I can quickly setup new servers to work the way I like.

Right now I don't have my .ssh directory under version control. But it would save a step if I could keep .ssh/authorized_keys in the dotfile repository.

It's just a public key. My private key sits only on trusted client machines in my possession, of course. I made it a 4096-bit RSA key because that seems like the best balance between wide compatibility with common sshd versions and security.

So my question is, is there any security problem with literally publicly publishing the public key? Nobody is regularly nosing around my dotfiles repository, but it's not a secret and anybody interested could read them.

Answer 1

Public Keys are designed for sharing, read access to and or publishing a public key is fine

Private Keys are secret, they should only be accessible to the owner of said private key.

To drive this point home, think back to every HTTPS website you have ever visited. In each case, as part of HTTPS the site gives you their public key. So not only is it safe to publish it, it is intended to be this way. For example, if you click on the green lock icon on your address bar, you can find the public key for this website (if you are viewing it on HTTPS)

*.stackexchange.com

Modulus (2048 bits):

BD 15 6A 1B 0A 03 69 CC 00 99 A0 4E 9E 31 99 34
3F 32 B8 6B 7C 62 0A 4D DC 45 41 72 8A 3E 92 DA
B3 64 45 B2 31 59 DE 71 60 D3 E3 26 91 DE 55 0D
3C F1 8C E2 C3 4C 01 F1 39 B4 A1 45 D5 9A 77 05
FC 2D 92 C6 B9 CE 10 4D DB 6F 7B 72 44 C0 18 38
4E B3 5E 3B 59 74 5C 52 E1 E7 3F E9 1C B8 23 F5
94 99 BE E7 BC 19 AA DE C0 6A C4 5E 4C 83 2D 5E
3B 1F 7F 97 56 42 28 C9 9E E4 D7 E8 45 E2 E1 D5
D5 E3 FD 73 01 D5 59 49 7C 97 82 F4 F3 AC 09 5B
4D 88 A1 F0 A3 7F 9A D6 2E E1 32 78 5C 0E F8 7D
74 E5 1C E8 C5 62 5A 78 AF 3C C4 51 75 FA F8 41
C4 5F 60 47 CE 81 80 83 57 6A 6C 31 29 EA C8 8A
CB C8 8C 3F 50 51 F0 06 F2 D2 24 18 60 87 7D AB
B0 6F 81 F6 3E B7 F1 F3 6F ED 67 73 41 EA FF 83
61 CA C3 2C A6 44 F2 58 21 6C C9 DD EC 95 85 7C
B2 AD E4 35 E2 9B 9F 82 0C 7A AB 58 18 0E 54 97

Public Exponent (24 bits):
01 00 01

Further examples of this can be found on github.com where they request that you attach a public key to your account for use with git clone git@github.com:<user>/<repo>

You can actually check the public keys of any user on github with the following URL

https://api.github.com/users/<user>/keys

mine is listed as:

[
  {
    "id": 18667533,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDraswAp7EbMwyYTzOwnSrsmr3nNMDaDf4e2YVaehLc9w6KN2ommomXZO8/V9N3yINNveGqrcVc9m2NTm04iILJUKd9o25ns8QIG6XSCt9SVx/Xw1J/SXfIWUKuEe0SgmIwVwkk8jetfG/Z7giSiU3dxxC4V9lHQCFgKOKBWGpNbINmqtmBWncX3HJKeXrpSddoePbZZ84IEFr4CWUlqoXyphpxqzpfA9sRpVTtyBPcUSj68j4+gKgEQN65G6LXys3q8BiwWxucci6s34vp4L8jKn7uYh26vLuT1oIbODJphCmpvMH+ABPkNQcFBk4rRLpCEAsoAhmvTk/NjnfZM+nd"
  },
  {
    "id": 21175800,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5tPV481acCZ5wm2E15gXkVRaKCE3lic/O8licyzW+eDE9rPpG4rHRRH9K2ENmstUh5nLEenb0nNhEGnsf3pIJRZ07JXwv16+lsJBSS8+YiWeMBlwo+JNaxwSyUlYUgl1ruogr0nR0KBqsYSWXuG0s2jm2IOV+0B/0fzDR/tiLFLj50+iJ9qCDSk/8fAsXz2xG39KcUcxmCbDXb/qSdESWaZc+pafNRiCcVNfMkKeDViWlzI4VkiTcfVCraHUuYx4jgOBB526dRWSDG9bLchwlJiopgT+k4X/TNe2l01DPwYetwLvY6V8rcPrjjJL8ifRTMSof1zRIoBgJZhRzWc1D"
  }
]

---

The exact opposite is true of Private Keys which should be secured at all times and never given to a third party or exchanged via email without encrypting them.

If someone has accessed your private key, they have the ability to access any device or encrypted file that was protected with your public key. It also means that they can sign things on your behalf. It is VERY bad if someone has gained access to your private key.

In many cases SSH Clients will not function if it is detected that the permissions of the Private key file are such that users other than you have read access.

Answer 2

Is it completely safe to publish an ssh public key?

No, but you can do it anyway without worries (lots of people do, just look at https://sks-keyservers.net/i/ or https://pgp.mit.edu/)

The reason why it's not completely safe is because if I know your public key, I can, with a neat piece of mathematics, calculate your private key. Your public key contains a large number n which basically is the product of two prime numbers, and if I find these two prime numbers, I can easily find your private key.

The reason why you don't have to worry: It's easy to find the factors of n when n = 21, but it's a lot harder when n is a number 4096 bits long. No mathematician currently alive or dead has published a way to factor such a large number in acceptable time. Using the best known method, we'd all be dead long, long before anyone found the factors that made up your n.

It's not completely impossible that someone finds a shortcut to factor large numbers. If that happens, RSA will be worthless. Until then, you don't have to worry.

SSH uses both RSA (or another signature scheme) and Diffie Hellman (for session key exchange). 1024 bit for Diffie-Hellman key exchange (which mathematically works a bit differently than RSA) might no longer be large enough. This is because some ssh implementations (and ssl implementations, if I remember correctly) which use Diffie Hellman reuse some constants instead of choosing them randomly and once someone built a machine to do the necessary computations, they could break all encryption based on these constants. 1024 bits still take an incredible amount of computing power to factorize or calculate discrete logarithms on (and billions of dollars to build machines to do it quickly), but it might be worth it to certain state-level actors, because just breaking a few problem instances will break such a large number of encrypted sessions. 2048 and 4096 bits are still considered safe, though.

The same goes for RSA keys; I don't think a 1024 bit number has been factored yet in public, but it's probably there on the horizon, meaning that it's probably possible for institutions with very large budgets to factor 1024 bit numbers now, albeit not in large quantities.

(Edits: Clarified the meaning of the last paragraph and corrected the error pointed out by RobIII)

Answer 3

Nothing is "completely safe"; the question is whether it adds any additional risks.

The SSH protocol sends the client's public key encrypted, only after it has negotiated a symmetric session encryption key with the server. So an adversary that eavesdrops on the connection doesn't learn the client's public key. This means that publishing it does give the adversary an extra piece of information they wouldn't have otherwise.

But what can the adversary do with that additional information? Well, this all hinges on whether the attacker can break RSA. Let's consider two subcases. (I'll assume that both the server and the client's RSA keys are large enough to be secure in the first place—2048 bits or more.)

The adversary has a general attack on RSA that requires knowledge of the public key

By general attack, I mean one that breaks RSA irrespective of what key you use. For example, this would be something like an efficient algorithm for solving the RSA problem (e.g., a polynomial-time prime factorization algorithm) or by building a practical quantum computer.

In this case it doesn't matter whether you publish your client public key or not, because SSH and every other application that uses RSA would be completely broken. So no additional risk.

The attacker has an attack against a subset of "weak" RSA public keys

This is a real-life problem. There are some systems that, because of faulty key generation algorithms or faulty random number generators, choose RSA keys that are actually vulnerable to attack. The most notable example is that the Debian GNU/Linux distribution shipped with a weak random number generator for nearly two years (September 2006 to May 13th, 2008). A 2011 survey of 7.1 million RSA keys in the public Internet found that about 0.4% of 1024 RSA public keys they saw were weak.

If your client public key is such a weak key and you publish it, then an attacker who obtains it may be able to tell so and exploit this fact. They would then be able to log in to the SSH servers that you use that key to authenticate to. That would indeed be an additional risk.

If your server has such a weak public key, then that server is insecure; an attacker can eavesdrop on the connections, which allows them to learn your public key anyway. So in this case there's no additional risk.

Conclusion

The additional risk from publishing your SSH client public key is small but not zero. The biggest risk is that your client public key is a weak one, something caused by faulty software. If you're going to publish a client public key you might want to take steps to make sure your key isn't a weak. For example:

• Check your public key against a weak key tester tool
• Generate your client keypair on a system where you've done due diligence to make sure that it won't give you weak keys. For example:
  • Apply all security patches to your operating system, particularly those that address issues with its random number generator, SSH, or any libraries that SSH depends on.
  • Take measures to ensure that the system has access to a good entropy source. (Complicated topic.)

Answer 4

No, unless you use a unique one per service. It lets attackers identify you.

If you use the same public key for service A and service B, and your public key gets leaked for both of them, this will cross-link your two accounts together.

Hopefully neither of the two services is embarrassing. But even in that case, this will give the attacker a better lead for figuring out which account(s) to hack someday, if he wants to attack you.

Answer 5

There is a slight risk of revealing your identity if your public key contains your hostname as a comment at the end, e.g. ssh-rsa C4F3B4B3... johndoe@companyname.com. If your name is fairly uncommon it may be possible to identify you.

See this question & answer for more detail: Should I publish my public SSH key with user@hostname at the end?

Answer 6

Yes, but...

If your security relies on the privateness of the public key, you are doing something sub-optimal. This is not what the asymmetric encryption is designed for.

All of the previous answers points some vulnerabilities

• which have a greater risk if your public key is known,
• or they show some additional defense which you have is it is kept secret.

In both cases, the real reason is that you don't use the public key for which it was designed. For example, the knowledge of your public key makes possible your identification. This can be handled by hidden pubkey, but it can be done better if you use some additional mechanism (for example, an additional encryption layer with per-session autogenerated random key pairs) for this task.

But, everything can be used also for other tasks, it can be even fruitful, particularly if we are not on the defensive side.

Answer 7

Right now I don't have my .ssh directory under version control. But it would save a step if I could keep .ssh/authorized_keys in the dotfile repository.

Even though it should be safe to make the public key public, I don't think this is a good idea:

The private key is also stored in the .ssh directory and there is a risk that you are not careful to exclude it from the dotfile repository and publish it accidentally.

Answer 8

One additional concern with sharing your public key is if it was unsafely generated. Numerous papers have come out about ways that RSA and Diffie Hellman keys can be backdoored but otherwise appear perfectly normal. In this scenario, providing your public key would give an attacker all the information they needed to derive your private key.

References:

http://kukuruku.co/hub/infosec/backdoor-in-a-public-rsa-key https://www.cryptologie.net/article/360/how-to-backdoor-diffie-hellman-quick-explanation/

Answer 9

There are several threats you can consider. One discussed by other answerers is that of a malicious user trying to crack the public key. Another threat worth considering is this malicious user replacing your public keys with his. If he changes the keys, and you do not notice this, then you may set up a system using the malicious user's keys--thus deploying HIS public key for which he owns the private pair.

Answer 10

Yes

If RSA works as designed, this should not be a security issue. It may reveal a bit of information about your identity, but nothing this question doesn't also show.

Why?

For AES, you need just 256 bits because the key is completely secret. With RSA, you're giving an adversary some info (the public key), but it can be show that it is still as hard to crack. But factoring numbers it getting faster quicker than brute-forcing passwords.

Simplistically, two randomly chosen prime numbers are the private key, and multiplied together form the public key. (This is doable because primes are quite common). RSA is based on the assumption that factoring them back to the two primes is hard. There has been a lot of progress in number factoring algorithms, and if full fledged quantum computers come along, Shor's algorithm will be the end of RSA

Answer 11

In terms of the theory of PKI systems, no. The system is designed to be "safe", or more accurately no weaker, when both the algorithm and public key are known to the world.

In practice, there could possibly be some exposure to you for other reasons. In short, don't compromise your own security through blunders; and it's best to create distinct keypairs for each individual purpose.

• If you forget and accidentally commit the private key, or a revocation certificate, and someone sees it, they could be used against you. By committing anything inside your .ssh folder you are accepting that risk of potential human error; you must be careful. (And if this does happen, simply deleting it again may not remove it from the history. Not in today's most popular systems. Depending on the version control system, you may have difficulty purging it completely.)
• Depending how public your repository is, and what else you use that public key for, hostile parties might possibly be able to track activity done with that public key and thereby build a history of your actions. Conceivably, identifying you in the process. Long shot.