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?

Jim
  • 330
  • 7
  • 16

2 Answers2

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.

potom
  • 360
  • 1
  • 2
  • 8
  • 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. – Jim Oct 03 '18 at 04: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 03 '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. – Jim Oct 03 '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 03 '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.

Rusty Weber
  • 472
  • 8
  • 21
  • "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 03 '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 03 '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 03 '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 03 '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 03 '18 at 17:02
  • Would a better version read, "If the public key is accessible to anyone you don't trust, it is a security risk unless a sufficiently strong enough encryption length was used"? – Rusty Weber Oct 03 '18 at 17:12
  • I appreciate the comments but everyone is getting way off in the weeds here. I'm not protecting Fort Knox. I just want to keep some system files for my business server in the cloud. I'd think there would be a relatively easy and secure way (or some service) for doing this in 2018. Thanks again. – Jim Oct 03 '18 at 19:42
  • Apologies, but your question is literally "Any security risk in creating root public/private keys and adding public key to GitHub repo?"... It sounds like this should really be split into two different questions. Can you make some possible edits for clarity maybe? – Rusty Weber Oct 03 '18 at 20:49
  • @Rusty RSA 1024 cracked on a few hours on a single machine using a GPU ? I don't believe you. The RSA-768 challenge took months on several large clusters. Every 4 additional bits of the modulus roughly doubles the attack time. What you witnessed was probably an attack on weak keys generated with not enough randomness. Either that, or you just made yourself a valuable target for intelligence agencies all around the world. – b0fh Oct 04 '18 at 17:00
  • @b0fh, you got me. They were talking advantage of a reduction in entropy based on when (down to the second) and how the keys were being generated on a very old instance of open ssh to make the amount of work needed to perform a brute force attack feasible. Mostly to make a point on security in a classroom setting. Maybe not an apples to apples comparison. None the less, it takes an almost trivial amount of time to generate a 4096 bit key which which isn't going to hurt and would still render an attack of the same type and magnitude fruitless. – Rusty Weber Oct 05 '18 at 17:54