On 27.06.24 06:34, Henry Qin wrote:
*Specific use cases:* 1. Combine sshd on an unprivileged port with kubectl port-forward to replace kubectl exec for shelling into containers running in a secure Kubernetes environment. Kubectl exec does not kill processes on disconnect, and does not support remote port forwarding, while ssh does both of these things. 2. Run an unauthenticated ssh server on a port that is accessible only inside a cluster without the risk of someone accidentally exposing a no-password account on an ssh running on port 22.
I'm not very familiar with k8s setups, so I might miss some specific requirements, but if I read correctly between the lines, you say that you have "good" control of a "safe" IP(v4) subnet *and* the accounts SSHing to each other therein, both client and server side.
If so, I don't think that "I don't see right away how those security mechanisms could be(come) useful me" is sufficient to conclude "I should wholesale have them disabled" (instead of coming up with a setup where they *happen* to allow the intended usage, but remain active).
In particular, what I imagine is to have a passphrase-less, more or less "global" user keypair distributed (by template?) to all accounts that may want to act as a client, and have the pubkey listed - with a 'from="..."' option to restrict it to the "safe" client IPs - in the ~/.ssh/authorized of all accounts relevant for the server side.
If pinpointing and templating the relevant accounts in the above way works out, there's no need to implement a kill switch for a security mechanism in sshd, to fiddle with PAM, or even to run a second, non-public sshd on a different port, the clients and servers would simply *happen* to have passwordless logins in(to) the "safe area" configured and ready to go as they're created off their respective templates.
(Bonus points if the authorized_keys entries also come with an 'expiry-time="..."' option and a *new* widely-distributed user keypair gets auto-rolled out in regular intervals, of course ...)
Kind regards, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
