The SSH protocol (aka Secure Shell) is used to establish secure and reliable communications between two hosts. It supports different authentication methods and uses strong encryption to protect exchanged data. It is possible to use SSH-based communications instead of clear-text remote CLI protocols (telnet, rlogin) and unencrypted file transfer methods (such as FTP). It is also possible to use SSH for forwarding or tunneling a port, X forwarding, building VPN, as a SOCKS proxy and even secure local mounts of remote directories.
SSH client and server should take the following steps to establish secure connection:
- Establish TCP connection between client and server
- Check compatibility of client and server software
- Use Diffie-Hellman algorithm to securely exchange encryption keys. Exchanged keys will be used to establish secure communication protected with symmetric cryptography.
At this step client also informs the server about ID/username it would like to use to authenticate itself.
- Client should verify the server’s public key to protect itself from MITM attacks
- Server and client should select common appropriate methods of client’s authentications. Both client and server should be configured and support those methods
- Client prioritizes a list of selected methods. The client uses elements from an ordered list of methods to authenticate itself. Client switches to a lower-priority method if it fails to authenticate itself with current one
- Client authenticates itself and starts using established secure connection.
SSH authentication methods
SSH generally offers different ways of authentication:
- Public key authentication – Each client uses a key pair to authenticate itself to a server. Server should find the key in the list of allowed keys.
- Password authentication – Client will ask you to enter a password, will encrypt it and use it to authenticate itself to a server.
- Host-based authentication – This method is similar to public key authentication, but client should not only use correct key, but also must connect from correct host.
- Keyboard authentication – Server will use client to present zero or more prompts to client PC operator and request answers from operator.
PS – Different SSH clients and servers are free to implement only subset of existing authentication methods, or even create their own methods. Though public key authentication support is required.
OpenSSH authentication methods
Here is a list of supported configuration parameters to set up different OpenSSH authentications methods:
- ChallengeResponseAuthentication is used to configure keyboard authentication. You should use specific backend send the challenges and check the responses.
- GSSAPIAuthentication – GSSAPI is a IETF standard for strong encrypted authentication. OpenSSH uses GSSAPI and kerberos 5 code to authenticate clients.
- HostbasedAuthentication is used to configure host-based authentication.
- PasswordAuthentication is used to configure password authentication.
- PubkeyAuthentication is used to configure public key authentication.
It is possible to use specified parameters to configure both OpenSSH server and OpenSSH client. Please refer to appropriate man pages for additional information.
It is possible to change the default priorities of used authentication methods for OpenSSH client with PreferredAuthentications configuration parameter.
It is possible to use a sequence of authentication methods to authenticate client connections. Refer the post below for more information.
Troubleshooting SSH authentication
There could be numerous reasons why you ssh client is unable to successfully connect and authenticate itself to your SSH server. It is important to understand that configuration and software issues may not be the case in your environment. Before troubleshooting SSH, you should always confirm that your SSH server is up, running and waiting for incoming connections on correct TCP port; it is also important to check that you have no firewall and routing issues between the client and server to connect. There is one simple option to skip all the checks and get their result: initiate TCP connection to server’s SSH port with telnet client:
$ telnet myserver.example.com 22 Trying 10.10.10.1... Connected to 10.10.10.1. Escape character is '^]'. SSH-2.0-OpenSSH_5.3 ^]
If everything is fine and you got information from server’s side, you could just use Ctrl+] and quit command to shut down your telnet connection and continue troubleshooting.
1. It is impossible to authenticate with password
Your OpenSSH client might generate these errors if it fails to authenticate itself with the password you have provided:
$ ssh testuser@testserver testuser@testserver's password: Permission denied, please try again.
This message indicates that authentication has failed and can be generated due to a number of reasons. Here are some possible troubleshooting steps:
- Confirm that you are using the correct username. OpenSSH client will use your current username if you haven’t configured another one or passed another username among the list of ssh command’s arguments.
- Check if you are using correct username/password to login.
- Check server’s configuration to confirm that it is possible to use the password to authenticate incoming connections.
- You can also check OpenSSH server’s PermitRootLogin configuration parameter if you are using root username to authenticate yourself.
2. It is impossible to authenticate with pubkey
The following error output shows that client is unable to authenticate itself with provided Public Key:
Permission denied (publickey).
There are many possible reasons for Public Key authentication’s failure, so there are many things to check to troubleshoot the issue:
– authorized_keys file and .ssh directory on OpenSSH server should not be available to third parties (only authenticated user should have access to them). Client’s private SSH key should not be available to third parties. Please check the list of requirements below:
Server: ~./ssh permissions should be 700 ~./ssh should be owned by your account ~/.ssh/authorized_keys permissions should be 600 ~/.ssh/authorized_keys should be owned by your account Client should also have: ~/.ssh/config permissions should be 600 ~/.ssh/id_* permissions should be 600
– OpenSSH server should be configured to support Public Key authentication (PubkeyAuthentication configuration parameter).
– Sometimes sysadmins are distributing SSH keys automatically, so it is essential to confirm that correct Public Keys are added to a list of authorized keys on OpenSSH server and there are no bugs in automation.
– If you are using very specific SSH software, you should spend some time to investigate its compatibility with OpenSSH client/server. If your software uses outdated weak cryptography or stores the key in outdated format (DSA), you could face compatibility issues.