login about faq

How to configure Tectia Server on Linux/Unix to authenticate end users using X509v3 certificates?

asked Jan 18 '12 at 17:31

SSH%20KB's gravatar image

SSH KB ♦
509249246237


From the end of this message, you can find an example Tectia Server's XML configuration file which allows end users to be authenticated using X509v3 certificates. The XML configuration is based on ssh-server-config-default.xml file and it has bare minimum changes in it, just to allow X509v3 user authentication to work.

Please change the following lines inside the example XML file (scroll bottom to see the XML) to reflect settings according to your environment:

1. Modify the path to the CA certificate and check that the file name itself is correct:

    <cert-validation>
            <ca-certificate name="myca" disable-crls="yes" file="/etc/ssh2/ca-certificate.crt" />
    </cert-validation>
  • NOTE: CLR checking here is disabled (disable-clrs="yes") so that you can get basic authentication working in your test lab. Please change this CRL setting to "no" when you plan to use the configuration in production environment.


2. Modify the certificate field selector: what fields Tectia Server will check from the end users' certificates and how operating system user accounts are going to be mapped with the certificates:

Tectia Server supports variables in its XML configuration which will allow you to keep the XML nice and tidy (%username%, %username-without-domain%, %hostname%)

<authentication-methods>
   <authentication action="allow">
       <auth-publickey />
       <authentication action="allow">
          <selector>
            <certificate field="subject-name" ignore-prefix="yes" ignore-suffix="yes" pattern="CN=%username%" />
          </selector>
       </authentication>
       <authentication action="deny" />
   </authentication>
</authentication-methods>

Optionally, also other fields can be checked from the end user's certificate:

- <certificate field="ca-list" pattern="exa-ca1,exa-ca2" />
- <certificate field="issuer-name" pattern="C=FI, O=SSH, CN=*" />
- <certificate field="subject-name" pattern="C=FI, O=SSH, CN=%username%" />
- <certificate field="serial-number" pattern="123456" />
- <certificate field="altname-email" pattern="%username%@ssh.com" />
- <certificate field="altname-fqdn" pattern="client.ssh.com" />
- <certificate field="altname-upn" pattern="%username%@ssh" />
- <certificate field="altname-ip" pattern="10.2.3.5" />

Another example regarding the certificate field checking:

<authentication-methods>
    <authentication action="allow">
            <auth-publickey />
            <authentication action="allow">
                    <selector>
                         <certificate field="subject-name" pattern="C=US, ST=MA, L=Boston, O=Tectia, OU=Sales-Test, CN=%username%, MAILTO=%username%@tectia.com" />
                    </selector>
            </authentication>
    <authentication action="deny" />
    </authentication>      
</authentication-methods>


3. Copy-paste the example XML file from the end of this page into (with minor modifications as explained in #1 and #2):

/etc/ssh2/ssh-server-config.xml


4. Restart the Tectia Server process:

/etc/init.d/ssh-server-g3 restart


5. Alternatively, you can also start temporary Tectia Server listener for testing purposes using a temporary XML configuration file (this example will use port 2222 and a special XML config file):

/opt/tectia/sbin/ssh-server-g3 -l 2222 -f /etc/ssh2/ssh-server-config-basic-user-authentication-with-certificates.xml


6. To start Tectia Server in debug mode (to get more information about certificate authentication errors), use the command:

/opt/tectia/sbin/ssh-server-g3 -D 7 -l 2222 -f /etc/ssh2/ssh-server-config-basic-user-authentication-with-certificates.xml


7. Please refer to Tectia Server's MAN page and example XML files for more information about the certificate/PKI settings:

man ssh-server-config
/etc/ssh2/ssh-server-config-example.xml
/etc/ssh2/ssh-server-config-tutorial.xml
/etc/ssh2/ssh-server-config-default.xml


8. The complete ssh-server-config.xml can be found from below (based on ssh-server-config-default.xml):

Changes that you will need to make into the example XML file below are explained in #1 and #2. You can scroll to the end of the web page and use horizontal slider bar in order to display long XML rows

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE secsh-server SYSTEM
"/etc/ssh2/ssh-tectia/auxdata/ssh-server-ng/ssh-server-ng-config-1.dtd" [
<!ENTITY configdir PUBLIC "secsh:directory(config-server)" "">
]>
<!-- Tectia Server 6.x - ssh-server-config-default.xml
 Copyright (c) Tectia Corporation. 
 This software is protected by international copyright laws. 
 All rights reserved.

 NOTE: This file demonstrates the hardcoded default settings used by 
 ssh-server-g3 when it loads its configuration. Changing this file will 
 not affect the actual default settings!

 To use this file as a basis of your server configuration, copy it to 
 the same directory with the name "ssh-server-config.xml". Edit the file 
 using a text editor or an XML editor. For more information on the 
 configuration syntax, see the ssh-server-config(5) manual page or SSH 
 Tectia Server Administrator Manual.

 ssh-server-g3 locates the DTD automatically. The DOCTYPE declaration
 shows the path on Unix platforms. On Windows, the path to DTD is:
 "C:\Program Files\SSH Communications Security\SSH Tectia\SSH Tectia AUX\ssh-server-ng\ssh-server-ng-config-1.dtd"

 The &configdir; entity is expanded by ssh-server-g3 as the default 
 configuration directory on each platform.
 On Unix: "/etc/ssh2"
 On Windows: "C:\Program Files\SSH Communications Security\SSH Tectia\SSH Tectia Server"

 If you edit the configuration file using an XML editor and want to 
 validate the XML, change the contents of the DOCTYPE declaration 
 according to your platform.
 -->

<secsh-server>

  <params>
    <crypto-lib mode="standard" />

    <!-- Replace the value of xauth-path with the path to the xauth 
         binary on your host. -->
    <!-- <settings xauth-path="/usr/X11R6/bin/xauth" /> -->

         <settings 
         windows-logon-type="interactive"
         resolve-client-hostname="no"
         />

    <hostkey>
       <private file="&configdir;/hostkey" />
    </hostkey>

    <listener id="default" port="22" />
    <logging>
        <log-events facility="auth" severity="informational">
            Auth_method_success Auth_method_failure Auth_methods_completed
            Auth_methods_available Hostbased_auth_warning
            Publickey_auth_warning Publickey_auth_success GSSAPI_auth_warning
            Keyboard_interactive_pam_auth_warning
            Keyboard_interactive_radius_auth_warning
            Keyboard_interactive_password_auth_warning
            Keyboard_interactive_securid_auth_warning
            GSSAPI_auth_success
            Keyboard_interactive_pam_auth_success
            Keyboard_interactive_radius_auth_success
            Keyboard_interactive_password_auth_success
            Keyboard_interactive_securid_auth_success
        </log-events>
        <log-events facility="auth" severity="warning">
            Hostbased_auth_error Publickey_auth_error GSSAPI_auth_error
            Keyboard_interactive_pam_auth_error
            Keyboard_interactive_radius_auth_error
            Keyboard_interactive_password_auth_error
            Keyboard_interactive_securid_auth_error
        </log-events>
        <log-events facility="daemon" severity="error">
            Server_start_failed
        </log-events>
        <log-events facility="daemon" severity="notice">
            Server_listener_failed Server_listener_started
            Server_listener_stopped Server_reconfig_finished
            Server_reconfig_started Server_stopping Server_running
            Server_starting
        </log-events>
        <log-events facility="daemon" severity="warning">
        Servant_exited Servant_error
        </log-events>
        <log-events facility="normal" severity="informational">
            Algorithm_negotiation_success Certificate_validation_success
            Certificate_validation_failure Key_store_create
            Key_store_destroy Key_store_add_provider Key_store_decrypt
            Key_store_sign Key_store_sign_digest Logout Disconnect
            Channel_open_failure Session_channel_open
            Session_channel_close Forwarding_channel_open
            Forwarding_channel_open Forwarding_channel_close
            Forwarding_listener_open Forwarding_listener_close
            Auth_listener_open Auth_listener_close Auth_channel_open
            Auth_channel_close
        </log-events>
        <log-events facility="normal" severity="security-failure">
            Connection_denied Login_failure
        </log-events>
        <log-events facility="normal" severity="security-success">
            Connect Login_success
        </log-events>
        <log-events facility="normal" severity="warning">
            Algorithm_negotiation_failure KEX_failure
            Key_store_create_failed Key_store_add_provider_failed
            Key_store_decrypt_failed Key_store_sign_failed
            Key_store_sign_digest_failed
        </log-events>
    </logging>

    <limits max-connections="256" max-processes="40" />

    <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
    <!-- MODIFY CA CERTIFICATE INFORMATION BELOW IN THIS X509V3 CONFIGURATION EXAMPLE. -->
    <!-- REMEMBER TO SET DISABLE-CLRS TO "NO" WHEN TAKING THE CONFIGURATION INTO USE -->
    <!-- IN PRODUCTION ENVIRONMENTS                                                 -->
    <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
    <cert-validation>
        <ca-certificate name="myca" disable-crls="yes" file="/etc/ssh2/Root_CA.crt" />
    </cert-validation>

    <!-- Change pam-calls-with-commands to "yes" to enable PAM account
     management, session and credential setting calls for
     connections regardless of authentication method. -->

    <pluggable-authentication-modules service-name="ssh-server-g3"
                                      pam-calls-with-commands="no" />

  </params>

      <!-- Some of the ciphers, macs, or authentication methods might be
           missing depending on your architecture. -->

  <connections>

    <connection name="connection" action="allow" tcp-keepalive="no">

      <!-- Rekey happens every hour or after 1GB of data, which ever is
           sooner. -->
      <rekey seconds="3600" bytes="1000000000" />

      <cipher name="aes128-cbc" />
      <cipher name="aes192-cbc" />
      <cipher name="aes256-cbc" />

      <!-- AES in SDCTR mode is not available in if the crypto-lib mode
           attribute is set to FIPS. -->

      <cipher name="aes128-ctr" />
      <cipher name="aes192-ctr" />
      <cipher name="aes256-ctr" />
      <cipher name="3des-cbc" />

      <!-- The following ciphers are not available if the crypto-lib mode
           attribute is set to FIPS. -->
       <cipher name="seed-cbc@ssh.com" />

      <!-- The following cipher is only available on Windows and Linux 
           x86 platforms. -->
       <cipher name="crypticore128@ssh.com" allow-missing="yes" />

        <mac name="hmac-sha1" />
        <!-- The following MACs are not available if the crypto-lib mode
             attribute is set to FIPS. -->
        <mac name="hmac-md5" />

        <!-- The following mac is only available on Windows and Linux 
            x86 platforms. -->
        <mac name="crypticore-mac@ssh.com" allow-missing="yes" />

        <!-- The following two (group) KEX methods are not
            available if the crypto-lib mode attribute is set to FIPS. -->
        <kex name="diffie-hellman-group15-sha256@ssh.com" />
        <kex name="diffie-hellman-group15-sha384@ssh.com" />
    </connection>

  </connections>

  <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
  <!-- MODIFY USER AUTHENTICATION/CERTIFICATE FIELD CHECKING INFORMATION BELOW IN THIS                            -->
  <!-- X509V3 CONFIGURATION EXAMPLE                                                                             -->
  <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

  <authentication-methods>
    <authentication action="allow">
        <auth-publickey />
        <authentication action="allow">
            <selector>
                <certificate field="subject-name" pattern="C=US, ST=MA, L=Boston, O=Tectia, OU=Sales-Test, CN=%username%, MAILTO=%username%@tectia.com" />
            </selector>
        </authentication>
    <authentication action="deny" />
    </authentication>
  </authentication-methods>

  <services>

      <!-- This following passwd-change group and rule are added to the
         initial configuration ONLY IF no configuration file is present.
         This default policy will be overridden if a configuration file
         is found, in which case in order to have a policy for enforced
         password changing, you will need to add a similar policy to
         your configuration file. -->

      <group name="passwd-change">
        <selector>
            <user-password-change-needed />
        </selector>
      </group>

      <!-- This rule is used to force password change. -->
      <rule group="passwd-change">
        <terminal action="deny" />
        <subsystem type="sftp" application="sft-server-g3" action="deny" />
        <command application="/usr/bin/passwd" action="forced" />
        <tunnel-local action="deny" />
        <tunnel-remote action="deny" />
      </rule>
      <!-- Enforced password change rule ends. -->

      <!-- By default, idle timeouts are disabled. -->
      <rule idle-timeout="0">
        <environment allowed-case-sensitive="TERM,PATH,TZ,LANG,LC_*" />
        <terminal action="allow" />
        <subsystem type="sftp" application="sft-server-g3" action="allow">
            <!-- Home folder and virtual folders, Windows specific. -->
            <attribute name="home" value="%USERPROFILE%" />
            <!-- These implicit default virtual folders are only set if no
                 virtual folders are set in the configuration. If you set
                 ANY virtual folders, none of the following will be set. -->
            <attribute name="virtual-folder" value="C=C:\" />
            <attribute name="virtual-folder" value="D=D:\" />
            <attribute name="virtual-folder" value="E=E:\" />
            <!-- ... all available drives. -->
        </subsystem>

        <command action="allow" />

        <!-- All tunnel types are distinct and independent of each
             other. -->
        <tunnel-agent action="allow" />
        <tunnel-x11 action="allow" />
        <tunnel-local action="allow" />
        <tunnel-remote action="allow" />

      </rule>

    </services>

  </secsh-server>


Hopefully this helps! With this example XML configuration file you should be able to get things started.

-- SamiM

link

answered Jan 18 '12 at 19:08

Sami%20Marttinen%201's gravatar image

Sami Marttinen 1
1

You can check Tectia Client's configuration instructions (for Windows) regarding X509v3 certificate authentication from here:

http://answers.tectia.com/questions/1353/how-to-set-up-user-authentication-with-certificates-on-windows

Check "Tectia Client" section from the article.

link

answered Jan 18 '12 at 20:36

Sami%20Marttinen's gravatar image

Sami Marttinen ♦
191114

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×4

Asked: Jan 18 '12 at 17:31

Seen: 7,855 times

Last updated: Jan 18 '12 at 20:36

All user contributed content licensed under the cc-by-sa license.
Powered by OSQA.