Chapter 6
Accessing Remote Systems with the Secure Shell (SSH) Utilities
The SSH implementation for SSH for OpenVMS 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 SSH for OpenVMS clients:
• Secure Shell Client (remote login program)
• SSHKEYGEN
• SSHAgent (authentication agent)
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.1.0 code base. 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.
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. The user must prove his/her identity to the remote system using one of several methods.
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 [ In this chapter, the [.SSH] subdirec t ory in the user’s login directory displays as SYS$LOGIN:[.SSH]
[.SSH2] displays as SYS$LOGIN:[.SSH2]] . 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.
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.
Note! HP’s TCP/IP services do not use the traditional UNIX rhosts and hosts.equiv files; it uses a proprietary format. Therefore, any information added to HP’s files via the "ADD PROXY" command must also be manually added to the SSH_DIR:RHOSTS and SSH_DIR:HOSTS.EQUIV files in order for it to be used by SSH for OpenVMS.
• 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 MULTINET_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 in the FILES section), 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.
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 SSH for OpenVMS:
1 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 Publickey Authentication 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.
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.
Expired Passwords
The SSH client supports the changing of expired passwords for SSH2 sessions only. When a password expires that may be changed by the user, the user will be prompted to re-enter the original password, then to enter a new password twice.
The new password is validated against the password history maintained by VMS. It is also validated against the VMS system dictionary of restricted passwords.
Note! If a user is required to use system-generated passwords, either because the GENPWD flag is set in SYSUAF or because the user has exceeded the limits on the number of password history entries, the user will not be allowed to log in via SSH. This is because the protocol does not allow for this VMS-specific feature. In these cases, the user must either log in via Telnet and reset the password that way, or the user must contact the system manager to reset the password.
The SSH v1 protocol does not provide a method for changing an expired VMS password. When an expired password is encountered by the SSH1 server, it will do one of two things.
1 If the logical name MULTINET_SSH_ALLOW_EXPIRED_PW is defined for allowing access for passwords that have exceeded the UAF value for PWDLIFETIME, or if the logical name MULTINET_SSH_ALLOW_PREEXPIRED_PW is defined for allowing access for users that have a pre-expired password, the server will allow the user to log in. In the logical name table LNM$SSH_LOGICALS, the logical name MULTINET_SSH_pid_PWDEXP (where pid is the process ID for the user process) will be defined. The system manager can look for this logical to be defined, and if so, take action such as executing the DCL SET PASSWORD command.
2 If the appropriate logical is not set as described above, the user will be denied access to the system. In that case, the user must log in interactively via another mechanism such as telnet and change the password, or the system manager must reset the password.
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.
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.
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).
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 Table 6-1 for details.
2 User's configuration file (in the local SYS$LOGIN [.SSH2]SSH2_CONFIG.) directory.
See Table 6-2 for details.
3 System-side configuration file (SSH2_DIR:SSH2_CONFIG.) See Table 6-2 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.
Note!
The qualifiers listed in Table 6 -1 are position dependent. You must place the qualifier(s) immediately after the SSH command. So the correct syntax is SSH /qualifier node command.
Table 6 -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. |
|
Select encryption algorithm(s). | |
|
Enable compression. | |
|
Read an alternative config file. | |
|
Set debug level. | |
|
Set escape character; "none" = disable (default: ~). | |
|
/HELP |
Display help text. |
|
Identity file for public key authentication. | |
|
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 all terminal activity to the specified log file. Defaults to SSH.LOG if "logfilename" is not specified. | |
|
Select MAC algorithm(s). | |
|
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) |
|
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. |
|
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"/DEBUG=2". |
|
/VERSION |
Display version number of the client. |
Table 6-2 SSH2_CONFIG File Configuration Keywords
The user may specify default configuration options 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 system will connect to port 17300 on petunia.flowers.com, and will use the default username of "dilbert".
• When a user types "$ SSH ROSE", the system 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 system will use the default username of "limabean", and 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:
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 JUN 06 2002 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, 3-JUN-2002 17:07
Last non-interactive login on Monday, 3-JUN-2001 08:30
MYSERV_$ type ssh_dir: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 3-JUN-2002 13:46:58.91
%REM-S-END, control returned to node MYCLIENT::
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 Jun 06 2001 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
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, 4-JUN-2002 13:46
Last non-interactive login on Tuesday, 4-JUN-2002 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 4-JUN-2002 14:10:26.16
%REM-S-END, control returned to node MYCLIENT::
$ ! 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 V4.4(119)
Connection opened (Assuming 8-bit connections)
<daisy.hair.com MultiNet FTP Server Process V4.4(16) at Thu 6-Jun-2002 3:20PM-EDT
[Attempting to log in as myname]
<User MYNAME logged into DISK$SYS_LOGIN:[MYNAME] at Thu 6-JUN-2002 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, 6-JUN-2002 08:07
Last non-interactive login on Thursday, 6-JUN-2002 15:21
Logged into DAISY at 6-JUN-2002 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.
When copying public key files from systems to the system running the SSH server, it is important for the key file to be created in STREAM-LF format or fixed-length 512-byte format on the VMS system. Use DIRECTORY/FULL to determine the format of the key file. The following copy operations should preserve the file format correctly from the specified source systems:
OpenVMS - MultiNet FTP in VMS mode
- DCL COPY
- FTP in BINARY mode
- SCP2
Other O/S - SCP2
- FTP in BINARY mode
If the key file is in VARIABLE format, the server is unable to read the key file successfully, with the result that public-key authentication fails. To convert a VARIABLE format key file to STREAM-LF format, the following FDL file may be used with the RMS CONVERT facility:
FIX_SSH2_KEYS.FDL:
TITLE "File for fixing SSH2 public keys"
IDENT "OpenVMS FDL Editor"
SYSTEM
SOURCE "OpenVMS"
FILE
ALLOCATION 64
BEST_TRY_CONTIGUOUS yes
EXTENSION 6
ORGANIZATION sequential
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL none
FORMAT stream_LF
SIZE 0
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 in a configuration file or on the command line using the following qualifier:
/LOCAL_FORWARD=([protocol/]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.
The recognized values for the optional protocol are: TCP (default), HTTP( equivalent to TCP), and FTP. The string inside of the ( ) must be quoted " " when the protocol is specified to prevent DCL from interpreting the "/" as the start of a qualifier.
TCP and HTTP don’t do anything to the data passing over the connection. When FTP is used, the data stream is examined for FTP, PORT, and PASV commands and their replies so that an SSH2 data stream can be substituted for the FTP data ports.
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. see graphic
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. see graphic
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.
The qualifier
/REMOTE_FORWARD=([protocol/]remoteport1:remotehost:remoteport2)
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. see graphic
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, issue the command:
$ 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.
The files in Table 6-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:).
Note! HP’s TCP/IP services do not use the traditional UNIX rhosts and hosts.equiv files; it uses a proprietary format. Therefore, any information added to HP’s files via the "ADD PROXY" command must also be manually added to the SSH_DIR:RHOSTS and SSH_DIR:HOSTS.EQUIV files in order for it to be used by SSH for OpenVMS.
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
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]
Table 6-4 SSH1 SSHKEYGEN Options
|
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. |
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/CONVERT_SSH1=file
MULTINET SSHKEYGEN /SSH2/CONVERT_X509=file
MULTINET SSHKEYGEN /SSH2/CONVERT_PKCS=file
MULTINET SSHKEYGEN /SSH2/EXTRACT_CERTS=file
MULTINET SSHKEYGEN /SSH2/HELP
MULTINET SSHKEYGEN /SSH2/VERSION
Table 6-5 SSH2 SSHKEYGEN Options
|
Option |
Description |
|
/BASE=nnn |
Number base for displaying key info |
|
/BITS=nnn |
Specify key strength in bits (default = 1024). |
|
/COMMENTS="comment" |
Provide the comment. |
|
/CONVERT_PKCS=file |
Convert a PKCS 12 file to an SSH2 format certificate and private key. |
|
/CONVERT_SSH1=file |
Convert SSH1 identity to SSH2 format. |
|
/CONVERT_X509=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. |
|
/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. |
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.
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/PROCESS_NAME="SSH_AGENT"/INPUT=NLA0:
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 MULTINET_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.
$ MULTINET SSHADD /LIST displays the identities currently held by the agent. The idea is that the agent is run on the user's workstation.
Adds identities for the authentication agent.
MULTINET SSHADD [OPTIONS] [FILE[,FILE,FILE]]
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.
These files exist in SYS$LOGIN:
