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

[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.

> 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.

> Thanks to all and best regards,
> 
> Jan

You're welcome, and best of luck to you.

Sincerely,

Demi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB288B55FFF9C22C1.asc
Type: application/pgp-keys
Size: 3099 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20201021/dae383a6/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20201021/dae383a6/attachment-0001.asc>