Increase security and usability with numerous accounts

Issue #3363 wontfix
Barry Allard created an issue

Currently: 'conq: repository access denied.' occurs when a public key is invalid for this repo but valid for another account when loaded before the public key desired. This is very painful for users managing multiple projects.

This happens because authentication succeeds 'debug1: Authentication succeeded (publickey).' means that ssh will accept whatever key is there blindly and passes off complete responsibility for authorization to conq. This, unfortunately, leads to fucking the customer.

This setup subtly prevents ssh from retrying normally because authentication has already succeeded.

The most effective solution would be to modify OpenSSH (very carefully, within the realm of possibility) to check for a specific exit value to indicated authorization failure from the restricted environment (shell replacement). This averts heavy, high-maintenance customization of OpenSSH when the existing 'conq' script has already been proven to implement the specific authorization necessary. Simply return the authorization failure exit code in conq for 'repository access denied, and OpenSSH would then retry the next method/key available.

Proposed /etc/ssh/sshd_config: \ ScriptedAuthorization yes \ ScriptedAuthorizationFailsOnExitCode 120 # The restricted environment (shell replacement) must return this value (i.e., 120) to signify authorization failure, auth will be retried with the next available key/method.

Comments (2)

  1. Charles McLaughlin

    Hi Barry,

    Thanks for the suggestion. I think you understand in this case your authentication passed, but your authorization can still fail if you're denied access to a specific private repository. If I understand you correctly, you're suggesting we let the client renegotiate authentication in that case (by trying another key), so there will be another attempt at authorization.

    The public key you upload to Bitbucket is not really associated with any particular repository, it's associated with your account. That allows you to authenticate. Whether you're allowed to access a repository over ssh is a separate issue. Again, I think you understand all that.

    While we appreciate your suggestion, there is a much easier way for you to solve this problem. The common approach is to make the configuration changes on the client side, either in your ssh config or your Git or Mercurial configs. For instance, Mercurial allows you to specify keys on the command line:

    hg clone -e 'ssh -C -i /.ssh/id_rsa'

    However, the most common approach is to specify it in your .ssh/config file. Here's an example:

    Host bb_work
      User hg
      Compression Yes
      IdentityFile ~/.ssh/bb_work_id_rsa
    Host bb_personal
      User hg
      Compression Yes
      IdentityFile ~/.ssh/bb_personal_id_rsa

    Then you could run commands such as:

    hg clone ssh://bb_personal/user/repo
    hg clone ssh://bb_work/user/repo

    You'd still have to make a conscious decision about which key to use by choosing the Host, but this works for the majority of our users and DVCS users in general



  2. Log in to comment