Kubernetes Secret ssh-publickey attribute misused for SSH publickey cert.
Closed this issue · 2 comments
In #211 the SSH authentication with public key certificate was added.
Integration in Kubernetes relies on following Kubernes Secret
base attributes:
ssh-privatekey
for SSH private keyssh-publickey
for SSH public key certificate, not the raw public key
(plus shorter names and custom names set via annotation).
For existing deployments (and even for sshpiper administrators) it can be confusing to use ssh-publickey
attribute not for actual SSH public key (although for usual client authentication, only the private key is required to be used by sshpiper), but for public key certificate. This then might lead to misunderstandings and errors like:
2023-08-30T10:35:00.822424808Z time="2023-08-30T10:35:00Z" level=error msg="cannot create upstream for 192.168.39.189:34408 (username [test-abc01]) with public key auth: Failed to convert the caPublicKey to an ssh.Certificate"
There can be deployments which store a SSH public/private keypair in the same secret under very same names (ssh-privatekey
and ssh-publickey
) and they reference this secret from Pipe
for sshpiper client configuration and in deployment for upstream server configuration (TBH, also our case).
I would propose to use different attribute name, which is clear about what value it carries. E.g., instead of ssh-publickey
use ssh-publickey-cert
.
agreed to change the name to -cert for better accuracy
changing crd is a big headache
ssh-publickey-cert
supported
ssh-publickey
is now deprecated