Damien Miller <djm at mindrot.org> writes:
> On Mon, 9 Dec 2024, Dmitry Belyavskiy wrote:
>
>> Dear colleagues,
>>
>> Can we somehow improve the UX related to a relatively freshly
>> introduced PerSourcePenalties option?
>>
>> A popular pattern implies installation of the users' keys to a
freshly
>> installed machine using ssh-copy-id script. The default settings
don't
>> allow this command to work normally and causes login failures.
>>
>> A reasonable workaround could be adding some threshold for a number of
>> failures before the penalties are applied.
>
> That's how the penalty system works now.
>
> Can you provide an example session that is failing? The default threshold
> is three authentication failures in a fifteen second period. I guess you
> have more keys than that?
I just bumped into this for ssh-copy-id's CI tests, which broke because
the tests launch loads of intentionally failing login attempts, and then
try a few that are supposed to work (so I'm now disabling
PerSourcePenalties for the test server).
> IMO it's probably ssh-copy-id that needs to change. It looks like it
> filters public keys by trying them against a target host.
That is indeed how it currently works.
> IMO it should check them directly against authorized_keys on the
> target system,
It's not clear to me how that can be reliably achieved. People quite
often add keys via other means, like getting them from LDAP, or having a
system-wide config in addition to the keys in authorized_keys, and
that's for things where the other end is openssh.
ssh-copy-id is also supposed to work for things that are not running
openssh, like dropbear, so I'm not sure what assumptions I can safely
make about what the other end is doing to handle keys.
> as that wouldn't cause login failures and will result in less logspam
> for server operators.
What I could do is notice when people have too many keys, and warn about
the possibility that they'll get locked out. I may well be doing
multiple redundant attempts with the same key (I'll have to check on
that) in which case I could try harder to only test any key once.
I guess for people that have many keys to test, I could take note of how
many failures I get, and could then introduce a delay between the tests
to avoid triggering the default settings.
Can one reset the penalty system's count by having a successful login?
If so I could make a point of logging-in with a working key in between
the key tests (or initiating a password-based login if we don't yet have
a working key, although that seems likely to be a pain for the user --
getting at least one key installed early seems like the way to go)
Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20241210/e7ecda4a/attachment.asc>