Mailing List Archive

"Semi-Trusted" SSH-Keys that also require PAM login
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.

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

AuthenticationMethods publickey,password

I want to be able to specify this per key. Right now, I do a work-around by specifying

command="/usr/bin/sudo /bin/login myusername"

for the "semi-trusted" keys in the login users' authorized_keys, but this has issues when using scp or rsync. (As I
understand, they execute some kind of remote shell or remote daemon, which is overwritten by the command-directive.
Unfortunately, this is where my expertise finds its limits and therefore, I was wondering whether anyone already had
a similar problem and found a solution or whether anyone would have an idea on how to proceed.

My thoughts go in the direction of still using authorized_keys and do something like

command="/verify/pam/login/or/whatever/via/some/script.sh && $SSH_ORIGINAL_COMMAND"

to use a script for external verification (allowing for any kind of additional checking, including PAM, but with a
different configuration) and then continue the normal execution.
Unfortunately, this has not worked for me.


So, is there any solution for this? Might it be as simple as using a different environment variable that I am simply not
aware of? Or could there be an entirely different approach? (Again, I want this for normal login, scp and rsync at
least.)


Thanks to all and best regards,

Jan
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
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
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
On Wed, Oct 21, 2020 at 03:05:38PM +0200, Jan Bergner <jan.bergner@indurad.com> 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.
>
> 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
>
> AuthenticationMethods publickey,password
>
> I want to be able to specify this per key. Right now, I do a work-around by specifying
>
> command="/usr/bin/sudo /bin/login myusername"
>
> for the "semi-trusted" keys in the login users' authorized_keys, but this has issues when using scp or rsync. (As I
> understand, they execute some kind of remote shell or remote daemon, which is overwritten by the command-directive.
> Unfortunately, this is where my expertise finds its limits and therefore, I was wondering whether anyone already had
> a similar problem and found a solution or whether anyone would have an idea on how to proceed.
>
> My thoughts go in the direction of still using authorized_keys and do something like
>
> command="/verify/pam/login/or/whatever/via/some/script.sh && $SSH_ORIGINAL_COMMAND"
>
> to use a script for external verification (allowing for any kind of additional checking, including PAM, but with a
> different configuration) and then continue the normal execution.
> Unfortunately, this has not worked for me.
>
>
> So, is there any solution for this? Might it be as simple as using a different environment variable that I am simply not
> aware of? Or could there be an entirely different approach? (Again, I want this for normal login, scp and rsync at
> least.)
>
> Thanks to all and best regards,
>
> Jan

I can't answer your question, but if you do get this
working this way, make sure that you don't explicitly
use $SSH_ORIGINAL_COMMAND in the command parameter.
That's never the right thing to do. If you do, it will
be re-evaluated by the user's login shell an extra time
before it is finally evaluated and executed, which will
often not do what you want.

Whatever command you put in the command parameter
should just inherit SSH_ORIGINAL_COMMAND in its
environment, without an additional round of shell
evaluation, and then, if the extra validation passes,
perform the equivalent of:

execv('/path/to/sh', ['sh', '-c', env('SSH_ORIGINAL_COMMAND')])

where the sh is the user's login shell (or /bin/sh if
there isn't a login shell listed in /etc/passwd).

This way, the original command will be executed exactly
as ssh would have done it, and so will be able to
support any original command.

cheers,
raf

P.S. If you only want the semi-trusted keys to be able
to execute a particular fixed set of arbitrary commands
(e.g. cronjobs), then an ssh command whitelisting tool
might meet your needs. Examples are:

https://github.com/raforg/sshdo (auto-learn/unlearn, exact commands only)
https://github.com/daethnir/authprogs (manual config, supports regexps)

But these won't help if those keys need to be used for
arbitrary unpredictable commands (e.g. humans).

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
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@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@indurad.com
www.indurad.com <http://www.indurad.com/>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
On Wed, 21 Oct 2020, 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.
>
> 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
>
> AuthenticationMethods publickey,password

Since the main difference here is how much you trust the originating host,
you might want to consider setting up host-based authentication for those
hosts and using a config like:

AuthenticationMethods publickey,password publickey,hostbased

This would allow users to log in with (public key AND password) OR
(public key and host-based).

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
On 22/10/2020 00:12, Jan Bergner wrote:
> 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?"

Would it be sufficient to have an additional layer of authentication
when the client connects from address X, but not address Y?  That is,
you are allowed to skip 2FA when connecting from a trusted IP address?

AuthenticationMethods publickey,password

Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
AuthenticationMethods publickey


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
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
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
Thanks for the tip with environment inheritance; that was helpful in
understanding what is actually going on.
I have done some testing and it seems, this is not the way to go.

If you do just plain "ssh user@host", the SSH_ORIGINAL_COMMAND is empty,
while doing scp or rsync fails with an error from the shell. Thus, I
would probably need to "intercept" at an earlier point, right?

Jan

Am 22.10.20 um 00:47 schrieb raf:
> On Wed, Oct 21, 2020 at 03:05:38PM +0200, Jan Bergner <jan.bergner@indurad.com> 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.
>>
>> 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
>>
>> AuthenticationMethods publickey,password
>>
>> I want to be able to specify this per key. Right now, I do a work-around by specifying
>>
>> command="/usr/bin/sudo /bin/login myusername"
>>
>> for the "semi-trusted" keys in the login users' authorized_keys, but this has issues when using scp or rsync. (As I
>> understand, they execute some kind of remote shell or remote daemon, which is overwritten by the command-directive.
>> Unfortunately, this is where my expertise finds its limits and therefore, I was wondering whether anyone already had
>> a similar problem and found a solution or whether anyone would have an idea on how to proceed.
>>
>> My thoughts go in the direction of still using authorized_keys and do something like
>>
>> command="/verify/pam/login/or/whatever/via/some/script.sh && $SSH_ORIGINAL_COMMAND"
>>
>> to use a script for external verification (allowing for any kind of additional checking, including PAM, but with a
>> different configuration) and then continue the normal execution.
>> Unfortunately, this has not worked for me.
>>
>>
>> So, is there any solution for this? Might it be as simple as using a different environment variable that I am simply not
>> aware of? Or could there be an entirely different approach? (Again, I want this for normal login, scp and rsync at
>> least.)
>>
>> Thanks to all and best regards,
>>
>> Jan
>
> I can't answer your question, but if you do get this
> working this way, make sure that you don't explicitly
> use $SSH_ORIGINAL_COMMAND in the command parameter.
> That's never the right thing to do. If you do, it will
> be re-evaluated by the user's login shell an extra time
> before it is finally evaluated and executed, which will
> often not do what you want.
>
> Whatever command you put in the command parameter
> should just inherit SSH_ORIGINAL_COMMAND in its
> environment, without an additional round of shell
> evaluation, and then, if the extra validation passes,
> perform the equivalent of:
>
> execv('/path/to/sh', ['sh', '-c', env('SSH_ORIGINAL_COMMAND')])
>
> where the sh is the user's login shell (or /bin/sh if
> there isn't a login shell listed in /etc/passwd).
>
> This way, the original command will be executed exactly
> as ssh would have done it, and so will be able to
> support any original command.
>
> cheers,
> raf
>
> P.S. If you only want the semi-trusted keys to be able
> to execute a particular fixed set of arbitrary commands
> (e.g. cronjobs), then an ssh command whitelisting tool
> might meet your needs. Examples are:
>
> https://github.com/raforg/sshdo (auto-learn/unlearn, exact commands only)
> https://github.com/daethnir/authprogs (manual config, supports regexps)
>
> But these won't help if those keys need to be used for
> arbitrary unpredictable commands (e.g. humans).
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@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@indurad.com
www.indurad.com <http://www.indurad.com/>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
Hello Damien, Brian and all,

thanks for the suggestions. I actually had not considered host-based
authentication and looked it up.
As I understand from my first quick reading, I would need to specify the
clients which are allowed to use host-based auth on the server with a
DNS name or an IP, which would not work for a client behind a CG NAT or
in a cellular network.
Or did I get this wrong?

So, this is also an answer to Brian. Right now, I cannot simply use IPs.
(However, it would not be out of reach to simply put all clients on a
private VPN. But I would consider that more of a work-around to the
original problem.)

Thanks and best,
Jan

Am 22.10.20 um 01:31 schrieb Damien Miller:
> On Wed, 21 Oct 2020, 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.
>>
>> 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
>>
>> AuthenticationMethods publickey,password
>
> Since the main difference here is how much you trust the originating host,
> you might want to consider setting up host-based authentication for those
> hosts and using a config like:
>
> AuthenticationMethods publickey,password publickey,hostbased
>
> This would allow users to log in with (public key AND password) OR
> (public key and host-based).
>
> -d
>

--
*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@indurad.com
www.indurad.com <http://www.indurad.com/>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
On 10/23/20 4:32 AM, Jan Bergner wrote:
> Hello Damien, Brian and all,
>
> thanks for the suggestions. I actually had not considered host-based authentication and looked it up.
> As I understand from my first quick reading, I would need to specify the clients which are allowed to use host-based auth on the server with a DNS name or an IP, which would not work for a client behind a CG NAT or in a cellular network.
> Or did I get this wrong?

You can use dynamic DNS to obtain a static DNS name. As your IP
address changes, the DNS record is updated accordingly. DNS spoofing
is not a security risk (beyond DoS) because the host must prove
possession of its secret key. This is the approach I recommend.

> So, this is also an answer to Brian. Right now, I cannot simply use IPs.
> (However, it would not be out of reach to simply put all clients on a private VPN. But I would consider that more of a work-around to the original problem.)

Using IP addresses is not a good idea, unless you are using a VPN
that prevents spoofing.

> Thanks and best,
> Jan

Sincerely,

Demi
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
On Fri, 23 Oct 2020, Jan Bergner wrote:

> Hello Damien, Brian and all,
>
> thanks for the suggestions. I actually had not considered host-based
> authentication and looked it up.
> As I understand from my first quick reading, I would need to specify the
> clients which are allowed to use host-based auth on the server with a DNS name
> or an IP, which would not work for a client behind a CG NAT or in a cellular
> network.
> Or did I get this wrong?

You can use the sshd_config HostbasedUsesNameFromPacketOnly option to
turn off the DNS checking in host-based authentication and rely only
on the correct key being presented (matching one in /etc/ssh/known_hosts).

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: "Semi-Trusted" SSH-Keys that also require PAM login [ In reply to ]
Well, this is more complicated than I would have hoped, but it will
indeed achieve my goal - even, if it does not allow to explicitly
require additional authentication per key.
Thus, I want to thank Demi and Damien for their suggestions.

So, I would set up sshd_config like this:

AuthenticationMethods publickey,password publickey,hostbased

Additionally, I might do an IP-match to relax the requirements for
devices inside a VPN.

One last thing I would consider a nice extra, as it would allow access
from another computer that is trustworthy but has no private key. (Like
a good and competent friend's laptop or something like that.)
Would it be possible to additionally allow password and
google-authenticator?
As I understand it, I can require the password method for the password
and nothing else but the password, while google-authenticator hooked
into PAM works with keyboard-interactive. So I think of something like

AuthenticationMethods publickey,password publickey,hostbased
keyboard-interactive

However, it is not clear to me, what exactly "password" does. Assuming
it also uses PAM, I am not certain, how I would instruct it to require
the second factor for one method (keyboard-interactive) while at the
same time being satisfied with only the password for the other method
(password).

Any thoughts?


Best,

Jan

Am 25.10.20 um 06:47 schrieb Damien Miller:
> On Fri, 23 Oct 2020, Jan Bergner wrote:
>
>> Hello Damien, Brian and all,
>>
>> thanks for the suggestions. I actually had not considered host-based
>> authentication and looked it up.
>> As I understand from my first quick reading, I would need to specify the
>> clients which are allowed to use host-based auth on the server with a DNS name
>> or an IP, which would not work for a client behind a CG NAT or in a cellular
>> network.
>> Or did I get this wrong?
>
> You can use the sshd_config HostbasedUsesNameFromPacketOnly option to
> turn off the DNS checking in host-based authentication and rely only
> on the correct key being presented (matching one in /etc/ssh/known_hosts).
>
> -d
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev