Hi, this is just an idea. I've observed that password authentication typically passes through the server-side PAM authentication modules. This may be useful for instance to unlock an encrypted home directory using the user's password. On the other side, public key authentication may be run passwordless from the client, which is also a great feature, but it does not allow to unlock the home directory. I wonder whether an hybrid authentication method could be implemented, where the password of the user is stored along with the authorized public key in the server, but instead of storing it in plain text, it would be stored encrypted with the public key. So that, I'm proposing a new authentication method that would send the encrypted password to the client, so the client could decrypt it with the private key, and then send it back to the server. Finally, the server would use the decrypted password to authenticate the user against the PAM modules. This way, the user would be able to unlock the home directory, and at the same time, the public key authentication would be passwordless. I'd love to hear your thoughts about this idea. -Eduardo
On ???, 03 ??? 2025, Eduardo Suarez-Santana via openssh-unix-dev wrote:> Hi, > > this is just an idea. > > I've observed that password authentication typically passes through the > server-side PAM authentication modules. This may be useful for instance to > unlock an encrypted home directory using the user's password. > > On the other side, public key authentication may be run passwordless from the > client, which is also a great feature, but it does not allow to unlock the home > directory. > > I wonder whether an hybrid authentication method could be implemented, where > the password of the user is stored along with the authorized public key in the > server, but instead of storing it in plain text, it would be stored encrypted > with the public key.This already can be achieved by specifying multiple values in AuthenticationMethods option. The documentation even provides this example: For example, "publickey,password publickey,keyboard-interactive" would require the user to complete public key authentication, followed by either password or keyboard interactive authentication. -- / Alexander Bokovoy
On 03/08/2025 10:54, Eduardo Suarez-Santana via openssh-unix-dev wrote:> I wonder whether an hybrid authentication method could be implemented, where > the password of the user is stored along with the authorized public key in the > server, but instead of storing it in plain text, it would be stored encrypted > with the public key. > > So that, I'm proposing a new authentication method that would send the > encrypted password to the client, so the client could decrypt it with the > private key, and then send it back to the server. > > Finally, the server would use the decrypted password to authenticate the user > against the PAM modules. > > This way, the user would be able to unlock the home directory, and at the same > time, the public key authentication would be passwordless.The nearest existing mechanism I can think of is SSH agent forwarding. Unfortunately, AFAIK the SSH agent protocol only has a "sign" operation, not a "decrypt" operation. But it is extensible. An example of how a PAM module can interact with SSH agent: https://github.com/uber/pam-ussh
On 03.08.25 11:54, Eduardo Suarez-Santana wrote:> I've observed that password authentication typically passes through the > server-side PAM authentication modules. This may be useful for instance to > unlock an encrypted home directory using the user's password.[...]> I wonder whether an hybrid authentication method could be implemented, where > the password of the user is stored along with the authorized public key in the > server, but instead of storing it in plain text, it would be stored encrypted > with the public key. > > So that, I'm proposing a new authentication method that would send the > encrypted password to the client, so the client could decrypt it with the > private key, and then send it back to the server.My .02: I'm wondering whether there actually is a use case for (or, much resource savings to be obtained by) SSH logins that do *not* make $HOME available. Because if -- there are none, -- you *want* people to do *keypair* auth to log into the server, and -- sshd defers the password auth to PAM (as you said it does, above), I would expect that setting "AuthenticationMethods publickey,password" already does everything that's really required from the *server* side. It would differ from your proposal in that the password would actually come only from the client side, eliminating the need for the (completely new) "server sends encrypted password to client for decryption" part. I'd *guess* that that greatly reduces the amount of coding required, and it would also mean that the security model remains "*all* sensitive material is stored only on the client", as it is with only-keypair-auth currently; might save a lot of thinking about potential new attack surfaces opened by a change. What would remain to be done is to (decrypt as needed on and) send the password from the client to the server in a (semi-)automated way. As the manpage for sshpass(1) will tell you https://linux.die.net/man/1/sshpass that's not something that the OpenSSH devs are terribly fond of, but it *can* be done with third party software (like, surprise, sshpass). In particular, if you have an agent running for GnuPG as well as for SSH, you may want to look at "Example 4" on https://www.redhat.com/en/blog/ssh-automation-sshpass for an idea how to connect the pipes ... Kind regards, -- Jochen Bern Systemingenieur Binect GmbH -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4336 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20250804/3aee72ea/attachment-0001.p7s>