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

[Jan Bergner]

Hello Demi et al,

first of all, thanks for your reply. I will provide some clarification 
below.

TL;DR: Let us rephrase the question to "How can I require an additional 
layer of authentication for certain SSH keys, but not for all of them?"

Am 21.10.20 um 18:25 schrieb Demi M. Obenour:
> On 10/21/20 9:05 AM, Jan Bergner 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.
> 
> Honestly, this is likely a bad idea.  Not because the extra layer
> of authentication is bad, but because you have no idea what those
> untrusted devices will do.
> 
> For example, there is nothing to prevent a device from injecting a
> backdoor into your ~/.ssh/rc or ~/.profile.  That could do anything you
> could, including creating a fake login session.  If you use sudo, they
> could implant a trojan sudo binary in your $PATH and get root access.
Normally, you would be right, of course, but the devices are not 
completely untrusted, either. Basically, I have three categories of devices:

1. My smartphone
Of course, I do not entirely distrust my smartphone. Otherwise I could 
not really use it for anything.
To be concrete, my concern is the backup.
In order to reliably backup your complete smartphone, you need root 
(which has other disadvantages) or you backup using your 
Google/Samsung/whatever-Account. And I distrust _them_. Think of "The 
Fappening". It is not inconceivable, that someone could get his hands on 
my private key. Then, the last layer of protection is the key's passphrase.
Thus, I thought that requiring the second password (PAM) is a reasonable 
compromise between security and convenience. (On the other hand, using a 
generalized approach like the pseudo-coded
command="/some/script.sh && $SSH_ORIGINAL_COMMAND"
would also allow for stronger authentication requirements.

2. The company laptop with Linux
I have set up this one myself. Therefore, I am also satisfied that it 
won't do anything nasty.
However, the LUKS password is also known to the other company admins - 
whom I trust, but who knows, who will enter the company in the future. 
The bigger issue is, again, the backup which is going to onedrive. 
Therefore, I have the same issue as with my smartphone.

3. The company laptop with Windows
This one is obviously the worst. I was not planning on using my 
"semi-trusted" keys here.


To sum this up, I am probably more paranoid than I would need to be 
considering my setup. On the other hand, I enjoyed giving this issue 
some thought and in order to get it running to my satisfaction, 
everything boils down to the question in my TL;DR:

How can I require an additional layer of authentication for certain SSH 
keys, but not for all of them?

I think this is an interesting question in general, as well.

> 
>> 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
> 
> I strongly recommend only allowing devices you trust to use SSH.
> Why do you need to login from these untrusted devices?  There might
> very well be a safer solution.
> 
> That said, if you must allow SSH from an untrusted device, I strongly
> recommend only allowing SFTP and rsync access, and only allowing it as
> a separate, unprivileged user.  This will solve most of the security
> holes, but you will need to be very careful about local privilege
> escalation vulnerabilities.  If you are on Linux, polyinstantiating
> /tmp will help a little.  If SELinux is in enforcing mode, using a
> low-privileged account (such as user_u or even guest_u) would help
> a lot.
> 
> If you only need to perform monitoring operations, you could use
> command="some custom script here", where the custom script only
> allowed various read-only operations.  For instance, you could use
> command="systemctl status </dev/null" to check if your services
> are running.
That won't do it for me.

One use-case is supporting my family with IT problems. (I could not 
really get rid of that job but I managed to bring all of them to Linux. 
So, the pain is not that bad.)
I don't have issues every week, but sometimes, I really need a shell, 
SSH-port-forwarding or a file transfer. (Be it config or whatever.) But 
then, their problems are usually solved within minutes.

Second, in my company, it can be very exhausting to get something as 
simple as a webserver to provide a file to a system or something like this.
On such occasions - and if it is not private or classified data, of 
course - I can save up to hours if I can just place something on my 
private server and use that for testing.
It is also often helpful for debugging connection issues for my company, 
when I can access a second device (like my server) inside an independent 
network and do the ping/nmap/traceroute-magic from there for comparison.


> 
>> Thanks to all and best regards,
>>
>> Jan
> 
> You're welcome, and best of luck to you.
> 
> Sincerely,
> 
> Demi
Best,

Jan
> 
> 
> _______________________________________________
> 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/>