Preface
This article is equivalent to a supplement to the previous article [Original] Three CentOS7 non-root users realize mutual password-free login_DCTANT's blog-CSDN blog
I encountered a problem on site that an old server failed to pass passwords with other servers. Obviously the public key settings in authorized_keys in the .ssh directory were correct, but other servers had to enter their passwords. I thought it would take 2 minutes. It was solved. Unexpectedly, it took half an hour to solve it.
Troubleshooting
1. Authorized_keys file permissions
First check the permissions of the authorized_keys file. Generally speaking, only the current user has editing permissions for this file, and other users do not have editing permissions, that is, 644 or 600 is fine.
If authorized_keys contains the editing permissions of other users, the password exemption will be invalid.
At present, the permissions of this file are correct.
2. Check whether the content in authorized_keys is correct
I have encountered this several times before. Because I used the vi editor when editing the content of authorized_keys, and then pasted it directly without switching to insert mode before pasting, the first s was swallowed as a command to switch functions. , the first letter is missing, causing the password exemption to fail.
Also, the contents of id_rsa.pub of several other servers or the contents of id_rsa.pub of this machine are copied less.
Then there was no problem this time.
3. Check whether the authorized_keys file name is correct
Some people like to type commands by hand, and then the authorized_keys file either misses the last s or misses letters in the middle, which also causes the password exemption to fail. So far, I don’t have this problem here either.
4. View the password-free self
To eliminate the password, you must first ensure that the server is exempt from the password, that is, directly execute:
cp id_rsa.pub authorized_keysThe authorized_keys generated in this way can not only exempt yourself from passwords, but also have the correct permissions.
Then I executed my own ssh remote connection, and found that I need to enter a password for my own ssh connection. It must not be a password-free mistake!
At that time, I felt like my eyes were going dark, and I thought that the problem was serious and had exceeded my understanding.
5. View logs
The log path is /var/log/secure, which needs to be viewed and executed by the root user.
tail -f -n200 /var/log/secure
The log shows Authentication refused: bad ownership or modes for directory /home/dct
problem solved
This is very strange. My dct user must have permissions to the directory /home/dct. How could this problem happen? Then I asked ChatGPT directly and it answered:
The "Authentication refused: bad ownership or modes for directory /home/dct" error usually means that the ownership or permissions of the directory "/home/dct" are incorrectly set, causing the SSH server to deny access during authentication.
To resolve this issue, you can follow these steps:
Check the ownership of the directory: Make sure the ownership of the directory "/home/dct" is configured correctly. For SSH users, this directory should belong to the correct user, which generally corresponds to a user account with corresponding permissions. You can use the following command to change the ownership of a directory:
sudo chown -R <user>:<usergroup> /home/dct
Replace <user> and <usergroup> with the correct user and usergroup.
Check the permission settings of the directory: Make sure the permissions of the directory "/home/dct" are set correctly. For SSH users, the directory's permissions should be set to 700, which will ensure that only the owner can read, write, and execute operations on it. You can use the following command to set the permissions of a directory:
sudo chmod 700 /home/dct
This will set the permissions of the "/home/dct" directory to 700.
Make sure to check and correct the ownership and permission settings of the directory "/home/dct" by following the steps above. If the problem persists, you may want to further examine the SSH server's configuration files and logs to determine if there are other configuration issues or errors.
The user permissions are definitely correct, but there is a problem with the permissions of the user directory! !
I don’t know which online “talent” changed the permissions of the user’s home directory to this, causing the password exemption to fail! !
implement
sudo chmod 700 /home/dctThat solves this problem! It’s been a long time since I’ve seen this. This user folder permission will also cause the password exemption to fail. This is the first time I have encountered it! !
