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.
How to use a certificate (public key authentication) to make ssh connection to Pragma FortressSSH server:
1. Server Side Configuration: Launch Local FortressSSH Configuration
dialog from the Windows Start menu > Pragma Server Management
shortcut. Click on the Authentication option. De-select all GSSAPI
authentication options. Under the Certificate authentication section,
following options are checked by default: 1) Allow authentication
from registry 2) Allow authentication from file and 3)
(Automatically) Store keys in the authorized_key file. The location
of the authorized_key file can be specified in the field labeled File
location. The default location for the file is typically under the
following sub directory of an user's home directory or user profile:
\App Data\PragmaSSH.
Select the checkbox labeled, Automatically store keys in the
registry, to create a PAD (pragma authentication data) and auto load
authentication information there. If this option is selected, Pragma
FortressSSH server will look for authentication information in the
registry first
2. From the client, logon to the Pragma FortressSSH server by specifying the appropriate DSA/RSA file (for the SSH2 protocol) or the identity file (for the SSH1 protocol). Pragma's console ssh and sftp clients automatically try the appropriate protocol defined key files at connection. If either of the "store key options (flle or reigstry)" are checked on the server side configuration, the public part of the public/private key pair will get automatically stored. Please note that the user making certificate connection to Pragma FortressSSH server for the first time will get prompted to enter password with "partial success" message. From second time and onwards, the user should be able to log on wilthout having to enter a password.
Syntax for SSH & SFTP connection with certificate authentication
To connect to a Fortress server using certificate authentication using Pragma console secure client, open up a DOS command prompt and type the following:
ssh -i <key> username@host
To make a SFTP connection with certificate authentication using Pragma console secure client, open up a DOS command prompt and type the following:
sftp -oIdentityFIle2=<key> username@host
NOTE: SFTP uses SSH2 protocol only. Therefore, you need to use SSH2 keys to connect. SSH1 Keys will not work.
Troubleshooting tip:
If an user's certificate is failing to authenticate, check the server user profile list for another user with the same name. The authorized_key file should be located in the following sub directory of an user's home directory or user profile: \AppData\PragmaSSH.