0

UPDATE: Just to confirm more about my setup in case it wasn't clear:

No private keys are ever shared anywhere.

(1) Human programmers using Mac each have one SSH key (in ~/.ssh/id_rsa) that they use to connect to all my BitBucket repositories (one company account). The public key element is placed in BitBucket to authorise them and that approves that one human for all of my BitBucket repositories.

(2) Ubuntu servers each have their own key pair setup and have one SSH key for each BitBucket repository they are approved to. Each public key is placed in each of the corresponding BitBucket repositories.

Basically I am trying to have one composer.json file (that uses the URL format shown below) work for both humans and servers (i.e. to work when a human has one SSH key to access all my BitBucket repositories (same account) -AND- when a server has individual SSH keys to access each BitBucket repository they are approved for).

--

I need to be able to configure my ~/.ssh/config file to use all these URLS:

git@bitbucket.org:username/repository-abc.git
git@bitbucket.org:username/repository-12345.git
git@bitbucket.org:username/another-repo.git

...but I can't use an alias.

So I CAN'T do this:

git@alias1:username/repository-abc.git
git@alias2:username/repository-12345.git
git@alias3:username/another-repo.git

The reason is that the URLs are to go in a composer.json file that is also used by local development computers that just use one SSH key for all the BitBucket repositories - and aren't configured to understand all the different aliases.

I can configure the server how I want it though and I have the below ~/.ssh/config configuration on the server.

Whenever it tries to read a private key file that isn't valid (e.g. the 2nd/3rd repo will try to read the first one first) it will fail. However, this can sort of work if I selectively enter the SSH key passphrase when it is the correct one, but ignore (just pressing enter) when it is not the correct one.

Host bitbucket.org
 HostName bitbucket.org
 IdentityFile ~/.ssh/alias1_private_key
Host bitbucket.org
 HostName bitbucket.org
 IdentityFile ~/.ssh/alias2_private_key
Host bitbucket.org
 HostName bitbucket.org
 IdentityFile ~/.ssh/alias3_private_key

It would be easy to just configure the aliases, but because the dev computers wouldn't understand that then I am stuck.

Is there a way to do something this below so that it can work for everything?

Host bitbucket.org
 HostName bitbucket.org
 Url git@bitbucket.org:username/repository-abc.git
 IdentityFile ~/.ssh/alias1_private_key
Host bitbucket.org
 HostName bitbucket.org
 Url git@bitbucket.org:username/repository-12345.git
 IdentityFile ~/.ssh/alias2_private_key
user2143356
  • 157
  • 2
  • 7

2 Answers2

1

If I understand correctly, each repository has a different authorized_key, each such key's private half being shared amongst the many users who should be able to access that repository?

If so, your problem is caused by a fundamentally broken setup on the server side. Keys authenticate users, and users are authorised to do certain things; the key should not be used to directly prove authorisation.

The model should be "one key per user, each user's key appearing in many repos", not "one key per repo, each repo's key shared amongst many users". It is because someone is torturing sshd on the server side that you can't find an easy way to solve this on the client side.

I hope that I'm wrong and that someone has a better suggestion, but if they don't, it's the fundamental misuse of sshd's authentication model that's causing the problem.

Edit: OK, your clarification helps, but you're still torturing the model. An Ubuntu server isn't a thing, separate from a user, that can act in its own right; the process that runs on the Ubuntu servers will still run under a particular UID.

UNIX doesn't generally distinguish between things done interactively by a user and things done on his/her behalf in his/her absence, and in trying to so distinguish, you're causing yourself problems (there are a number of exceptions to the rule, like sudo, but even then the exceptions are often bent back to the rule, with eg Default !requiretty and NOPASSWD clauses, for non-interactive use that simulates interactive).

Treat the UID that runs the non-interactive process as if it were a person, which also has one keypair whose public half is used everywhere that process' UID is authorized to go, and the problems will go away.

If there's a good business reason why you can't do that, now would be a good time to tell us.

MadHatter
  • 79,770
  • 20
  • 184
  • 232
  • Hi. I couldn't have been clear in my original question. I've updated it. I don't share private keys at all. The question should be more clear now. Thanks for the answer. I've really been struggling for this and nobody seems to know the answer. Thanks again. – user2143356 May 02 '14 at 09:07
  • Thanks. My setup should in fact be increased security. I use the root user on the server to make SSH connections with BitBucket. I don't allow root login, but I do a "su - root" from another user account to access root. The need for individual SSH keys for a server is so that server can only access certain repositories on BitBucket. I use BitBucket 'deployment keys' to authorise a server to certain repositories. That gives read-only access to the small selection of repositories I choose. I can't see any other way to do it and certainly don't want one server to have access to all repositories. – user2143356 May 02 '14 at 09:43
  • I son't think I could have explained things as I don't understand what you mean by "UNIX doesn't generally distinguish between things done interactively by a user and things done on his/her behalf in his/her absence". I simply log in to the server, do a "su - root", enter the root password and then use that server to pull from BitBucket. – user2143356 May 02 '14 at 09:45
  • **I am no BitBucket expert**; I have "*but with a cursory eye o'erglanced*" the documentation. But it looks to me as if it's BitBucket that is forcing this broken model of authorisation on you; they're using a public key for direct proof of authorisation. If that's so, then the best advice I can give is to get a proper source code management system; this one is unfit for purpose. – MadHatter May 02 '14 at 10:02
0

SSH's config doesn't care anything about the directory paths on each HostName. It cares only about hostnames and they private keys used for the particular hosts.

So you cannot achieve what you want using a single config file.

You would need to be able to use a separate SSH config file for each repository, and then somehow tell git to use that config file with SSH. However, I don't know if SSH config file parameter can be specified with git.

Tero Kilkanen
  • 36,796
  • 3
  • 41
  • 63