"Semi-Trusted" SSH-Keys that also require PAM login

Jan Bergner jan.bergner at indurad.com
Thu Oct 22 00:05:38 AEDT 2020


Hello all,

in order to connect to my SSH servers from untrusted devices like company computers or my smartphone, I set up 2FA with
google-authenticator hooked into PAM.

However, this is not really 2FA at least for the smartphone, since I use the same device for generating the TANs and it
is also at least inconvenient to always require a new TAN for each connection. I do not want to solely rely on SSH keys
on these devices since - as I pointed out - I do not really trust them.

So, my idea was to use SSH keys but to also require the server's PAM login for these "semi-trusted" keys. But of course,
I want to trust the keys on my own laptop and desktop without an additional PAM password. Therefore, I cannot simply use
something like

AuthenticationMethods publickey,password

I want to be able to specify this per key. Right now, I do a work-around by specifying

command="/usr/bin/sudo /bin/login myusername"

for the "semi-trusted" keys in the login users' authorized_keys, but this has issues when using scp or rsync. (As I
understand, they execute some kind of remote shell or remote daemon, which is overwritten by the command-directive.
Unfortunately, this is where my expertise finds its limits and therefore, I was wondering whether anyone already had
a similar problem and found a solution or whether anyone would have an idea on how to proceed.

My thoughts go in the direction of still using authorized_keys and do something like

command="/verify/pam/login/or/whatever/via/some/script.sh && $SSH_ORIGINAL_COMMAND"

to use a script for external verification (allowing for any kind of additional checking, including PAM, but with a
different configuration) and then continue the normal execution.
Unfortunately, this has not worked for me.


So, is there any solution for this? Might it be as simple as using a different environment variable that I am simply not
aware of? Or could there be an entirely different approach? (Again, I want this for normal login, scp and rsync at
least.)


Thanks to all and best regards,

Jan


More information about the openssh-unix-dev mailing list