Troubleshooting the problem that openssh still needs to enter password after password-free login

background

A Windows 11 host A in my hand has set up SSH password-free login, but it still needs to enter the password every time it connects to it. Because A is used frequently, it is troublesome to enter the password every time. Take the time to investigate and solve it today. Record it.

Troubleshoot ideas

1. First confirm whether the relevant settings of password-free login are correct.

1.1 Confirm whether the publickey of client B is added to .ssh/authorized_keys of host A.

1.2 Confirm that the key configuration items of C:\ProgramData\ssh\sshd_config of host A are as follows.

PubkeyAuthentication yes
AuthorizedKeysFile    .ssh/authorized_keys

#Match Group administrators
#       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

After the modification, restart the sshd service and try again, still need to enter the password.

2, using the comparison method. B uses the same settings (B is also the same OS), connects B from A, but can achieve password-free login. Using beyondcompare to compare the main configuration files of A&B and found no difference. Simply overwrite all B's configuration files to A. After restarting sshd, B still needs to enter when connecting to A.

This is a little strange.

3. Try to uninstall and reinstall A's openssd, but the problem remains the same.

4. After a search, no valuable clues were found. On second thought, since you have to enter it every time, what about disabling password login in the configuration file. Change PasswordAuthentication in the configuration file to no (default is yes). An error is reported when reconnecting, and the error message is as follows:

Permission denied (publickey,keyboard-interactive)

According to this news, I searched again and finally found something valuable:

Windows 10 Enable SSH server Configure SSH certificate key password-free login to Windows and error 1607 Permission denied request to enter password record - Rain Tears - Who can understand

Inspired by this article, change strictmodes to no (default is yes). Reconnect, and finally no need to enter a password.

root cause analysis

Although the problem seems to be solved, the strictmodes on host B is yes, but password-free login is possible, indicating that there must be other reasons. Continue to analyze. Find the official explanation of strictmodes:

Get started with OpenSSH | Microsoft DocsInstalling OpenSSH Client and Server for Windows.icon-default.png?t=M276https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstusesshd_config(5) - OpenBSD manual pagesicon-default.png?t=M276https://man.openbsd.org/sshd_config

The explanation is as follows: 

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 permissions and ownership are checked unconditionally.

 In this case, check the permissions of the .ssh directory (Properties -> Security), and sure enough, there are some other accounts that can be written.

Note: Compared with host B, the "normal" writable accounts of .ssh are: SYSTEM, user account, and administrators group.

All redundant accounts will be cut off. Then change strictmodes back to yes. Restart the sshd service. Again, finally no need to enter a password.

Summarize

1. The reason why .ssh is writable by other accounts is that the root cause is in the process of dealing with this problem: after Windows is installed, the Microsoft account is used by default to log in, and the automatically generated user document directory is truncated to 5 characters. Manually modify it to the full name. But the document directory name does not automatically follow the change. A series of processing operations are carried out for this purpose. During this process, a temporary account was created, and other accounts were created. As a result, the .ssh directory write permission account under the user account is increased.

2. The process of changing the windows login account folder is also a pit. Hope windows will be more intelligent in the future. Change the user name, folder name, registry, environment variables, etc. can also automatically follow the changes.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=324062140&siteId=291194637