On 10/21/20 7:12 PM, Jan Bergner wrote: > 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. Indeed it is! My concerns all had to do with the integrity of the client and the confidentiality of its memory. I had not considered that you might fully trust the client's integrity, and the confidentiality of its memory, but not the confidentiality of its filesystem. In that case, requiring an extra layer of authentication makes perfect sense. Ironically, QubesOS TemplateVMs are in a similar situation. They have very high integrity, but anything on their root filesystem is accessible to untrusted VMs based on 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 >> >> 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. Those are very valid use-cases that I had not considered. Thanks for mentioning them. >>> Thanks to all and best regards, >>> >>> Jan >> >> You're welcome, and best of luck to you. >> >> Sincerely, >> >> Demi > Best, > > Jan 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
