Kubernetes Secret ssh-publickey attribute misused for SSH publickey cert.

[vholer]

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 key
• ssh-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.

[tg123]

agreed to change the name to -cert for better accuracy

changing crd is a big headache

[tg123]

ssh-publickey-cert supported

ssh-publickey is now deprecated