F-Secure SSH and OpenSHH. VPN Authentication Configuration Guide. Copyright 2005 CRYPTOCard Corporation All Rights Reserved

Transcription

1 F-Secure SSH and OpenSHH VPN Authentication Configuration Guide Copyright 2005 CRYPTOCard Corporation All Rights Reserved

2 Overview OpenSSH works with CRYPTOCard PAM authentication module on Linux based computers to provide secure encrypted remote authentication. It provides twofactor authentication for ssh login to an enabled remote machine. Once installed on the client/server machine, a user is to authenticate against a CRYPTO- Server using their CRYPTOCard token generated one-time password. Authentication With CRYPTO-Server acting as the authentication server for an SSH enabled resource, an authenticated connection sequence would be as follows: 1. A user initiates an SSH VPN connection request. The end user initiating the connection is then prompted to provide a username and a one-time-password from an active CRYPTOCard token. 2. The SSH resource using CRYPTOCard PAM forwards the authentication request to a CRYPTO-Server in a CAP protocol formatted packet. The CRYPTO-Server validates the username and one-time-password combination and returns a response in a CAP packet to the SSH resource. 3. Based on the response from the CRYPTO-Server, the user is either granted access over an encrypted channel or denied access. Compatibility For security reasons and compatibility with CRYPTOCard PAM module you must have SSH2 version 2.4 for F-Secure or SSH2 version 2.9 for OpenSSH. It is available for client and server machines running Linux. It can be used with any CRYPTOCard token type. 3 rd Party Integration: SSH 1

3 Installation Prerequisites The Linux and CRYPTOCard username must be identical and the CRYPTOCard user must have an account on the Linux system in order for the users to connect. If the Linux account does not exist, the user will fail to authenticate. This condition does not apply if NIS/NIS+/NFS or LDAP is being used. CRYPTO-Server 6.3 must be installed and operational. In addition, the CAPProtocol Entity must include a NAS key value that includes the IP address range of all client/server machines that will authenticate using ssh. Configuring sshd Step 1: Enabling ssh PAM application to use CRYPTOCard Open a terminal window. Change directory to /etc/pam.d Edit the sshd PAM application file using vi. Add the CRYPTOCard PAM module (pam_cap_auth.so) on first line and comment out the line that requires pam_stack.so module for static password authentication, as follows: #%PAM-1.0 auth auth #auth account password session pam_cap_auth.so server= :624 noeus pam_nologin.so 5. Save the file and exit. Part 2- Enabling PAM in Challenge/Response mode Change directory to /etc/ssh and edit sshd_config file using vi. For challenge response the following changes must also be made to the sshd_config file: PasswordAuthentication no 3 rd Party Integration: SSH 2

4 PermitEmptyPasswords no ChallengeResponseAuthentication yes PAMAuthenticationViaKbdInt yes (not in newer versions of OpenSSH) UsePrivilegeSeparation no Save the file and exit. Re-start sshd deamon: # /etc/init.d/sshd restart 10. Copy the pam_cap_auth.so module to /lib/security directory. Note: The pam_cap_auth.so file comes with your CRYPTOCard distribution package under pam-module directory. CRYPTO-Server Configuration You may need to configure the CRYPTO-Server to accept CAP communication from client hosts that you use to ssh to the server. Connect to the CRYPTO-Server using the Console, and choose Server -> System Configuration & Status from the menu. In the Entity column choose CapProtocol. Next look at the Value corresponding to the key NAS.2. The value of this key defines which CAP clients are allowed to connect to the CRYPTO-Server. 3 rd Party Integration: SSH 3

5 CapProtocol NAS.# keys By default, the CRYPTO-Server is configured to listen for CAP requests from any host on the same subnet. You can manually define as many CAP clients as desired by adding NAS.# entries to the CRYPTO-Server configuration. The syntax of the data for a NAS entry is as follows: <First IP>, <Last IP>, <Hostname>,, <Perform Reverse Lookup?> Where: <First IP>: The first IP address of the CAP client(s) configured in this NAS.# key. <Last IP>: The last IP address of the CAP client(s) configured in this NAS.# key. If only one IP address is defined by a NAS.# key, the <First IP> and <Last IP> will be the same. <Hostname>: Only applies in cases where the NAS.# key is for one host. Required for performing reverse lookup. The next field is not applicable and must be blank (i.e.,,) <Perform Reverse Lookup?>: An added security feature of the CRYPTO-Server is its ability to verify the authenticity of a CAP client by cross-checking its IP address with the Domain Name Server. If this value is set to true, when the CRYPTO-Server receives a CAP request from the CAP client defined by this NAS.# entry, it sends a request to the DNS using the hostname set in the NAS.# entry. The DNS should respond with the same IP address as configured in the NAS.# entry, otherwise the CRYPTO-Server assumes that the CAP packet is coming from some other host posing as the CAP client, and ignores the request completely. 3 rd Party Integration: SSH 4