Damien Miller <djm@xxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
