Mailing List Archive

Hi,

Either AddKeysToAgent is enabled or you have ControlMaster set to "yes" or "auto".

--
Iain

?On 8/21/21, 13:21, "openssh-unix-dev on behalf of matthewhtb@danwin1210.me" <openssh-unix-dev-bounces+iain.morgan=nasa.gov@mindrot.org on behalf of matthewhtb@danwin1210.me> wrote:

Hello,

I hope my question is apt for this list.

I am using OpenSSH_8.2p1 on Ubuntu 20.04.

I connect to a remote SSH server with the -i /path/to/file identity file
option. My local machine asks me for a password for the identity file.
This is because I created a password when using ssh-keygen.

However, after I exit from the SSH server, and log back in I am not asked
for a password. Some kind of caching is happening.

Is there a way to force the password to be asked on every occasion when
using an identity file?

I have searched but it looks as if everyone wants to avoid using
passwords, not deliberately attempting to use them.

Thank you.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mindrot.org%2Fmailman%2Flistinfo%2Fopenssh-unix-dev&amp;data=04%7C01%7Ciain.morgan%40nasa.gov%7Cc41933a8fc5641a89b9608d964e131bc%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637651740645924639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BOiMrzPdOE%2FQ5n4Is94pqDBwH%2Bo%2F8HDq6ZFKZFASE9s%3D&amp;reserved=0

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> On 21 Aug 2021, at 22:19 , matthewhtb@danwin1210.me wrote:
>
> Hello,
>
> I hope my question is apt for this list.
>
> I am using OpenSSH_8.2p1 on Ubuntu 20.04.
>
> I connect to a remote SSH server with the -i /path/to/file identity file
> option. My local machine asks me for a password for the identity file.
> This is because I created a password when using ssh-keygen.
>
> However, after I exit from the SSH server, and log back in I am not asked
> for a password. Some kind of caching is happening.

It gets loaded into the ssh-agent for things ssh forwarding

> Is there a way to force the password to be asked on every occasion when
> using an identity file?

unload it from the ssh agent, or remove the ssh agent.

> I have searched but it looks as if everyone wants to avoid using
> passwords, not deliberately attempting to use them.

jumping twenty times an hour between 100 different instances behind jumphosts, you do tend to
focus on only protecting the ssh-agent/key when you aren’t at your desk or the laptop/etc. gets stolen, not while you need to
connect to lots of hosts to type in that 20+ character pass phrase.

I recall there are various settings in the GUI/desktop managers to unload the keys when the screen locker activates
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, Aug 21, 2021 at 5:32 PM hvjunk <hvjunk@gmail.com> wrote:
>
>
> > On 21 Aug 2021, at 22:19 , matthewhtb@danwin1210.me wrote:
> >
> > Hello,
> >
> > I hope my question is apt for this list.
> >
> > I am using OpenSSH_8.2p1 on Ubuntu 20.04.
> >
> > I connect to a remote SSH server with the -i /path/to/file identity file
> > option. My local machine asks me for a password for the identity file.
> > This is because I created a password when using ssh-keygen.
> >
> > However, after I exit from the SSH server, and log back in I am not asked
> > for a password. Some kind of caching is happening.
>
> It gets loaded into the ssh-agent for things ssh forwarding

Many window managers now include an ssh-agent by default. It can be
startling, and destructive when you need to use a particular key for
things like SSH keys for particular git repos.


> > Is there a way to force the password to be asked on every occasion when
> > using an identity file?
>
> unload it from the ssh agent, or remove the ssh agent.

Which OS and window manager are you using? The "ssh-agent -D" command
should always work, but some "wallets" will just keep reloading the
!@#$ keys when running your GUI. Ripping out that "wallet" by the
roots may help.

You might want to turn off "AddKeysToAgent" in your ~/.ssh/config
file, to keep from adding that key to your agents accidentally. Use
"man ssh_config" to review that documenttion, it can be disabled for
all hosts or on a target basis.

> > I have searched but it looks as if everyone wants to avoid using
> > passwords, not deliberately attempting to use them.
>
> jumping twenty times an hour between 100 different instances behind jumphosts, you do tend to
> focus on only protecting the ssh-agent/key when you aren’t at your desk or the laptop/etc. gets stolen, not while you need to
> connect to lots of hosts to type in that 20+ character pass phrase.
>
> I recall there are various settings in the GUI/desktop managers to unload the keys when the screen locker activates

Those are often referred to as "wallets", and yeah. It's distinct from
wallet to wallet. A command to do "ssh-agent -D"
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2021/08/21 20:19, matthewhtb@danwin1210.me wrote:
> Hello,
>
> I hope my question is apt for this list.
>
> I am using OpenSSH_8.2p1 on Ubuntu 20.04.
>
> I connect to a remote SSH server with the -i /path/to/file identity file
> option. My local machine asks me for a password for the identity file.
> This is because I created a password when using ssh-keygen.
>
> However, after I exit from the SSH server, and log back in I am not asked
> for a password. Some kind of caching is happening.
>
> Is there a way to force the password to be asked on every occasion when
> using an identity file?
>
> I have searched but it looks as if everyone wants to avoid using
> passwords, not deliberately attempting to use them.

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. See sshd_config(5):

AuthenticationMethods
Specifies the authentication methods that must be successfully
completed for a user to be granted access. This option must be
followed by one or more lists of comma-separated authentication
method names, or by the single string any to indicate the default
behaviour of accepting any single authentication method. If the
default is overridden, then successful authentication requires
completion of every method in at least one of these lists.

For example, "publickey,password publickey,keyboard-interactive"
would require the user to complete public key authentication,
followed by either password or keyboard interactive authentication.
Only methods that are next in one or more lists are offered at each
stage, so for this example it would not be possible to attempt
password or keyboard-interactive authentication before public key.


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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

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

On 8/24/2021 6:26 PM, Damien Miller wrote:
> 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.

One way to do this is with certificate extensions.
I did that for Shibboleth, AD and gov issues PIV cards years ago. The government
agency CA will only add the Microsoft EKU Smart Card Logon (1.3.6.1.4.1.311.20.2.2)
to the authentication certificate where the key resides on the smart card.
This requires trusting this policy of the CA.
(Never tried that with SSH.)

>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

--

Douglas E. Engert <DEEngert@gmail.com>

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev