Is it completely safe to publish an ssh public key?

  • 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.

    The public key is meant to be public, so yes. It should be okay. If there is no need for you to do it then don't put it out there for no reason but you should be fine.

    Hey, putting .ssh under version control is a neat idea. I wonder why I never thought of that.

    Define "completely safe." Am I allowed to beat you with a rubber hose until you told me the answer? Can I spend trillions of dollars and millions of years attempting to break it?

    Nick: Dude, if you want my users' vocabulary cards that bad, just break my office window and clone my hard drive. So much aggression.

    I think it's worth nothing that GitHub publishes public keys of all its users. You don't even have to be logged in.

    Just a bit of an observation: Nothing in IT is completely safe, aside tossing your system in an industrial shredder, and then tossing the fragments in a blast furnace.

    @NZKshatriya and tossing the blast furnace into the sun, and then tossing the sun into a black hole...

    @djsmiley2k That black hole is NOT perfectly safe. Stephen Hawking reversed his original opinion. It is not safe to assume that no information leaks from a black hole ;-). Such an information sink would contradict fundamental principles of how the universe works. For example it could be used to get rid of the clutter on my hard drives. Alas...

    Keep in mind that if you aren't willing to publish your public key, your private key won't be of any use.

    One more observation from a non-expert: it is reasonably safe to share the public key, but is it safe to take the authorized_keys from a shared repository? If you completely trust the versioning repository ok, but if somebody else can access the repository and edit it he will be able to gain access to all the PCs using that file... If this is fine with you then share it...

    @Brian : obligatory XKCD that fits the Nick T idea: https://xkcd.com/538/

    I second @frarugi87 - it's safe to publish your public key, but whether it's ok to automatically download and trust a public key from somewhere depends a lot on how secure that somewhere is.

    Nick may have gone a bit aggressive with the wording, but his point is a good one. The term "completely safe" is an anathema to security people because there is no such thing as "completely safe." If you remove the word "completely," and just ask "is it safe," you avoid those sorts of issues. (of course, making that change now would invalidate most of the answers)

    @Brian "rubber hose" is per https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis ; I didn't intend any aggression, though perhaps the term isn't that well known outside the security-conscious.

    @CortAmmon: "Is it safe?" is arguably **worse** than "Is it completely safe?" because you've replaced an answerable question with a vague imprecise one! Better is to ask "Is it as safe as ...?"

    @Brian It is not a matter of aggression, it is a matter of a fundamental flaw in your question. "Completely safe" is a meaningless expression in these discussions because if a scheme is supposed to grant some people access while keeping others out, then you can never rule out blind luck. So is the probability that someone will not figure out your private key 100.0000000000000% if you publish your public key? No, it is not. But it is never the goal to make something "Completely Safe", because that is impossible. The goal is to make it "Safe Enough".

    I would say it's *not* safe to put your `authorized_keys` into a public repository. If the operator of this repo (say, GitHub) is compromised, they will be able to replace / add their own public key and subsequently log in to any servers that you clone this file to!

  • 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):
    af 46 03 ce c7 13 e6 2e 93 d8 56 91 b1 31 8d 0a 
    22 c1 f0 eb 4f 5e ef 0d f6 20 32 b9 a4 4e 87 f9 
    d2 d2 44 51 b0 df 30 50 c9 35 4e 68 19 84 fb 98 
    33 aa 05 4b 7e fb 57 c5 b6 2e a8 4b 04 ca cf 5e 
    2e e5 9e 1b ca b7 60 c5 58 2c b0 df c4 6b 0d b1 
    2c 33 97 73 54 61 2b 9a 1b b1 dc 5d 10 a9 c4 c8 
    f7 6c e3 55 6e b5 0e 61 3b 35 24 0b 89 1e 32 a2 
    75 69 4e 97 40 68 ee 23 48 f2 71 9f c7 7e e2 9d 
    6c 22 55 36 24 64 a4 f0 b6 52 58 5a 9a 44 e7 3b 
    2a d5 ed 95 63 f8 1d a8 4d 45 9b 5d c2 f2 f9 74 
    81 06 18 d5 b1 fb b0 7e 5d 50 1f 63 5c a0 73 f5 
    22 b2 57 64 03 e6 b7 0f 6f b7 58 0b 57 80 56 51 
    65 9f f5 09 61 63 29 62 4d 30 02 3a 64 10 2d 95 
    b8 12 36 04 58 c5 d7 1d 95 e2 21 3c b0 b3 93 35 
    b2 b1 f9 6d 7e 20 66 b2 68 33 e9 50 a8 15 1e 0a 
    80 9a 3c 19 dd cc 79 35 a8 8c 1b 61 33 5d 12 2f 
    
    Exponent (24 bits):
    65537
    

    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 [email protected]:<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.

    I guess this could be improved by exposing the reason why private keys are private and so on

    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 (technically unproven) assumption that factoring them back to the two primes is hard.

    @J.A.K: To expand on that, the private key isn't actually the product of the two primes p and q. It's the modular inverse of the public key exponent e over the modulus p * q. The modulus p * q and e are published. If you can factor p * q, you know p and q and can calculate the modular inverse of e.

    I don't think most people click on this page to comprehend the underlying mathematical nuances, because the question is about the basic properties of what a public key is. "The security lies in...." would have been a better phrasing, i agree. But i believe this is also why RSA-129 was generated; to show the hardness of factorization in a graspable way

    Agreed, but my comment explains what the modulus and exponent in the above stack exchange example are. Plus the fact that the modulus is *not* the whole key makes it possible to reuse the modulus in software like ssh and just choose different exponents, and this is why it's likely that three-letter agencies are interested in spending billions of dollars to factorize just a few numbers - if they can factorize an often used modulus, every public key which is actually available in public and based on that modulus is an instant door to the private key. So I do think it's relevant to the question.

    @Pascal umm I think you are confusing RSA with DH. With RSA the modulus needs to be distinct for each keypair. If you have the modulus and both exponents then you can recover p and q http://www.di-mgt.com.au/rsa_factorize_n.html.

    Well, yes, the point about reuse in fact applies to DH (see my own answer about reusing constants in DH - shouldn't gloss over the details when I point my finger... sorry!). The immediate problem with *all* ssh keys sharing the same RSA modulus would be that in order to compute the keypair when generating a new keypair, you need access to p and q, the factors of the modulus n. So if ssh reused the same modulus for every RSA key, its source code would contain p and q as constants. So we could simply go look for p and q in the source code - no need to calculate (or spend) anything at all :-)

    Interestingly, when I was viewing your answer over HTTP (no S) the answer said **"Sure, you can publish your public _and_ your private keys, no problem"**.

    @Pascal: Your first comment about the private key is **totally wrong**. The modular inverse of any integer over any modulus is **easily computable** (in logarithmic time). The private key is the multiplicative inverse of the public key modulo (p-1) * (q-1), not p * q. p * q is published, but (p-1)*(q-1) is hard to compute without knowing p or q.

    @J.A.K.: See my above comment. And if anyone is actually interested in security, it's up to them to understand enough mathematics to not do stupid things. A lot of security professionals who don't end up making their systems insecure for very naive reasons from a mathematical point of view.

    @user21820: Yup - you're right. Like I said, shouldn't point my finger and get it wrong, too! Next time I'll actually look it up instead of trying to wing it from memory before I make an idiot of myself ;-) And sorry, J.A.K.

    @Pascal: No idiot will admit mistakes. Besides, I was amused that your actual answer did not state anything wrong about RSA, unlike here. =)

    Quick tip about github keys. If you use the url https://github.com/user.keys it will return them ready to place in authorized keys.

    @Pascal You have no idea how often i mess that up myself ;) . The fact that people are pitching in makes this a great place, the rest will sort itself out.

  • 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 Hellmann 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)

    1024 bit RSA would probably be a bit too close for comfort. 2048 bit should be fine, 4096 bit adds a fair deal of safety margin (but not as much as would, say, going from AES-128 to AES-256) *against currently publicly known attacks*.

    Agreed. I see the last paragraph is misleading; I meant to say that 2048 and 4096 bit keys are safe for RSA too while 1024 bit keys probably aren't any more, given that even a public/research effort might soon factorize one (so three letter agencies are probably ahead)

    `"Note that ssh lets you choose between RSA and Diffie Hellman."` I could be mistaken but aren't the options "RSA1", "DSA", "RSA" (for RSA2), "ECDSA" and "ED25519"? Correct me if I'm wrong.

    Hmmm, you're right. I remembered wrong - according to http://security.stackexchange.com/questions/76894/how-does-ssh-use-both-rsa-and-diffie-hellman, it seems ssh uses RSA for it's signature capabilities and Diffie Hellman for key exchange - so I'd assume Diffie Hellman is always used as the key exchange algorithm no matter which signature scheme (RSA1, DSA, ECDSA, ED25519) you use. I'll edit the answer to reflect it.

    "No mathematician currently alive or dead has published a way to factor such a large number in acceptable time." i think user @PeterShor might disagree with you

    @SteveCox true, but salvagable with the addition of one word. "usable". Hardware capable of running Shor's algorithm in subexponential time doesn't yet exist. It's still quite some time away afaik.

    @RobIII, Pascal: "RSA1" isn't a signature scheme, it means "RSA for SSHv1", where the RSA key was used for _decryption_ – in the now-obsolete SSHv1 protocol the server would encrypt a challenge to your key. (Which is why it _only_ supported RSA, I assume.) All other options are signature keys for SSHv2 protocol, and yes, SSHv2 supports quite a few signature schemes and uses *DH for key exchange.

    @grawity -Ah - you never finish learning. This is why I love stackexchange. Thanks!

  • 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.)

    You might also recommend rotating keys as a mitigation. Any tips on tooling to make that easy? For instance, after adding a new private key, are there tools to warn you client-side whenever you use an old key to login to a site, so you know that you still need to change the authorize_keys file on that server?

    Anyway +1, this is the best answer as it actually looks at what potential risks do and don't exist.

  • 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.

    Identification is pretty much the only real risk of "leaking" a public key.

    @Mehrdad Freaky.

    @Mehrdad Nice find. It took me a moment to realize it had given me a "passed" however. It echoed the public keys "below", but I couldn't find them. Finally realized what it had echoed was nothing, as in none tried.

  • 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... [email protected]. 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 [email protected] at the end?

    It works for ssh auth even if you remove the hostname at the end.

    Yes, it works because it's just a comment which can be removed. But if you forget to remove it yourself before giving it away, it can be a problem.

    My host name was 2013-iMac.local, which isn't all that personal, but it could have been.

  • 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.

  • 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.

  • 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/

  • 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.

  • 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

    Please do not downvote without leaving a comment about the reason.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM