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

[Jan Bergner]

Thanks for the tip with environment inheritance; that was helpful in 
understanding what is actually going on.
I have done some testing and it seems, this is not the way to go.

If you do just plain "ssh user at host", the SSH_ORIGINAL_COMMAND is empty, 
while doing scp or rsync fails with an error from the shell. Thus, I 
would probably need to "intercept" at an earlier point, right?

Jan

Am 22.10.20 um 00:47 schrieb raf:
> On Wed, Oct 21, 2020 at 03:05:38PM +0200, Jan Bergner <jan.bergner at indurad.com> wrote:
> 
>> 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
> 
> I can't answer your question, but if you do get this
> working this way, make sure that you don't explicitly
> use $SSH_ORIGINAL_COMMAND in the command parameter.
> That's never the right thing to do. If you do, it will
> be re-evaluated by the user's login shell an extra time
> before it is finally evaluated and executed, which will
> often not do what you want.
> 
> Whatever command you put in the command parameter
> should just inherit SSH_ORIGINAL_COMMAND in its
> environment, without an additional round of shell
> evaluation, and then, if the extra validation passes,
> perform the equivalent of:
> 
>    execv('/path/to/sh', ['sh', '-c', env('SSH_ORIGINAL_COMMAND')])
> 
> where the sh is the user's login shell (or /bin/sh if
> there isn't a login shell listed in /etc/passwd).
> 
> This way, the original command will be executed exactly
> as ssh would have done it, and so will be able to
> support any original command.
> 
> cheers,
> raf
> 
> P.S. If you only want the semi-trusted keys to be able
> to execute a particular fixed set of arbitrary commands
> (e.g. cronjobs), then an ssh command whitelisting tool
> might meet your needs. Examples are:
> 
>    https://github.com/raforg/sshdo (auto-learn/unlearn, exact commands only)
>    https://github.com/daethnir/authprogs (manual config, supports regexps)
> 
> But these won't help if those keys need to be used for
> arbitrary unpredictable commands (e.g. humans).
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

-- 
*Jan Bergner, M.Sc. *
Senior IT Administrator

*indurad GmbH*
*The Industrial Radar Company*

Belvedereallee 5
52070 Aachen, Germany
Office: + 49 241 538070-61
Front Desk: + 49 241 538070-0
Fax: + 49 241 538070-99

jan.bergner at indurad.com
www.indurad.com <http://www.indurad.com/>