openssh unix dev - Jun 2024 - Proposal to add a DisableAuthentication option to sshd ServerOptions

Hi folks,

I've recently started to work on a patch for openssh that introduces a new
option to disable authentication.
I'd like to explain why I think this might be generally useful, and solicit
opinions on whether such a patch would be acceptable to the maintainers as
a pull request.

*Why is this useful?*

Openssh has useful capabilities such as remote and local port-forwarding,
as well as better terminal management compared to older tools like telnet
that support anonymous login.
With this option, we can use openssh in scenarios where authentication is
not required.

*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.

*Why is this useful when openssh already has **PermitEmptyPassword*?
PermitEmptyPasswords is a reasonable option for many uses, but it requires
that the user actually has an empty password, which is not desirable if we
also want a user to be accessible externally without the risk of a
misconfigured ssh server on port 22.

This additional option allows a user to be accessible without a password in
environments where authorization is granted by other means, even if they
otherwise have a password.


*Is this a patch that you would be willing to entertain?*

Thanks,
~Henry

On 6/26/2024 9:34 PM, Henry Qin wrote:
> Hi folks,
>
> I've recently started to work on a patch for openssh that introduces a
new
> option to disable authentication.
> I'd like to explain why I think this might be generally useful, and
solicit
> opinions on whether such a patch would be acceptable to the maintainers as
> a pull request.
Why not just use a different PAM stack? The new release allows 
specifying the stack name. This should do what you want with no code 
changes using Password / KbdInteractive AuthN.

-- 

Carson

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>