Monday, February 10, 2014

[eldos] SSH Authentication methods

SSH (Secure Shell) is an invention of a private company, aimed to provide secure access to remote hosts' console and for other network services (such as file transfer or remote execution of processes). SSH is mostly popular in Unix/Linux world, although servers for Windows platform also exist.
One of SSH protocol family parts is SSH Authentication Protocol. This protocol was created to allow the client software perform verification of server authenticity and also authenticate itself. Since there can be various types of clients (automated scripts or the human operator) on the client side, SSH Authentication Protocol offers various ways of authentication:
  • Public key authentication (main authentication method)
  • Password authentication
  • Host-based authentication
  • Keyboard authentication

Selecting authentication methods

SSH/SFTP client components support all mentioned methods of authentication. To specify, which methods should be used, set the value of AuthenticationTypes property.

Public key authentication

Public key authentication method is the only method that each software (both client and server) is required to implement. This method expects each client to have a key pair (key pair is a pair of keys, properly generated using one of asymmetric encryption algorithms, either RSA or DSA). The client first sends a public key to the server. If the server finds the key in the list of allowed keys, the client encrypts certain data packet using private key and sends the packet to the server together with the public key.
In SSH/SFTP client components public key authentication is done using TElSSHMemoryKeyStorage class. This class is a storage for keys (represented by TElSSHKey class). The application should put a key (which contains both public and private parts) to the storage and attach KeyStorage to ElSSHClient or other SSH/SFTP component via this component's KeyStorage property.

Password authentication

This form of authentication is the simplest one. The user specifies the username (on Unix/Linux systems this is usually system-wide username as specified in /etc/passwd) and corresponding password. Such authentication lets the user have only one set of credentials necessary for authentication.
In SSH/SFTP client components public key authentication is supported via UserName and Password properties.

Host-based authentication

Host-based authentication is used to restrict client access only to certain host. This method is similar to public key authentication, however the server maintains a list of hosts and their public keys (so using the public key on other host won't authenticate the client). As with public key authentication, the application should use TElSSHMemoryKeyStorage class.

Keyboard authentication

Keyboard authentication is the advanced form of password authentication, aimed specifically at the human operator as a client. During keyboard authentication zero or more prompts (questions) is presented to the user. The user should give the answer to each prompt (question). The number and contents of the questions are virtually not limited, so certain types of automated logins are also possible.
SSH/SFTP client components support keyboard authentication via OnAuthenticationKeyboard event. The client application should fill Responses parameter (of the mentioned event) with replies to questions contained in Prompts parameter. Echo parameter specifies if the response should be displayed on the screen or masked as the user types it. The number of responses must be equal to the number of prompts.

Being notified about result of authentication

Once the server has authenticated the client (or failed to do this), the event is fired by SSH/SFTP client components. If the authentication is successful, OnAuthenticationSuccess event is fired, otherwise OnAuthenticationFailure is fired.

Authentication of servers

We have reviewed the ways that the client can use to authenticate itself when connecting to the server. But what about the server? Shouldn't the client know, to what server it has connected?
Unlike SSL, SSH protocol generally doesn't operate with anything useable like X.509 certificates (although some SSH servers support X.509 authentication, certificates are only used as a container for the keys). The only thing the server has is a key pair. The server sends the public key to the client software and the client should decide if it trusts the key. Not very secure, isn't it? The validation process is done using OnKeyValidate event of SSH/SFTP client components of SecureBlackbox. The client can show key's hash to the user, or check the key database or perform some other action to decide if the key is valid.

No comments:

Post a Comment