1. Problem description
During a GreePlum cluster password-free configuration process, it is necessary to use ordinary users to implement ssh password-free login. The previous feedback is that the root user can complete the password-free login, but the same configuration for ordinary users does not take effect. It prompts that a password is required.
Site environment:
2. Problem analysis and treatment
2.1. Open debug mode/detailed information mode debugging
As shown in the figure above, after the ssh client sent the secret key, it was not accepted by the server, resulting in a failure to trust the secret key, and an error was reported: we did not send a packet, disable method; the passwoud mode was used for new authentication communication.
2.2. Open debugging mode of sshd service
The service starts a debug mode process:/usr/sbin/sshd -d -p 2222
The client re-initiates the connection to 2222, and observes the information on the service side:
As shown in the figure above, it shows that there is a problem with the permissions of the public key file of the user on the client side; the normal output is as follows:
query related information, you can try: Check the permissions on your home directory, .ssh directory, and the authorized_keys file: If your ssh server is running with 'StrictModes on', it will refuse to use your public keys in the ~/.ssh/authorized_keys file. Your home directory should be writable only by you, ~/.ssh should be 700, and authorized_keys should be 600 .
Check the home directory secret key directory permissions:
It is found that the default permission of ~/.ssh/authorized_keys is 664, and other permissions are normal. After modifying the authorized_keys permission to 600, try again, and ssh passes without password.
Verify as follows:
3. Appendix
3.1 SSH public key authentication problems analysis ideas
Getting more debug info when connecting with your ssh client: Add a ‘-v’ option to your ssh command (e.g. ssh chuyeow@remotehost -v -v -v). Add more ‘-v’ for more detailed debug (you can do up to ‘-v -v -v’ I think).
Debugging on the remote host by running sshd in debug mode: Run ‘/usr/sbin/sshd -d -p 2222′ on the remote host and connect to it. ‘2222′ here is the port number of the sshd process you started on the remote host.
tail the authentication log: Run ‘tail -f /var/log/auth.log’ on the remotehost. You can watch the log as you try to connect via SSH with your key.
Make sure your ssh key agent is running: Do a ‘ps aux|grep ssh-agent’. Make sure your key agent is running. If you’re not using ssh-agent (I like keychain from Gentoo, or SSHKeyChain for Mac OS X), do whatever you have to do to ensure that your keychain is running.
Make sure your private key is added to the ssh key agent: Do a ’ssh-add -l’ to check that ssh-agent has your key. Likewise, if you are using something else, check your keychain application has your private key.
Check the permissions on your home directory, .ssh directory, and the authorized_keys file: If your ssh server is running with ‘StrictModes on’, it will refuse to use your public keys in the ~/.ssh/authorized_keys file. Your home directory should be writable only by you, ~/.ssh should be 700, and authorized_keys should be 600.
3.2 ssh encryption and decryption process
1. The client and server establish an SSH connection, and use the Diffie-Helman key exchange algorithm to negotiate a symmetric key;
2. The client uses the negotiated symmetric key to encrypt the data to be sent, and then send it to the server;
3. The server receives the encrypted data, decrypts it with the negotiated symmetric key, and performs corresponding processing;
4. The server encrypts the data to be sent with the negotiated symmetric key, and then sends it to the client.
5. The client receives the encrypted data, decrypts it using the negotiated symmetric key, and performs corresponding processing.
Data encryption algorithms can generally be divided into three categories: symmetric encryption; asymmetric encryption; one-way encryption.
Symmetric algorithm : The so-called symmetric encryption algorithm uses the same key for encryption and decryption . Its basic algorithms include DES, 3DES, AES and so on. Features: use the same key for encryption and decryption; divide the original data into blocks of fixed size and encrypt them one by one. Defects: too many keys; key distribution.
Asymmetric Algorithms: Keys appear in pairs . The implementation algorithms include RSA, DSA, ELGama, etc. Public key (pubkey): open to everyone; private key (secret key): keep it for yourself, and must ensure its privacy. Features: The data encrypted with the public key can only be decrypted with the private key paired with it; and vice versa. Its main application scenarios are:Digital signature: mainly to allow the receiver to confirm the identity of the sender;
key exchange: the sender encrypts a symmetric key with the public key of the other party and sends it to the other party;
data encryption: due to the slow time of encrypting data, it is generally not used to encrypt data.One-way: the basic algorithms are: MD5, SHA1, etc. Features: Can only be decrypted, but not decrypted; can be used to extract data fingerprints; fixed-length output, avalanche effect (that is, a small change in data content may cause a huge change in the output result). It is generally used to extract the feature code of the file, and a small change in the file data will cause an avalanche effect.
#加密
openssl enc -des3 -a -salt -in a.txt -out txt.file
#解密
openssl enc -d -des3 -a -salt -in txt.file -out a2.txt
