Hacker News Reader

Comment by doubleunplussed | Hacker News Reader

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.

View on HN

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

You can wrap an ssh key with a password.

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.

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/) style manner.

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.

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

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.

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.

Reply on news.ycombinator.com