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

[Jan Bergner]

Well, this is more complicated than I would have hoped, but it will 
indeed achieve my goal - even, if it does not allow to explicitly 
require additional authentication per key.
Thus, I want to thank Demi and Damien for their suggestions.

So, I would set up sshd_config like this:

AuthenticationMethods publickey,password publickey,hostbased

Additionally, I might do an IP-match to relax the requirements for 
devices inside a VPN.

One last thing I would consider a nice extra, as it would allow access 
from another computer that is trustworthy but has no private key. (Like 
a good and competent friend's laptop or something like that.)
Would it be possible to additionally allow password and 
google-authenticator?
As I understand it, I can require the password method for the password 
and nothing else but the password, while google-authenticator hooked 
into PAM works with keyboard-interactive. So I think of something like

AuthenticationMethods publickey,password publickey,hostbased 
keyboard-interactive

However, it is not clear to me, what exactly "password" does. Assuming 
it also uses PAM, I am not certain, how I would instruct it to require 
the second factor for one method (keyboard-interactive) while at the 
same time being satisfied with only the password for the other method 
(password).

Any thoughts?


Best,

Jan

Am 25.10.20 um 06:47 schrieb Damien Miller:
> On Fri, 23 Oct 2020, Jan Bergner wrote:
> 
>> Hello Damien, Brian and all,
>>
>> thanks for the suggestions. I actually had not considered host-based
>> authentication and looked it up.
>> As I understand from my first quick reading, I would need to specify the
>> clients which are allowed to use host-based auth on the server with a DNS name
>> or an IP, which would not work for a client behind a CG NAT or in a cellular
>> network.
>> Or did I get this wrong?
> 
> You can use the sshd_config HostbasedUsesNameFromPacketOnly option to
> turn off the DNS checking in host-based authentication and rely only
> on the correct key being presented (matching one in /etc/ssh/known_hosts).
> 
> -d
>