Authentication

Click on the Authentication option of Local FortressSSH Configuration dialog (launched from Windows Start Menu > Pragma Server Management shortcut) to configure the Authentication settings.

Limit Authentication Attempts

Enable the check box to configure the number of times a user my try to authenticate. Enter your preferred number in the edit box for authentication attempt limits. This value can be overridden by the client.

Password Options



Password: Click on this check box to connect with a valid username and password. Both the username and the password are encrypted as they are passed from the client to the server using the SSH protocol.

Store Password: Use this drop down menu to configure whether ssh user password will be cached / stored or not. Please note that the password stored are twice encrypted using AES-256. The first encryption is with a proprietary key, the second is with the Local System user key. This means that decryption can only be performed using our proprietary key from a process running as the LOCAL_SYSTEM account on the machine on which it was encrypted

 

Public Key Options



Public Key / Certificate: Click on this check box to log in with certificate authentication. Certificate authentication uses public/private key pair to authenticate an user making ssh connection to the server. If certificate authentication fails and password authentication is allowed, the user will be prompted for a password. For more information on certificate authentication, click here.

Allow authentication from registry: This option uses cached certificate information from the registry to authenticate an user. To turn off this option, de-select the check box

Allow authentication from file: This option uses stored certificate information from the authorized_key file to authenticate an user. The authorized_key file is located in the PragmaSSH folder under the user profile. To turn off this option, de-select the check box.

Automatically store keys in registry: Turn this option on when allowing certificate access to automatically store/load keys in the registry (PAD).

Store keys in authorized file: Turn this option on when allowing certificate access to automatically store/load keys in the authorized_key file located in the \AppData\PragmaSSH folder of an user's home directory or user profile.

Authenticate using UPN (if available in certificate): Turn this option on to authentication using UPN. This option uses the UPN in the SAN (Subject Alternative Name) field of the certificate to map the certificate to the user account. This means that association using the PAD or authorizedkeys file is not necessary. Please note that if this option is disabled (unchecked), then either the authorizedkey or the PAD must be enabled (checked) in order to associate the user with the certificate.

Public Key Authentication / Certificate User Mapping

Public Key authentication uses a public/private key pair. The keys can be RSA or DSA. In this authentication scheme, the user provides the server with the public part of the key, and shows that they have the corresponding private part of the key (by signing data with it). For authentication just involving the RSA/DSA key, a mechanism needs to exist to provide authorized mapping between the key and a user. The mapping is provided by the authorized_keys file or PAD (pragma authentication data) mapping. Keys need to be manually placed in these locations or auto loaded using the "Automatically store keys in registry" or "(Automatically) Store keys in authorized file" option. Presently, there is no way to manually load PAD data. Auto loading will allow a user to cache the key information in the authorized key store (file or pad) upon successful password validation.

If the key is wrapped in an X.509v3 certificate, we may not need the authorized key mapping since the certificate contains account information. However, public certificates can still be placed in the authorized key stores. There are two ways that certificates can be mapped to users under windows. The first is authorized key mapping, which is just an extension of the standard public key mapping. In this scheme, the base64 DER public certificate is placed in the authorized keys file or PAD in the same manner as an RSA/DSA key. The second is Implicit mapping. If the certificate contains a UPN alternative name that can be associated with a users Kerberos name, then that information can be used to identifiy the user to the computer. This option is on by default, but can be disabled by changing the value of "AuthenticateAgainstUPN" registry setting (located under HKLM/Software/PragmaSystems/SSHD) to "no".

Public Key authentication can be problematic for users that have profiles on remote shares. The problem is that the logon token generated during the authentication does not have network credentials. In Windows, the only way to get network credentials is using a negotiated security context (GSSAPI - if delegation is configured by your system administrator) or by providing a password. To address this problem, the Pragma FortressSSH server contains an option to cache the users password. The password is twice encrypted using AES-256. The first encryption is with a proprietary key, the second is with the Local System user key. If a password is cached, it will be used automatically to provide the user with a token that has access to network shares. At this time, passwords can only be cached by the server using two registry values under the SSHD key (HKLM/Software/PragmaSystems/SSHD) . The ‘CacheWindowsCredentials’ value says whether caching is enabled and the ‘OnlyCacheCredForCert’ value indicates whether all passwords should be cached, or just the ones associated with autoloading of keys. In order to remove passwords from the cache, the user entry in the PAD (HKLM/Software/PragmaSystems/SSHD/PAD) or the entire PAD needs to be deleted.

 

GSSAPI Options



GSSAPI (Generic Security Service Application Programming Interface) is an industry wide standard to access various security authentication mechanisms in an environment without knowing how it is implemented in an operating system. GSSAPI is the accepted standard in SSH world to use Kerberos or NTLM for user authentication. This allows users to login to a system securely without having to provide a password. All SSH related standard documents, including GSSAPI use in SSH, can be found at the web site http://www.ietf.org/html.charters/secsh-charter.html

Kerberos: Click on this check box to use Kerberos authentication. It is a highly secured authentication method that uses secret-key cryptography. During Kerberos authentication, the client proves its identity to the server and vice versa. A SSH user’s identity is authenticated cryptographically by a Kerberos server without the user having to provide a password. GSSAPI (Kerberos) supported SSH client must be used to connect with this authentication method.

Kerberos supports authentication across a wide variety of platforms like Microsoft Windows, Linux, HP-UX, Solaris and AIX using credentials obtained from the operating system. Starting with Windows 2000, all Microsoft Windows (2000, XP, 2003) uses Kerberos as the standard authentication method and Microsoft Active Directory is built with Kerberos and fully supports it.

Token Delegation for Kerberos: This is a Kerberos specific option. Check this box to allow the Kerberos authenticated user to have access to other network resources on the server. If this box is off, the authenticated user may not have full access to all resources using Kerberos delegated permissions/privileges. This option needs to be on if a user needs to access any network resources, such as mapped drives or the ability to ssh or telnet to another server.

For this option to work, the system must be able to generate a delegate-level token. To do this, the following conditions must be met:

1. The user logging in cannot be marked as sensitive and cannot be delegated in Microsoft Active Directory directory service.

   • Log onto the domain controller using an administrator account.

   • Go to Active Directory Users and Computers

   • Right-click the user account that is to be delegated, and click Properties.

   • Under the Account tab, within the Account options, make sure that Account is sensitive and cannot be delegated is not selected.

2. The FortressSSH server must be marked as trusted for delegation in Active Directory. If the service logon properties have been changed under the Configure InetD Service page, that user must be marked as trusted for delegation in Active Directory.

   • If the FortressSSH service is running as a user

     • Log onto the domain controller using an administrator account.

     • Go to Active Directory Users and Computers

     • Right-click the user account that is to be delegated, and click Properties.

     •  Under the Account tab, within the Account options, click Account is trusted for delegation to select

   • If the FortressSSH service is running as LocalSystem

     • Log onto the domain controller using an administrator account.

     • Go to Active Directory Users and Computers

     • Right-click the computer on which FortressSSH is installed and click Properties.

     •  Under the General tab, within the Account options, click Trust computer for delegation to select.

 

GSSAPI NTLM: Click on this check box to use GSSAPI NTLM authentication. NTLM is an authentication protocol used in various Microsoft network protocol implementations. NTLM is used throughout Microsoft's systems as an integrated single sign-on mechanism. In both GSSAPI (NTLM and Kerberos) methods, the interactive user information will be sent as the remote user context. You will not be prompted for username or password. GSSAPI authentication cannot be used to log on a user other than the client interactive user. GSSAPI (NTLM) supported SSH client must be used to connect with this authentication method.

NTLM should be used to access Windows NT 4.0 server as Kerberos is not supported in NT 4.0. For Windows 2000, XP, 2003 or Vista, NTLM can also be chosen as these platforms supports both Kerberos and NTLM. Note that Unix/Linux clients do not support NTLM, so NTLM option is only available to SSH clients which are on Windows platforms. NTLM is an older authentication protocol used in various Microsoft network protocol implementations like Windows NT 4.0, 95, 98 and Me.

Authenticate without Message Integrity Check (MIC): Use this drop down menu to set a preferred MIC (Message Integrity Check) setting. Selecting “Allow” will authenticate connection from a client with or without MIC support. Selecting “Deny” will NOT authenticate connection from a client without MIC support. Selecting “Force” will make the server authenticate ONLY without MIC, meaning SSH clients will see this server not supporting MIC.

 


CAC/Smart Card Support

Authenicate with Certificate/CAC/Smart Card: To restrict Pragma FortressSSH server with Certificate/CAC/Smart Card authentication for logons, change the configuration which disables password and Kerberos GSSAPI authentication options as shown above.

 

NOTE: The ordering of authentication is GSSAPI (Kerberos/NTLM), Certificate, Password. If either GSSAPI or certificate authentication fails, password authentication will be used. If any of the options are disabled, then that method will be skipped. If password is disabled and one of the advanced options fails, the user will be disconnected.