SSH Server implements x509v3-sign-rsa and x509v3-sign-dss Authentication

 Certificate Based Authentication advantages over plain public keys and passwords

Let's begin explaining the advantages of Certificate Based Authentication in SSH by going over the problems with plain public keys and passwords. The Secure Shell version 2 (SSH-2) protocol has always allowed passwords and plain public keys for user authentication. The use of passwords is known to be very risky for many reasons such as users tend to write them down or use weak (easy to guess) passwords. As a result the use of plain public keys is a clearly superior solution to passwords. However, for client authentication, even though cryptographically very secure, plain public keys lack a convenient method of matching them to user accounts on which SSH-2 sessions are expected to run.

The configuration of public key authentication requires

• The use of utilities to generate a key pair,
• Temporary SSH-2 logon using user name and password,
• Transfer of public key file(s) to the SSH-2 server,
• Manual editing of text-based configuration files ,
• And finally setting access rights of the configuration file

- for each SSH-2 user.

The complexity and difficulty required for configuration and setup of the public key solutions is daunting for most, impossible for others.  That in itself, renders the solution unacceptable in the majority of production environments, especially ones utilizing mobile devices. Furthermore, the temporary use of files, passwords, and human mistakes can compromise the security of the solution based on plain public keys.

However, this does not mean that you should be without a very strong authentication and secure solution!  Georgia SoftWorks considered the issues with public keys and passwords and engineered a Digital Certificate solution with all the cryptographic benefits of the plain public keys  without the problems identified above. The Digital Certificated solution is based on the  x509v3-sign-rsa and x509v3-sign-dss standards.

SSH-2 - Authentication with x509v3-sign-rsa, x509v3-sign-dss and Digital Certificates - A Better and Solution for Commercial Environments

A Digital Certificate (also know as public key certificate, or identity certificate) binds a name (or identity) to a public key value.  This is an excellent method for verifying the identity while the configuration and setup is much simpler and manageable than with plain public keys.

The 'x509v3-sign-rsa' and 'x509v3-sign-dss' SSH-2 authentication standards use Digital Certificates instead of plain public keys and provided GSW the protocol level base needed to address the problems described above and eliminate the security risks associated with implementation of the user's configuration.

These standards allow use of digital certificates instead of plain public keys. A digital certificate is composed of a public key securely bound to its owner's identity. As stated in the internet draft:

'No constraints are placed on the presence of user account information in the certificates used for user authentication. Their validation and mapping is left as an implementation and configuration detail for the implementors and deployers.'

Georgia SoftWorks researched and developed an innovative, easy to use, and secure implementation of the 'validation and mapping' stated above. All of the configuration is done through a GUI with wizard style dialogs reminiscent of IIS certificate-to-user account mapping. The solution preserves all of the cryptographic strength of the public key solution, adds convenient, well scaling, certificate-to-user account mapping options while eliminating the time consuming, error-prone, and potentially insecure setup.

The overall solution allows to authenticate SSH-2 users who log on with a client certificate by mapping the certificates to Windows user accounts. The client certificates are analyzed and used to either deny or grant host access to a connecting session. There are two methods in which one can map certificates.

'One-to-one' mapping maps a individual client certificate to a individual Windows user account. The SSH-2 server compares certificates from a pre-configured list with the client certificate that is sent by the SSH-2 client. An identical match must occur for the mapping to proceed.

'Many-to-one' mapping maps multiple certificates to an individual Windows user account. It uses wildcard matching rules to define the certificate criteria for mapping. This type of mapping does not compare the actual client certificate. Instead, it accepts all client certificates that meet specific criteria. If a certificate match the rules, it is  mapped to the indicated user account. Typically one would also select a Certificate Trust List (CTL) to assure the client certificates are truly trustworthy. CTLs make it possible to limit the number of acceptable root CAs which are able to issue certificates to users.

	Plain Public Keys		Digital Certificates
	Key Pair (Public Key/Private Key) Generation on Client		Obtain Certificate
	Temporary SSH-2 Server Logon using User Name/Password		Completely Avoided
	Transfer of public key file(s) to the SSH-2 Server		Completely Avoided with Many-to-One mapping. Set up rules for certificate content
	Manually editing of text-based configuration for EACH SSH2 user		One-to-one mapping, Use GUI to select a certificate Many-to-one mapping, set up certificate rules with GUI
	Setting Access Rights for the Configuration File		Completely Avoided. Configuration files is maintained by GUI and encrypted

GSW SSH2 Digital Certification Authentication
Server and UTS Setup		Device and Client Setup