CephCII · Management SecurityManagement Security
Securing the cephadm SSH path
What you'll learn
- Describe how cephadm authenticates to hosts
- Locate and protect the cephadm key
- Constrain what the key can do
- Rotate it without losing orchestration
Prerequisites
None — start here.
Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18
Why this matters in production
The cephadm SSH key grants privileged access to every host in the cluster from a single place, which makes it the broadest secret Ceph creates.
How cephadm authenticates
The active manager holds the private key.
Every managed host carries the corresponding public key in the
authorized_keys of the configured user.
cephadm connects as that user and escalates to run containers.
ceph cephadm get-pub-key
ceph cephadm get-user
# the private key, which lives in the config store
ceph config-key get mgr/cephadm/ssh_identity_key | head -1
It lives in the monitors' config-key store, replicated across the
quorum — not in a file on one host.
grep -c "$(ceph cephadm get-pub-key | awk '{print $2}')" \
~ceph/.ssh/authorized_keys 2>/dev/null || echo "check the configured user"
Protecting it
| Exposure | Control |
|---|---|
| The key in the config-key store | anyone with client.admin can read it |
| The key on disk during bootstrap | remove bootstrap copies afterwards |
The authorized_keys entries | restrict with from= where the manager hosts are stable |
| The escalation path | the configured user’s sudo rules |
# restrict by source address in authorized_keys
# from="10.10.5.11,10.10.5.12" ssh-ed25519 AAAA... ceph-cephadm
The from= restriction limits the key to connections originating at the
manager hosts. It has to be updated when managers move, which is a real
operational cost — worth paying where the manager placement is fixed.
ceph orch ps --daemon-type mgr --format json | python3 -c '
import sys,json
for d in json.load(sys.stdin):
print(d.get("hostname"), d.get("status_desc"))'
What the key can do
Whatever the configured user can do, which by default includes running
containers with device access — that is root-equivalent on the host.
| Approach | Effect |
|---|---|
Connect as root | simplest; the key is root everywhere |
| Connect as a dedicated user with sudo | the key is root everywhere via sudo |
| Restrict the sudo rules | limits what the key reaches, at the cost of breaking operations cephadm needs |
ceph cephadm get-user
There is no configuration that makes this key non-privileged. cephadm
deploys daemons that need device access, so the access it requires is
inherently root-equivalent. The honest posture is to treat it as such
rather than to attempt to constrain it into something it cannot be.
Rotating it
# generate and distribute a new key
ceph cephadm generate-key
ceph cephadm get-pub-key > /tmp/ceph-new.pub
# distribute to every host, then verify
ceph orch host ls --format json | python3 -c '
import sys,json
for h in json.load(sys.stdin): print(h["hostname"])' | while read h; do
ssh-copy-id -f -i /tmp/ceph-new.pub "$(ceph cephadm get-user)@$h"
done
ceph orch host ls
ceph orch ps --refresh | head
Verify orchestration works against every host before removing the old
public key from authorized_keys — a partially distributed new key leaves
hosts unmanageable.
ceph cephadm clear-key # only after the new key is confirmed everywhere
Quiz
Knowledge check · 4 questions
Q1. Where does the cephadm SSH private key live?
Q2. Permitting the cephadm user to run exactly the container commands cephadm needs, and nothing more, still leaves that user with arbitrary root.
Q3. Rotate the cephadm SSH key.
A team suspects the cephadm key may have been exposed and wants to rotate it across 14 hosts without losing orchestration.
Q4. What does a `from=` restriction in `authorized_keys` achieve, and what does it cost?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Treat client.admin as a path to root on every host, not merely control
of Ceph — it can read the cephadm private key from the config-key store.
When rotating that key, distribute the new one and verify orchestration
against every host before removing the old.
Cross-course references
- Kubernetes: a node bootstrap credential grants what the kubelet can do, which is broad
- Linux: management-plane keys are privileged by function, not by configuration