skip to content

Walk through the exact CLI steps to set up Maven password encryption from scratch.

level: middleimportance: must knowfreq 50%

answer

  1. master first then server
  2. --encrypt-master-password
  3. --encrypt-password
  4. <settingsSecurity><master>
  5. quote shell special chars

basics

~10 s

First run mvn --encrypt-master-password to create the master, paste its output into ~/.m2/settings-security.xml. Then run mvn --encrypt-password for each server password and paste the {token} into the <server><password> in settings.xml.

solid answer

~40 s

Two-step setup. Step 1: generate the master password with `mvn --encrypt-master-password` (newer Maven prompts interactively; older accepts it inline). It prints an `{...}` token; put that inside a `<settingsSecurity><master>...</master></settingsSecurity>` element in `~/.m2/settings-security.xml`. Step 2: for each repository secret, run `mvn --encrypt-password`, which encrypts using that master and prints another `{...}` token; paste it into the `<server><password>` of `~/.m2/settings.xml`. From then on Maven decrypts transparently. Common gotchas: shells expanding `{`, `}` or special chars (quote the password), and forgetting that the master and server passwords are different things. You can also relocate settings-security.xml to a removable drive via a `<relocation>` path for slightly better hygiene.

code

bash · 8 lines
bash
# 1) create master -> paste into ~/.m2/settings-security.xml
mvn --encrypt-master-password

# 2) encrypt a repo password -> paste into <server><password> in settings.xml
mvn --encrypt-password

# verify (debug log shows auth applied, not the plaintext)
mvn -X dependency:resolve

go deeper

for a junior

Can recall there are two encrypt commands but may confuse order.

for a middle

Executes both steps correctly and knows which token lands in which file.

for a senior

Handles shell-quoting pitfalls, verifies with -X, considers relocation.

for a principal

Standardizes the bootstrap (or replaces it) across the org and CI images.

## The order matters: master first, then server passwords Server-password encryption depends on the master already existing, so you create the master first. ## Step 1 — create the master password Run: ```bash mvn --encrypt-master-password ``` Modern Maven prompts you to type the master secret (so it isn't in shell history); older versions accept it as an argument: `mvn --encrypt-master-password mySecret`. Output looks like `{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}`. Put it in **`~/.m2/settings-security.xml`**: ```xml <settingsSecurity> <master>{jSMOWnoPFgsHVpMvz5VrIt5kRbzGpI8u+9EF1iFQyJQ=}</master> </settingsSecurity> ``` ## Step 2 — encrypt each server password For every repository credential: ```bash mvn --encrypt-password ``` It prompts for the actual repo password, encrypts it with the master, and prints another token like `{COQLCE6Du7v...}`. Paste that into the matching `<server>` in `~/.m2/settings.xml`: ```xml <server> <id>nexus-releases</id> <username>deploy-bot</username> <password>{COQLCE6Du7v...}</password> </server> ``` ## Verify Run any goal that touches the repo (e.g. `mvn -X deploy` or `dependency:resolve`); `-X` debug logs show the decrypted auth being applied without printing the plaintext. ## Gotchas - **Two distinct secrets**: the master (in settings-security.xml) vs. the server password (in settings.xml). Mixing them up is the #1 mistake. - **Shell quoting**: braces and `$` get mangled by bash; prefer the interactive prompt or wrap inline args in single quotes. - **Relocation**: `<settingsSecurity><relocation>/media/usb/settings-security.xml</relocation></settingsSecurity>` points to the real master file elsewhere.

  • What goes in settings-security.xml vs settings.xml?
    settings-security.xml holds the <master> token; settings.xml holds the encrypted per-<server> password token.
  • Why might the printed token break when passed inline in bash?
    Braces and $ are shell-special; bash may expand or strip them. Use the interactive prompt or single-quote the argument.

saying these in an interview costs you the question

  • Encrypting the server password before creating the master
  • Pasting the master token into settings.xml or vice versa
  • Claiming --encrypt-password uses a per-server salt you must manage manually

context

resolving links…