6. Accessing Remote Systems with the Secure Shell (SSH) Utilities

 

SSH for OpenVMS provides the client software for allowing secure interactive connections to other computers, replacing TELNET.

The following topics describe how to configure, maintain, and use the following SSH for OpenVMS client and utilities:

·         Secure Shell Client (remote login program)

·         SSHKEYGEN

·         SSHAGENT (authentication agent)

·         SSHADD

·         CERTTOOL

·         CERTVIEW

·         CMPCLIENT

·         Public key subsystem

SSH Protocol Support

The SSH client software supports both the SSH1 and SSH2 protocols. SSH1 and SSH2 are different, and incompatible protocols. While SSH2 is generally regarded to be more secure than SSH1, both protocols are offered by SSH for OpenVMS, and although they are incompatible, they may exist simultaneously on server systems, including SSH for OpenVMS servers. The SSH client identifies the protocol(s) offered by any given server. If both SSH2 and SSH1 protocols are offered, the client will always use SSH2. Otherwise, the client will use the correct protocol based on the server’s capability.

The cryptographic library used by SSH for OpenVMS SSH2 is FIPS 140 Level 2 compliant, as determined by the Computer Security Division of the National Institute of Science and Technology (NIST).


Secure Shell Client

$ SSH hostname[#port] [qualifiers] [command]

$ SSH "user@hostname[#port]" [qualifiers] [command]

SSH (Secure Shell) is a program for logging into and executing commands on a remote system. It replaces insecure protocols like rlogin, rsh, and telnet, and provides secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can be forwarded over the secure channel. SSH connects and logs into the specified hostname.

Qualifier

Description

/ALLOW_REMOTE_CONNECT

Allow remote hosts to connect local port forwarding ports. The default is only localhost; may connect to locally bound ports.

/CIPHER=(cipher-1,…,cipher-n)

Select encryption algorithm(s).

/COMPRESS

Enable compression.

/CONFIG_FILE=file

Read an alternative client config file.

/DEBUG=level

Set debug level.

/ESCAPE_CHARACTER=char

Set escape character; none = disable (default: ~).

/HELP

Display help text.

/IDENTITY_FILE=file

Identity file for public key authentication.

/IPV4

Use IPv4 protocol to connect.

/IPV6

Use IPv6 protocol to connect.

/LOCAL_FORWARD=

([protocol/]listenport:host:port,…)

Causes the given port on the local (client) host to be forwarded to the given host and port on the remote side. The system to which SSH connects acts as the intermediary between the two endpoint systems. Port forwardings can be specified in the configuration file. Only SYSTEM can forward privileged ports.

See the Port Forwarding section for more details.

/LOG_FILE=logfilename

Log all terminal activity to the specified log file. Defaults to SYS$DISK:[]SSH.LOG if logfilename is not specified.

/MAC=(mac-1,…,mac-n)

Select MAC algorithm(s).

/NO_AGENT_FORWARDING

Disable authentication agent forwarding.

/NO_X11_FORWARDING

Disable X11 connection forwarding.

/OPTION=(option-1,…option-n)

Gives options in the format used in the configuration file. This is useful for specifying options for which there is no separate command line flag. The options have the same format as a line in the configuration file and are processed prior to any keywords in the configuration file.

For example: /OPTION=(CompressionLevel=6)

/PORT=port

Connect to this port on server system. Server must be listening on the same port.

/QUIET

Quiet Mode. Causes all warning and diagnostic messages to be suppressed. Only fatal errors display.

/REMOTE_FORWARD=

([protocol/]listenport:host:port,…)

Forward remote port to local address. These cause SSH to listen for connections on a port and forward them to the other side by connecting to host port.

/USE_NONPRIV_PORT

Use a non-privileged (>1023) source port.

/USER=user

Log in to the server system using this username.

/VERBOSE

Display verbose debugging messages. Equal to /DEBUG=2

/VERSION

Display version number of the client.

Initial Server System Authentication

When an initial connection is made from the client system to the server system, a preliminary authentication of the server is made by the client. To accomplish this, the server system sends its public key to the client system.

SSH maintains a directory containing the public keys for all hosts to which it has successfully connected. For each user, this is the [.SSH2.HOSTKEYS] directory under the individual SYS$LOGIN directory. In addition, a system-wide directory of known public keys exists in the system directory pointed to by the logical name MULTINET_SSH2_HOSTKEY_DIR, and this may be populated by the system manager. Both directories are searched as needed when establishing a connection between systems. Any new host public keys are added to the user's HOSTKEYS directory. If a host's identification changes, SSH warns about this and disables password authentication to prevent a trojan horse from getting the user's password. Another purpose of this mechanism is to prevent man-in-the-middle attacks that could be used to circumvent the encryption. The SSH configuration option StrictHostKeyChecking can be used to prevent logins to a system whose host key is not known or has changed.

Host-Based Authentication

Host-based authentication relies on two things: the existence of the user's system and username in either SSH_DIR:HOSTS.EQUIV or in the individual user's SYS$LOGIN:.RHOSTS or SYS$LOGIN:.SHOSTS file; and the server system having prior knowledge of the client system's public host key.

When a user logs in to SSH2:

1.      The server checks the SSH_DIR:HOSTS.EQUIV file, and the user's SYS$LOGIN:.RHOSTS and SYS$LOGIN:.SHOSTS files for a match for both the system and username. Wildcards are not permitted.

2.      The server checks to see if it knows of the client's public host key (SSH2_DIR:HOSTKEY.PUB on VMS client systems) in either the user’s SYS$LOGIN:[SSH2.KNOWNHOSTS] directory or in the system-wide directory pointed to by the MULTINET_SSH2_KNOWNHOSTS_DIR logical name. The key file is named FQDN_algorithm.PUB. For example, if the client system is foo.example.com and its key uses the DSS algorithm, the file that would contain its key on the server would be FOO_EXAMPLE_COM_SSH-DSS.PUB. This key file must exist on the server system before attempting host-based authentication.

3.      If the key file is found by the server, the client sends its digitally signed public host key to the server. The server will check the signature for validity.

 

When a user logs in to SSH1, host-based authentication alone is not allowed by the server because it is not secure. The second (and primary) authentication method is the RHOSTS or HOSTS.EQUIV method combined with RSA-based host authentication. It means that if the login would be permitted by .RHOSTS, .SHOSTS, SSH_DIR:HOSTS.EQUIV, or SSH_DIR:SHOSTS.EQUIV file, and if the client’s host key can be verified (see SYS$LOGIN:[.SSH]KNOWN_HOSTS and SSH_DIR:SSH_KNOWN_HOSTS), only then is login permitted. This authentication method closes security holes due to IP spoofing, DNS spoofing, and routing spoofing.

 

Caution! SSH_DIR:HOSTS.EQUIV,.RHOSTS, and the rlogin/rshell protocol are inherently insecure and should be disabled if security is desired.

 

 

Public Key Authentication

The SSH client supports DSA-based authentication for SSH2 sessions, and RSA-based authentication for SSH1 sessions. The scheme is based on public key cryptography. There are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key.

SSH1

SSH supports RSA-based authentication. The scheme is based on public-key cryptography. There are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key.

RSA is one such system. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key (SYS$LOGIN:[.SSH]AUTHORIZED_KEYS lists the public keys permitted for log in), and only the user knows the private key.

When the user logs in:

1.      The SSH client program tells the server the key pair it would like to use for authentication.

2.      The server checks if this key pair is permitted.

3.      If it is permitted, the server sends the SSH client program running on behalf of the user a challenge (a random number) encrypted by the user's public key. The challenge can only be decrypted using the proper private key.

4.      The user's client then decrypts the challenge using the private key, proving that he/she knows the private key but without disclosing it to the server.

5.      SSH implements the RSA authentication protocol automatically.

 

The key identity files are created with SSHKEYGEN. To create the RSA key pair files: run SSHKEYGEN to create the RSA key pair: IDENTITY. and IDENTITY.PUB.  Both of these files are stored in the user’s SYS$LOGIN:[.SSH] directory. IDENTITY. is the private key; IDENTITY.PUB is the public key.

Once you have created your identity files:

1.      Transfer the IDENTITY.PUB file to the remote machine.

2.      Update the AUTHORIZED_KEYS file on the remote machine by appending the contents of the public key file to the SYS$LOGIN:[.SSH]AUTHORIZED_KEYS file on the remote host. The format of the AUTHORIZED_KEYS file requires that each entry consists of a single long line.

 

After this, the user can log in without giving the password. RSA authentication is much more secure than rhosts authentication. The most convenient way to use RSA authentication may be with an authentication agent. See Public Key Authentication for more information.

SSH2

When the user logs in:

1.      The client reads possible keys to be used for authentication from its IDENTIFICATION file.

2.      Note that this file does not contain the actual keys; rather, it contains the name of the key files.

3.      The client sends to the server its list of keys.

4.      The server compares each key that it received to see if it can match this key with one of those specified in the AUTHORIZATION file.

5.      The server tells the client the key that was accepted. The client then signs the key with a digital signature that only the server with the proper key could verify, and sends the signature to the server.

6.      The server verifies the signature.

Password Authentication

The password is sent to the remote host for checking. The password cannot be seen on the network because all communications are encrypted. When the server accepts the user's identity it either executes the given command or logs into the system and gives the user a normal shell on the remote system. All communication with the remote command or shell will be encrypted automatically.

Using Public Key Authentication with SSH

When a parameter such as a username or hostname is quoted, it’s always passed verbatim to the other side. When it’s not quoted, it’s lowercased. The username entered is used when constructing the digital signature for a key.

On the host side, the uppercase username will be used, and on the server side, the lowercased username (the default on the server since VMS isn’t case-sensitive) will be used to generate the digital signature of the public key that’s being used, as shown in the following examples:

$ MULTINET SSH2 ”USER@HOSTNAME” command

USER is the username that was specified in all uppercase letters. Public key authentication fails.

$ MULTINET SSH2 “user@HOSTNAMEcommand

user is the username that was specified in all lowercase letters. Public key authentication is successful.

Break-in and Intrusion Detection

Care must be exercised when configuring the client to minimize problems due to intrusion records created by OpenVMS security auditing. The SSH user should consult the system manager to determine the authentication methods offered by the SSH server. Examples of such authentication methods include HostBased, PublicKey, and Password. The client should be configured to not attempt any authentication method that is not offered by the server.

If a client attempts authentication methods not offered by the server, the OpenVMS security auditing system may log several intrusion records for each attempt to create a session to that server. The result being that the user could be locked out and prevented from accessing the server system without intervention from the server's system manager.

Session Termination

The user can disconnect by typing “~.”. All forwarded connections can be listed with “~#”. All available escapes can be listed with “~?”. A single tilde character can be sent as “~~” (or by following the tilde with a character other than those described above). The escape character must always follow a carriage return to be interpreted as special. The escape character “~” can be changed in configuration files or on the command line.

The session terminates when the command or shell on the remote system exits, or when the user logs out of an interactive session, and all X11 and TCP/IP connections have been closed. The exit status of the remote program is returned as the exit status of SSH.

X11 Forwarding

With X11 in use, the connection to the X11 display forwards to the remote side any X11 programs started from the interactive session (or command) through the encrypted channel. Also, the connection to the real X server is made from the local system. The user should not set DECW$DISPLAY manually. Forwarding of X11 connections can be configured on the command line or in configuration files.

The DECW$DISPLAY value set by SSH points to the server system with a display number greater than zero. This is normal and happens because SSH creates a “proxy" X server on the server system for forwarding the connections over the encrypted channel.

SSH sets up “fake” Xauthority data on the OpenVMS server, as OpenVMS does not support Xauthority currently. It generates a random authorization cookie, stores it in Xauthority on the server, and verifies that any forwarded connections carry this cookie and replace it by the real cookie when the connection is opened. The real authentication cookie is never sent to the server system (and no cookies are sent in plain text).

Configuring the SSH Client

The SSH client uses only SSH2 configuration keywords. There are no SSH1-specific configuration keywords for the SSH client.

The SSH client obtains configuration data from the following sources (in this order):

1.      Command line options. See the below table for details.

2.      User’s configuration file (SYS$LOGIN [.SSH2]SSH2_CONFIG). See the following table for details.

3.      System-wide configuration file (SSH2_DIR:SSH2_CONFIG).  See the following table for details.

 

For each parameter, the first obtained value is used. The configuration files contain sections bracketed by “Host" specifications. That section applies only for hosts that match one of the patterns given in the specification. The matched host name is the one given on the command line. Since the first obtained value for each parameter is used, more host-specific declarations should be given near the beginning of the file, and general defaults at the end.

Keyword

Value

Default

Description

AllowedAuthentications

List

All methods except for HostBased

Permitted techniques, listed in desired order of attempt. These can be the following:

keyboard-interactive, password, publickey, kerberos-1@ssh.com, kerberos-tgt-1@ssh.com, kerberos-2@ssh.com, kerberos-tgt-2@ssh.com, and hostbased. Each specifies an authentication method. The authentication methods are tried in the order in which they are specified with this configuration parameter.

AuthenticationSuccessMsg

Y/N

Y

Print message on successful authentication

AuthorizationFile

Filename

Authorization

Authorization file for publickey authentication. See below for more information on the contents of this file.

BatchMode

Y/N

N

Don’t prompt for any input during session

Ciphers

Cipher list

None

Supported encryption ciphers

ClearAllForwardings

Y/N

N

Ignore any specified forwardings

Compression

Y/N

N

Enable data compression

DebugLogFile

Filename

None

Specify the file to hold debug information. If used with the QuietMode keyword turned on as well, only the first part of the log information will be written to SYS$ERROR, until the DebugLogFile keyword is parsed. If QuietMode is not used, all debug output will go to both SYS$ERROR and the log file.

DefaultDomain

 Domain

 

Specify domain name

EscapeChar

Character

 “~”

Set escape character (^ = CTRL key)

ForwardAgent

Y/N

Y

Enable agent forwarding

ForwardX11

Y/N

Y

Enable X11 forwarding

GatewayPorts

Y/N

N

Allow connection to locally forwarded ports

Host

Pattern

 

Begin the per-host configuration section for the specified  host

HostCA

Certificate

None

Specifies the CA certificate (in binary or PEM [base64] format) to be used when authenticating remote hosts. The certificate received from the host must be issued by the specified CA and must contain a correct alternate name of type DNS (FQDN). If the remote host’s name is not fully qualified, the domain specified by configuration option DefaultDomain is not fully qualified, the domain specified by configuration option DefaultDomain is appended to it before comparing it to certificate alternate names. If no CA certificates are specified in the configuration file, the protocol tries to do key exchange with ordinary public keys. Otherwise, certificates are preferred.

Multiple CAs are permitted.

HostCANoCRLs

Certificate

None

Similar to HostCA but disables CRL checking for the given ca-certificate.

IdentityFile

Filename

Identification

Name of identification file for public key authentication

KeepAlive

Y/N

Y

Send keepalives

LdapServers

ServerURL

None

Specified as

ldap://

server.domainname:389

 

CRLs are automatically retrieved from the CRL distribution point defined in the certificate to be checked if the point exists.

 

Otherwise, the comma-separated server list given by option LdapServers is used. If intermediate CA certificates are needed in certificate validity checking, this option must be used or retrieving the certificates will fail.

LocalForward

Port, Socket

 

Local port forwarding

Macs

Algorithm

None

Select MAC (Message Authentication Code) algorithm

NoDelay

Y/N

N

Disable Nagle

(TCP_NODELAY)

NumberOfPasswordPrompts

Number

3

Number of times the user is prompted for a password

before the connection is dropped

PasswordPrompt

String

 “%U’s password:”

Password prompt.  The following substitutions may be made within the prompt string:

%U = insert user’s username

%H = insert user’s system name

Port

Port

22

Server port number

QuietMode

Y/N

Y

Quiet mode - only fatal errors are displayed

RandomSeedFile

Filename

Random_seed

Random seed file

RekeyIntervalSeconds

Seconds

3600

Number of seconds between doing key exchanges during a session. 0 = disable

RemoteForward

Port, Socket

 

Remote port forwarding

SendNOOPPackets

Y/N

N

Send NOOP packets through the connection. Used typically to prevent a firewall from closing an interactive session

StrictHostKeyChecking

Y/N/Ask

Y

Behavior on host key mismatch

TryEmptyPassword

Y/N

N

Attempt an empty password first when doing password authentication.

Note: Doing so may result in an extra intrusion being logged.

User

Username

 

Remote username

VerboseMode

Y/N

N

Verbose mode

 

The user may specify default configuration options, called “stanzas”, for different destination systems. The format of this within the configuration file is:

hostname:

  keyword        value  

  keyword        value

 

hostname2:

   keyword       value

   keyword       value

For example:

petunia:

  port   17300  

  user    jdoe  

  host   petunia.example.com

 

rose:

  port   16003  

  user    alice 

  host   rose.example.com

  allowedauthentications password

 

*.beans.com:

  user           limabean  

  keepalive      no  

  ciphers        3des,twofish

In the preceding example:

·         When a user types SSH PETUNIA, the client will connect to port 17300 on petunia.example.com, and will use the default username of jdoe.

·         When a user types SSH ROSE, the client will connect to port 16003 on host rose.example.com, and will use the default username of alice, and only allow password authentication.

·         When a user types SSH anything.BEANS.COM, the client will use the default username of limabean, will not send keepalives, and will only allow 3DES or TWOFISH encryption.

 

The user may override defaults specified in configurations. Options that are specified on the command line override any like options in the configuration file. For example, if the user wants to use a username of bob when connecting to host rose instead of the default username of alice, this would be specified as:

 $ SSH /USER=BOB ROSE

Authorization File Options

The authorization file has the same general syntax as the configuration files. The following keywords may be used.

 

Key

This is followed by the filename of a public key in the [.SSH2] directory file that is used for identification when contacting the host. If there is more than one key, they are all acceptable for login.

 

Options

This keyword, if used, must follow the Key keyword above. The various options are specified as a comma-separated list. See below for documentation of the options.

 

Command

Deprecated - use Options instead.

Available Options

 

allow-from

deny-from

Specifies that in addition to public-key authentication, the canonical name of the remote host must match the pattern(s). These parameters follow the logic of AllowHosts/DenyHosts described in detail in sshd2_config. Specify one pattern per keyword, and multiple keywords can be used.

 

command=”command

This is used to specify a “forced command” that will be executed on the server side instead of anything else when the user is authenticated. This option might be useful for restricting certain public keys to perform just a specific operation. An example might be a key that permits remote backups but nothing else. Notice that the client may specify TCP/IP and/or X11 forwarding unless they are explicitly prohibited.

 

idle-timeout=time

Sets idle timeout limit to time in seconds (s or nothing after number), in minutes (m), in hours (h), in days (d), or in weeks (w). If the connections have been idle (all channels) for the specified period of time, the connection is closed down.

 

no-port-forwarding

Forbids TCP/IP forwarding when this key is used for authentication. Any port forward requests by the client will return an error. This might be used, for example, in connection with the command option.

 

no-x11-forwarding

Forbids X11 forwarding when this key is used for authentication. An X11 forward request by the client will return an error.

Authentication Configuration Examples

Hostbased Authentication Example

The following is an example of how to set up the SSH client and SSH2 server for Hostbased authentication:

$!

$! First, generate the host key - ONLY if it doesn't exist!

$!

$ multinet sshkeygen /ssh2 /host

Generating 1024-bit dsa key pair

4 oOo.oOo.oOo

 

Key generated.

1024-bit dsa, myname@myclient.foo.com, Thu MAR 04 2022 13:43:54

Private key saved to multinet_ssh2_hostkey_dir:hostkey.

Public key saved to multinet_ssh2_hostkey_dir:hostkey.pub

 

$ directory multinet_ssh2_hostkey_dir:hostkey.*

Directory MULTINET_SPECIFIC_ROOT:[MULTINET.PSCSSH.SSH2.HOSTKEYS]

HOSTKEY.;1          HOSTKEY.PUB;1

Total of 2 files $!

$! Copy the client system public key to the user directory on the server

$!

$! DECnet must be running before you execute the following commands:

$!

$ copy multinet_ssh2_hostkey_dir:hostkey.pub -

_$ myserv"myname myuser"::[.ssh2.knownhosts]myclient_foo_com_ssh-dss.pub

$!

$! Finally, log into the server system and ensure the

$! SSH_DIR:HOSTS.EQUIV file is correct

$!

$ SET HOST MYSERV

 

      Welcome to OpenVMS (TM) VAX Operating System, Version V7.3

Username: myname

Password:

 

      Welcome to OpenVMS VAX V7.3

    Last interactive login on Monday,  1-MAR-2022 17:07

    Last non-interactive login on Monday, 1-MAR-2022 08:30

 

MYSERV_$ type multinet:hosts.equiv

#

# HOSTS.EQUIV - names of hosts to have default "r" utility access to the local # system.

#

#   This file should list the full domain-style names.

#

#   This list augments the users' SYS$LOGIN:.RHOSTS file for authentication.

#   Both the .RHOSTS and the HOSTS.EQUIV files are cached by multinet -

#   see the section entitled "RLOGIN and RSHELL Authentication Cache"

#   in the _Administrator's Guide_ for more information on controlling

#   the cache.

#

#   This file is ignored for the users SYSTEM and ROOT. SYSTEM and ROOT

#   must have a SYS$LOGIN:.RHOSTS file if you want to use RSHELL or RLOGIN

#   with them.

# localhost

myclient.foo.com       myname

 

MYSERV_$

MYSERV_$ logout

  MYNAME      logged out at  1-MAR-2022 13:46:58.91 %REM-S-END, control returned to node MYCLIENT::

Publickey Authentication Example

The following is an example of how to set up the SSH client and SSH2 server for Publickey authentication:

$!

$! First, generate a key tuple $!

$ multinet sshkeygen /ssh2

Generating 1024-bit dsa key pair   

1 oOo.oOo.oOo.

 

Key generated.

1024-bit dsa, myname@myclient.foo.com, Thu Mar 04 2022 14:06:10

Passphrase :

Again      :

 

Private key saved to DISK$USERDISK:[MYNAME.SSH2]id_dsa_1024_a.

Public key saved to DISK$USERDISK:[MYNAME.SSH2]id_dsa_1024_a.pub

$ directory [.ssh2]id*.*/since = TODAY

 

Directory DKA0:[MYNAME.SSH2]

 

ID_DSA_1024_A.;1    ID_DSA_1024_A.PUB;1

 

Total of 2 files.

$!

$! Now create the IDENTIFICATION. file.  This contains the name of

$! all the keys you wish to use for public-key authentication.

$!

$ set default [.ssh2]

$ copy tt: identification. idkey id_dsa_1024_a

  ^Z

$!

$! Copy the key to the user's [.ssh2] directory on the server system

$!

$ copy id_dsa_1024_a.pub myserv"myname mypass"::[.ssh2]

$!

$! Now log into the server system and create the AUTHORIZATION file

$!

$ set host myserv

 

      Welcome to OpenVMS (TM) VAX Operating System, Version V7.3

 

Username: myname

Password:

 

      Welcome to OpenVMS VAX V7.3

 

    Last interactive login on Tuesday,  2-MAR-2022 13:46

    Last non-interactive login on Tuesday,  2-MAR-2022 13:47

 

$ set default [.ssh2]

$ directory [.ssh2]id*.*

 

Directory DKA0:[MYNAME.SSH2]

 

ID_DSA_1024_A.PUB;1

 

Total of 1 file.

$ copy tt: authorization.key id_dsa_1024_a.pub

  ^Z 

$ logout

  MYNAME      logged out at 2-MAR-2004 14:10:26.16 %REM-S-END, control returned to node MYCLIENT::

 

SSH1 Example

$ ! An example of the procedure of setting up SSH to enable

$ ! RSA-based authentication.

$ ! Using SSH client node to connect to an SSH server node.

$ !

$ ! On the client node

$ !

$ MULTINET SSHKEYGEN /SSH1

Initializing random number generator...

Generating p:  ...............................++ (distance 662)

Generating q:  .................++ (distance 370)

Computing the keys...

Testing the keys...

Key generation complete.

Enter file in which to save the key (DISK$SYS_LOGIN:[MYNAME.ssh]identity.):

Enter passphrase:

Enter the same passphrase again:

Your identification has been saved in DISK$SYS_LOGIN:[MYNAME.ssh]identity..

Your public key is:

1024 33 13428..........29361 MYNAME@long.hair.com

Your public key has been saved in DISK$SYS_LOGIN:[MYNAME.ssh]identity.pub

$ !

$ ! A TCP/IP stack must be loaded on the remote system.

$ !

$  FTP DAISY /USER=MYNAME/PASSWORD=DEMONSOFSTUPIDITY -

_$ PUT DISK$SYS_LOGIN:[MYNAME.ssh]identity.PUB

_$ DISK$SYS_LOGIN:[MYNAME.ssh]identity.PUB

long.hair.com MultiNet FTP user process V5.4(119)

Connection opened (Assuming 8-bit connections)

<daisy.hair.com MultiNet FTP Server Process V5.4(16) at Thu 4-Mar-2022 3:20PM-EDT

[Attempting to log in as myname]

<User MYNAME logged into DISK$SYS_LOGIN:[MYNAME] at Thu 4-MAR-2022 3:21PMEDT, job 20e00297.

<VMS Store of DISK$SYS_LOGIN:[MYNAME.SSH]IDENTITY.PUB; started.

<Transfer completed.  395 (8) bytes transferred.

<QUIT command received. Goodbye.

$

$ TELNET DAISY

Trying... Connected to DAISY.HAIR.COM.

 

        Authorized Users Only (TM) VAX Operating System, Version V7.1

 

Username: MYNAME

Password:

 

     Welcome to OpenVMS (TM) VAX Operating System, Version V7.1 on node

DAISY

    Last interactive login on Thursday,  4-MAR-2022 08:07

    Last non-interactive login on Thursday,  6-MAR-2022 15:21

         Logged into DAISY at  4-MAR-2022 15:22:43.68 $ !

$ ! For the first entry into the AUTHORIZED_KEYS file copy

$ ! (or rename) the file [.SSH]IDENTITY.PUB to [.SSH]AUTHORIZED_KEYS.

$ !

$ COPY [.SSH]IDENTITY.PUB [.SSH]AUTHORIZED_KEYS.

$

$ ! FOR SUBSEQUENT ENTRIES use the APPEND command

$ !

$ APPEND [.SSH]IDENTITY.PUB [.SSH]AUTHORIZED_KEYS.

$

$ ! A sanity check of the file protections shows

$ !

$ DIRECTORY/PROTECTION [.SSH]*.*

 

Directory DISK$SYS_LOGIN:[MYNAME.SSH]

 

AUTHORIZED_KEYS.;1   (RWE,RWED,RE,E)

IDENTITY.;1          (RWD,RWD,,)

IDENTITY.PUB;1       (RWE,RWED,RE,E)

KNOWN_HOSTS.;1       (RWD,RWD,,)

RANDOM_SEED.;1       (RWD,RWD,,)

 

Total of 5 files.

$ !

$ DIRECTORY/PROTECTION SSH.DIR

 

Directory DISK$SYS_LOGIN:[MYNAME]

 

SSH.DIR;1            (RWD,RWD,,)

Total of 1 file.

SSH2 User Authentication Using Certificates:

 

Client setup: Copy the private key and certificate (.crt) into the user’s [.ssh2] directory, and edit the [.ssh2]identification file, adding the entry “certkey private_key_name”.

$ dir [.ssh2]

Directory DKA0:[JDOE.SSH2]

AUTHORIZATION.;13 IDENTIFICATION.;1 MYCERT.;1 MYCERT1.CRT.;2

Total of 4 files.

 

$ type [.ssh2]identification.

certkey mycert1

$

 

Server setup:

1. Copy the CA certificate into your SSH2_DIR: directory.

2. Add the following entries in SSH2_DIR:SSHD2_CONFIG:

Pki SSH2_DIR:CAcertname

Mapfile SSH2_DIR:CAcertname.map

The Pki keyword begins an authority block for a given CA certificate. There might be more than one CA certificate along with its own mapping file.

The Mapfile keyword specifies the location of the certificate to username mapping file.

In addition, for testing, you might use PkiDisableCRLs yes to disable CRL checking for the     given authorization block.

3. Create the mapping file SSH2_DIR:CAcertname.map. The mapping file consists of rows of the following format:

userid mappingrule mapdata

userid is the user ID that’s allowed to login for the given cert (there might be multiple userid values for a given certificate).

mappingrule is one of subject, email, serialandissuer or emailregex.

·         subject means that the following mapdata is matched against the subject of the certificate.

·         email is the e-mail alternative subject extension

·         emailregex allows the use of regular expressions - e.g., %subst%

emailregex ([a-z}|+)@example\.com would allow any trusted certificate having an e-mail alternative name of  username@example.com to login with userid username)

·         SerialAndIssuer is the serial number and DN of the issuer separated by whitespace.

 

DNs are used in reverse LDAP order (e.g., c=US,o=Foobar,cn=Jane Doe).

SSH2 Host Key Authentication Using Certificates

Server setup:

1. Create a certificate for the server. The host certificate must contain the fully-qualified domain name (FQDN) as the DNS alternative name.

2. Copy the private key and certificate into the MULTINET_SSH2_HOSTKEY_DIR directory.

3. Add the following entries into the ssh2_dir:sshd2_config file:

HostKeyFile multinet_ssh_hostkey_dir:hostcert

HostCertificateFile multinet_ssh_hostkey_dir:hostcert.crt

 

Client setup:

1. Copy the CA certificate into the MULTINET_SSH2_HOSTKEY_DIR directory.

2. Add the following entries into the ssh2_dir:ssh2_config file:

HostCA multinet_ssh_hostkey_dir:CAcert.crt

DefaultDomain client_FQDN

 

 

Note: For testing purposes, you can use HostCANoCRLs instead of HostCA to disable CRL   checking.

 

 

Port Forwarding

Port forwarding is a mechanism whereby programs that use known TCP/IP ports can have encrypted data forwarded over unsecure connections. This is also known as "tunneling".

If the user is using an authentication agent, the connection to the agent is forwarded automatically to the remote side unless disabled on the command line or in a configuration file. Forwarding of arbitrary TCP/IP connections over the secure channel can be specified either on the command line or in a configuration file.

 

Note: Forwarded ports (tunnels) exist only as long as the SSH session that established them exists; if the SSH session goes away, so do the forwardings.

 

 

/LOCAL_FORWARD=(localport:remotehost:remoteport)

This causes localport on the system the client is running on to be forwarded to remotehost:remoteport. The system to which SSH2 connects acts as the intermediary between the two endpoint systems.

For example: Use port forwarding to allow a system (midsys) to encrypt and forward TELNET sessions between itself (mysys) that's outside a corporate firewall to a system (remotesys) that is inside a corporate firewall. Note that the use of port 2300 in the examples is arbitrary.

From the DCL prompt on mysys:

$ SSH midsys /local_forward=(2300:remotesys:23)

With the SSH session to midsys now active, type in another window on mysys:

$ telnet localhost /port=2300

 

Note: The SSH session must remain active for port forwarding activity.

 

 

This causes a connection to mysys:2300. The SSH2 client has bound to this port and will see the connection request. SSH sends an "open channel" request to midsys, telling it there's a connect request for port 23 on remotesys. Midsys will connect to remotesys:23 and send back the port information to mysys. Mysys completes the connection request, and the TELNET session between mysys and remotesys is now in place, using the tunnel just created through the firewall between mysys and midsys.

All traffic between mysys and midsys (through the firewall) is encrypted/decrypted by SSH on mysys and SSHD on midsys, and hence, is safe. TELNET does not know this, of course, and does not care.

Note that ports can also be forwarded from a local host to the remote host that's running SSHD, as illustrated in this figure.

In this example, port 2300 on mysys is being forwarded to remotesys:23. To do this, use SSH on mysys:

$ SSH remotesys /local_forward=(2300:remotesys:23)

Then, also on mysys, type:

$ telnet localhost /port=2300

When SSH and SSHD start their dialog, SSHD on remotesys connects back to itself, port 23, and the TELNET session is established.

 

/REMOTE_FORWARD=(remoteport1:remotehost:remoteport2)

This causes remoteport1 on the system to which SSH connects to be forwarded to remotehost:remoteport2. In this case, the system on which the client is running becomes the intermediary between the other two systems.

For example, a user wants to use mysys to create a tunnel between sys1:4000 and sys2:23, so that TELNET sessions that originate on sys1:4000 get tunneled to sys2 through the firewall.  On mysys:

$ SSH sys1 /remote_forward=(4000:sys2:23)

Now, on sys1, a user could establish a TELNET session to sys1 by doing:

$ telnet localhost /port=4000

The mechanism used for making the TELNET connection (setting up the tunnel) is essentially the same as described in the /LOCAL_FORWARD example above, except that the roles of SSH and SSHD in the dialog are reversed.

Other Files                                               

The files in the below table are used by SSH. Note that these files generally reside in the [.SSH2] subdirectory from the user’s SYS$LOGIN directory. The [.SSH2] subdirectory is created automatically on your local system the first time SSH is executed, and on a remote OpenVMS system the first time an SSH connection is made to that system. File protection for SYS$LOGIN:SSH2.DIR should be (S:RWD,O:RWD,G:,W:).

File Name

Resides

On

Description

[.SSH2]SSH2_CONFIG.

Client

System

This is the individual configuration file. This file is used by the SSH2 client. It does not contain sensitive information. The recommended file protection is 

(S:RWD,O:RWD,G:,W:).

[.SSH2]IDENTIFICATION

Client

System

Contains the information about private keys that can be used for public-key authentication when logging in.

[.SSH2]ID_alg_bits_seq

Client

System

Contains a private key for authentication.

       alg is either RSA or DSA

       bits is the length of the key

       seq is an incrementing alphabetic value

Thus, a key named ID_DSA_1024_A. indicates this is a private DSA key 1024 bits long, and it is the first time the key was generated using SSHKEYGEN. A user may have multiple private key files in a directory.

[.SSH2]ID_alg_bits_seq.PUB

Client System and Server

System

Contains a public key for authentication.

       alg is either RSA or DSA

       bits is the length of the key

       seq is an incrementing alphabetic value

Thus, a key named ID_DSA_1024_B.PUB indicates this is a public DSA key 1024 bits long,

and it is the second time the key was generated using SSHKEYGEN. A user may have multiple public key files in a directory.

[.SSH2.HOSTKEYS]xxx.PUB

Client

System

Contains public host keys for all hosts the user has logged into. The files specifications have the format KEY_port_hostname.PUB

       port is the port over which the connection was made.

       hostname is the hostname of the key's host.

For example, if tulip.example.com was accessed via port 22, the key file would be

 KEY_22_TULIP_EXAMPLE_

COM.PUB.

If this file changes on the host (for example, the system manager regenerates the host key), SSH2 will note this and ask if you want the new key saved. This helps prevent man-in-the-middle attacks.

[.SSH2]RANDOM_SEED.

Client

System

Seeds the random number generator.

This file contains sensitive data and MUST have a protection of no more than (S:RWD,O:RWD,G:,W:), and it must be owned by the user. This file is created the first time the program is run and is updated automatically. The user should never need to read or modify this file. On OpenVMS systems, multiple versions of this file will be created; however, all older versions of the file may be safely purged.

Use the DCL command:

SET FILE /VERSION_LIMIT=n RANDOM_SEED to set a limit on the maximum number of versions of this file that may exist at any given time.

MULTINET:.RHOSTS

Server

System

Is used in host-based authentication to

list the host/user pairs that are permitted to log in.

Each line of the file contains a host name (in the fully qualified form returned by name servers), and then a username on that host, separated by a space. This file must be owned by the user and must not have write permissions for anyone else. The recommended permission is read/write for the user, and not accessible by others.

MULTINET:.SHOSTS

Server

System

Is used the same way as .RHOSTS.

MULTINET:HOSTS.EQUIV

Server

System

Is used during .rhosts authentication. It contains fully qualified host names, one per line. If the client host is found in this file, login is permitted provided client and server usernames are the same. Additionally, successful RSA host authentication is required.

 

This file should only be writable by

SYSTEM.

MULTINET:SHOSTS.EQUIV

Server

System

Is processed exactly as

SSH_DIR:HOSTS.EQUIV. This file may be useful to permit logins using SSH but not using rshell/rlogin.

SSH2_DIR:SSH2_CONFIG

Client

System

This is a system-wide client configuration file. This file provides defaults for those values that are not specified in a user’s configuration file, and for users who do not have a configuration file. This file must be world readable.

MULTINET_SSH2_KNOWNHOSTS_DIR

Server

System

Contains public host keys for all hosts the system has logged into. The files specifications have the format

KEY_port_hostname.PUB

       port is the port over which the connection was made.

       hostname is the hostname of the key's host.

For example, if tulip.example.com was accessed via port 22, the key file would be:

 

KEY_22_TULIP_EXAMPLE_

COM.PUB

 

If this file changes on the host (for example, the system manager regenerates the host key), SSH will note this and ask if you want the new key saved. This helps prevent man-in-the-middle attacks.

 


 

SSHKEYGEN

Generates authentication key pairs. The format of the keys is incompatible between SSH1 and SSH2. Therefore, the correct format keys must be generated for each version of the protocol to be supported.

There is no way to recover a lost passphrase. If the passphrase is lost or forgotten, you need to generate a new key and copy the corresponding public key to other systems.

Each key may be protected via a passphrase, or it may be left empty. Good passphrases are 10-30 characters long and are not simple sentences or otherwise easily guessable. Note that the passphrase can be changed later, but a lost passphrase cannot be recovered, as a “one-way” encryption algorithm is used to encrypt the passphrase.

SSH1

MULTINET SSHKEYGEN /SSH1 [/BITS=n] [/IDENTITY_FILE=file]

                         [/PASSPHRASE=passphrase] [/COMMENT=comment]

 

MULTINET SSHKEYGEN /SSH1 /CHANGE_PASSPHRASE [/PASSPHRASE=old_passphrase] [/NEW_PASSPHRASE=new_passphrase]

 

MULTINET SSHKEYGEN /SSH1 /CHANGE_COMMENT [/PASSPHRASE=passphrase]

                         [/COMMENT=comment]

 

MULTINET SSHKEYGEN /SSH1 /CHANGE_CIPHER [/IDENTITY_FILE=file]

                         [/PASSPHRASE=passphrase]

 

MULTINET SSHKEYGEN /SSH1 /HOST [/BITS=n][/COMMENT=comment]

 

Option

Description

/BITS=nnn

Specify key strength in bits (default = 1024).

/CHANGE_PASSPHRASE

Change the passphrase of private key file.

/CHANGE_COMMENT

Change the comment for a key.

/CHANGE_CIPHER

Change the cipher to current default (3DES).

/COMMENT=”comment

Provide the comment.

/HOST

Generate the host key.

/IDENTITY_FILE=file

Specify the name of the host key file.

/PASSPHRASE=ppp

Provide the current passphrase.

/NEW_PASSPHRASE=ppp

Provide new passphrase.

/VERSION

Print sshkeygen version number.

SSH2

MULTINET SSHKEYGEN /SSH2[/BITS=n][/COMMENT=comment][/KEYTYPE=type]

                     [/KEYS=(key1...keyn)]

                     [/PASSPHRASE=ppp|/NOPASSPHRASE][/STIR=file][/QUIET]

MULTINET SSHKEYGEN /SSH2/HOST

                     [/BITS=n][/COMMENT=comment][/STIR=file][/QUIET]

MULTINET SSHKEYGEN /SSH2/DERIVE_KEY=file

MULTINET SSHKEYGEN /SSH2/EDIT=file

MULTINET SSHKEYGEN /SSH2/FINGERPRINT=file

MULTINET SSHKEYGEN /SSH2/INFO=file [/BASE=n]

MULTINET SSHKEYGEN /SSH2/SSH1_CONVERT=file

MULTINET SSHKEYGEN /SSH2/X509_CONVERT=file

MULTINET SSHKEYGEN /SSH2/PKCS_CONVERT=file

MULTINET SSHKEYGEN /SSH2/EXTRACT_CERTS=file

MULTINET SSHKEYGEN /SSH2/HELP

MULTINET SSHKEYGEN /SSH2/VERSION

 

Option

Description

/BASE=nnn

Number base for displaying key info

/BITS=nnn

Specify key strength in bits (default = 1024).

/COMMENTS=”comment

Provide the comment.

/PKCS_CONVERT=file

Convert a PKCS 12 file to an SSH2 format certificate and private key.

/SSH1_CONVERT=file

Convert SSH1 identity to SSH2 format.

/X509_CONVERT=file

Convert private key from X.509 format to SSH2 format.

/DERIVE_KEY=file

Derive the private key given in file to public key.

/EDIT=file

Edit the comment/passphrase of the key.

/EXTRACT_CERTS=file

Extract certificates from a PKCS 7 file.

/FINGERPRINT=file

Dump the fingerprint of file.

/INFO=file

Load and display information for file.

/HELP

Print help text.

/HOST

Generate the host key.

/KEYS=(key1,...,keyn)

Generate the specified key file(s).

/KEYTYPE=(dsa | rsa)

Choose the key type: dsa or rsa.

/OPENSSH_CONVERT=file

Convert the specified OpenSSH key to SSH2 format

/OUTPUT_FILE=file

Write the key to the specified output file

/PASSPHRASE=ppp

Provide the current passphrase.

/NOPASSPHRASE

Assume an empty passphrase.

/QUIET

Suppress the progress indicator.

/STIR=file

Stir data from file to random pool.

/VERSION

Print sshkeygen version number.

/[NO]WARN

Enable or disable warnings if the process of generating host keys using /HOST will cause existing host keys to be overwritten. If enabled, the user will be prompted to overwrite them. If disabled, no warnings or prompts are issued if the host keys exist.

Default is /WARN.

 

There is also a comment field in the public key file that is for the convenience to the user to help identify the key. The comment can tell what the key is for, or whatever is useful. The comment is initialized to nnn-bit dsa, username@hostname, ddd mm-dd-yyyy hh:mm:ss when the key is created unless the /COMMENT qualifier is used, and may be changed later using the /EDIT qualifier.

 

Note: When the /HOST qualifier is used, the /KEYS=(key1,...keyn) qualifier is ignored.

 

 

 

Note: The public key file must be world readable.

 

 


 

SSHAGENT

MULTINET SSHAGENT

 

Description

SSHAGENT is a program that holds authentication private keys. Both SSH1 and SSH2 keys are supported by SSHAGENT. SSHAGENT may be started in the beginning of a login session by including the commands to start it in, for example, LOGIN.COM. It may also be started interactively at any time during a login session.

To start SSHAGENT, one of the three methods may be used:

1.      Start it in a separate window:

$ MULTINET SSHAGENT

2.      Spawn it as a subprocess:

$ SPAWN/NOWAIT MULTINET SSHAGENT

3.      Run it in a detached process:

$ RUN/DETACHED/OUTPUT=AGENT.OUT/INPUT=NLA0:/PROCESS_NAME="SSH AGENT" –

$_ SSH_EXE:SSH-AGENT2

The agent is used for public key authentication when logging to other systems using SSH. A connection to the agent is available to all programs run by all instances of the user on a specific system. The name of the mailbox used for communicating with the agent is stored in the MULTINET_SSH_AGENT_username logical name.

The agent does not have any private keys initially. Keys are added using SSHADD. When executed without arguments, SSHADD adds the user’s identity files. If the identity has a passphrase, SSHADD asks for the passphrase. It then sends the identity to the agent. Several identities can be stored in the agent; the agent can use any of these identities automatically.

MULTINET SSHADD /LIST displays the identities currently held by the agent.

Files

[.SSH]IDENTITY in SYS$LOGIN:

Contains the RSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify a passphrase when generating the key. That passphrase is used to encrypt the private part of this file. This file is not used by SSHAGENT, but is added to the agent using SSHADD at login.

 

 

 


 

SSHADD

Adds identities for the authentication agent.

MULTINET SSHADD [OPTIONS] [FILE[,FILE,FILE]]

 

DESCRIPTION

SSHADD adds identities to SSHAGENT, the authentication agent. When run without arguments, SSHADD adds the file [.SSH]IDENTITY. Alternative file names can be given on the command line. If any file requires a passphrase, SSHADD asks for the passphrase from the user.

The authentication agent must be running and must have been executed by the user for SSHADD to work.

FILE is an identity or certificate file. If no file is specified, the files in the user’s [.SSH2] directory are used.

OPTIONS

/HELP

Display help text.

/LIST

List all identities currently represented by the agent.

/LOCK

Lock the agent with a password.

/NOSSH1

Agent cannot use SSH1 keys.

/PURGE

Remove all identities from the agent.

/REMOVE

Remove the identity from the agent. In order to remove identities, you must either issue the command from the subdirectory that the identities are located in, or issue the command using the full path name of the identity (as is seen in an SSHADD /LIST command).

/TIMEOUT=n

Agent should delete this key after the timeout value (in minutes) expires.

/UNLOCK

Unlock the locked agent.

/URL

Give key to the agent as a URL.

FILES

These files exist in SYS$LOGIN:

[.SSH]IDENTITY

Contains the RSA authentication identity of the user. This file should not be readable by anyone but the user. It is possible to specify a passphrase when generating the key. That passphrase is used to encrypt the private part of this file. This is the default file added by SSHADD when no other files have been specified.

If SSHADD needs a passphrase, it reads the passphrase from the current terminal if it was run from a terminal. If SSHADD does not have a terminal associated with it but DECW$DISPLAY is set, it opens an X11 window to read the passphrase.

[.SSH]IDENTITY.PUB

Contains the public key for authentication. The contents of this file should be added to [.SSH]AUTHORIZED_KEYS on all systems where you want to log in using RSA authentication. There is no need to keep the contents of this file secret.

[.SSH]RANDOM_SEED

Seeds the random number generator. This file should not be readable by anyone but the user. This file is created the first time the program is run, and is updated every time SSHKEYGEN is run.

 


 

CERTTOOL

multinet certtool [options] /pk10 /subject=subject /key_usage=flags

/extended_key_usage=flags

 

multinet certview [options] /pk12 /input_files=objects

 

Description

The CERTTOOL utility is used for different needs concerning X.509 certificates.

 

Options

/BITS=n

Key strength in bits (default 2048)

/DEBUG=n

Set debug level to n

/EXTENDED_KEY_USAGE=(flag1…flagn)

(PKCS#10 only)

Extended key usage flags, as a comma-separated list.  Valid values are:

·         anyExtendedKeyUsage

·         ServerAuth

·         clientAuth

·         codeSigning

·         emailprotection

 

No extended flags are set by default.

/HELP[=(PK10,PK12)]

Display help.  More detailed help on manipulating PKCS#10 and PKCS#12 certs is available by adding the PK10 and PK12 qualifier, respectively, to the HELP switch.

/INPUT_FILES=(file1…filen)

(PKCS#12 only)

List of files to include in the PFX package.

/KEY_TYPE=type

Create a new key of type DSA or RSA.

/KEY_USAGE=(flag1…flagn)

(PKCS#10 only)

Key usage flags, as a comma-separated list.  Valid values are:

·         digitalSignature

·         nonRepudiation

·         keyEncipherment

·         dataEncipherment

·         keyAgreement

·         keyCertSign

·         CRLSign

·         encipherOnly

·         decipherOnly

 

Default values are digitalSignature and keyEncipherment.

/OPTION=(x,y)

Set certificate option x to y.  The options that can be set are dependent upon the type of certificate (PKCS#10 or PKCS#12) being affected.

For PKCS#10:

·         DNS - set certificate DNS names.

·         Email - set certificate email addresses.

 

For PKCS#12:

·         KeyPBE - set the PBE scheme for shrouding keys.  default means pbeWithSHAAnd3-KeyTripleDES-CBC.

·         SafePBE - set the PBE scheme for protecting safes.  default means pbeWithSHAAand40BitRC2-CBC.

/OUTPUT_FILE=prefix

Use prefix as the prefix for all output filenames.  Private key filenames will be prefix.SSH2 and PKCS#10 fields will be prefix.PKCS10.

/PRIVATE_KEY=keyname

Use keyname as the private key.

/SUBJECT=”subject

(PKCS#10 only)

Use subject as the certificate subject.

/VERSION

Display the version of CERTTOOL.

 

Example:

 

$ MULTINET CERTTOOL /PK10 /SUBJECT=(“cn=john doe,cn=lima,cn=beans” -

$_ /PRIVATE_KEY=DKA0:[JOHENDOE.SSH2]ID_DSA_1024_A 

 

PKCS#10 creation succcesful.

Wrote certificate request to output.pkcs10.

 


 

CERTVIEW

multinet certview [options] certificate [, certificate, …, certificate]

 

Description

CERTVIEW can be used to view certificates and check their validity.  This tool can also be used to output the data in format that is suitable for insertion in the SSH2_DIR:SSHD2_CONFIG configuration file.

 

Valid Options

/COMMENT

Prepend information lines with # (comment mark)

/DEBUG=n

Set debug level to n

/FORMAT_OUTPUT

Output data in a format suitable for insertion to usermap

/HELP

Display help

/QUIET

Don’t display certificate information

/VALIDATE=certificate

Validate using the CA certificate certificate

/VERBOSE

Increase verbosity (display extensions).

/VERSION

Display version information

 

Example:

$ MULTINET CERTVIEW MYCERT_PKCS7.P7B-1_SSH2_CRT

Certificate MYCERT_PKCS7.P7B-1_SSH2_CRT

Certificate issuer ........... : MAILTO=foo@bar.com, C=US, ST=CO,L=Colorado Springs, CN=FOOCA

Certificate serial number .... : 20668029027158235697617769792662904421

Certificate subject .......... : MAILTO=foo@bar,com, C=US, ST=CO, L=Colorado Springs, CN=FOOCA

 


 

CMPCLIENT

multinet cmpclient [options]/ca_access_url=“url” /subject=“subject” /cert-file [private-key]

 

Description

Allows users to enroll certificates. It will connect to a CA (certification authority) and use the CMPv2 protocol for enrolling a certificate. The user may supply an existing private key when creating the certification request or allow a new key to be generated.

 

Command Parameters

url

Specifies the URL for the Certification Authority

subject

Specifies the subject name for the certificate. For example,

“c-ca,o=acme,ou=development,cn=Bob Jones”

Cert-file

Specifies the file the certification is written to.

Private-key

Specifies the private key to be written to.

 

Valid Options

/BASE=name

Specify base prefix for the generated files.

/BITS=n

Specify the key length in bits.

/CA_URL=“url

Specify the URL of the Certification Authority.

/DEBUG=n

Set debug to level n (0-60).

/ENROLLMENT_PROTOCOL=prot

Use specified enrollment protocol (SCEP or CMP).

/EXTENSIONS

Enable extensions in the subject name.

/GENERATE_KEY

Generate a new private key.

/HELP

Print this help text.

/PROXY_URL“=url

Specify the URL of the HTTP proxy server URL to be used when connecting to the certification authority.

/REFNUM=refnum:key

Specify the CMP enrollment reference number and key.

/SOCKS_SERVER=“url

Specify the URL of the SOCKS server URL to be used when connecting to the certification authority.

/SUBJECT=“subject

Specifies the subject name for the certificate.

/TYPE=rsa|dsa

Specify the key type to generate (default: RSA)

/USAGE_BITS=n

Specify the key usage bits.

/VERSION

Print the version information for this program.

 

Examples:

1. Enroll a certificate and generate a DSA private key:

$ multinet cmpclient/type=dsa/generate_key/base=mykey/refnum=1234:abc -

_$ /ca_access_url=“http://www.ca-auth.domain:8080/pkix/”-

_$ /subject=“c=us,o=foobar,cn=John Doe” ca-certification.crt

This will generate a private key called mykey.prv and a certificate called mykey-0.crt.

2. Enroll a certificate using a supplied private key and provide an e-mail extension:

$ multinet cmpclient/base=mykey/refnum=12345:abcd -

_$ /ca_access_url=“http://www.ca-auth.domain:8080/pkix/”-

_$ /subject=“c=us,o=foobar,cn=John Doe:email=jdoe@example.com” -

_$ ca-certification.crt my_private_key.prv

This will generate and enroll a certificate called mykey-0.crt.

 

 

Note: SSH stores and uses software certificates in DER encoded binary format. You can use

sshkeygen to import and convert PKCS#12 packages (/pkcs_convert=file) into private key/certificate pair, X.509 format private key into SSH private key (/x509_convert=file) or PKC#7 into certificate (/extract_certs=file).

 

 


 

Public Key Subsystem

The public key subsystem and assistant that can be used to add, remove and list public keys stored on a remote server.  The public key assistant and server are based upon a recent IETF draft, so other implementations of SSH may not yet offer this functionality.

The public key assistant can be started with:

$ MULTINET PUBLICKEY_ASSISTANT [qualifiers] [[user@]host[#port]]

Public Key Assistant Commands

 

ADD key-file-name

Transfers the key file name to the remote system.  The file name specified is expected to be in the SSH2_CONFIG directory from the user's login directory. e.g., ADD ID_DSA_1024_A.PUB will transfer the public key in ID_DSA_1024_A.PUB to the remote system and updates the AUTHORIZATION.  file on the remote system to include this key name.

 

CLOSE

Closes the connection to the remote system.

 

DEBUG {no | debug_level}

Sets debug level (like in SFTP2).

 

DELETE key finger-print

Deletes the key that matches the fingerprint specified.  It is necessary to do a LIST command before this to get a list of the fingerprints (and for the program to build its internal database mapping fingerprints to keys).

 

EXIT

Exits the program.

 

HELP

Displays a summary of the commands available.

 

LIST

Displays the fingerprint and attributes of keys stored on the remote system.  The attributes that are listed will vary with key. Example output:

Fingerprint: xozil-bemup-favug-fimid-tohuk-kybic-loz-fukuc-kuril-gezahloxex

key type: ssh-dss

Comment: 1024-bit dsa, user@simple.example.com, Wed Jun 05 2022 21:05:40

 

OPEN [user@]host[#port]

Opens a connection to a remote public key subsystem.

 

QUIT

Quits the program.

 

UPLOAD key-file-name

Synonym for the ADD command.

 

VERSION [protocol-version]

Displays or sets the protocol version to use. The protocol version can only be set before the OPEN command is used. The default version is 1.

 

Public Key Assistant Qualifiers

 

/BATCHFILE

Provides a file with public key assistant commands to be executed. Starts SSH2 in batch mode. Authentication must not require user interaction.

 

/CIPHER

Selects encryption algorithm(s).

 

/COMPRESS

Enables SSH data compression.

 

/DEBUG

Sets debug level (0-99).

 

/HELP

Displays a summary of the qualifiers available.

 

/MAC

Selects MAC algorithm(s). /MAC=(mac-1,…,mac-n)

 

/PORT

Tells SFTP2 which port SSHD2 listens to on the remote machine.

 

/VERBOSE

Enables verbose mode debugging messages. Equal to /DEBUG=2. You can disable verbose mode by using debug disable.

 

/VERSION

Displays version number only.