Summary

The user is unable to log in using SSH although Access Routes, authenticator settings and so on have been checked and seem correct.

Issue

The user is unable to log in although Access Routes, authenticator settings and so on seem correct.
Note that sshd_config is probably set to strict mode as is recommended.

In BoKS Manager 6.7 and 7.0, an entry is made to the audit log with the following message:

Bad login (ssh auth using ssh_pk from xxx.xxx.x.x). SSH public key strict modes check failed. Public key from files.

Resolution / Workaround

boks_sshd being configured to use strict Mode implies that all keys and authorized_keys files need to be writable only by the user in question (and root). This also applies to the directory and any parent directories.
That is, none of / , /home , /home/user and /home/user/.ssh can have the group or other write bit set. The id_* and the authorized_keys files must not have these set either, and should in fact only be readable by the user (600 permissions).

Correcting the permissions and/or ownership of the files/directories should correct the problem.

Note that, in BoKS Manager 6.7 and 7.0, this is only a problem if using the authorized_keys file as the only user key location. If using "boksdb" as the public key location, the key is never searched in local files. If using "files,boksdb" as the key location, the file lookup fails and the search continues in the BoKS database (boksdb).

This is a generic SSH issue, not specific to BoKS and is controlled by a parameter in sshd_config - StrictModes. The default is on, as is recommended.

The following is an extract from the sshd_config man page on Solaris 10 (other platforms are similar):


StrictModes
Specifies whether sshd(8) should check file modes and
ownership of the user's files and home directory before
accepting login. This is normally desirable because
novices sometimes accidentally leave their directory or
files world-writable. The default is ``yes''. Note
that this does not apply to ChrootDirectory, whose per-
missions and ownership are checked unconditionally.


Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: June 28, 2019