[FishEye Knowledge Base]
SCMs typically support simple username and password combinations for authentication. However, in FishEye and Crucible, more complex authentication methods are supported for the following repository types:
The configuration of these authentication methods in FishEye is described below. Note, the authentication method can also be configured as part of a particular repository's definition.
Although Subversion supports more complex authentication methods like ssh and ssl certificate authentication, these are not currently configurable in FishEye. When using the bundled svnkit library, these are typically configured using Java property definitions.
On this page:
The authentication methods are configured as part of a particular repository definition.
There are four authentication methods for a repository:
When a FishEye repository type supports these authentication methods, you will see an Authentication section during repository configuration (e.g. the "Mercurial Authentication" section in the screenshot below). This section will be available when initially defining a repository configuration and also in the "SCM Details" section when maintaining a repository.
Screenshot: Selecting an authentication method
This is the simplest authentication method. It means that FishEye can connect to the repository using Git or Mercurial without any credentials or authentication. If you have supplied credentials via another mechanism (such as ssh-agent or a default passphrase-less private key for a ssh connection) Git or Mercurial will use this automatically.
This option is appropriate for,
Screenshot: 'No authentication' selected for a local repository
FishEye's access to repositories is always read-only, so it can easily be used with repositories which only require authentication and authorisation for write operations.
If you want to control repository access using SSH keys, you can choose this method of authentication to have FishEye generate and manage the public/private key pair for you. This is the most secure option for ssh access, as the private key is never transmitted across the network.
Click Generate to generate the key pair (see "Generating a SSH key pair" screenshot below). FishEye will generate and store the public and private key pair. The key is specific to the repository being indexed.
Screenshot: Generating a SSH key pair
The public key will be displayed to allow you to copy it to your repository server and to associate the key with your user account (see "Public Key of Generated Key displayed" screenshot below). The private key is stored by FishEye and never exposed to users or administrators.
Screenshot: Public key of generated key displayed
If you wish to change the key, click Remove and then generate a new key.
When using SSH keys, you will typically specify a username as part of the URL you use to access the repository.
Public hosting systems such as Bitbucket and GitHub provide simple web-based mechanisms for associating public keys with your account. For these systems, a generic username is used in the repository URL and it is the key that determines the account. See the screenshots below for examples of how to associate keys with Bitbucket and GitHub accounts.
Screenshot: Key management on Bitbucket
Screenshot: Key management on GitHub
If you are using SSH keys for repository access and already have an SSH key or you would prefer to manage your SSH keys yourself, this authentication method allows you to upload the private key to FishEye. Please note however, that FishEye can only use passphrase-less SSH keys. (To vote for support for private keys with passphrases, see http://jira.atlassian.com/browse/CRUC-5579.)
Generating a key within FishEye, as described above, is our preferred approach to using SSH keys. We believe it is advisable to use a private key for a single purpose. Different access needs should use different keys. This option should only be used if you must use an existing key.
If you choose to use this option, you will be transmitting your private key across the network to your FishEye server. We strongly recommend that you enable https for Fisheye before you do this.
The private key is uploaded by your web browser file upload operation. As soon as FishEye completes the file upload, it verifies that the provided key is in fact a valid private SSH key and that it does not have a passphrase. To change the stored key, remove the current key by clicking Remove, and then upload the new key.
Screenshot: Private key upload
Tip: If you are uploading under OSX and using 10.6 or later, you can press command-shift-period to display hidden files and directories. This makes it easier to access ssh key files stored in their default .ssh directory
This authentication method is used when using http/https to access your repository with a username and password. For these repositories, the repository location URL includes the username for the account and the password is configured in the Password field (see "Password authentication" screenshot below).
Screenshot: Password authentication
It is possible to specify both the username and password in a repository URL. If you do this FishEye will warn you to remove the password from the URL definition, as it would conflict with the password specified in the password field. When using password authentication, FishEye will always manage the password separately from the repository URL.
Screenshot: Do not provide password in URL
error: git was compiled without libcurl support.
The Generate key pair for SSH option is the safest option to use, as private keys are never transmitted across the network. If an attacker gains access to your private key, they have access to all the services that are allowed by that key pair.
Since FishEye only requires read access to your accounts, it is best to create a user that only has read access to the repositories you want to index and add the public key to that user's account settings. This way, even if the private key is compromised, while your source can be accessed, you can easily revoke that user's access and/or remove their public keys and the attacker will not be able to change or modify any of your data.
If you are using a Unix-style system with SSH key authentication and do not want to perform key management in FishEye at all, it is possible to launch FishEye in the context of an
ssh-agent process. When FishEye launches sub-processes to interact with the repository, the ssh command in those sub-processes will inherit access to the ssh keys in the ssh-agent process. This approach would allow you to use ssh keys with passphrases. Please refer to your operating system documentation for more information on
If your FishEye installation is using Windows, you must use OpenSSH for SSH connectivity, rather than alternatives like TortoiseHg or Putty.
Download and install Git for Windows, as this includes OpenSSH. Be careful about the options you choose during the install: