2.2. Authentication Options

suSSHi is your multi-tool Swiss Army Knife when it comes to authentication and authorization. On the client and on the target side, suSSHi supports Public Key authentication, Keyboard-Interactive and Password authentication. Depending on your business requirements, multiple combinations are possible.

What makes suSSHi a masterpiece in authentication is the full integration of all authentication dialogs within the SSH authentication phase. It simplifies client error handling and enables graphical SSH clients with authentication dialogs to display them correctly instead of showing prompts in the terminal session.

2.2.1. Client Auth Methods

suSSHi supports three different methods to authenticate the user to the gateway:

  • SSH Public Key Authentication

  • SSH Keyboard-Interactive Authentication

  • SSH Password Authentication

2.2.2. Target Auth Methods

suSSHi supports four different methods to authenticate against the target system:

  • SSH Public Key Authentication with Gateway Keys

  • SSH Public Key Authentication with User Keys via Agent Forwarding

  • SSH Keyboard-Interactive Authentication

  • SSH Password Authentication

The SSH Keyboard-Interactive and SSH Password Authentications can be further leveraged by using one of the authentication options Static Password, Preserve Password or Dynamic One-Time Password.

2.2.3. Chaining Auth Methods

The target authentication methods will be used more or less independently from the client authentication method used. So it is possible to authenticate the client using public keys while additionally prompting the user for keyboard-interactive authentication sent by the target system.

To guide the user through complex authentication steps for non-public-key authentication suSSHi prefers keyboard-interactive authentication. In this way, meaningful prompts can be rendered for the user, since password authentication prompts that are generated by the client and are also not flexible.

It is helpful to consider the possible combinations individually:

  1. User Public Key to Gateway / Gateway Public Key to Target

    ../_images/auth_methods_chain_1.png

    In this combination, the user authenticates at the suSSHi Gateway using his own SSH public key (RSA, ED25519 or DSA).

    After successful authentication and authorization, the gateway tries to log in at the destination using one of its own gateway keys. At the destination, at least one of the gateway keys must be stored in the authorized keys for the respective target user. In this variant, the user’s public key does not have to be stored on the target.

  2. User Public Key to Gateway / Keyboard-Interactive to Target

    ../_images/auth_methods_chain_2.png

    In this combination, the user authenticates at the suSSHi Gateway using his own SSH public key (RSA, ED25519 or DSA). After successful authentication and authorization, the gateway attempts to log on to the destination using keyboard-interactive authentication. This requires interaction with the user, who enters the target credentials when prompted, which are then passed from the gateway to the destination.

  3. User Public Key to Gateway / Password to Target

    ../_images/auth_methods_chain_3.png

    This authentication is quite similar to the previous one, except that the target system expects a password authentication instead of a keyboard-interactive authentication. Nevertheless, the user is prompted to enter the credentials using the keyboard-interactive method.

  4. User Public Key to Gateway / User Public Key to Target via Agent Forwarding

    ../_images/auth_methods_chain_4.png

    This authentication combination is very interesting if the user wants or has to use his own key material for authentication at the destination. In order to authenticate with the user’s public key at the destination without having to temporarily store the key on the gateway, the suSSHi Gateway must access the client’s SSH agent via the SSH Agent Forwarding mechanism.

    To achieve this, the user must have started a local SSH agent before with his key loaded for authentication at the destination. Furthermore, a corresponding profile must be set up in the Access Rule so that this user should authenticate at the target system via “Public Key - User SSH Auth Agent Forwarding”.

    If the user now accesses the target system via suSSHi, he is first authenticated at the gateway with his SSH public key and then forwarded to the target system after a successful authorization check. To perform authentication at the target, the suSSHi Gateway requests access to the client’s SSH agent within the SSH session and communicates with it to obtain the potential public keys. The SSH agent then matches these keys with the target. If one of the keys is accepted by the target, the suSSHi Gateway requests a valid signature of the public key from the SSH agent and presents it to the target as well. The target then completes the authentication and allows the login.

  5. Keyboard-Interactive to Gateway / Keyboard-Interactive to Target

    ../_images/auth_methods_chain_5.png

    In this case, the user logs into the suSSHi Gateway using the keyboard-interactive method. This can be done with a statically stored user password, or it can be used in suSSHi Gateways custom coding, where the user requests a One-Time Password Token authentication system on the backend to verify the One-Time Password.

    After successful authentication and authorization, the gateway attempts to log in to the destination using keyboard-interactive authentication. This requires interaction with the user, who enters the target credentials when prompted, which are then passed from the gateway to the destination.

  6. Keyboard-Interactive to Gateway / Gateway Public Key to Target

    ../_images/auth_methods_chain_6.png

    In this case, the user logs into the suSSHi Gateway using the keyboard-interactive method. This can be done with a statically stored user password, or it can be used in suSSHi Gateways custom coding, where the user requests a One-Time Password Token authentication system on the backend to verify the One-Time Password.

    After successful authentication and authorization, the gateway tries to log on to the destination using one of its own gateway keys. At the destination, at least one of the gateway keys must be stored in the authorized keys for the respective target user. In this way, the user’s public key does not have to be stored on the target.

  7. Password to Gateway / Password to Target

    ../_images/auth_methods_chain_7.png

    This method is quite similar to the method “Keyboard-Interactive to Gateway / Keyboard-Interactive to Target”, except that the password method is used instead of the keyboard-interactive authentication towards the client and also towards the target.

  8. Password to Gateway / Gateway Public Key to Target

    ../_images/auth_methods_chain_8.png

    This method is again very similar to the “Keyboard-Interactive to Gateway / Gateway Public Key to Target” method, except that towards the client the password method instead of the keyboard-interactive method is used.