Chapter 2: A deeper insight on authentication
A deeper insight on authentication
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.
Authenticating with public keys
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:
you scan a list of files that contain public keys. each key is sent to the SSH server, until the server acknowledges a key (a key it knows can be used to authenticate the user).
then, you retrieve the private key for this key and send a message proving that you know that private key.
The function ssh_userauth_autopubkey() does this using the available keys in “~/.ssh/”. The return values are the following:
SSH_AUTH_ERROR: some serious error happened during authentication
SSH_AUTH_DENIED: no key matched
SSH_AUTH_SUCCESS: you are now authenticated
SSH_AUTH_PARTIAL: some key matched but you still have to provide an other mean of authentication (like a password).
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:
Retrieve the public key with ssh_import_pubkey_file().
Offer the public key to the SSH server using ssh_userauth_try_publickey(). If the return value is SSH_AUTH_SUCCESS, the SSH server accepts to authenticate using the public key and you can go to the next step.
Retrieve the private key, using the ssh_pki_import_privkey_file() function. If a passphrase is needed, either the passphrase specified as argument or a callback will be used.
Authenticate using ssh_userauth_publickey() with your private key.
Do not forget cleaning up memory using ssh_key_free().
Here is a minimalistic example of public key authentication:
int authenticate_pubkey(ssh_session session) { int rc; rc = ssh_userauth_publickey_auto(session, NULL); if (rc == SSH_AUTH_ERROR) { fprintf(stderr, "Authentication failed: %s\n", ssh_get_error(session)); return SSH_AUTH_ERROR; } return rc; }
Authenticating with a password
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:
int authenticate_password(ssh_session session) { char *password; int rc; password = getpass("Enter your password: "); rc = ssh_userauth_password(session, NULL, password); if (rc == SSH_AUTH_ERROR) { fprintf(stderr, "Authentication failed: %s\n", ssh_get_error(session)); return SSH_AUTH_ERROR; } return rc; }
The keyboard-interactive authentication method
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:
Even the first call can return SSH_AUTH_DENIED or SSH_AUTH_SUCCESS.
The server can send an empty question set (this is the default behavior on my system) after you have sent the answers to the first questions. You must still parse the answer, it might contain some message from the server saying hello or such things. Just call ssh_userauth_kbdint() until needed.
The meaning of “name”, “prompt”, “instruction” may be a little confusing. An explanation is given in the RFC section that follows.
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 occured.
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:
int authenticate_kbdint(ssh_session session) { int rc; rc = ssh_userauth_kbdint(session, NULL, NULL); while (rc == SSH_AUTH_INFO) { const char *name, *instruction; int nprompts, iprompt; name = ssh_userauth_kbdint_getname(session); instruction = ssh_userauth_kbdint_getinstruction(session); nprompts = ssh_userauth_kbdint_getnprompts(session); if (strlen(name) > 0) printf("%s\n", name); if (strlen(instruction) > 0) printf("%s\n", instruction); for (iprompt = 0; iprompt < nprompts; iprompt++) { const char *prompt; char echo; prompt = ssh_userauth_kbdint_getprompt(session, iprompt, &echo); if (echo) { char buffer[128], *ptr; printf("%s", prompt); if (fgets(buffer, sizeof(buffer), stdin) == NULL) return SSH_AUTH_ERROR; buffer[sizeof(buffer) - 1] = '\0'; if ((ptr = strchr(buffer, '\n')) != NULL) *ptr = '\0'; if (ssh_userauth_kbdint_setanswer(session, iprompt, buffer) < 0) return SSH_AUTH_ERROR; memset(buffer, 0, strlen(buffer)); } else { char *ptr; ptr = getpass(prompt); if (ssh_userauth_kbdint_setanswer(session, iprompt, ptr) < 0) return SSH_AUTH_ERROR; } } rc = ssh_userauth_kbdint(session, NULL, NULL); } return rc; }
Authenticating with “none” method
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:
int authenticate_kbdint(ssh_session session) { int rc; rc = ssh_userauth_none(session, NULL); return rc; }
Getting the list of supported authentications
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:
int test_several_auth_methods(ssh_session session) { int method, rc; rc = ssh_userauth_none(session, NULL); if (rc != SSH_AUTH_SUCCESS) { return rc; } method = ssh_userauth_list(session, NULL); if (method & SSH_AUTH_METHOD_NONE) { // For the source code of function authenticate_none(), // refer to the corresponding example rc = authenticate_none(session); if (rc == SSH_AUTH_SUCCESS) return rc; } if (method & SSH_AUTH_METHOD_PUBLICKEY) { // For the source code of function authenticate_pubkey(), // refer to the corresponding example rc = authenticate_pubkey(session); if (rc == SSH_AUTH_SUCCESS) return rc; } if (method & SSH_AUTH_METHOD_INTERACTIVE) { // For the source code of function authenticate_kbdint(), // refer to the corresponding example rc = authenticate_kbdint(session); if (rc == SSH_AUTH_SUCCESS) return rc; } if (method & SSH_AUTH_METHOD_PASSWORD) { // For the source code of function authenticate_password(), // refer to the corresponding example rc = authenticate_password(session); if (rc == SSH_AUTH_SUCCESS) return rc; } return SSH_AUTH_ERROR; }