Hello, after upgrading 14-CURRENT to recent sources September, the 8th 2021, we realizes today a strange non-standard behaviour when connecting attempts from several clients to 14-CURRENT based machines were made involving sshd.
First discovered on 13-STABLE clients (NanoBSD, router/fw appliance). With non-public-key authentication we copy the config partition tar'ed over to a backup system. This worked great until yesterday. Today the connection is dropped immediately, /var/log/auth.log (sshd log on 14-CURRENT) states: Sep 9 19:19:10 <4.6> thor sshd[1350]: Failed password for user01 from 192.168.11.111 port 24332 ssh2 A usual ssh login attempt also fails this way: Permission denied, please try again. The same behaviour is to observe with Xubuntu 20.04 clients and several other FreeBSD 13.0-RELENG and 13-STABLE clients. Also 14-CURRENT-to-14-CURRENT connection attempts are negative! The only working scheme right now is public key authentication and that is for some scenarios not applicable. What has changed in the recent 14-CURRENT OpenSSH update that dramatically that working schematics do not work any more? By the way, on the target host's sshd, on all instances, settings like these [...] PasswordAuthentication yes ChallengeResponseAuthentication yes UsePAM yes are set explicitely, while "UsePAM" produces an error: /etc/ssh/sshd_config line 89: Unsupported option UsePAM this sound ridiculous, since the usage of that tag is documented in the man page as well as present in the example sshd_config and set yes by default. What is wrong here? How can the sshd issue be fixed? Kind regards and thanks in advance, O. Hartmann -- O. Hartmann