libssh
0.11.0
The SSH library
|
In our guided tour, we merely mentioned that the user needed to authenticate. We didn't explain much in detail how that was supposed to happen. This chapter explains better the four authentication methods: with public keys, with a password, with challenges and responses (keyboard-interactive), and with no authentication at all.
If your software is supposed to connect to an arbitrary server, then you might need to support all authentication methods. If your software will connect only to a given server, then it might be enough for your software to support only the authentication methods used by that server. If you are the administrator of the server, it might be your call to choose those authentication methods.
It is not the purpose of this document to review in detail the advantages and drawbacks of each authentication method. You are therefore invited to read the abundant documentation on this topic to fully understand the advantages and security risks linked to each method.
libssh is fully compatible with the openssh public and private keys. You can either use the automatic public key authentication method provided by libssh, or roll your own using the public key functions.
The process of authenticating by public key to a server is the following:
The function ssh_userauth_autopubkey() does this using the available keys in "~/.ssh/". The return values are the following:
The ssh_userauth_publickey_auto() function also tries to authenticate using the SSH agent, if you have one running, or the "none" method otherwise.
If you wish to authenticate with public key by your own, follow these steps:
Here is a minimalistic example of public key authentication:
The function ssh_userauth_password() serves the purpose of authenticating using a password. It will return SSH_AUTH_SUCCESS if the password worked, or one of other constants otherwise. It's your work to ask the password and to deallocate it in a secure manner.
If your server complains that the password is wrong, but you can still authenticate using openssh's client (issuing password), it's probably because openssh only accept keyboard-interactive. Switch to keyboard-interactive authentication, or try to configure plain text passwords on the SSH server.
Here is a small example of password authentication:
The keyboard-interactive method is, as its name tells, interactive. The server will issue one or more challenges that the user has to answer, until the server takes an authentication decision.
ssh_userauth_kbdint() is the the main keyboard-interactive function. It will return SSH_AUTH_SUCCESS,SSH_AUTH_DENIED, SSH_AUTH_PARTIAL, SSH_AUTH_ERROR, or SSH_AUTH_INFO, depending on the result of the request.
The keyboard-interactive authentication method of SSH2 is a feature that permits the server to ask a certain number of questions in an interactive manner to the client, until it decides to accept or deny the login.
To begin, you call ssh_userauth_kbdint() (just set user and submethods to NULL) and store the answer.
If the answer is SSH_AUTH_INFO, it means that the server has sent a few questions that you should ask the user. You can retrieve these questions with the following functions: ssh_userauth_kbdint_getnprompts(), ssh_userauth_kbdint_getname(), ssh_userauth_kbdint_getinstruction(), and ssh_userauth_kbdint_getprompt().
Set the answer for each question in the challenge using ssh_userauth_kbdint_setanswer().
Then, call again ssh_userauth_kbdint() and start the process again until these functions returns something else than SSH_AUTH_INFO.
Here are a few remarks:
Here is a little note about how to use the information from keyboard-interactive authentication, coming from the RFC itself (rfc4256):
3.3 User Interface Upon receiving a request message, the client SHOULD prompt the user as follows: A command line interface (CLI) client SHOULD print the name and instruction (if non-empty), adding newlines. Then for each prompt in turn, the client SHOULD display the prompt and read the user input. A graphical user interface (GUI) client has many choices on how to prompt the user. One possibility is to use the name field (possibly prefixed with the application's name) as the title of a dialog window in which the prompt(s) are presented. In that dialog window, the instruction field would be a text message, and the prompts would be labels for text entry fields. All fields SHOULD be presented to the user, for example an implementation SHOULD NOT discard the name field because its windows lack titles; it SHOULD instead find another way to display this information. If prompts are presented in a dialog window, then the client SHOULD NOT present each prompt in a separate window. All clients MUST properly handle an instruction field with embedded newlines. They SHOULD also be able to display at least 30 characters for the name and prompts. If the server presents names or prompts longer than 30 characters, the client MAY truncate these fields to the length it can display. If the client does truncate any fields, there MUST be an obvious indication that such truncation has occurred. The instruction field SHOULD NOT be truncated. Clients SHOULD use control character filtering as discussed in [SSH-ARCH] to avoid attacks by including terminal control characters in the fields to be displayed. For each prompt, the corresponding echo field indicates whether or not the user input should be echoed as characters are typed. Clients SHOULD correctly echo/mask user input for each prompt independently of other prompts in the request message. If a client does not honor the echo field for whatever reason, then the client MUST err on the side of masking input. A GUI client might like to have a checkbox toggling echo/mask. Clients SHOULD NOT add any additional characters to the prompt such as ": " (colon-space); the server is responsible for supplying all text to be displayed to the user. Clients MUST also accept empty responses from the user and pass them on as empty strings.
The following example shows how to perform keyboard-interactive authentication:
The primary purpose of the "none" method is to get authenticated without any credential. Don't do that, use one of the other authentication methods, unless you really want to grant anonymous access.
If the account has no password, and if the server is configured to let you pass, ssh_userauth_none() might answer SSH_AUTH_SUCCESS.
The following example shows how to perform "none" authentication:
You are not meant to choose a given authentication method, you can let the server tell you which methods are available. Once you know them, you try them one after the other.
The following example shows how to get the list of available authentication methods with ssh_userauth_list() and how to use the result:
The SSH server might send a banner, which you can retrieve with ssh_get_issue_banner(), then display to the user.
The following example shows how to retrieve and dispose the issue banner: