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

Reply via email to