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_ecdsaAh, 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>
Maybe Matching Threads
- How to get "Enter passphrase" on command line rather than GUI pop-up?
- Identify multiple users doing reverse port FWD with their pubkeys
- Identify multiple users doing reverse port FWD with their pubkeys
- Some wishes regarding revoked keys
- end-to-end encryption