-1

In my instance of this problem, my company requires encryption in flight for EVERYTHING, and we use Stash to manage our git repos. In order to have access, you must have an SSH key registered on your Stash user account, and then you must have permission to engage with a given project or repository.

We want to set up a unified development environment on an AWS box so we don't continuously run into problems onboarding new people and setting up their environments again and again (too busy to script up at present time), but Git makes this surprisingly tough. Is there a way to have multiple SSH keys tied into one Git installation and simply change users with git config user.name/email?

patrickjp93
  • 399
  • 4
  • 20

1 Answers1

-1

For this task, I'd ditch Windows and would apt install git-core gitolite on a GNU/Linux box (a VM running which is as cheap as dirt). gitolite is exactly a low-ceremony solution which puts Git behind a single system user and distinguishes individual developers based on their SSH pubkeys. It also allows managing permissions for those developers etc. You control a gitolite instance by pushing changes made in a special administrative Git repository which contains a config file and SSH pubkeys of developers.

Otherwise, yes:

  • Access to an account by means of a pubkey is managed by an SSH server based on the list of keys "authorized" for that account.

    OpenSSH honors a special file named "authorized_keys" located under the ~/.ssh directory of the user.

    The OpenSSH's client also includes a special command ssh-copy-id which is able to update the "~/.ssh/authorized_keys" file with the "identity" of an executing local user—their SSH pubkey—using non-key-based authentication (typically password-based "keyboard interactive").

  • OpenSSH also supports a special modifier, "force_command" for each key in that file, which allows to restrict what commands the connected and authorized user is able to call in its session.

    This makes it possible to lower the attack surface.

Note that gitolite takes care of both of these things automatically.

kostix
  • 51,517
  • 14
  • 93
  • 176
  • While I am a Linux advocate, my company is VERY Windows-centric, and there are a lot of .NET projects we have to convert to Java before I can possibly make a unified Dev environment on Linux. – patrickjp93 Mar 07 '17 at 01:28
  • I've got an impression your question was about setting up a centralized server to host shared Git repositories. Am I correct? If yes, how does this relate to dev. envs.? That just would be a server with SSH access and a bunch of disk space. – kostix Mar 07 '17 at 04:21
  • I keep getting railed for over-explaining my issues, but it's about having one machine be a dev environment on AWS where multiple users can log in, and each should have their own repo copies, and can pull/push/commit with different credentials each. – patrickjp93 Mar 08 '17 at 01:25
  • OK, I see now, thanks. Still not quite grasp the problem with SSH keys then. Could you provide an imaginary checklist of what should happen when you onboard a new dev? Say, 1) A profile is created for this dev on that AWS box; 2) This new dev should somehow get an SSH key which is "known" by all the Git repos that box communicates with. Am I correct regarding (2)? – kostix Mar 08 '17 at 14:52
  • Due to business reqs, the servers can't have multiple profiles/accounts. We log in with different credentials, but everyone can see and touch everything if they can log in. 1)A new dev gets a new directory with his/her own .ssh folder to keep their unique key. 2) you are correct, and that's already handled by an internal API of ours. 3) any dev can edit/commit/pull/push from a unique copy of a repo 4) devs can run a unique copy of a wrapper for git which has unique paths, user names, et al inside and feed it the root of the repo directory as an argument. – patrickjp93 Mar 09 '17 at 03:39
  • I *think* I've managed to grasp what you're after. This problem might be attacked from two fronts. 1) Update your Git wrapper to also set the `GIT_SSH` env. variable which should be set to a script which calls `ssh -i path/to/the/users/ssh_key`. `-i` stands for "identity" and is the private part of the key in SSH parlance. 2) Have the ~/.ssh/config updated for each onboarded dev. This file might include sort-of "virtual hosts" which both refer to a real host and provide host-specific config options--including the path to the SSH key. – kostix Mar 09 '17 at 08:58
  • …so, say, when `dev42` is onboarded, you add an entry named somehow after that dev ("dev42" itself would be OK as well) and add put the pathname to that dev's SSH key there. Then the dev42 uses "dev42" as the name of the host in their Git repo URLs. Alternatively, look for a way to make the SSH client spawned by Git read an alternative config file--maybe there's an env. var for this. Then, each dev would just get a customized SSH client config file. – kostix Mar 09 '17 at 09:01
  • See [this](https://git-scm.com/book/tr/v2/Git-Internals-Environment-Variables) and [this](https://manpages.debian.org/ssh_config). And [this](https://confluence.atlassian.com/bitbucket/configure-multiple-ssh-identities-for-gitbash-mac-osx-linux-271943168.html) (or do a google search for `git`+`"~/.ssh/config"`). – kostix Mar 09 '17 at 09:03