Security

For security purposes, your Helix administrator can configure the Helix server to require SSL-encrypted connections, user passwords, and to limit the length of time for which your login ticket is valid. The following sections provide details:

SSL-encrypted connections

If your installation requires SSL, make sure your P4PORT is of the form ssl:hostname:port. If you attempt to communicate in plaintext with an SSL-enabled Helix server, the following error message is displayed: 

Failed client connect, server using SSL.
Client must add SSL protocol prefix to P4PORT.

Set P4PORT to ssl:hostname:port, and attempt to reconnect to the server.

The first time you establish an encrypted connection with an SSL-enabled server, you are prompted to verify the server’s fingerprint: 

The authenticity of '10.0.0.2:1818' can't be established,
this may be your first attempt to connect to this P4PORT.
The fingerprint for the key sent to your client is
CA:BE:5B:77:14:1B:2E:97:F0:5F:31:6E:33:6F:0E:1A:E9:DA:EF:E2

Your administrator can confirm whether the displayed fingerprint is correct or not. If (and only if) the fingerprint is correct, use the p4 trust command to add it to your P4TRUST file. If P4TRUST is unset, this file is assumed to be .p4trust in your home directory: 

$ p4 trust
The fingerprint of the server of your P4PORT setting
'ssl:example.com:1818' (10.0.0.2:1818) is not known.
That fingerprint is
CA:BE:5B:77:14:1B:2E:97:F0:5F:31:6E:33:6F:0E:1A:E9:DA:EF:E2
Are you sure you want to establish trust (yes/no)?
Added trust for P4PORT 'ssl:example.com:1818' (10.0.0.2:1818)

If the fingerprint is accurate, enter yes to trust this server. You can also install a fingerprint directly into your trust file from the command line. Run: 

$ p4 trust -p ssl:hostname:port -i fingerprint

where ssl:hostname:port corresponds to your P4PORT setting, and fingerprint corresponds to a fingerprint that your administrator has verified.

From this point forward, any SSL connection to ssl:example.com:1818 is trusted, so long as the server at example.com:1818 continues to report a fingerprint that matches the one recorded in your P4TRUST file.

If the Helix server ever reports a different fingerprint than the one that you have trusted, the following error message is displayed: 

******* WARNING P4PORT IDENTIFICATION HAS CHANGED! *******
It is possible that someone is intercepting your connection
to the Perforce P4PORT '10.0.50.39:1667'
If this is not a scheduled key change, then you should contact
your Perforce administrator.
The fingerprint for the mismatched key sent to your client is
18:FC:4F:C3:2E:FA:7A:AE:BC:74:58:2F:FC:F5:87:7C:BE:C0:2D:B5
To allow connection use the 'p4 trust' command.

This error message indicates that the server’s fingerprint has changed from one that you stored in your P4TRUST file and indicates that the server’s SSL credentials have changed.

Although the change to the fingerprint may be legitimate (for example, your administrator controls the length of time for which your server’s SSL credentials remain valid, and your server’s credentials may have expired), it can also indicate the presence of a security risk.

Warning

If you see this error message, and your Helix administrator has not notified you of a change to your server’s key and certificate pair, it is imperative that you independently verify the accuracy of the reported fingerprint.

Unless you can independently confirm the veracity of the new fingerprint (by some out-of-band means ranging from the company’s intranet site, or by personally contacting your administrator), do not trust the changed fingerprint.

Connecting to services that require plaintext connections

If your Helix installation requires plaintext (in order to support older Helix applications), set P4PORT to tcp:hostname:port. If you attempt to use SSL to connect to a service that expects plaintext connections, the following error message is displayed: 

Perforce client error:
    SSL connect to ssl:_host_:_port_ failed (Connection reset by peer).
    Remove SSL protocol prefix from P4PORT.

Set P4PORT to tcp:hostname:port (or, if you are using applications at release 2011.1 or earlier, set P4PORT to hostname:port), and attempt to reconnect to the service.

Passwords

Depending on the security level at which your Helix installation is running, you might need to log in to Helix before you can run Helix commands. Without passwords, any user can assume the identity of any other Helix user by setting P4USER to a different user name or specifying the -u option when you issue a p4 command. To improve security, use passwords.

Setting passwords

To create a password for your Helix user, issue the p4 passwd command.

Passwords may be up to 1,024 characters in length. Your system administrator can configure Helix to require “strong” passwords, the minimum length of a password, and if you have been assigned a default password, your administrator can further require that you change your password before you first use Helix.

By default, the Helix server defines a password as strong if it is at least eight characters long and contains at least two of the following:

  • Uppercase letters
  • Lowercase letters
  • Non-alphabetic characters

In an environment with a minimum password length of eight characters, for example, a1b2c3d4, A1B2C3D4, aBcDeFgH would be considered strong passwords.

To reset or remove a password (without knowing the password), Helix superuser privilege is required. If you need to have your password reset, contact your Helix administrator. See the Helix Versioning Engine Administrator Guide: Fundamentals for details.

Using your password

If your Helix user has a password set, you must use it when you issue p4 commands. To use the password, you can:

  • Log into Helix by issuing the p4 login command, before issuing other commands.
  • Set P4PASSWD to your password, either in the environment or in a config file.
  • Specify the -P password option when you issue p4 commands (for instance, p4 -P mypassword submit).
  • Windows or OS X: store your password by using the p4 set -s command. Not advised for sites where security is high. Helix administrators can disable this feature.

Connection time limits

Your Helix administrator can configure the Helix server to enforce time limits for users. Helix uses ticket-based authentication to enforce time limits. Because ticket-based authentication does not rely on environment variables or command-line options, it is more secure than password-based authentication.

Tickets are stored in a file in your home directory. After you have logged in, your ticket is valid for a limited period of time (by default, 12 hours).

Logging in and logging out

If time limits are in effect at your site, you must issue the p4 login command to obtain a ticket. Enter your password when prompted. If you log in successfully, a ticket is created for you in the ticket file in your home directory, and you are not prompted to log in again until either your ticket expires or you log out by issuing the p4 logout command.

To see how much time remains before your login expires, issue the following command: 

$ p4 login -s

If your ticket is valid, the length of time remaining is displayed. To extend a ticket’s lifespan, use p4 login while already logged in. Your ticket’s lifespan is extended by 1/3 of its initial timeout setting, subject to a maximum of your ticket’s initial timeout setting.

To log out of Helix, issue the following command:

$ p4 logout

Working on multiple computers

By default, your ticket is valid only for the IP address of the computer from which you logged in. If you use Helix from multiple computers that share a home directory (typical in many UNIX environments), log in with: 

$ p4 login -a

Using p4 login -a creates a ticket in your home directory that is valid from all IP addresses, enabling you to remain logged into Helix from more than one computer.

To log out from all computers simultaneously, issue the following command:

$ p4 logout -a

For more information about the p4 login and p4 logout commands, see the P4 Command Reference.