Authentication. Black Box Advanced Console Server

Chapter 3

Authentication

..........................................................................

Chapter 3 - Authentication

This chapter presents the procedures for assigning and configuring the authentication service(s) that the CS, system or any of its components and devices will be using.

Authentication is the process by which the system, or more specifically, an authentication service such as Kerberos, Ldap or Tacacs, verifies the identity of users (to verify who they claim to be) as well as to confirm receipt of communication to authorized recipients. This chapter includes the following topics:

•

Device Authentication

•

Linux-PAM

•

Shadow Passwords

•

HTTP Signed Digital Certificate

•

X.509 Certificate on SSH

3.1 Device Authentication

Authentication is the process of identifying an individual, usually based on a username and password. In security systems, authentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity.

Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. With the CS, authentication can be performed locally, or with a remote Radius, Tacacs, ldap database, or kerberos.

How to configure

Follow the steps below to configure an authentication type.

VI mode - Parameters involved and passed values

To configure the authenticaton type of the CS, follow the steps below:

Step 1 - Edit the /etc/portslave/pslave.conf file.

Edit the all.authtype parameter in the pslave.conf file to specify the type of authentication server being configured. The table below contains a brief description of each authentication type.

Parameter Description

all.authtype

Type of authentication used. There are several authentication type options:

•

None (no authentication)

This option is invalid when the serial port is configured for Power

Management. The system defaults to “Local” if no authentication type is selected.

•

Local (authentication is performed using the /etc/passwd file)

•

Remote (This is for a terminal profile only. The unit takes in a username but does not use it for authentication. Instead it passes it to the remote server where it is then used for authentication.)

•

Radius (authentication is performed using a Radius authentication server)

•

TacacsPlus (authentication is performed using a TacacsPlus authentication server)

Table 3.1: Authentication parameters in /etc/portslave/pslave.conf

54

Parameter

all.authtype

(cont.)

Description

•

Ldap (authentication is performed against an ldap database using an ldap server. The IP address and other details of the ldap server are defined in the file /etc/ldap.conf)

•

Kerberos (authentication is performed using a kerberos server. The IP address and other details of the kerberos server are defined in the file

/etc/krb5.conf)

•

Local/Radius (authentication is performed locally first, switching to

Radius if unsuccessful)

•

Radius/Local (the opposite of the previous option)

•

Local/TacacsPlus (authentication is performed locally first, switching to TacacsPlus if unsuccessful)

•

TacacsPlus/Local (the opposite of the previous option)

•

RadiusDownLocal (local authentication is tried only when the Radius server is down)

•

TacacsPlusDownLocal (local authentication is tried only when the

TacacsPlus server is down)

•

Kerberos/Local (Kerberos authentication is tried first, switching to

Local if unsuccessful)

•

KerberosDownLocal (local authentication is tried only when the kerberos server is down)

•

Ldap/Local (LDAP authentication is tried first, switching to local if unsuccessful)

•

LdapDownLocal (local authentication is tried only when the ldap server is down)

•

NIS - All authentication types but NIS follow the format all.authtype

<Authentication>DownLocal or <Authentication> (e.g. all.authtype radius or radiusDownLocal or ldap or ldapDownLocal, etc). NIS requires all.authtype to be set as local, regardless if it will be "nis" or its “Downlocal" equivalent. The service related to "nis" or its

“Downlocal" equivalent would be configured in the /etc/nsswitch.conf file, not in the /etc/portslave/pslave.conf file.

Note that this parameter controls the authentication required by the

Advanced Console Server. The authentication required by the device to which the user is connecting is controlled separately.

Table 3.1: Authentication parameters in /etc/portslave/pslave.conf

NOTE:

If you want to dial in to the serial port on an CS series with CHAP authentication, you need to do the following:

1. Configure Sxx.authtype as local.

2. Add users in Advanced Console Server.

BLACK BOX® CS Command Reference Guide

55

3. Insert the users in the file /etc/ppp/chap-secrets.

4. Insert the file /etc/ppp/chap-secrets in the file /etc/config_files.

5. Execute the saveconf command.

Step 2 - Configuring an authentication server.

The parameters for each type of authentication server is stored in its own configuration file on CS.

Authentication

Server

Radisu

TacacsPlus

Kerberos

LDAP

NIS

File Path

/etc/raddb/server

/etc/tacplus.conf

/etc/krb5.conf

/etc/ladp.conf

/etc/yp.conf

Table 3.2: Authentication Servers and File Path

Step 3 - Activating and saving the changes made.

To activate the changes issue the command:

# runconf

To save the changes, run the command:

# saveconf

56

CLI Method - Authentication

Follow the below procedures to:

•

Configure the authentication type for the CS serial ports.

•

Configure user access to the serial ports.

•

Configure the authentication type for accessing the console of a connected device.

•

Configure an authentication server.

To configure the authentication type for the serial ports.

Step 1 - Open the CLI interface by issuing the command:

# CLI

Step 2 - Navigate to the following path.

cli>config physicalports access authtype [value]

For physicalports specify a port number, select a range, or enter “all”. For example,

“physicalport 4”, “physicalports 1-8”, or “physicalports all”.

Step 3 - To see the list of authentication types, from >authtypes

<Press tab to see list of possible values>

Authentication type “None” is not a valid option when the serial port is configured for Power

Management connection protocol. The system defaults to “Local” if no authentication type is selected.

To configure user access to the serial ports

Step 1 - Open the CLI interface by issuing the command:

# CLI

Step 2 - Navigate to the following path.

cli>config security

This menu lets you execute the following actions:

BLACK BOX® CS Command Reference Guide

57

•

adduser - To add an user you need to pass the following parameters: user name

<username>; administrator privileges or not <admin - yes|no>; biouser or not

<biouser - yes|no>; password <password>; comments <comments>. Example: security>adduser username john admin no biouser no password john1234

•

addgroup - To add a group it is necessary to inform the group name <groupname> and the members <usernames> of this group. Example: security>addgroup groupname test usernames john,mary

•

delgroup - To delete a group it is necessary to inform the name of the group

<groupname> you want to delete. Example: security>delgroup groupname test

•

deluser - To delete an existing user, it is necessary to inform the user you want to delete by specifying the <username> parameter. Example: security>deluser username blackbox

•

loadkey - This options allows you to get the user’s public key via scp. The user must be enrolled in the local database of the unit. You must specify the user name

<username> and the url <url>. The url must follow this syntax:

user@host:pathname. Example: security>loadkey username root url [email protected]/home/key

•

passwd - Change the password of a user. You need to inform the user <username> and the new password <newpassword> of the user. Example: security>passwd username root newpassword diffucultpasswd1234

To configure authentication type for device console access.

Step 1 - Open the CLI interface by issuing the command:

# CLI

Step 2 - Navigate to the following path.

cli>config security authentication authtype <string>

Step 3 - To see the list of authentication types, from >authtype

<Press tab to see list of possible values>

The following list of authentication types appears.

Nis, kerberos, local/Nis, Nis/local, kerberos/local, local/TacacsPlus, NisDownLocal, kerberosDownLocal, local/radius, RadiusDownLocal, ldap, none, TacacsPlus,

58

ldap/local, radius,TacacsPlus/local, ldapDownLocal,

radius/local, TacacsPlusDownlocal, and local. For more information about this please see the all.authtype parameter

on

Table 3.1, “Authentication parameters in

/etc/portslave/pslave.conf,” on page 54

To configure an authentication server.

Step 1 - Open the CLI interface by issuing the command:

# CLI

Step 2 - Navigate to the following path.

cli>config security authentication

Step 3 - To see the list of authentication server types, from

>authentication, press the tab to see the list of possible values. The following list of authentication types appears.

nisserver,radiussecret,tacplusauthsvr1,radiustimeout tacplusauthsvr2, krbdomain, radiusacctsvr1, tacplusraccess, krbserver,radiusacctsvr2, secureldap, tacplusretries, ldapbasedomain, radiusauthsvr1, tacplussecret, ldapserver, radiusauthsvr2,tacplusacctsvr1, tacplustimeout, nisdomain, radiusretries,tacplusacctsvr2

Step 4 - Configure an authentication server.

#config security authentication <server option> <ip address>

To activating the configuration.

cli> config runconfig

To save the configuration.

cli> config savetoflash

To exit the CLI mode.

cli> quit

BLACK BOX® CS Command Reference Guide

59

Access Control via Radius Attribute NAS-Port-id

This feature provides an additional way to control the access to serial ports other than the one based in usernames or groups. The authentication type must be Radius for this feature to function. The Radius server administrator must configure the user (in the radius server database) with one NAS-PORT-id attribute for each serial port that the user is allowed to access.

In the example below the user alfred can access the serial ports ttyS11, ttyS13, and ttyS17: alfred Auth-Type = Local, Password = ‘alfred’

Service-Type = Framed-User,

Framed-Protocol = PPP,

NAS-Port-Id = 11,

NAS-Port-Id = 13,

NAS-Port-Id = 17

The pam_radius module will check whether the NAS-Port-Id matches one of those sent by the radius server. If the radius server does not send the NAS-Port-Id attribute, no check is performed.

No configuration is needed for the CS. However, the authentication type must be

“radius”. Authentications like radiusDownLocal, radius/local, etc. will not validate the

NAS-port-Id if the user was locally authenticated.

NIS Client

NIS (Network Information System) provides simple and generic client-server database access facilities that can be used to distribute information. This makes the network appear as a single system, with the same accounts on all hosts. The objective of this feature is to allow the administrator to manage CS accounts on a NIS server.

The NIS client feature needs these following files/commands:

File/Command

/etc/yp.conf

/etc/domainname.conf

Description

This file contains the configuration used by ypbind.

This file contains the NIS domain name (set by the command domainname).

Table 3.3: NIS client requirements

60

File/Command

/usr/sbin/ypbind

/usr/bin/ypwhich

/usr/bin/ypcat

/usr/bin/ypmatch

/usr/sbin/domainname

Description

Finds the server for NIS domains and maintains the NIS binding information.

Returns the name of the NIS server that supplies the NIS services.

Prints the values of all keys from the NIS database specified by map name.

Prints the values of one or more keys from the NIS database specified by map name.

Shell script to read/write the NIS domain name.

Table 3.3: NIS client requirements

NIS Client Configuration

Step 1 - Run the command domainname.

You’ll want to make sure that you have the NIS domain name set.

Command:

# domainname [NIS domain name] show or set the system's NIS/YP domain name, e.g.:

# domainname blackbox mycompany-nis

Step 2 - Edit the /etc/yp.conf file.

You will need to configure the NIS server. Example: If the NIS server has the IP address 192.168.160.110, you’ll have to add the following line in the file: ypserver 192.168.160.110

Step 3 - Edit the /etc/nsswitch.conf file.

Change the /etc/nsswitch.conf file ("System Databases and Name service Switch

"configuration file) to include the NIS in the lookup order of the databases.

Step 4 - Configure the parameter "<all/sxx>.authype" as "local".

How to Test the Configuration

To test the configuration do the following:

BLACK BOX® CS Command Reference Guide

61

Step 1 - Start up the following command:

# /usr/sbin/ypbind

Step 2 - Display the NIS server name.

Display the name of NIS server by running the following command:

# /usr/bin/ypwhich

Step 3 - Display the “all users” entry.

Displays the all users' entry in the NIS database by running the following command:

# /usr/bin/ypcat -t passwd.byname

Step 4 - Display the user's entry in the NIS passwd file.

# /usr/bin/ypmatch -t <userid/username> passwd.byname

If the preceding steps were performed successfully, you now need to change the

/etc/inittab file by uncommenting the line that performs a ypbind upon startup.

nsswitch.conf file format

The /etc/nsswitch.conf file has the following format:

<database> : <service> [ <actions> <service> ] where:

<database> - available: aliases, ethers, group, hosts, netgroup, network, passwd, protocols, publickey, rpc, services and shadow

<service> - available: nis (use NIS version 2), dns (use Domain Name Service) and files

(use the local files)

<actions> - Has this format: [ <status> = <action> ] where:

<status> = SUCCESS, NOTFOUND, UNAVAIL or TRYAGAIN

<action> = return or continue

•

SUCCESS - No error occurred and the desired entry is returned. The default action for this status is 'return'

•

NOTFOUND - The lookup process works fine, but the needed value was not found. The default action for this status is “continue.”

62

•

UNAVAIL - The service is permanently unavailable.

•

TRYAGAIN - The service is temporarily unavailable.

To use NIS only to authenticate users, you need to change the lines in /etc/nsswitch.conf that reference passwd, shadow, and group.

Examples

4. You wish to authenticate the user first in the local database. If the user is not found, then use NIS: passwd: files nis shadow: files nis group: files nis

5. You wish to authenticate the user first using NIS. If the user is not found, then use the local database: passwd: nis files shadow: nis files group: nis files

6. You wish to authenticate the user first using NIS. If the user was not found or the

NIS server is down, then use the local database: passwd: nis [UNAVAIL=continue TRYAGAIN=continue] files shadow: nis [UNAVAIL=continue TRYAGAIN=continue] files group: nis [UNAVAIL=continue TRYAGAIN=continue] files

BLACK BOX® CS Command Reference Guide

63

3.2 Kerberos Authentication

Kerberos is a computer network authentication protocol designed for use on insecure networks, based on the key distribution model. It allows individuals communicating over a network to prove their identity to each other while also preventing eavesdropping or replay attacks, and provides for detection of modification and the prevention of unauthorized reading

Kerberos Server Authentication with Tickets support

The CS has support to interact on a kerberized network. You can find in the next lines a brief explanation about how kerberos works. Later in this section, a practical a step by step example will be presented.

How Kerberos Works

On a kerberized network, the Kerberos database contains principals and their keys (for users, their keys are derived from their passwords). The Kerberos database also contains keys for all of the network services.

When a user on a kerberized network logs in to their workstation, their principal is sent to the Key Distribution Center (KDC) as a request for a Ticket Granting Ticket (TGT).

This request can be sent by the login program (so that it is transparent to the user) or can be sent by the kinit program after the user logs in.

The KDC checks for the principal in its database. If the principal is found, the KDC creates a TGT, encrypts it using the user's key, and sends it back to the user.

The login program or kinit decrypts the TGT using the user's key (which it computes from the user's password). The TGT, which is set to expire after a certain period of time, is stored in your credentials cache. An expiration time is set so that a compromised TGT can only be used for a certain period of time, usually eight hours (unlike a compromised password, which could be used until changed). The user will not have to re-enter their password until the TGT expires or they logout and login again.

When the user needs access to a network service, the client uses the TGT to request a ticket for the service from the Ticket Granting Service (TGS), which runs on the KDC.

The TGS issues a ticket for the desired service, which is used to authenticate the user.

Configuring CS to use Kerberos Tickets authentication

For this example we will consider that a kerberos server with ticket support is properly configured in the network. The manual will only approach the CS configuration.

Here we will assume that the kerberos server has the following configuration:

64

•

Principal: john

•

Host (Black Box CS): cs48-2.blackbox.com

CS Configuration

Configuring it for SSH:

Step 1 - Configure and start a NTP server

All involved parts must be synchronized with a NTP server. To configure a NTP server see

“NTP (Network Time Protocol)” on page 197

.

Step 2 - Configure authentication and protocol in the /etc/portslave/pslave.conf file. Open the file and edit these parameters:

all.authtype local all.protocol socket_ssh.

Step 3 - Activate and save the configuration, by issuing the commands:

# runconf

# saveconf

Step 4 - Add an user with the same name as the “principal”, configured in the

Kerberos server.

# adduser john

Step 5 - Configure the krb5.conf file. The /etc/krb5.conf file must be exactly the same as the one that is in the Kerberos server.

It is highly recommended to copy it directly from the server, instead of editing it.

To copy using scp, issue the command:

# scp [email protected]:/etc/krb5.conf /etc/krb5.conf

Step 6 - Extract the host that is in the Kerberos server database to the CS:

# kadmin -p admin/admin

Where the first “admin” is the service and the second one is the user.

This will prompt a Kerberos server menu. To extract the configured hosts run the following commands in the kadmin menu: kadmin: ktadd host/cs48-2.blackbox.com

kadmin: q

To list all configured hosts in the Kerberos server, run the command:

BLACK BOX® CS Command Reference Guide

65

# klist -k

The above command will show all hosts added through the ktadd command in the

Kerberos server.

Step 7 - Configure hostname and domain name.

To configure the hostname and the domain name, issue the commands:

# hostname cs48-2

# domainname blackbox.com

Rlogin and Telnet:

To access the CS through rlogin or Telnet, follow the steps described above plus the ones describe below.

Step 1 - Configure the /etc/inetd.conf file by uncommenting the lines:

#KERBEROS SERVICES klogin stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/klogind -ki telnet stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/telnetd

Step 2 - Restart the inetd service, by issuing the command:

# daemon.sh restart NET

Step 3 - Save the configuration.

# saveconf

Test the configuration:

All the steps below will be performed in the client side:

Step 1 - The client must have a kerberized SSH and configure the

/etc/ssh/ssh_config file, according to the example below:

GSSAPIAuthentication yes

GSSAPICleanupCreds yes

Step 2 - The client must have the same krb5.conf file present in the Kerberos server.

# scp [email protected]:/etc/krb5.conf /etc/krb5.conf

66

Step 3 - Requesting the ticket to the Kerberos server.

# kinit -f -p john

Password for [email protected]: ******

You will be prompted to insert a password, that is the “principal” password that is in the Kerberos server database.

Step 4 - Checking if the ticket was successful received:

# klist

Step 5 - Connect, from the client, to the CS via SSH:

Opening a SSH connection to the CS itself:

#ssh [email protected]

Opening a SSH session to one of the CS ports:

# ssh john:[email protected]

Step 6 - Connecting via RLOGIN to the CS itself, with forwardable tickets (to connect to the CS ports using ts_menu):

# rlogin -l john cs48-2.blackbox.com -F

Then run ts_menu to access the desired serial port.

Step 7 - Connecting via Telnet to the CS itself with forwardable tickets (to connect to the CS ports using ts_menu):

telnet -l john cs48-2.blackbox.com -F

Then run ts_menu to access the desired serial port.

Kerberos Server Authentication

To authenticate users on a Kerberos sever, it is necessary to edit two configuration files: pslave.conf and krb5.conf. Below is a step by step example:

Step 1 - Edit the /etc/portslave/pslave.conf file.

Open the /etc/portslave/pslave.conf file running the following command:

# vi /etc/portslave/pslave.conf

Look for the all.authtype and all.protocol parameters and change their values according to the example below:

BLACK BOX® CS Command Reference Guide

67

all.authtype kerberos all.protocol socket_ssh ##or socket_server or socket_server_ssh

To use the Telnet protocol to access the serial ports of the unit, set the all.protocol parameter to socket_server.

To use both Telnet and SSH to access the unit, set the all.protocol parameter to socket_server_ssh. In this example we are using the SSH protocol.

Step 2 - Edit the /etc/krb5.conf file.

Open the /etc/krb5.conf running the following command:

# vi /etc/krb5.conf

Basically, all the changes needed in this file are related to the network domain.

Substitute all listed parameters that are configured with “blackbox.com” with the correspondent domain of your network. Below is an example of the file:

[logging] default = FILE:/var/log/krb5libs.log

kdc = FILE:/var/log/krb5kdc.log

admin_server = FILE:/var/log/kadmind.log

[libdefaults] ticket_lifetime = 24000 default_realm = BLACBOX.COM

default_tgs_enctypes = des-cbc-crc default_tkt_enctypes = des-cbc-crc

[realms]

BLACKBOX.COM = { kdc = kerberos.blackbox.com:88 admin_server = kerberos.blackbox.com:749 default_domain = blackbox.com

}

[domain_realm]

.blackbox.com = BLACKBOX.COM

blackbox.com = BLACKBOX.COM

File Description 3.1: /etc/krb5.conf

68

[kdc] profile = /var/kerberos/krb5kdc/kdc.conf

[pam] debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false

File Description 3.1: /etc/krb5.conf

Step 3 - Activating changes.

To activate the changes made, run the command:

# runconf

Step 4 - Testing configuration

To test the configuration, it is necessary to access any serial port using the Telnet protocol (this is the case of the approached e.g.). From a remote machine issue the following command:

# telnet 192.168.0.1 7001

# w

A prompt will ask for an user and password. Log with the user and password previously configured in the Kerberos server.

In the CS run the command:

The response for this command will be something like this:

1:03pm up 57 min, 1 user, load average: 0.00, 0.00, 0.00

USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root ttyS0 12:07pm 0.00s 1.47s 0.15s /bin/sh /usr/bin

CAS users : 1

USER TTY FROM LOGIN@ PID/Command blackbox ttyS1 192.168.0.143:1503 01:02pm 512/-RW_srv ttyS

The last line of the command response shows the user “blackbox” accessing the first serial port of the CS unit.

BLACK BOX® CS Command Reference Guide

69

Step 5 - Saving changes.

To save the configuration, run the command:

# saveconf

70

3.3 LDAP Authentication

Here we are going to describe the basic steps to configure a LDAP server on linux. We will also give instructions about how to configure the CS box.

Configuring an LDAP server on Linux

The steps below are intended to guide the installation of a LDAP server on a generic

Linux machine.

Step 1 - The packages required for the LDAP servers are:

•

db (Sleepycat Berkeley Database)

•

openssl (OpenSSL)

•

openldap (OpenLDAP)

It's also possible to load the source codes and compile them, but it is easier to load these packages from your distribution CD-ROM or via Internet.

Step 2 - Go to the directory /etc/openldap or /usr/local/etc/openldap.

Change the directory running the following command:

# cd /usr/local/etc/openldap

NOTE:

The example uses /usr/local path. Change all references of /usr/local if the path is different, and check if the directory/file really exists.

Step 3 - Create the certificates:

To create the certificates, run the following commands in the given sequence:

# ln -s /usr/local/bin/openssl.

# ln -s /usr/local/ssl/misc/CA.pl.

# PATH=$PATH:.

# CA.pl -newca <-- answer questions, you MUST fill in "commonName"

# CA.pl -newreq <-- repeat

# CA.pl -signreq

# mv newreq.pem ldapkey.pem

# chmod 0600 ldapkey.pem

# mv newcert.pem ldapcert.pem

Step 4 - Edit slapd.conf. The basic configuration to make it work is:

BLACK BOX® CS Command Reference Guide

71

The basic configuration of the file is like described below: include /usr/local/etc/openldap/schema/core.schema

include /usr/local/etc/openldap/schema/cosine.schema

pidfile /usr/local/var/slapd.pid

argsfile /usr/local/var/slapd.args

TLSCipherSuite HIGH:MEDIUM:+SSLv2

TLSCertificateFile /usr/local/etc/openldap/ldapcert.pem

TLSCertificateKeyFile /usr/local/etc/openldap/ldapkey.pem

TLSCACertificateFile /usr/local/etc/openldap/demode/cacert.pem

database bdb suffix "dc=blackbox,dc=com,dc=br" rootdn "cn=admin,dc=blackbox,dc=com,dc=br" rootpw bitadmin directory /usr/local/var/openldap-data index objectClass eq

File Description 3.2: slapd.conf configuration

Step 5 - Start LDAP server.

To start the server run the command:

# /usr/local/libexec/slapd -h "ldap:/// ldaps:///"

This will allow the LDAP server accept both secured mode and non-secure mode.

Step 6 - Add entries.

Example: ldapadd -x -D "cn=admin,dc=blackbox,dc=com,dc=br" -w bitadmin dn: uid=helio,dc=blackbox,dc=com,dc=br objectClass: person objectClass: uidobject uid: helio cn: Helio Fujimoto sn: Fujimoto userPassword: bithelio

To list the entries:

72

ldapsearch -x -D "cn=admin,dc=blackbox,dc=com,dc=br" -w bitadmin

'(objectClass=*)'

This is enough to set up a LDAP server with some users, for PAM authentication purposes.

Configuring the CS side

To configure the unit for PAM authentication, follow the steps below:

Step 1 - Configure all.protocol as ldap, in /etc/portslave/pslave.conf

Step 2 - Configure the /etc/ldap.conf file.

Edit the following parameters: host 200.246.93.95 <== LDAP server IP address or name base dc=blackbox,dc=com,dc=br <== distinguished name of the search base uri ldaps://200.246.93.95 <== to use secure LDAP

File Description 3.3: /etc/ldap.conf configuration

Step 3 - Activating and saving the changes made.

To activate the changes issue the command:

# runconf

To save the changes, run the command:

# saveconf

Active Directory

A Windows 2000 or Windows 2003 Server edition is necessary. In the CS side, the

/etc/ldap.conf must be configured.

BLACK BOX® CS Command Reference Guide

73

What needs to be set in the /etc/ldap.conf

Follow the example below to set correctly the necessary parameters:

# The Windows 2003 server IP address host 200.246.93.118

# The Distinguished name (In our active directory, the format was set

# to blackboxcorporation.local) base dc=blackboxCorporation,dc=local

# Here you can insert any user you had created, or the administrator

# user.

binddn cn=Administrator,cn=Users,dc=blackbox,dc=local

# Password for that user bindpw test123

# PAM login attribute pam_login_attribute sAMAccountName

# Update Active Directory password, by creating Unicode password and

# updating unicodePwd attribute.

pam_password ad

File Description 3.4: /etc/ldap.conf

Enabling TACACS+ Authorization for Serial Ports

Using an authorization method in addition to authentication provides an extra level of system security. By enabling the raccess parameter, administrators require an additional level of security checking. After each user is successfully authenticated through the standard login procedure, the CS uses TACACS+ to authorize whether or not each user is allowed to access specific serial ports.

By default the raccess parameter is not enabled allowing all users full authorization.

When the raccess parameter is enabled, users are denied access unless they have the proper authorization, which must be set on the TACACS+ server itself.

Configuring Authorization with a TACACS+ Server [CLI]

Step 1 - In CLI mode, enter the following string:

config > security > authentication> tacplusraccess yes

Step 2 - To save the configuration, enter the command:

74

config > savetoflash

Configuring Authorization with a TACACS+ Server [vi]

Step 1 - Open /etc/tacplus.conf

Step 2 - Edit the service parameter to be raccess:

service=raccess

Setting User Authorization Permissions on the TACACS+ Server [vi]

The authorization for each user is defined on the TACACS+ server itself in the file

/etc/tacacs/tac_plus.cfg on the "Linux Fedora Core 3"

The location of this configuration file may be different on other Linux distributions.

Step 1 - On the TACACS+ server, open the file

/etc/tacacs/tac_plus.cfg

.

Step 2 - Edit the following lines:

The text in bold type face is included as an example. user = tomj{

name = "Tom Jones"

service = raccess {

port1 = LAB2/ttyS2

port2 = 192.168.0.1/ttyS1

port3 = CAS/ttyS1

port4 = 172.32.20.10/ttyS6

port5 = LAB1/ttyS7

port6 = Knuth/ttyS16

}

}

Table 3-4: Parameters for Specifying User Authorization on a TACACS+ Server

Parameter Description Example Value user =

<username>

Defines the username as specified on the CS.

tomj

BLACK BOX® CS Command Reference Guide

75

Table 3-4: Parameters for Specifying User Authorization on a TACACS+ Server

Parameter Description Example Value name =

<"optional description">

Optional to specify additional information about user.

This parameter must include quotes.

The maximum number of characters allowed is 256.

Adding more than 256 characters stops the server from restarting and produces a "FAILED" message at the time of authorization.

"Tom Jones" raccess

service =

<authorization method>

Specifies the authorization method used whether the user is allowed or denied access when the raccess parameter is set on the CS.

Only users who have this parameter set to raccess will have authorization to access the specified ports?

port<#> =

<

CS

>/<Port>

Specify which serial ports on the CS the user has authorization to access. port# is a sequential label used by the CS.

< CS> is the name or IP address of the CS box.

<Port> is the serial port the user can access on the specified CS box.

port1 = LAB2/ttyS2

76

3.4 Group Authorization

This feature enables the “group” information retrieval from the authentication servers

TACACS+, RADIUS, and LDAP, and adds another layer of security by adding a network-based authorization. It retrieves the “group” information from the authentication server and performs an authorization through CS.

The following sections describe the procedures to configure TACACS+, RADIUS, and

LDAP authentication servers, and the corresponding configuration process on CS.

Configuring a TACACS+ authentication server

On the server, add “raccess” service to the user configuration and define which group or groups the user belongs to.

user = <username>{ service = raccess{ group_name = <Group1>[,<Group2,...,GroupN>];

}

}

On the CS, edit the following parameters in the /etc/tacplus.conf file.

authhost1=192.168.160.21 accthost1=192.168.160.21 secret=secret encrypt=1 service=ppp protocol=lcp timeout=10 retries=2

authhost1: This address indicates the location of the TacacsPlus authentication server. A second

TacacsPlus authentication server can be configured with the parameter authhost2.

accthost1: This address indicates the location of the TacacsPlus accounting server, which can be used to track how long users are connected after being authorized by the authentication server. Its use is optional. If this parameter is not used, accounting will not be performed. If the same server is used for authentication and accounting, both parameters must be filled with the same address. A second TacacsPlus accounting server can be configured with the parameter accthost2.

secret: This is the shared secret (password) necessary for communication between the CS and the

TacacsPlus servers.

encrypt: The default is 1 which means encryption is enabled. To disable encryption change the value to 0.

BLACK BOX® CS Command Reference Guide

77

service: The service that should be enabled. The default is ppp. If you are enabling another service, for example, “raccess” authorization on the TacacsPlus server, then it should be mentioned in this field on CS.

protocol: The default is lcp (line control protocol). Specify another paramter if required.

timeout: This is the timeout (in seconds) for a TacacsPlus authentication query to be answered.

retries: Defines the number of times each TacacsPlus server is tried before another is contacted.

The first server authhost1 is tried for the specified number of times, before the second authhost2, if configured, is contacted and tried for the specified number of times. If the second server fails to respond TacacsPlus authentication fails.

Configuring the authorization on CS to access the serial ports [CLI]

In CLI mode, enter the following string:

1. cli > config security authentication tacplusraccess yes

2. cli > config physicalports <serial port number> access users/groups <list of users or group names separated by commas>

Save the configuration to flash

3. cli > config > savetoflash

Configuring a RADIUS authentication server

On the server, edit /etc/raddb/users and add a new string attribute (ATTRIBUTE

Framed-Filter-Id) similar to the following example?

groupuser1 Auth-Type= Local, Password =”xxxx”

Service-Type=Callback-Framed-User,

Callback-Number=”305”,

Framed-Protocol=PPP,

Fall-Through=No

If the Frame-Filter-Id already exists, just add the group_name to the string starting with a colon “:”

Framed-Filter-

Id=”:group_name=<Group1>[,<Group2>,...,<GroupN>]”,

On the CS, edit /etc/raddb/server format: server[:port] secret [retries] [timeout] for example,

78

auth1 172.20.0.2 blackbox 3 5 acct1 172.20.0.2 blackbox 3 5

Where,

server : The radius server address.

port: The port field is optional. The default port name is “radius” and is looked up through

/etc/services.

secret: The shared password required for communication between CS and the Radius server.

retries: The number of times each Radius server is tried before another is contacted

timeout: The default is 3 seconds. The timeout field determines how long the system should wait before responding with a success or failure response from the authentication server.

Multiple radius servers can be configured in this file. The servers are tried in the order in which they appear. If a server fails to respond, the next configured server is tried.

Configuring the authorization on CS to access the serial ports [CLI]

In CLI mode, enter the following string: cli > config physicalports <serial port number> access users/groups <list of users or group names separated by commas>

Save the configuration to flash

2. cli > config > savetoflash

Configuring an LDAP authentication server

On the server, edit the “info” attribute for the user and add the following syntax.

info: group_name=<Group1>[,<Group2>,...,<GroupN>];

Configuring the authorization on CS to access the serial ports [CLI]

In CLI mode, enter the following string: cli > config physicalports <serial port number> access users/groups <list of users or group names separated by commas>

Save the configuration to flash

BLACK BOX® CS Command Reference Guide

79

2. cli > config > savetoflash

80

3.5 Linux-PAM

Linux-PAM (Pluggable Authentication Modules for Linux) is a suite of shared libraries that enable the local system administrator to choose how applications authenticate users.

In other words, without (rewriting and) recompiling a PAM-aware application, it is possible to switch between the authentication mechanism(s) it uses. Indeed, one may entirely upgrade the local authentication system without touching the applications themselves.

It is the purpose of the Linux-PAM project to separate the development of privilegegranting software from the development of secure and appropriate authentication schemes. This is accomplished by providing a library of functions that an application may use to request that a user be authenticated. The PAM library has a series of configuration files located in /etc/pam.d/ to authenticate a user request via the locally available authentication modules. The modules themselves will usually be located in the directory /lib/security and take the form of dynamically loadable object files.

The Linux-PAM authentication mechanism gives the system administrator the freedom to stipulate which authentication scheme is to be used. S/he has the freedom to set the scheme for any/all PAM-aware applications on your Linux system. That is, s/he can authenticate from anything as generous as simple trust (pam_permit) to something as severe as a combination of a retinal scan, a voice print and a one-time password!

Linux-PAM deals with four separate types of (management) task. These are: authentication management, account management, session management, and password management. The association of the preferred management scheme with the behavior of an application is made with entries in the relevant Linux-PAM configuration file. The management functions are performed by modules specified in the configuration file.

Following is a figure that describes the overall organization of Linux-PAM:

BLACK BOX® CS Command Reference Guide

81

Figure 3.1 - Data flow diagram of Linux-PAM

The left of the figure represents the application: Application X. Such an application interfaces with the Linux-PAM library and knows none of the specifics of its configured authentication method. The Linux-PAM library (in the center) consults the contents of the PAM configuration file and loads the modules that are appropriate for Application

X. These modules fall into one of four management groups (lower center) and are stacked in the order they appear in the configuration file. These modules, when called by Linux-PAM, perform the various authentication tasks for the application. Textual information, required from or offered to the user can be exchanged through the use of the application-supplied conversation function.

The Linux-PAM Configuration Directory

Linux-PAM is designed to provide the system administrator with a great deal of flexibility in configuring the privilege-granting applications of their system. The local configuration of those aspects of system security controlled by Linux-PAM is contained in the directory /etc/pam.d/. In this section we discuss the correct syntax of and generic options respected by entries for the files in this directory.

82

Configuration File Syntax

The reader should note that the Linux-PAM-specific tokens are case-insensitive. The module paths, however, are case-sensitive since they indicate a file’s name and reflect the case-dependence of typical Linux file systems. The case-sensitivity of the arguments to any given module is defined for each module in turn.

In addition to the lines described below, there are two special characters provided for the convenience of the system administrator:

# Comments are preceded by this character and extend to the next end-of-line.

A general configuration line of a file in the /etc/pam.d/ directory has the following form: filename module-type control-flag module-path arguments

The meaning of each of these tokens is explained below. After the meaning of the above tokens is explained, the method will be described.

Token

File-name

Module-type

Description

The service name associated with the entry. For example, ‘ftpd’,

‘rlogind’, ‘su’, etc. There is a special service-name, reserved for defining a default authentication mechanism. It has the name ‘OTHER’ and may be specified in either lower or upper case characters. Note, when there is a module specified for a named service, the ‘OTHER’ entries are ignored.

One of (currently) the four types of module. The four types are as follows:

•

Auth - This module type provides two aspects of authenticating the user. First, it establishes that the user is who they claim to be, by instructing the application to prompt the user for a password or other means of identification. Second, the module can grant group membership, independently of the /etc/groups, or other privileges through its credential-granting properties.

Table 3.5: /etc/pam.d/ tokens description

BLACK BOX® CS Command Reference Guide

83

Token

Module-type (cont.)

Control-flag

Description

•

Account - This module performs non-authentication-based account management. It is typically used to restrict or permit access to a service based on the time of day, currently available system resources (maximum number of users) or perhaps the location of the applicant user—‘root’ login only on the console.

•

Session - Primarily, this module is associated with doing things that need to be done for the user before or after they can be given service. Such things include the logging of information concerning the opening or closing of some data exchange with a user, mounting directories, etc.

•

Password - This last module type is required for updating the authentication token associated with the user. Typically, there is one module for each ‘challenge/response’ based authentication

(auth) module-type.

The control-flag is used to indicate how the PAM library will react to the success or failure of the module it is associated with. Since modules can be stacked (modules of the same type execute in series, one after another), the control-flags determine the relative importance of each module. The application is not made aware of the individual success or failure of modules listed in the ‘/etc/pam.d/ directory. Instead, it receives a summary of success or fail responses from the Linux-PAM library.

The order of execution of these modules is that of the entries in the

/etc/pam.d/ directory: The control-flag can be defined with one of two syntaxes. The simpler (and historical) syntax for the control-flag is a single keyword defined to indicate the severity of concern associated with the success or failure of a specific module. There are four such keywords: required, requisite, sufficient and optional.

Table 3.5: /etc/pam.d/ tokens description

The Linux-PAM library interprets these keywords in the following manner:

Keyword

Required

Description

This indicates that the success of the module is required for the moduletype facility to succeed. Failure of this module will not be apparent to the user until all of the remaining modules (of the same module-type) have been executed.

Table 3.6: /etc/pam.d/ keywords description

84

Keyword

Requisite

Sufficient

Optional

Description

This is similar to required. However, in the case that such a module returns a failure, control is directly returned to the application. The return value is that associated with the first required or requisite module to fail. Note that this flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium. It is conceivable that such behavior might inform an attacker of valid accounts on a system. This possibility should be weighed against the significant concerns of exposing a sensitive password in a hostile environment.

The success of this module is deemed ‘sufficient’ to satisfy the Linux-

PAM library that this moduletype has succeeded in its purpose. In the event that no previous required module has failed, no more ‘stacked’ modules of this type are invoked. (Note: in this case subsequent required modules are not invoked.) A failure of this module is not deemed as fatal to satisfying the application.

As its name suggests, this control-flag marks the module as not being critical to the success or failure of the user’s application for service. In general, Linux-PAM ignores such a module when determining if the module stack will succeed or fail. However, in the absence of any definite successes or failures of previous or subsequent stacked modules this module will determine the nature of the response to the application.

One example of this latter case is when the other modules return something like PAM_IGNORE.

Table 3.6: /etc/pam.d/ keywords description

Module Path

Module Path is the path-name of the dynamically loadable object file--the pluggable module itself. If the first character of the module path is ‘/’, it is assumed to be a complete path. If this is not the case, the given module path is appended to the default module path: /lib/security.

Currently, the CS has the following modules available:

Module Name

pam_access pam_deny

Description

Provides logdaemon style login access control.

Deny access to all users.

Table 3.7: Available PAM modules in the CS

BLACK BOX® CS Command Reference Guide

85

Module Name

pam_env pam_filter pam_group pam_issue pam_lastlog pam_limits pam_listfile pam_motd pam_nologin pam_permit pam_radius pam_rootok

Description

This module allows the (un)setting of environment variables. The use of previously set environment variables as well as PAM_ITEMs such as

PAM_RHOST is supported.

This module was written to offer a plug-in alternative to programs like ttysnoop. Since a filter that performs this function has not been written, it is currently only a toy. The single filter provided with the module simply transposes upper and lower case letters in the input and output streams. (This can be very annoying and is not kind to termcap-based editors.)

This module provides group settings based on the user’s name and the terminal they are requesting a given service from. It takes note of the time of day.

This module presents the issue file (/etc/issue by default) when prompting for a username.

This session module maintains the /var/log/lastlog file. It adds an open entry when called via the pam_open_session()function and completes it when pam_close_session() is called. This module can also display a line of information about the last login of the user. If an application already performs these tasks, it is not necessary to use this module.

This module, through the Linux-PAM open-session hook, sets limits on the system resources that can be obtained in a user session. Its actions are dictated more explicitly through the configuration file discussed in

/etc/security/pam_limits.conf.

The listfile module provides a way to deny or allow services based on an arbitrary file.

This module outputs the motd file (/etc/motd by default) upon successful login.

Provides standard Unix nologin authentication.

This module should be used with extreme caution. Its action is to always permit access. It does nothing else.

Provides Radius server authentication and accounting.

This module is for use in situations where the superuser wishes to gain access to a service without having to enter a password.

Table 3.7: Available PAM modules in the CS

86

Module Name

pam_securetty pam_time pam_tacplus pam_unix pam_warn pam_krb5 pam_ldap

Description

Provides standard UNIX securetty checking.

Running a well-regulated system occasionally involves restricting access to certain services in a selective manner. This module offers some time control for access to services offered by a system. Its actions are determined with a configuration file. This module can be configured to deny access to (individual) users based on their name, the time of day, the day of week, the service they are applying for and their terminal from which they are making their request.

Provides TacacsPlus Server authentication, authorization (account management), and accounting (session management).

This is the standard UNIX authentication module. It uses standard calls from the system’s libraries to retrieve and set account information as well as authentication. Usually this is obtained from the /etc/passwd and the /etc/shadow file as well when shadow is enabled.

This module is principally for logging information about a proposed authentication or application to update a password.

The Kerberos module currently used is pam_krb5. This PAM module requires the MIT 1.1+ release of Kerberos, or the Cygnus CNS distribution. It has not been tested against heimdal or any other Kerberos distributions. Important file: /etc/krb5.conf. The krb5.conf file contains

Kerberos configuration information, including the locations of KDCs and admin servers for the Kerberos realms of interest, defaults for the current realm and for Kerberos applications, and mappings of hostnames onto Kerberos realms. Normally, you should install your krb5.conf file in the directory/etc. You can override the default location by setting the environment variable KRB5_CONFIG.

Pam_ldap looks for the ldap client configuration file “ldap.conf” in

/etc/. Here's an example of the ldap.conf file (partial):

# file name: ldap.conf

# This is the configuration file for the LDAP

# nameservice

# switch library and the LDAP PAM module.

# Your LDAP server. Must be resolvable without using

# LDAP.

host 127.0.0.1

# The distinguished name of the search base.

base dc=padl,dc=com

Table 3.7: Available PAM modules in the CS

BLACK BOX® CS Command Reference Guide

87

Arguments

The arguments are a list of tokens that are passed to the module when it is invoked. They are much like arguments to a typical Linux shell command. Generally, valid arguments are optional and are specific to any given module. Invalid arguments are ignored by a module, however, when encountering an invalid argument, the module is required to write an error to syslog(3).

The following are optional arguments which are likely to be understood by any module.

Arguments (including these) are in general, optional.

Arguments

debug no_warn use_first_pass try_first_pass use_mapped_ pass

Description

Use the syslog(3) call to log debugging information to the system log files.

Instruct module to not give warning messages to the application.

The module should not prompt the user for a password. Instead, it should obtain the previously typed password (from the preceding auth module), and use that. If that doesn’t work, then the user will not be authenticated. (This option is intended for auth and password modules only).

The module should attempt authentication with the previously typed password (from the preceding auth module). If that doesn’t work, then the user is prompted for a password. (This option is intended for auth modules only).

This argument is not currently supported by any of the modules in the

Linux-PAM distribution because of possible consequences associated with U.S. encryption exporting restrictions.

Table 3.8: List of valid arguments to PAM

88

Arguments

expose_account

Description

In general, the leakage of some information about user accounts is not a secure policy for modules to adopt. Sometimes information such as user names or home directories, or preferred shell, can be used to attack a user’s account. In some circumstances, however, this sort of information is not deemed a threat: displaying a user’s full name when asking them for a password in a secured environment could- also be called being

‘friendly’. The expose_account argument is a standard module argument to encourage a module to be less discrete about account information as deemed appropriate by the local administrator. Any line in (one of) the configuration file(s), that is not formatted correctly will generally tend (erring on the side of caution) to make the authentication process fail. A corresponding error is written to the system log files with a call to syslog(3).

Table 3.8: List of valid arguments to PAM

BLACK BOX® CS Command Reference Guide

89

3.6 Shadow Passwords

The default /etc/passwd file has the user “root” with password “bb”. You should change the password for user “root” as soon as possible.

The Advanced Console Server has support for Shadow Passwords, which enhances the security of the system authentication files.

For

CS

release 2.6, Shadow Passwords are enabled by default. If you are upgrading from release 2.3.0-2 (or earlier), a previous configuration is detected and the translation from

/etc/passwd to /etc/shadow happens automatically.

90

3.7 Certificate for HTTP Security

The following procedure enables you to obtain a Signed Digital Certificate. A certificate for the HTTP security is created by a CA (Certificate Authority). Certificates are most commonly obtained through generating public and private keys using a public key algorithm like RSA or X.509. The keys can be generated by using a key generator software.

Procedure

Step 1 - Enter OpenSSL command.

On a Linux computer, key generation can be done using the OpenSSL package, through the following command:

# openssl req -new -nodes -keyout private.key -out public.csr

If this command is used, the following information is required:

Parameter Description

Country Name (2 letter code) [AU]:

State or Province Name (full name) [Some-

State]:

Locality Name (e.g., city) []:

The country code consisting of two letters.

Provide the full name (not the code) of the state.

Enter the name of your city.

Organization Name (e.g., company) [Internet

Widgits Ltd]:

Organization that you work for or want to obtain the certificate for.

Organizational Unit Name (e.g., section) []:

Common Name (e.g., your name or your server’s hostname) []:

Email Address []:

Department or section where you work.

Name of the machine where the certificate must be installed.

Your email address or the administrator’s email address.

Table 3.9: Required information for the OpenSSL package

The other requested information can be skipped.

The certificate signing request (CSR) generated by the command above contains some personal (or corporate) information and its public key.

Step 2 - Submit CSR to the CA.

BLACK BOX® CS Command Reference Guide

91

The next step is to submit the CSR and some personal data to the CA. This service can be requested by accessing the CA Web site and is not free. There is a list of

CAs at the following URL pki-page.org

The request will be analyzed by the CA, for policy approval and to be signed.

Step 3 - Upon receipt, install certificate.

After the approval, the CA will send a certificate file to the origin, which we will call Cert.cer, for example purposes. The certificate is also stored on a directory server.

The certificate must be installed in the GoAhead Web server, by following these instructions:

Step 3.1 - Open a Terminal Server session and do the login.

Step 3.2 - Join the certificate with the private key into the file

/web/server.pem.

#cat Cert.cer private.key > /web/server.pem

Step 3.3 - Copy the certificate to the file /web/cert.pem.

#cp Cert.cer /web/cert.pem

Step 3.4 - Include the files /web/server.pem and /web/cert.pem in

/etc/config_files.

Step 3.5 - Save the configuration in flash.

#saveconf

The certification will be effective in the next reboot.

92

3.8 X.509 Certificate on SSH

The OpenSSH software included with CS has support for X.509 certificates. The administrator must activate and configure the SSH to use X.509. In order to implement authentication of SSH sessions through exchange of X.509 certificates, the following configuration is required.

Step 1 - The certificates signed and issued by CA (Certification Authority) should be loaded on both user and the client. See the procedures in section 3.7 on how to obtain and install signed digital certificates.

Step 2 - Client Identification extracted by OpenSSL command from the client’s certificate, and added to the AuthorizedKeyFile in sshd_config file.

Step 2.1 - Use the following command to extract the client identification

#openssl x509 -noout -subject -in cli_cert.crt

Step 2.2 - Change “subject=” to “x509v3-sign-rsa disTinguishednameE:” in the result and append to AuthorizedKeysFile in “sshd_config” file in CS.

Step 3 - Upload hostkey to CS in /etc/ssh directory.

To configure X.509 certificate for SSH

vi Mode

Step 1 - Edit /etc/ssh/sshd_config file

Step 2 - Uncomment or modify the following lines to read as follows.

AllowedCertPurpose sslclient

CACertificateFile /etc/ssh/ca/ca-bundle.crt

HostKey /etc/ssh/hostkey

ChallengeResponseAuthentication no

HostbasedAuthentication no

StrictModes no

PasswordAuthentication no

PubkeyAuthentication yes

RhostsRSAAuthentication no

RSAAuthentication no

UsePrivilegeSeparation yes

BLACK BOX® CS Command Reference Guide

93

Step 3 - Restart SSH

CLI Mode

Step 1 - Enter the CLI mode

[root@CAS etc]# CLI

Step 2 - Enter the following string at the cli> prompt

cli>config network profile custom ssh_x509

At the ssh_x509> prompt, enter the following strings.

ssh_x509>CA_file <path and filename of CA certificate> ssh_x509>hostkey <path and filename of hostkeys> ssh_x509>authorizedkeys <path and filename of authorized keys>

For example: ssh_x509>CA_file /etc/ssh/ca-bundle.crt ssh_x509>hostkey /etc/ssh/hostkey ssh_x509>authorizedkeys /etc/ssh/authorized_keys

To check the configuration, enter the following command at the prompt.

ssh_x509>show

The following information should appear.

[ssh_x509]

CA_file: /etc/ssh/ca-bundle.crt

hostkey: /etc/ssh/hostkey authorizedkeys: /etc/ssh/authorized_keys

Script Mode

Step 1 - Run the following “ssh_act_x509” script

[root@CAS root]# ssh_act_x509

The following message appears:

94

For X509 authentication, first you need to be sure that you had upload the CA certificate, the HostKey and added the proper Authorized Key.

Step 2 - Enter the required information at each prompt.

AuthorizedKeysFile[/etc/ssh/authorized_keys]:

CACertificateFile[/etc/ssh/ca/ca-bundle.crt]:

HostKey[/etc/ssh/ssh_host_key]:

Do you want disable Password Authentication and accept only

Certificates?(y/n)

Step 3 - Check the configuration in /etc/ssh/sshd_config file.

To connect to CS using SSH X.509 certificate

Step 1 - Edit /etc/ssh/sshd_config file. See “To configure X.509 certificate for

SSH”, if needed.

Step 2 - Configure the client you need to access with X.509 certificate

Step 3 - Copy the certificate files to CS. See “Certificate for HTTP Security”, if

needed.

To check if the file was copied, run the following command at the prompt.

[root@cs48 root]# ls -l /etc/ssh/ca/ca-bundle.crt

[root@cs48 root]# ls -l /etc/ssh/hostkey

To connect to CS’s serial ports using SSH X.509 certificate

Step 1 - Edit /etc/ssh/sshd_config file. See “To configure X.509 certificate for

SSH”, if needed.

Step 2 - Configure the client you need to access with X.509 certificate

Step 3 - Copy the certificate files to CS. See “Certificate for HTTP Security”, if

needed.

To check if the file was copied, run the following command at the prompt.

[root@cs48 root]# ls -l /etc/ssh/ca/ca-bundle.crt

BLACK BOX® CS Command Reference Guide

95

[root@cs48 root]# ls -l /etc/ssh/hostkey

Step 4 - Configure the serial ports for “socket_ssh” protocol and assign the IP address of the connected device.

96