Proposal to add a DisableAuthentication option to sshd ServerOptions

[Jochen Bern]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20240628/ba262091/attachment-0001.p7s>