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@xxxxxxxxxxx
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@xxxxxxxxxxx
www.indurad.com <http://www.indurad.com/>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
