slackhq/nebula · error
unknown user %s
Error message
unknown user %s
What it means
The SSH server's public-key authenticator looks up the connecting client's username in the trustedKeys map configured on the SSHServer. If no key set is registered for that user, authentication fails with 'unknown user'. This is the first gate of SSH auth, before the per-key check.
Source
Thrown at sshd/server.go:69
s.authLock.RLock()
defer s.authLock.RUnlock()
for _, ca := range s.trustedCAs {
if bytes.Equal(ca.Marshal(), auth.Marshal()) {
return true
}
}
return false
},
UserKeyFallback: func(c ssh.ConnMetadata, pubKey ssh.PublicKey) (*ssh.Permissions, error) {
pk := string(pubKey.Marshal())
fp := ssh.FingerprintSHA256(pubKey)
s.authLock.RLock()
defer s.authLock.RUnlock()
tk, ok := s.trustedKeys[c.User()]
if !ok {
return nil, fmt.Errorf("unknown user %s", c.User())
}
_, ok = tk[pk]
if !ok {
return nil, fmt.Errorf("unknown public key for %s (%s)", c.User(), fp)
}
return &ssh.Permissions{
// Record the public key used for authentication.
Extensions: map[string]string{
"fp": fp,
"user": c.User(),
},
}, nil
},
}
View on GitHub (pinned to dd8f660c0a)
Solutions
- Set the SSH client's username to the exact user configured under the ssh section (e.g. ssh -l <user>)
- Add the connecting user and its authorized public keys to the nebula config's ssh trusted_keys
- Reload/restart nebula after editing the ssh config so trustedKeys is repopulated
- Verify with `ssh <host> -l <user> -v` which username is being offered
Example fix
// before (nebula.yaml)
ssh:
listen: 127.0.0.1:2222
# no trusted user configured for 'admin'
// after
ssh:
listen: 127.0.0.1:2222
trusted_users:
admin:
- "ssh-ed25519 AAAA... me@host" Defensive patterns
Strategy: validation
Validate before calling
const configuredUser = "admin"
if sshUser !== configuredUser {
throw new Error(`ssh user ${sshUser} is not configured; use -l ${configuredUser}`)
} Try / catch
try {
sshConnect(user, key)
} catch (e) {
if (e.message.includes("unknown user")) {
console.error(`wrong SSH user; expected one of configured trusted_users`)
}
throw e
} Prevention
- Pass the username explicitly: ssh -l <configured-user> and never rely on the OS username
- Keep ssh.trusted_users entries in sync across the fleet via config management
- After enabling the SSH listener, smoke-test the login before depending on it
When it happens
Trigger: An SSH client connects to nebula's SSH debug listener with c.User() not present in s.trustedKeys — i.e. the username was never added via the server's trusted-keys configuration (configSSH / config path).
Common situations: Typo in the ssh.username config value; SSH client using the OS username instead of the configured debug user; SSH listener enabled but trusted keys only registered for a different user.
Related errors
- unknown public key for %s (%s)
- failed to parse private key: %s
- no outside connection
- no inside interface (tun)
- no certificate state
AI-assisted analysis of slackhq/nebula@dd8f660c0a (2026-09-03).
Data as JSON: /api/errors/74cd1a2ee8e28737.
Report an issue: GitHub.