3

I would like to do version control on some important directories on my server such as /etc/apache. All the files and subdirectories in that directory are owned by root:root. Would it be considered a security risk to create a public/private key pair for my root user, add that key to a Github repo, and then store that apache directory on Github? If it is a security risk, what's the "best practice" method of storing system directories (as opposed to personal directories) on Github?

  • 1
    The best practice is not to do it. Use a private git repo instead. – Michael Hampton Oct 3 '18 at 3:45
  • 2
    Note that you can see any GitHub user's SSH public keys by going to github.com/USERNAME.keys. "Public keys" really are public. – Moshe Katz Oct 3 '18 at 15:53
5

It's not a security risk per se - public keys are public.

However you may still want to keep your config files at least somewhat private rather then expose them to the whole world on github. What if you have a misconfiguration in the config that has some security implications? You don't necessarily show it to everyone.

Have a look at GitHub Private repositories (you'll need a subscription), or look at GitLab (private repos are free), or host your GIT repo on some server that you control.

| improve this answer | |
  • Thanks. I actually use BitBucket so the repository in question is private. I just used Github in my question as it's better known than BB but the principle would be the same. – Ray Oct 3 '18 at 4:04
  • I agree with Potom as well. Having apache config files where anyone can read them is a hazard. Have you thought about making a git server local to your network or machine? – Rusty Weber Oct 3 '18 at 17:24
  • No I haven't considered that. I would think in this day and age of "cloud computing" that wouldn't be necessary. I travel constantly and don't have a permanent home so keeping a local machine is not feasible. I guess I could create my own VM in the cloud but, again, there should be a better solution. – Ray Oct 3 '18 at 19:39
  • What about using a VPN to gain access to your work/home network while traveling? Everything would be protected, held inside of your work network, accessible to you from anywhere so long as you are using your VPN client to log in, as well as extendible to individuals you deem worthy by giving them access to your VPN. – Rusty Weber Oct 3 '18 at 20:42
-1

YES.

If the public key is accessible to anyone you don't trust, it is a security risk unless a key of sufficient length was generated. It does take a LOT of computing power and time to factor out all of the prime numbers used in creating an RSA key pair, but with enough time and effort the key can be broken. However, by A LOT.. I mean A LOT of time and effort. Like, hundreds years of computing. Usually the only people with these kind of resources available are governments and even then they can have difficulty breaking the encryption.

HOWEVER! When you generate an ssh RSA key pair, you can make it more difficult, so difficult it becomes essentially impossible, for anyone to reverse engineer your private key by increasing the length of the keys generated. For each additional bit, you increase the amount of work a computer has to do to crack your code by about a factor of 2. The default length for RSA keys in ssh is 2048. The following is an example of creating a key with a size of 4096.

ssh-keygen -t rsa -b 4096

This key should be significantly harder to crack and can be increased in size from there even. Git hub recommends that you use a bit length of 4096 when creating RSA keys.

| improve this answer | |
  • "Years of computing" is understating things. Barring an unknown exploit or groundbreaking revolution in how we compute things, even governments are looking at million-plus year timelines to break an 4096 bit SSH key. Public keys are called that because you can safely give them to the public. – ceejayoz Oct 3 '18 at 16:41
  • Hence the reason I suggested the use of a longer key. a 1024 bit key can be cracked on a parallelized process utilizing a graphics card in about 2-4 hours. I've seen it done. A 2048 key is significantly harder, but some states might have enough resources to crack even that. 4096 though.... that would take eons worth of computing. – Rusty Weber Oct 3 '18 at 16:44
  • 1
    The default for ssh-keygen is 2048, and Github recommends 4096 in their docs. I don't think they'll even accept a 1024 bit key. – ceejayoz Oct 3 '18 at 16:47
  • Then wouldn't the correct answer be.. "Create an ssh RSA key pair of 4096 bits"? That is what github recommends after all. They probably recommend it for a reason. After all, states like china, Russia, and the US would love to tamper with much of the code in many of the open source projects on git hub. I wouldn't be surprised if they recommend that key-length because one of those governments has already tried something less than honorable. As such.. why the downvote? – Rusty Weber Oct 3 '18 at 16:56
  • The downvote is for the false statement "If the public key is accessible to anyone you don't trust, it is a security risk." If you revised your answer to one simply focusing on the need for a strong key, I'd be inclined to reverse it. – ceejayoz Oct 3 '18 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.