openssh unix dev - Aug 2021 - How can I make SSH with an identity file always demand a password?

On 23.08.21 12:18, Stuart Henderson wrote:
> Other replies have looked at this from the client side and agent caching,
> but you can also require on the server that a password *as well as* a
> public key is offered. That also guards against users who did not use
> a password/passphrase to protect their key.
Or [ fail to use | use a reimplementation that lacks ] the "-c" and
"-t"
options of ssh-add.

However, I seem to remember that at some point (one or two years ago?),
there was an announcement that in future versions of OpenSSH, the server
side may get *told* whether the auth was done with or without *human*
interaction on the client side (i.e., when talking about user keypair
auth, passphrase entered vs. straight out of some agent) and could
reject a non-interactive attempt, which would satisfy the OP's need. Any
news of that, or am I misremembering?

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

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

On Tue, 24 Aug 2021, Jochen Bern wrote:
> On 23.08.21 12:18, Stuart Henderson wrote:
> > Other replies have looked at this from the client side and agent
caching,
> > but you can also require on the server that a password *as well as* a
> > public key is offered. That also guards against users who did not use
> > a password/passphrase to protect their key.
> 
> Or [ fail to use | use a reimplementation that lacks ] the "-c"
and "-t"
> options of ssh-add.
> 
> However, I seem to remember that at some point (one or two years ago?),
> there was an announcement that in future versions of OpenSSH, the server
> side may get *told* whether the auth was done with or without *human*
> interaction on the client side (i.e., when talking about user keypair
> auth, passphrase entered vs. straight out of some agent) and could
> reject a non-interactive attempt, which would satisfy the OP's need.
Any
> news of that, or am I misremembering?
Someone might have asked, but I would have replied that it would not
be reliable as the client could simply lie about whether the attempt
was interactive or not, thereby making it an unreliable signal at the
server.

Since then, FIDO keys have come along. The user-presence/user-verified
bits are probably the closest you can come to this. We fully support
these, but there are caveats - the biggest of which is that you have
to implement your own key attestation flow to ensure the keys that
you're trusting at the server are actually resident on hardware.

-d