4 ms·

What's the recommended way to manage git clones on shared computers now? In the past, multiple people would use these computers, and would push and pull using

What's the recommended way to manage git clones on shared computers now? In the past, multiple people would use these computers, and would push and pull using their own github credentials. I'm talking lab computers in a research context, where there is a shared login to the computer, but where we use our own github credentials to access a shared repo we all have commit rights to. Now what are we supposed to do? I don't want to put my ssh key, or an access token or whatever, on a shared computer. My colleagues using that computer should not be able to access my other github repos. I should be entering a password, something I can keep in my head.

efnx 5y ago
You can use an access token (and not store it), or you can use one unique ssh key per machine. But yeah, it looks like for your use case this is not a great change.
devman0 5y ago
You can wrap an ssh key with a password.
swiley 5y ago
In general shared computers should have seperate users, on Linux your user is just an su - away.
- doubleunplussed 5y ago
  In this case the environment is shared and so there is a single user account - this is for example a computer in a laboratory, connected to instruments. Multiple user accounts would defeat the purpose of it being a shared computer. It's a shared computer because everyone is using it for the same thing.
  - swiley 5y ago
    You can have a folder that's g+rwx and just give everyone different accounts for things like git. That's the reason these things exist.
aloisklink 5y ago
Honestly, in the case of a shared computer, I wouldn't recommend even using a password. A lot of employers put monitoring software on their computers, and have keyloggers that can record your passwords. It's probably illegal for them to use the passwords, but I have heard horror stories where employers secretly log into their worker's social media accounts. I'd recommending buying a U2F or FIDO2 security key, and creating a ed25519-sk or ecdsa-sk SSH key, see: https://github.blog/2021-05-10-security-keys-supported-ssh-git-operations/#the-same-ssh-keys-you-already-know-and-love-just-a-little-different https://github.blog/2021-05-10-security-keys-supported-ssh-g... Basically, the SSH key is stored on the hardware key, and for every single git pull/git push you need to do, you must have the security key plugged in. If you're worried about forgetting the key and leaving it plugged in, you could add a password to the SSH key as well, so you're doubly protected.
ajtjp 5y ago
Not necessarily recommended, but something that was done by a real team at a real company. We all had our own GitHub Enterprise accounts. But only one was logged on to each computer. Rather than switch out the accounts when someone else used a computer, we just included the initials of whoever was making the commit in the message. E.g. DU: Fix some bug, if Double Unplussed was making the commit. This only really worked because no one was using a GitHub login that they also used for personal projects - only the corporate ones were connected. And it made the GitHub statistics on who was contributing what completely useless. But it did mean that we could rotate among the shared computers and push easily, and if you did need to ask someone for help when investigating a bug, you could still see who made the changes via git blame - just by looking at the message instead of who Git thought had pushed it. Might not work for your use case, and I'm sure some readers will be horrified, but it worked well enough for us, in an XKCD 1172 (https://xkcd.com/1172/ https://xkcd.com/1172/) style manner.
- doubleunplussed 5y ago
  That's an orthogonal issue, we already use a pre-commit hook that prompts for the committers name instead of caching it. Who commits is one thing, who authenticates a push is another. I guess we could have a shared github account and I could give it commit rights to the specific repositories. But that's still pretty silly that I should have to do that.

efnx 5y ago

You can use an access token (and not store it), or you can use one unique ssh key per machine. But yeah, it looks like for your use case this is not a great change.

devman0 5y ago

You can wrap an ssh key with a password.

swiley 5y ago

In general shared computers should have seperate users, on Linux your user is just an su - away.

doubleunplussed 5y ago
In this case the environment is shared and so there is a single user account - this is for example a computer in a laboratory, connected to instruments. Multiple user accounts would defeat the purpose of it being a shared computer. It's a shared computer because everyone is using it for the same thing.
- swiley 5y ago
  You can have a folder that's g+rwx and just give everyone different accounts for things like git. That's the reason these things exist.

aloisklink 5y ago

Honestly, in the case of a shared computer, I wouldn't recommend even using a password. A lot of employers put monitoring software on their computers, and have keyloggers that can record your passwords. It's probably illegal for them to use the passwords, but I have heard horror stories where employers secretly log into their worker's social media accounts. I'd recommending buying a U2F or FIDO2 security key, and creating a ed25519-sk or ecdsa-sk SSH key, see: https://github.blog/2021-05-10-security-keys-supported-ssh-git-operations/#the-same-ssh-keys-you-already-know-and-love-just-a-little-different https://github.blog/2021-05-10-security-keys-supported-ssh-g... Basically, the SSH key is stored on the hardware key, and for every single git pull/git push you need to do, you must have the security key plugged in. If you're worried about forgetting the key and leaving it plugged in, you could add a password to the SSH key as well, so you're doubly protected.

ajtjp 5y ago

Not necessarily recommended, but something that was done by a real team at a real company. We all had our own GitHub Enterprise accounts. But only one was logged on to each computer. Rather than switch out the accounts when someone else used a computer, we just included the initials of whoever was making the commit in the message. E.g. DU: Fix some bug, if Double Unplussed was making the commit. This only really worked because no one was using a GitHub login that they also used for personal projects - only the corporate ones were connected. And it made the GitHub statistics on who was contributing what completely useless. But it did mean that we could rotate among the shared computers and push easily, and if you did need to ask someone for help when investigating a bug, you could still see who made the changes via git blame - just by looking at the message instead of who Git thought had pushed it. Might not work for your use case, and I'm sure some readers will be horrified, but it worked well enough for us, in an XKCD 1172 (https://xkcd.com/1172/ https://xkcd.com/1172/) style manner.

doubleunplussed 5y ago
That's an orthogonal issue, we already use a pre-commit hook that prompts for the committers name instead of caching it. Who commits is one thing, who authenticates a push is another. I guess we could have a shared github account and I could give it commit rights to the specific repositories. But that's still pretty silly that I should have to do that.