We would be honored if you visited our blog Visit the GSW Forums and read/post/reply to topics and questionsView GSW Training Videos on Team Services
Back to GSW UTS Overview page
UTS - SSH2 Server Certificate Based Authentication
Learn more about the GSW UTS - Overview    
Our News

2014 at GSW

View our Updated Forums

Connect with GSW

Stay current with GSW by connecting with us through our blog and our social media pages.



GUI Config Tool

GSW GUI Configuration Tool

Windows Explorer style interface allowing provisioning and configuration management. Familiar to use operations such as copy, paste, rename, delete, export, import are applied to configurations on a user or system basis. Create templates and quickly view summary configuration data.

TEAM SERVICES  provides your mobile device users a breakthrough in Telnet/SSH2 technology that shatters all prior usability and efficiency standards by allowing unprecedented user collaboration.  Now mobile device users are empowered to share resources, transfer, swap, share and recover dropped sessions. All from the mobile device, no system administrator necessary. All operations can be performed in under 60 seconds.

Video Overviews

Team Services  the first feature set to offer Video overviews. We are excited to provide additional methods to meet customer expectations. Visit the GSW Video Channel!

Request a Webinar

Want to know more about UTS, RC MDMS or GSWBrowse? Request a Webinar. Give us a call or use our contact form and request a webinar.

Privacy Policy - Terms of Use

 

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.


GSW Mapping Configuration GUI

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


 

 
 
Share it!    Bookmark  SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss at Delicious Digg SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss Share SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss with your Twitter followers Share SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss at StumbleUpon Add SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss to your Technorati favorites Share SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss on Facebook Share SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss on Blinklist Share SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss on Diigo Share SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss on Reddit Share SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss on Linked In Seed the vine with SSH Authentication - x509v3-sign-rsa, x509v3-sign-dss