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
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: application/pgp-keys
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
