Artifactory provides several system-wide settings to control access to different resources. These are found under Artifactory | Security | Settings in the Administration module.
Allow Basic Read of Build Related Info
|This setting gives all users view permissions to published modules for all builds in the system. This is regardless of any specific permissions applied to a particular build. And only applies to anonymous users if the "Apply on Anonymous Access" is enabled.|
API Keys Management
The export target directory on your server.
To revoke all API keys in the system, click Revoke API Keys for All Users.
SSH Server Configuration
Artifactory supports SSH authentication for Git LFS and the JFrog CLI using RSA public and private keys. This allows these tools to exchange sensitive information with the Artifactory server that is authenticated via SSH.
There are two main facets of SSH authentication:
- Server authenticates itself to the client: The server must be authenticated before you send it any confidential data. For example, you should not authenticate a user to the server with the user's password before the server has been authenticated. The server is authenticated in the following manner. When the SSH connection is established, the server sends its public key to the client, and the client matches the key to a list of known public keys stored in a
known_hostsfile. (Before the first ever connection to the server, you must obtain the server's public key by some other means and add it it to the
known_hostsfile manually). This verifies that the server is indeed the owner of the stored public key, since only that server will have the corresponding private key. It also verifies that the server is known (and not an imposter) since its public key is stored in the
- User authenticates itself to the server: This process mirrors the process of the server being authenticated to the client. The user must first provide his public key to the server which stores it in the user's account authorization list. Then, when the user tries to log in, the server sends the user back his public key, and the user must show that he holds the corresponding private key.
SSH is not supported if using Artifactory Saas cloud service.
To configure SSH authentication, you need to execute the following main steps:
Configuring Server Authentication
In this step you will configure Artifactory's SSH authentication parameters. First you need to generate an SSH key pair for Artifactory. For example, on a Linux-based system, you could execute the following command:
Then, to configure Artifactory for SSH authentication, in the Administration module, select Artifactory | Security | SSH Server and fill in the required fields.
Enable SSH Authentication
|When checked, SSH authentication is enabled|
|The port that should be used for an SSH connection|
Custom URL Base
|The Custom Base URL that should be used for SSH connections. Note that this is the same Custom URL Base configured in the Administration module under Configuration | General.|
Public key/Private key
|The key pair used for authentication|
Configuring User Authentication
In this step, you will configure Artifactory with your public key so that you may be authenticated when sending requests to Artifactory from the Git LFS client or from the Artifactory CLI.
First, you need to generate a key pair. For example, on a Linux-based system, you could execute the following command:
Your public and private keys should be created under the
Don't forget to update your public key
Update your public key under the SSH section of your User Profile.
Configuring the Client
To configure your Git LFS client, please refer to Authenticating with SSH.
Signing Keys Management
Artifactory lets you manage a pair of GPG signing keys so you can sign packages for authentication in several formats such as Debian, Opkg and YUM. You can manage your GPG signing keys in the Administration module under Artifactory | Security | Signing Keys.
The way to generate keys is platform dependent.
The example below shows how to generate the public and private keys on Linux:
You also need to specify a pass phrase that must be used together with the signing keys. The pass phrase can be saved, or passed in with a REST API call.
To upload your signing keys, in the Admin tab, go to Admin | Artifactory | Security | Signing Keys.
Once you have specified the key file, click Upload for the corresponding field.
Artifactory will indicate when keys are installed, and you can click on the Public key is installed link to download the public key.
If your signing keys were created with a pass-phrase, enter it in the designated field. You can click "Verify" to make sure the pass-phrase matches the uploaded keys.
Upload your pass-phrase with REST
If you prefer not to upload your pass phrase using the UI, you can set it using the REST API.
Downloading the Public Key
Once you have uploaded your signing keys, you can download your public key whenever needed using the Public key is installed link.
Trusted Keys Management
To create a trust between Distribution, source Artifactory instances, and Artifactory Edge nodes, you will need to deploy the generated GPG key to each service.
You create your signing key using the following:
- Distribution service: Set Signing Key for Distribution REST API
- Source Artifactory and Artifactory Edge node: Set GPG Public Key REST API
For more information, see GPG Signing.
You can upload your Distribution service GPG public key to the source and Edge Artifactory in the Administration module under Artifactory | Security | Trusted Keys.
Some remote repositories (e.g. Red Hat Networks) block access from clients that are not authenticated with an SSL/TLS certificate. Therefore, to use a remote repository to proxy such resources, Artifactory must be equipped with the corresponding SSL/TLS certificate.
Certificates are managed in the Administration module under Artifactory | Security | Certificates.
A certificate entered into this module should be a PEM file that includes both a private key and its corresponding certificate.
To add a new certificate, click New.
Provide the Certificate Alias and copy the certificate contents into the designated area. Alternatively, you can drag and drop the corresponding PEM file into the designated area.
To avoid text errors, we recommend dragging and dropping the PEM file into the designated area
Password-protected PEM files are not supported
Make sure the PEM file you upload is not password-protected.
Using a Certificate with a Remote Repository
When a remote repository proxy's a resource that requires authentication with a certificate, you need to obtain the certificate from the resource's owner and add it to the list of certificates as described above.
Under the remote repository's Other Settings, select the certificate you want to use from the list provided in the SSL/TLS Certificate field.
Proxying a Resource that Uses a Self-Signed Certificates
If the remote resource that your Artifactory remote repository is proxying (e.g. Red Hat Network's server) uses an untrusted server certificate (i.e. it is self-signed and not signed by any known Certificate Authority), you need to import the server's certificate into Artifactory's JVM truststore. To learn more about configuring a Self-Signed Certificate in Artifactory, please refer to Managing TLS Certificates.
You cannot configure a self-signed certificate in Artifactory SaaS
If you are using Artifactory SaaS (as opposed to an on-prem installation), you will not be able to proxy resources that use untrusted (i.e. self-signed) certificates since you do not have access to the Artifactory SaaS JVM truststore.