15. Accessing Remote Systems with the Secure Shell (SSH) Utilities
The SSH implementation for TCPware provides the client software for allowing secure interactive connections to other computers in the manner of rlogin/rshell/telnet.
The following topics describe how to configure, maintain, and use the following TCPware 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. The SSH1 implementation is based on the V1.5 protocol and 1.3.7 F-Secure code base, and the SSH2 implementation is based on the V2 protocol and the F-Secure 3.2.0 code base. While SSH2 is generally regarded to be more secure than SSH1, both protocols are offered by TCPware, and although they are incompatible, they may exist simultaneously on server systems, including TCPware servers. The SSH client identifies the protocol(s) offered b3y 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 TCPware SSH2 (this does not apply to SSH1 sessions) is compiled from unaltered cryptographic source code from F-Secure which is FIPS 140-2 level 2 compliant, as determined by the Computer Security Division of the National Institute of Science and Technology (NIST).
SSH Client Return Status Codes
In versions of TCPware prior to V5.x, the return status codes from the SSH clients listed above were based on UNIX-style status codes, causing problems for many VMS users. Beginning with TCPware V5.x, a logical name may be defined that will cause the SSH clients listed above to use VMS-style return codes. If the logical name isn’t defined, the old-style codes will still be used by default. Refer to table C-1 in the TCPware for OpenVMS User’s Guide for a description of the new status codes.
To enable the new status codes instead of using the pre-TCPware V5.x codes, the logical name TCPWARE_SSH_NEW_STATUS_CODES must be defined system-wide
Secure Shell Client (remote login program)
$ SSH hostname[#port] [qualifiers] [command]
or
$ SSH "user@hostname[#port]" [qualifiers] [command]
SSH (Secure Shell) is a program for logging into and executing commands on a remote system. It replaces 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.
|
Table 16-1 SSH Client Command Options and Qualifiers |
|
|
Qualifier |
Description |
|
/ALLOW_REMOTE_CONNECT |
Allow remote hosts to connect local port forwarding ports. The default is only localhost; may connect to locally binded ports. |
|
/CIPHER=(cipher-1,...,cipher-n) |
Select encryption algorithm(s). |
|
/COMPRESS |
Enable compression. |
|
/CONFIG_FILE=file |
Read an alternative client configuration 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. |
|
/IDKEY=(key1,key2,...,keyn) |
Specifies the key(s) to be used for publickey authentication. If specified, the IDENTIFICATION file is ignored. |
|
/IPV4 |
Use IPV4 protocol to connect. |
|
/IPV6 |
Use IPV6 protocol to connect. |
|
/LOCAL_FORWARD= |
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 option has 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= |
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 user name. |
|
VERBOSE |
Display verbose debugging messages. Equal to |
|
/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 off the individual SYS$LOGIN directory[1]. In addition, a system-wide directory of known public keys exists in the system directory pointed to by the logical name TCPWARE_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.
Hostbased Authentication
Hostbased 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.
• For SSH2
When a user logs in:
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 TCPWARE_SSH2_KNOWNHOSTS_DIR logical name. The key file is named <FQDN>_<algorithm>.PUB. For example, if the client system is “foo.bar.com” and its key uses the DSS algorithm, the file that would contain its key on the server would be “FOO_BAR_COM_SSH-DSS.PUB”. This key file must exist on the server system before attempting hostbased 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.
• For SSH1
This form of 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.
Note! To the administrator: SSH_DIR:HOSTS.EQUIV,.RHOSTS, and the rlogin/rshell protocol are inherently insecure and should be disabled if security is desired.
Publickey 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.
• For 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.
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.
3 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.
4 SSH
implements the RSA authentication protocol automatically.
The Key Identity files are created with SSHKEYGEN. To create the RSA key pair files with TCPware:
• 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. SeePub for more information.
• For SSH2
When the user logs in:
1 The client reads possible keys to be used for authentication from its IDENTIFICATION file. Note that this file does not contain the actual keys; rather, it contains the name of the key files.
2 The client sends to the server its list of keys.
3 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.
4 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.
5 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 Publickey 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:
$ SSH2 ”XXXXXXX@HOSTNAME” command
XXXXXXX is the username that was specified in all uppercase letters.
Public key authentication fails.
$ SSH2 “xxxxxxx@HOSTNAME command
xxxxxx 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 with “~.”. 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 SSH Client Command Options and Qualifiers for details.
2 User’s configuration file (SYS$LOGIN [.SSH2]SSH2_CONFIG). See Table 16-2 for details.
3 System-wide configuration file (SSH2_DIR:SSH2_CONFIG). See SSH2_CONFIG File Configuration Keywords 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 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 |
sNone |
Similar to HostCA, but disables CRL checking for the given ca-certificate. |
|
IdentityFile |
Filename |
Identification |
Name of identification file for publickey authentication |
|
KeepAlive |
Y/N |
Y |
Send keepalives |
|
LdapServers |
ServerURL |
None |
Specified as 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 users’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 |
|
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 |
|
VerifyHostKeyDNS |
Y/N/ASK |
N |
Determines if the host key fingerprint must be matched in DNS. |
Note! Notes Regarding SSH2_CONFIG
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 dilbert
host petunia.flowers.com
rose:
port 16003
user dogbert
host rose.flowers.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.flowers.com, and will use the default username of “dilbert”.
• When a user types “$ SSH ROSE”, the client will connect to port 16003 on host rose.flowers.com, and will use the default username of “dogbert”, 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 “catbert” when connecting to host rose instead of the default username of “dogbert”, this would be specified as:
$ SSH /USER=CATBERT 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
This keyword is deprecated (though it still works). Use Options instead.
Options that can be specified:
allow-from and 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 {Allow,Deny} Hosts 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 that long a 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.
SSH Client/Server 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!
$!
$ netcu 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 2014 13:43:54
Private key saved to tcpware_ssh2_hostkey_dir:hostkey.
Public key saved to tcpware_ssh2_hostkey_dir:hostkey.pub
$ directory tcpware_ssh2_hostkey_dir:hostkey.*
Directory TCPWARE_SPECIFIC:[TCPWARE.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 tcpware_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-2014 17:07
Last non-interactive login on Monday, 1-MAR-2014 08:30
MYSERV_$ type tcpware: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
# TCPWARE_ - 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-2014 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
$!
$ netcu sshkeygen /ssh2
Generating 1024-bit dsa key pair
1 oOo.oOo.oOo.
Key generated.
1024-bit dsa, myname@myclient.foo.com, Thu Mar 04 2014 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-2014 13:46
Last non-interactive login on Tuesday, 2-MAR-2014 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-2014 14:10:26.16
%REM-S-END, control returned to node MYCLIENT::
Note! The public key assistant and subsystem can also be used to transfer public keys and maintain the authorization file to implementations that support the public key subsystem.
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
$ !
$ NETCU 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 TCPware FTP user process V6.0(119)
Connection opened (Assuming 8-bit connections)
<daisy.hair.com TCPware FTP Server Process V6.0(16) at Thu 6-Mar-2013
3:20PM-EDT
[Attempting to log in as myname]
<User MYNAME logged into DISK$SYS_LOGIN:[MYNAME] at Thu 6-MAR-2013
3:21PM-EDT, 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-2014 08:07
Last non-interactive login on Thursday, 6-MAR-2014 15:21
Logged into DAISY at 4-MAR-2014 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:
1. Copy the private key and certificate (.crt) into the user’s [.ssh2] directory, and edit the [.ssh2] identification file, adding entry “certkey private key name”.
$dir [.ssh2]
Directory DKA0:[DILBERT.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 userid that’s allowed to login for the given cert (there
might be multiple userids for a given certificate).
Mapping rule is one of subject, email, serialandissuer
and emailregex.
Subject means that the following mapdata is matched against the subject
of the certificate:
Email is the e-mail alternative subject extension (with emailregex can
be used regular expressions - e.g., %subst% emailregex ([a-z}|+)@foo\.com would
be any trusted certificate having e-mail alternative name of
<username>@foo.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=Dilbert Dogbert).
SSH2 Hostkey Authentication Using Certificates
Server setup:
1. Create a certificate for the server. Host certificate must contain FQDN as DNS alternative name.
2. Copy the private key and certificate into TCPWARE_SSH2_HOSTKEY_DIR directory.
3. Add the following entries into ssh2_dir:sshd2_config file
HostKeyFile tcpware_ssh_hostkey_dir:<hostcert>
HostCertificateFile tcpware_ssh_hostkey_dir:<hostcert>.crt
Client setup:
1. Copy the CA certificate in TCPWARE_SSH2_HOSTKEY_DIR directory.
2. Add the following entries into ssh2_dir:ssh2_config
HostCA tcpware_ssh_hostkey_dir:<CAcert>.crt
DefaultDomain <domain of the FQDN of the client>
Note! For testing purposes, you can use HostCANoCRLs instead of HostCA to disable CRL checking.
Host Key Verification Using DNS
TCPware SSH can be configured to calculate the fingerprint of the host key it receives, then perform a lookup in DNS for that fingerprint. This can help prevent man-in-the-middle attacks. See RFC 4255 for more details. Refer to Appendix D of the TCPware for OpenVMS Management Guide for information on configuring DNSSEC on TCPware systems.
In order to do this, the following conditions must be met:
• DNSSEC must be enabled and configured for the DNS used by the client.
• A host key SSHFP record must be generated, signed by the zone key, and added to the DNSSEC configuration as a type SSHFP record for the server system. The TCPware SSH-KEYGEN2 utility can be used to display the host key SSHFP type record for DNS.
• The client configuration keyword VerifyHostKeyDNS must be set to “Y” or “ASK”
• The client configuration keyword StrictHostKeyChecking must be set to “Y” or “ASK”.
When the host key is received from the server, and after the client goes through its normal host key checking (e.g., does the client already know about this host key), it checks the status of the VerifyHostKeyDNS keyword. If not set to “N”, the client calculates the fingerprint of the host key, then performs a DNS lookup of the key,
If no records are found, the user may be given the option of proceeding (if VeifyHostKeyDNS is set to “ASK”). If the user responds “N”, then the session is terminated. Otherwise, the host key is accepted and the session continues.
If one or more records are found, the fingerprint and type of the host key received are compared against those found in DNS. If no matches are made, the user may be given the opportunity to ignore this state (see above).
If a match was made, the RRSET_VALIDATED flag returned by DNSSEC is examined to see if the signing of the records can be fully trusted. If this is true, the host key processing is complete. If this flag is false, the user may be given the opportunity to ignore this state (see above).
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 localhost to the
remotehost 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 Table 16-3 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.flowers.com was accessed via port 22,
the keyfile would be "KEY_22_TULIP_FLOWERS_ |
|
[.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: |
|
SSH_DIR:.RHOSTS |
Server System |
Is used in hostbased 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 user name 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. |
|
SSH_DIR:.SHOSTS |
Server System |
Is used the same way as .RHOSTS. |
|
TCPWARE:HOSTS.EQUIV |
Server System |
Is used during .rhosts authentication. It contains fully-qualified hosts names, one per line. If the client host is found in this file, login is permitted provided client and server user names are the same. Additionally, successful RSA host authentication is required. This file should only be writable by SYSTEM. |
|
TCPWARE: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. |
|
TCPWARE_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.flowers.com was accessed via port 22,
the keyfile would be "KEY_22_TULIP_FLOWERS_ |
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.
Note! The Host Key has no password.
SSH1
NETCU SSHKEYGEN /SSH1 [/BITS=n] [/IDENTITY_FILE=file]
[/PASSPHRASE=passphrase] [/COMMENT=comment]
NETCU SSHKEYGEN /SSH1 /CHANGE_PASSPHRASE [/PASSPHRASE=old_passphrase]
[/NEW_PASSPHRASE=new_passphrase]
NETCU SSHKEYGEN /SSH1 /CHANGE_COMMENT [/PASSPHRASE=passphrase]
[/COMMENT=comment]
NETCU SSHKEYGEN /SSH1 /CHANGE_CIPHER [/IDENTITY_FILE=file]
[/PASSPHRASE=passphrase]
NETCU SSHKEYGEN /SSH1 /HOST [/BITS=n][/COMMENT=comment]
Table 16-4 SSH1 SSHKEYGEN Options
|
Option |
Description |
|
/BITS=nnn |
Specify key strength in bits |
|
/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
NETCU SSHKEYGEN /SSH2[/BITS=n][/COMMENT=comment][/KEYTYPE=type]
[/KEYS=(key1...keyn)]
[/PASSPHRASE=ppp|/NOPASSPHRASE][/STIR=file][/QUIET]
NETCU SSHKEYGEN /SSH2/HOST
[/BITS=n][/COMMENT=comment][/STIR=file][/QUIET]
NETCU SSHKEYGEN /SSH2/DERIVE_KEY=file
NETCU SSHKEYGEN /SSH2/EDIT=file
NETCU SSHKEYGEN /SSH2/FINGERPRINT=file
NETCU SSHKEYGEN /SSH2/INFO=file [/BASE=n]
NETCU SSHKEYGEN /SSH2/SSH1_CONVERT=file
NETCU SSHKEYGEN /SSH2/X509_CONVERT=file
NETCU SSHKEYGEN /SSH2/PKCS_CONVERT=file
NETCU SSHKEYGEN /SSH2/EXTRACT_CERTS=file
NETCU SSHKEYGEN /SSH2/HELP
NETCU SSHKEYGEN /SSH2/VERSION
NETCU SSHKEYGEN /SSH2/NOWARN
NETCU SSHKEYGEN /SSH2/DNS_DIGEST
|
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. |
|
/DNS_DIGEST |
Calculate and display a DNSSEC SSHFP record of the local host key that can be added to a DNS configuration file. |
|
/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 (authentication agent)
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:
$ SSHAGENT
2. Spawn it as a subprocess:
$ SPAWN/NOWAIT 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 Publickey 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 TCPWARE_SSH_AGENT_ username logical name. Note that while the agent mailbox is accessible only by the user that starts the agent, a user with sufficient VMS privileges could access the agent mailbox and steal or modify keys currently loaded into the agent (although, the keys as stored on disk cannot be modified simply by accessing the agent).
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.
$ SSHADD /LIST displays the identities currently held by the agent. The
idea is that the agent is run on the user's workstation.
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.
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 users[.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
certtool [options] /pk10 /subject=<subject> /key_usage=<flags>
/extended_key_usage=<flags>
certview [options] /pk12 /input_files=<objects>
Description
The CERTTOOL utility is used for different needs concerning X.509 certificates.
Valid 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 files 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:
$ CERTTOOL /PK10 /SUBJECT=(“cn=john doe,cn=lima,cn=beans”-
$_ /PRIVATE_KEY=DKA0:[JOHENDOE.SSH2]ID_DSA_1024_A
PKCS#10 creation successful.
Wrote certificate request to output.pkcs10.
CERTVIEW
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 user-map |
|
/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:
$ 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
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 |
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:
$
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=Dilbert
Dogbert”
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:
$ cmpclient/base=mykey/refnum=12345:abcd -
_$ /ca_access_url=“http://www.ca-auth.domain:8080/pkix/”-
_$ /subject=“c=us,o=foobar,cn=Dilbert
Dogbert:email=foo@bar.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 Publickey assistant can be started with:
$ PUBLICKEY_ASSISTANT [qualifiers] [[user@]host[#port]]
Publickey 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 finger prints (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-huloz-fukuc-kuril-gezah-loxex
key type: ssh-dss
Comment: 1024-bit dsa, user@simple.example.com, Wed Jun 05
2012 21:05:40
OPEN [user@]host[#port] Opens a connection to a remote publickey subsystem.
QUIT- Quits the program.
UPLOAD 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.
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.
Publickey Assistant Qualifiers
/BATCHFILE - Provides file with publickey 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.
Other Implementations
VanDyke includes this in their SecureFX and VShell products. VanDyke also has a patch available for a server for OpenSSH.