Read SSH_AUTH_INFO_0 in addition to using SSH_AUTH_SOCK?

[lizthegrey]

Hi, I'm trying to check whether the SSH key used during initial authentication (rather than once a session is established, SSH_AUTH_SOCK is populated, and we're using sudo etc.) matches a specific allowlist of keys.

I thought about writing my own PAM module but realized that we could reuse 90% of the code already here to read key fingerprints out of a file, etc. -- and just check against the file list a key that sshd already validated for us and passed to us in SSH_AUTH_INFO_0.

Would you accept a pull that did this?

[jbeverly]

TLDR: Probably yes. 8-)

---

So, hypothetically (e.g. when I get free time, which seems to be never...) I have been planning on migrating this to a structure that can be rebased on top of upstream openssh regularly. This work started in https://github.com/jbeverly/pam_ssh_agent_auth-2.0/tree/jamie.2.0_wip and it's been what seems like forever since I looked at it (I don't even recall where I left off)

In principle, that is probably a better place for something like this, and perhaps this is something that might fit in upstream openssh too.

However, since 2.0 is not currently close to release, not functional, and has grown out of date, I'm happy to consider it for this (much) older codebase too (which is at least in working condition). Note that there are some caveats with this older code that might matter to you: This was based on a version of openssh that is too old to understand openssh certificates, and is also missing some of the newer key formats.

I also was wondering if you could explain a little more about what you're planning on doing? I gather from clues in the question that you would use this by adding it onto the PAM auth stack of sshd itself (where we would need to have UsePam in sshd_config) and you want to add some additional checking on the key being referenced in SSH_AUTH_INFO_0 therein. Where my curiosity is piqued is the

SSH key used during initial authentication matches a specific allowlist of keys.

part. Because to my eye, that seems like a description of just normal authorized_keys functionality, and so I'm assuming you are wanting to do something more clever here (for some reason, my first thought was that this might be related to some sort of git+ssh usecase; but I'm just blindly guessing).

[lizthegrey]

We have a mixture of people who are using ssh keys on disk for which we want to mandate use of a second factor with pam_oath.so, and people who are using ssh keys stored in hardware tokens implementing the openpgp smart card interface, that we trust to not need a numerical second factor from a phone.

authorized_keys will let both through, but won't allow us to check against a more restrictive set afterwards without a PAM module.

[lizthegrey]

Leaving myself some notes from when I inevitably get to this: https://github.com/openssh/openssh-portable/blob/9b655dc9c9a353f0a527f0c6c43a5e35653c9503/auth2.c#L785 https://github.com/CERN-CERT/pam_2fa/blob/50986444005e87823b4d625df2114ceccbb6532c/ssh_user_auth.c#L13 https://github.com/jbeverly/pam_ssh_agent_auth/blob/master/pam_ssh_agent_auth.c#L191

[lizthegrey]

Rawr, it seems that the default openssh 7.6p1 still doesn't add it to auth, only before running session and account. Trying to patch a custom openssh and trying to see if we can access SSH_AUTH_INFO_0 now...

[lizthegrey]

Okay, it's necessary to patch one's openssh with https://bugzilla.mindrot.org/attachment.cgi?id=3091, then the info is passed at auth stage.

Mar 24 15:05:23 localhost sshd[5531]: pam_ssh_agent_auth: Got SSH_AUTH_INFO_0: `publickey ssh-rsa AAAAB3...
Mar 24 15:05:23 localhost sshd[5531]: pam_ssh_agent_auth: Attempting authentication: `root' as `elizabeth' using /etc/security/authorized_keys

[wmertens]

I presume this is fixed with your PR?

[lizthegrey]

Affirm, my PR last year fixed it, but it's not yet part of a tagged release.