4 ms·

Why do you think this is a common problem? I've never heard of anyone leaving private keys on the server. Usually the ssh-keygen is run locally on their machine

Why do you think this is a common problem? I've never heard of anyone leaving private keys on the server. Usually the ssh-keygen is run locally on their machine and the public key is deployed on the server.

3np 6y ago
Oh, I've seen it plenty times when users want to SSH from server A to server B, they copy their private key from their workstation to server A.
- systemvoltage 6y ago
  Oh boy... I need to step out into the wilderness more :-D
- bsder 6y ago
  Urk. Wow. The bigger issue is "Don't copy a private key. Ever. Period." How would you even do this? Don't the various private key containers make this quite difficult?
  - chrisan 6y ago
    It is just plain text in linux. Nothing hard to copy about it
- midasuni 6y ago
  A natural consequence of server admins disabling ssh agent forwarding. All these “security truisms” tend to ignore the real world. When you remove features, people will work around it in a less secure way.
- deleted 6y ago
  [deleted]
- deckard1 6y ago
  A result of people not understanding how public/private keys work. They just want it to work, and copy everything over to get what they want done. These same people probably also joke about the marketing folks down the hall leaving post-it notes with their password on their monitor. Security is the first casualty in the battle for convenience.
vorticalbox 6y ago
What if you need to git ssh clone? Can you use your private key locally while your are currently connected to the a server? Genuine question, this is why I have a private key on the server in out office so I can clone our private repos. Can you use your local private key then?
- ploxiln 6y ago
  Yes, you can pretty easily use "SSH agent forwarding", which grand-parent comment calls "the devil", but really it's not that bad when used selectively, and a lot better than copying the private key to the server.
- viraptor 6y ago
  If you're cloning a specific application, the server could have its own key with read-only access to the repo. But if you're using that for deployment, you could (in AWS) grant the instance access to specific S3 paths and pass a specific artefact URL to be downloaded. (Or something similar for other environments) But maybe you've got a different use case? I'd start with "why are you using git directly on a (production?) server?"
  - corobo 6y ago
    I'm gonna out myself because nobody is giving reasons Why is it bad to git clone on a production server? Let's assume I'm not an idiot please, just misguided. This isn't reddit. Let's also assume I'm using an ssh key that is only used for the purposes of pulling the repo, no write access, never reused (deploy keys as the git* services call them) It's really hard to see these tips as anything but parroting someone else if nobody throws down a reason
    - xyzzy123 6y ago
      I don't think you're outing yourself exactly; this is a scale-dependent question. People will give different answers because their experience is coloured by the size of the systems and organisations they have experience with. At small scale it's fine. Plenty of useful and valuable stuff runs on a handful of servers that have consistent identities etc and people manage them interactively. Process lives in people's heads or (better) a wiki. At large scale it's a completely bonkers thing to do. There are tons of nodes; it doesn't make sense to mutate just one unless something has gone badly wrong. Interactive login to a production system should be triggering an incident or at least linked to one. Really you shouldn't be mutating systems in any kind of "manual" way because that kind of change is supposed to be locked down to authorised deployment methods. The current state of the system has to be legible to other team members and other teams, and the easiest way to do that is by looking at what's gone through the deployment process, which is usually navigable via a dashboard. In the middle, it's possible you could have a deployment system that relies on "git clone" with a key on the instance. That would be a little weird because git is not a great way to store or distribute build artefacts. Not crazy though - could make sense in some situations.

3np 6y ago

Oh, I've seen it plenty times when users want to SSH from server A to server B, they copy their private key from their workstation to server A.

systemvoltage 6y ago
Oh boy... I need to step out into the wilderness more :-D
bsder 6y ago
Urk. Wow. The bigger issue is "Don't copy a private key. Ever. Period." How would you even do this? Don't the various private key containers make this quite difficult?
- chrisan 6y ago
  It is just plain text in linux. Nothing hard to copy about it
midasuni 6y ago
A natural consequence of server admins disabling ssh agent forwarding. All these “security truisms” tend to ignore the real world. When you remove features, people will work around it in a less secure way.
deleted 6y ago
[deleted]
deckard1 6y ago
A result of people not understanding how public/private keys work. They just want it to work, and copy everything over to get what they want done. These same people probably also joke about the marketing folks down the hall leaving post-it notes with their password on their monitor. Security is the first casualty in the battle for convenience.

vorticalbox 6y ago

What if you need to git ssh clone? Can you use your private key locally while your are currently connected to the a server? Genuine question, this is why I have a private key on the server in out office so I can clone our private repos. Can you use your local private key then?

ploxiln 6y ago
Yes, you can pretty easily use "SSH agent forwarding", which grand-parent comment calls "the devil", but really it's not that bad when used selectively, and a lot better than copying the private key to the server.
viraptor 6y ago
If you're cloning a specific application, the server could have its own key with read-only access to the repo. But if you're using that for deployment, you could (in AWS) grant the instance access to specific S3 paths and pass a specific artefact URL to be downloaded. (Or something similar for other environments) But maybe you've got a different use case? I'd start with "why are you using git directly on a (production?) server?"
- corobo 6y ago
  I'm gonna out myself because nobody is giving reasons Why is it bad to git clone on a production server? Let's assume I'm not an idiot please, just misguided. This isn't reddit. Let's also assume I'm using an ssh key that is only used for the purposes of pulling the repo, no write access, never reused (deploy keys as the git* services call them) It's really hard to see these tips as anything but parroting someone else if nobody throws down a reason
  - xyzzy123 6y ago
    I don't think you're outing yourself exactly; this is a scale-dependent question. People will give different answers because their experience is coloured by the size of the systems and organisations they have experience with. At small scale it's fine. Plenty of useful and valuable stuff runs on a handful of servers that have consistent identities etc and people manage them interactively. Process lives in people's heads or (better) a wiki. At large scale it's a completely bonkers thing to do. There are tons of nodes; it doesn't make sense to mutate just one unless something has gone badly wrong. Interactive login to a production system should be triggering an incident or at least linked to one. Really you shouldn't be mutating systems in any kind of "manual" way because that kind of change is supposed to be locked down to authorised deployment methods. The current state of the system has to be legible to other team members and other teams, and the easiest way to do that is by looking at what's gone through the deployment process, which is usually navigable via a dashboard. In the middle, it's possible you could have a deployment system that relies on "git clone" with a key on the instance. That would be a little weird because git is not a great way to store or distribute build artefacts. Not crazy though - could make sense in some situations.