Home / Alt manpages / openssl-srp(1ssl)

  • openssl-srp(1ssl)
  • OpenSSL command
  • linux

Maintain an OpenSSL SRP Verifier File Safely

You will finish with a small workflow for adding, listing, changing and removing users in an OpenSSL SRP verifier file. The examples use the openssl srp command from OpenSSL 3.6.1 on this machine. The installed Debian package record is OpenSSL 3.0.13, so check the binary you actually run before copying the examples into a deployment.

Allow about fifteen minutes for a first test. You need the OpenSSL command and a path where you can create a private file. The command is deprecated, and it manages an old SRP password-file format rather than a general user database. Do not introduce it into a new service without first checking that the service still supports this format.

1. Check the binary and its warning

Start with read-only checks. No elevated privileges are needed when the verifier file belongs to your user:

$ command -v openssl
/home/linuxbrew/.linuxbrew/bin/openssl
$ openssl version
OpenSSL 3.6.1 27 Jan 2026
$ openssl srp -help
Usage: srp [options] [user...]

The manual describes srp as deprecated. That is a compatibility warning, not a reason to change an existing verifier file immediately. It is a reason to keep the workflow isolated, record the OpenSSL version, and plan a migration if the consuming service offers a supported authentication mechanism.

Checkpoint: make sure command -v points to the OpenSSL installation you intend to use. A shell can find a different binary from the one represented by your distribution package.

2. Prepare a private verifier file

With -srpvfile, the command operates directly on the named file. The file must already exist for the first operation on this installation. For a new path, create it without truncating an existing file, then set restrictive permissions:

$ umask 077
$ touch "$HOME/srp-verifiers.txt"
$ chmod 600 "$HOME/srp-verifiers.txt"
$ ls -l "$HOME/srp-verifiers.txt"
-rw------- 1 your-user your-group 0 ... /home/your-user/srp-verifiers.txt

This file contains salts and verifiers used to check SRP credentials. It is not the user's clear-text password, but it is still authentication material. Keep it out of source control and backups that are not protected to the same standard. Use sudo only when the service's account or an existing protected directory requires it. If you create the file as root, the service account must be able to read it and ordinary users must not be able to replace it.

Do not overwrite an existing file with the install command. If the path already exists, stop and inspect it first:

$ stat "$HOME/srp-verifiers.txt"
$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list

An empty file produces:

List all users

3. Add one user

Choose one action flag, the verifier file, an SRP group, and the username. The -gn value selects the RFC 5054 group strength for a new verifier. The installed command accepts 1024 as a group identifier:

$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" \
    -add -gn 1024 -userinfo 'staging account' alice
Enter pass phrase for alice:
Verifying - Enter pass phrase for alice:

Enter the SRP password at both prompts. It is deliberately not placed in the command line or in shell history. A successful add exits quietly. Check it immediately:

$ printf 'exit status: %s\n' "$?"
exit status: 0
$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list
List all users
alice

The username is a positional argument, not the value of an option. Quote it if your local account naming rules allow characters that the shell would otherwise interpret. Do not put several unrelated operations in one invocation: -add, -modify, -delete and -list are mutually exclusive.

4. List a whole file or one user

Use -list without a username for every entry, or append one or more usernames to narrow the check:

$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list alice
List all users
alice
$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list bob
List all users
user "bob" does not exist, ignored.

The exact diagnostic wording is version-specific. Use the exit status as well as the text. A missing user is not evidence that the file is missing, corrupt or unreadable. If the command reports that it cannot load or parse the index file, stop before changing anything and check the path, ownership, permissions and whether another tool has written a different file format.

5. Change a verifier

Use -modify for an existing username. This is security-sensitive because it changes the credential that the service will accept. Arrange a maintenance window if the account is active, and tell the user that their old SRP password will stop working:

$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" \
    -modify -gn 1024 -userinfo 'rotated staging account' alice
Enter pass phrase for alice:
Verifying - Enter pass phrase for alice:

Verify the entry remains present:

$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list alice
List all users
alice

The command does not provide a rollback operation. Before a planned modification, make a protected copy and record who approved it:

$ cp --preserve=mode,ownership,timestamps \
    "$HOME/srp-verifiers.txt" "$HOME/srp-verifiers.txt.before-alice-change"

If the change is wrong, stop the dependent service if necessary and restore that copy only after checking its owner and mode. Do not restore a stale copy over newer account changes.

6. Delete a user deliberately

-delete removes the named user from the verifier file. This is destructive and cannot be undone by the command. Confirm the exact username, take a protected backup, and expect clients using that identity to fail afterwards:

$ cp --preserve=mode,ownership,timestamps \
    "$HOME/srp-verifiers.txt" "$HOME/srp-verifiers.txt.before-delete"
$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -delete alice
user "alice" deleted.

Check that the user is gone:

$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list alice
List all users
user "alice" does not exist, ignored.

For recovery, stop changes to the file, compare the backup with the current file, and restore it with an explicit command only when you are sure no later account updates would be lost:

$ install -m 600 "$HOME/srp-verifiers.txt.before-delete" \
    "$HOME/srp-verifiers.txt"
$ openssl srp -srpvfile "$HOME/srp-verifiers.txt" -list alice

If the file is owned by a service account, preserve that ownership as well. A successful restore that the service cannot read is still an outage.

7. Use a configuration section only when needed

The alternative is -config CONFIG_FILE -name SECTION. Use this when the existing OpenSSL setup defines an SRP section and you need the command to select that definition. Otherwise, -srpvfile is easier to audit because the target file is visible in the command. Do not invent a section name or assume the system-wide OpenSSL configuration contains one; inspect the configuration supplied by the service and test against a copy first.

-passin and -passout are for the input and output file password source, using OpenSSL's passphrase-source syntax. They are separate from the interactive SRP password prompts shown above. Do not put secrets directly in process arguments when a safer passphrase source is available.

Done means

  • The binary and version were checked, and the command's deprecated status is understood.
  • The verifier path was selected deliberately, created or inspected with restrictive permissions, and kept out of source control.
  • Each invocation used exactly one action and the expected username list.
  • New or changed users were verified with -list and the immediate exit status.
  • Before modification or deletion, a protected backup existed; recovery would preserve the service account's ownership and access.