When you use SSH key-based authentication, you have to make sure that, for all users who need to use this technology, the public key is available on the servers where they want to log in. When logging in, the user creates an authentication request that is signed with his private key. This authentication request is matched to the public key of the same user on the server where that user wants to authenticate. If it matches, the user is allowed to come in; if it doesn't, the user is denied access.
Public/private key-based authentication is enabled by default on SUSE Linux Enterprise Server; therefore, only when no keys are present will the server prompt the user for a password. The following summarizes what happens when a user tries to establish an SSH session with a server:
1. If public key authentication is enabled, which by default is the case, SSH checks the .ssh directory in the user's home directory to see whether a private key is present.
2. If a private key is found, SSH creates a packet with some data in it (the salt), encrypts that packet with the private key, and next sends it to the server. With this packet, the public key is sent as well.
3. The server now checks whether a file with the name authorized_keys exists in the home directory of the user. If it doesn't, the user cannot authenticate with his keys. If this file does exist and the public key is an allowed key and also is identical to the key that was previously stored on the server, the server uses this key to check the signature.
4. If the signature could be verified, the user is granted access. If it didn't work out, the server will prompt the user who tries to connect for his password.
All this sounds pretty complicated, but it isn't. Everything is happening transparently, if everything has been set up correctly. Also, you won't even notice a delay. All this ordinarily happens in less than a second.
Was this article helpful?