openssh unix dev - Feb 2020 - question about pubkey and passphrase

Hi folks,

Since Docker can bind-mount every .ssh directory I am looking for
some way to forbid unprotected private keys.

AFAICS it is currently not possible on the sshd to verify that
the peer's private key was protected by a passphrase. Can you
confirm?


Regards
Harri

Ultimately, any client can say whatever it wants to the server. So it would be
impossible to 100% guarantee that.

________________________________________
From: openssh-unix-dev <openssh-unix-dev-bounces+kevin.fox=pnnl.gov at
mindrot.org> on behalf of Harald Dunkel <harald.dunkel at aixigo.com>
Sent: Monday, February 10, 2020 6:10 AM
To: openssh-unix-dev at mindrot.org
Subject: question about pubkey and passphrase

Hi folks,

Since Docker can bind-mount every .ssh directory I am looking for
some way to forbid unprotected private keys.

AFAICS it is currently not possible on the sshd to verify that
the peer's private key was protected by a passphrase. Can you
confirm?


Regards
Harri

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://protect2.fireeye.com/v1/url?k=96cfafc7-ca7a907e-96cf85d2-0cc47adc5fce-899a0df4bd35ba36&q=1&e=e42fb84f-994c-4b30-90c6-59a2c0d2b321&u=https%3A%2F%2Flists.mindrot.org%2Fmailman%2Flistinfo%2Fopenssh-unix-dev

On 02/10/2020 03:10 PM, Harald Dunkel wrote:
> Since Docker can bind-mount every .ssh directory I am looking for
> some way to forbid unprotected private keys.
... why aren't you worried about Docker on the *servers* stealing the
(necessarily passphrase-less) *host* privkeys if it can really grab
whatever it likes? Or *TONS* of data it shouldn't have access to, if the
server runs anything perpendicular to that one Docker container's
purpose ...
> AFAICS it is currently not possible on the sshd to verify that
> the peer's private key was protected by a passphrase. Can you
> confirm?
In the general case, the client connecting may have the privkey in the
standard location, elsewhere (-i option), pre-loaded into ssh-agent,
stored in a file with a *different* format (e.g., PuTTY instead of
OpenSSH), etcetera.

In particular in the case of ssh-agent, the software doing the
authentication (ssh-agent, ssh, and sshd) has no information about the
*file* the privkey originally came from (as that was handled by
ssh-add), much less whether that one was protected at that time, or
still is now.

*If* you have enough control over the clients to run a file scan on
*them* and have the result reported back to you every now and then, you
could try to permanently invalidate "offending" privkeys by
distributing
a collection of the corresponding pubkeys to your servers and pointing
sshd at it with the RevokedKeys config.

(Note, however, that offhand, I cannot find a command that allows you to
derive a pubkey from a privkey, or confirm that a given pubkey
corresponds to some (even nonencrypted) privkey. Think "evil user makes
a dozen copies of some newly created, unencrypted privkey, adds the
sysadmins' pubkeys in files with corresponding filenames, and waits for
your next scan".)

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200210/62d9dedf/attachment.p7s>

(Anonymizing the reply I received as the sender apparently chose not to
send it to the list.)

On 02/10/2020 07:30 PM, [someone] wrote:
> On Feb 10, 2020, at 10:03 AM, Jochen Bern <Jochen.Bern at binect.de>
wrote:
>> In particular in the case of ssh-agent [...]
> 
> Yes, but if there is an ssh-agent running and you have a root process, you
> could query the keys in it.
A root process on the client machine should be able to record the
passphrase as the user types it, to name but one option, so that's
pretty much a "game over" situation - short of having the privkey
operations moved to a hardware token with its own input device.

An attacker on the client machine who can merely *communicate* with the
running ssh-agent should not be able to *extract* any privkeys from it.
He can try to *use* them, though - and that's why I advocate to always
use the -c and -t options of ssh-add.

(Not that I would be likely to notice if the attacker were to slip in
one confirmation popup *right* when I'm, e.g., distributing a file to a
couple dozen target machines every once in a while, though. If the popup
were to state the target machine/account, it would be more helpful to me
than now, showing the keypair about to be used.)

(FWIW, I'm using Ksshaskpass and OpenSSH's ssh-agent + ssh-add. IIRC
I've once seen a system/distrib where even the agent was *not*
OpenSSH's, in spite of it using OpenSSH ssh and sshd.)
>> Note, however, that offhand, I cannot find a command that allows you to
>> derive a pubkey from a privkey,
> 
> Presuming you have the key for the privkey you may use
>   ssh-keygen -y -f .ssh/id_ecdsa
Ah, I missed the -y option when I skimmed the manpage, thanks ...

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200210/4414eec7/attachment.p7s>

On Mon, 10 Feb 2020, Harald Dunkel wrote:
> Hi folks,
> 
> Since Docker can bind-mount every .ssh directory I am looking for
> some way to forbid unprotected private keys.
> 
> AFAICS it is currently not possible on the sshd to verify that
> the peer's private key was protected by a passphrase. Can you
> confirm?
That's not possible - the client could simply lie about whether the
key was password-protected and the server has no way to determine the
truth.

However, the new U2F/FIDO key types about to be released in openssh-8.2
do offer some features that might solve your problem. These include
optionally writing an "attestation certificate" that can be used to
prove that a key was unexportably stored in hardware, and signature-
time flags that indicate whether a user explicitly authorised the
signature (by touching the security token).

In the future, it will be possible to PIN-protect FIDO keys and have
this fact attested to in the signature too. I.e. a sshd will be able
to check and optionally refuse authentication by keys that are were not
unlocked by a PIN. I hope to get to this not long after openssh-8.2 is
done.

-d

Hi folks,

On 2020-02-10 23:59, Damien Miller wrote:
> On Mon, 10 Feb 2020, Harald Dunkel wrote:
> 
>> Hi folks,
>>
>> Since Docker can bind-mount every .ssh directory I am looking for
>> some way to forbid unprotected private keys.
>>
>> AFAICS it is currently not possible on the sshd to verify that
>> the peer's private key was protected by a passphrase. Can you
>> confirm?
> 
> That's not possible - the client could simply lie about whether the
> key was password-protected and the server has no way to determine the
> truth.
> 
Thanx very much for your detailed replies. I take this as a confirmation.

Of course I did not mean to blame openssh for this problem.


Regards
Harri

On 02/10/2020 11:59 PM, Damien Miller wrote:
> However, the new U2F/FIDO key types about to be released in openssh-8.2
> do offer some features that might solve your problem. These include
> optionally writing an "attestation certificate" that can be used
to
> prove that a key was unexportably stored in hardware, and signature-
> time flags that indicate whether a user explicitly authorised the
> signature (by touching the security token).
> 
> In the future, it will be possible to PIN-protect FIDO keys and have
> this fact attested to in the signature too. I.e. a sshd will be able
> to check and optionally refuse authentication by keys that are were not
> unlocked by a PIN. I hope to get to this not long after openssh-8.2 is
> done.
What would be the authority that the sshd would need to trust in these
scenarios, some sorta-CA run by the token manufacturer? Or would this
require the user to present his token to a registration desk of the
servers' admins beforehand, thus proving that the keypair going to issue
the signatures *is* on a tamper-proof token?

Can't "all be in the connection", because "the client could
lie" applies
here just as well ...

... oh, and which clock would the time-of-signature info be based on?

(Personally, I'ld rather try fitting a server-issued challenge nonce
into the protocol than tackling the unruly beast of authenticating
timing sources ... any news from ntp's next-gen (v5) auth yet? :-S )

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200211/6eca4be0/attachment.p7s>