The VMS SharkOpenVMS Notes: Configuring SSH2 for SFTP, SCP, etc.

  1. The information and software presented on this web site are intended for educational use only by OpenVMS application developers and OpenVMS system attendants.
     
  2. The information and software presented on this web site are provided free of charge.
     
  3. The information and software presented on this web site are presented to you as-is. I will not be held responsible in any way if the information and software presented on this web site damages your computer system, business or organization (sounds like the legal warning from a Microsoft shrink-wrap seal, eh?)
     
  4. Is this text too small? You have two options:
    1. hold down the CTRL key while rolling the mouse wheel (zoom-in, zoom-out)
    2. use your keyboard like so:
      • hit: CTRL with "-" key to zoom smaller
      • hit: CTRL with "+" key to zoom larger
      • hit: CTRL with zero key to reset zoom
 Edit: 2014-10-28 (update section: TCPIP Services for OpenVMS)

Menu

SSH and SSH2

Modes

  1. In default out-of-the-box mode, these technologies encrypt your connection to conceal everything. Most interactive users will not need to go beyond this mode.
     
  2. You can go one step further and deposit YOUR public key at a remote location so you will not need a password (the private-public key replaces the password). This is a prerequisite for doing autonomous non-interactive (batch) transfers.
     
  3. If you like, you can encode a pass-phrase in your private key (this will foil an evil sys op on your system) but this is not allowed when setting up Secure Shell for automated (batch) transfers.  

Configuring SSH2 for "Key Authentication" ( TCPware )

Programs like SFTP, SFTP2, SCP, SCP2, Secure Telnet, etc. all rely upon SSH (Secure SHell) which means that SSH must be set up and active before you try these other technologies.

If you have ever attempted to use SFTP to do an automated data transfer via a application program or shell script, then you already know that there is no way to provide a password. You might think this is a bug, but it is really a security feature. The creators of SFTP wanted to stop people from placing hard-coded passwords in scripts.

  1. The easiest way to create the necessary files is to first log into the local account designated to do the automated SFTP transfer.
     
    Caveat: If you disregard my local account suggestion then attempt to create these files with a privileged account (it is possible by the way) then make a single typo while doing so, certain utilities (like SSHKEYGEN), will attach newly created keys to YOUR account rather than target account you are attempting to modify.
     
  2. You will not be able to test the file transfer capabilities unless you are logged into the designated transfer account.
     
  3. In some instances, the far-end account manager will only provide you with an account and password. It will be your responsibility to log onto the far-end to place your public key.
     
  4. SSH1 only supports RSA keys but SSH2 supports either RSA or DSA keys. The patent on the RSA key algorithms expired in 1999 but may people still use it.
     
  5. Don't quote me on this, but I have been led to believe that these large keys (512 to 4096 bits) are only used during the initial connection set up. After that, all encryption is done by a less demanding ciphers like: DES (56 bit), IDEA (128 bit), TwoFish (256 bit), etc. 
     
  6. Caveat: I may be wrong, but I think DSA keys are preferred with SSH2, not RSA.

    Bug (2011-02-14): I have discovered some weird crashes with recent SSH patch kits for both TCPware-5.8 and TCPware-5.9. PSC has been notified.
    Update (2011-09-15): PSC fixed most problems fixed with ECO kit SSH_V592P030 but SSHKEYGEN still defaults to RSA so maybe this was a feature :-)
    Update (2012-04-xx): SSHKEYGEN in ECO kit SSH_V592P040 defaults to DSA so now everything is right with the world
     
    1. this command will used to default to RSA encryption:
       
          $ sshkeygen /ssh2/nopass
       
    2. this command will used to force a stack dump (unless KEYTYPE is specified):
       
          $ sshkeygen /ssh2/nopass/keys=[.ssh2]yada
       
    3. but this command appears to work properly (no stack dump):
       
          $ sshkeygen /ssh2/nopass/keys=[.ssh2]yada/keytype=dsa
       
    So from this point on, these notes will always specify the KEYTYPE whether the bug gets fixed or not.

    It may be a good idea to always specify the KEYTYPE as a command line parameter then also include the key-type string (DSA or RSA) in the file name. This will saving you time during later debugging. I prefer names of the form: user_node_type_bits (neil_ON_KAWC09_dsa_1024) so they'll be self describing after the public half is copied to a remote location.
     
  7. More UI weirdness.
     
    SSHKEYGEN is a DCL symbol which is converted into NETCU commands. Therefore:
    DCL Command Notes
    $sshkeygen /help this does not work
    $sshkeygen /ssh1 /help this does work
    $sshkeygen /ssh2 /help this does work
     
  8. SSH Key Size:
     
    1. Generating 1024-bit keys on Alpha or Itanium seem to require no time at all.
       
    2. It doesn't matter if you are on a real VAX or an emulation like Charon-VAX on a fast Pentium-Xeon server, generating keys larger than 512-bits seem to take a ridiculous amount of time (many minutes) so I would advise against them.
       
      Caveat: When on VAX, if your destination server requires public keys larger than 512 then try 768 before you go to 1024.

Keystroke Examples (OpenVMS)

Example Assumptions:

Caveats:

  1. I strongly recommend you set up two pristine test accounts on your system. You will need them to test your SSH technology after any stack upgrades or patches. The classical names in cryptography are Bob and Alice so I created accounts BOB and ALICE.
     
  2. Lowercase key names
     
    1. On VMS-to-VMS connections, case is almost always irrelevant because everything is up-cased behind the scenes.
       
    2. On UNIX-to-VMS connections case is also almost irrelevant (because everything is up-cased behind the scenes)
       
    3. On VMS-to-UNIX connections uppercase may cause some problems. Why? Let's assume your "identification." file contained the line "idkey YADA". During the initial connection handshake, "YADA" will be sent across the link but many UNIX clients will then append a lower case extension expecting to find public key file on the UNIX system named "YADA.pub". So do yourself a favor and try to always use lowercase letters in all your key files, and key references. If your VMS account is not set up to work in lower case (only applies to OpenVMS-7.2 and later; 90% are not set up this way), then you will need to switch back and forth like so:
      $SET PROC/CASE=SENS/PARSE=EXTENDED                    ! switch to dangerous mode
      ...do some case-sensitive work. Like:
         1) generating lowercase keys...
         2) renaming files from uppercase to lowercase
      $SET PROC/CASE=BLIND/PARSE=TRADITION ! switch back to default OpenVMS mode
      You may find these two DCL scripts useful.

Demo Commands and Responses

legend:
	<ur>	= user response
	<sr>	= system response

================================================================================
Step-01
Interactively log into the local system as BOB then create a new key-pair
================================================================================
<sr>	-i-in script: CSMIS$USER3:[ADMCSM.BOB]LOGIN.COM;15		! from login script
	-i-on node  : KAWC09						! from login script
	-i-exiting  : login.com						! from login script
	KAWC09::BOB>							! user's DCL prompt
<ur>	sshkeygen /ssh2/keys=[.ssh2]BOB_ON_KAWC09/nopass/keytype=dsa	! type this command
<sr>	Generating 1024-bit dsa key pair
	   1 oOo.oOo.oOo
	Key generated.
	1024-bit dsa, BOB@kawc09.on.bell.ca, Tue Aug 19 2008 10:37:30
	Private key saved to [.SSH2]BOB_ON_KAWC09			! private key stays here
	Public key saved to [.SSH2]BOB_ON_KAWC09.pub			! public key to distribute
	
	KAWC09::BOB>							! user's DCL prompt

================================================================================
Step-02
Create file "[.ssh2]identification." (tells the client which keys are available)
Notes: 1. only use $CREATE if the file doesn't yet exist (otherwise use $EDIT)
       2. otherwise, add the line desired line to the existing file
       3. only add entries for private keys located in this directory (some of
          these public keys may have been copied here from other systems)
================================================================================
<sr>	KAWC09::BOB>
<ur>	cre [.ssh2]identification.	! notice "no file extension"
	idkey BOB_ON_KAWC09		! entry for a private key file
	<ctrl-z>			! hit the ctrl-z key
<sr>	KAWC09::BOB>			! user's DCL prompt

================================================================================
Step-03
Copy desired public key(s) to the destination account on remote system
Notes: 1. use $scp (secure copy) or $sftp (secure FTP)
       2. you will need a password for the remote account
       3. if you don't have access to it, then mail this key-file to
          someone at the remote system who can install it for you
       4. if you've read any books on spying or cryptography, this is the step
          where the ambassador delivers the code keys in a diplomatic pouch.
================================================================================
<sr>	KAWC09::BOB>
<ur>	scp [.ssh2]BOB_ON_KAWC09.pub - 
"ALICE@kawc15.on.bell.ca::[.ssh2]BOB_ON_KAWC09.PUB" <sr> Host key not found from database. Key fingerprint: xuhec-habos-durif-tohev-fuzer-cyhip-kydiv-labih-ribyg-posuz-koxyx You can get a public key's fingerprint by running (OpenVMS) $ sshkeygen /ssh2/fingerprint=publickey.pub (UNIX) % ssh-keygen -F publickey.pub on the keyfile. Are you sure you want to continue connecting (yes/no)? <ur> yes <sr> Host key saved to CSMIS$USER3:[ADMCSM.BOB.SSH2.HOSTKEYS]key_22_kawc15_on_bell_ca.pub host key for kawc15.on.bell.ca, accepted by BOB Tue Aug 19 2008 10:58:27 *** WARNING *** THE PROGRAMS AND DATA STORED ON THIS SYSTEM ARE LICENSED TO OR ARE PRIVATE PROPERTY OF THIS COMPANY AND ARE LAWFULLY AVAILABLE ONLY TO AUTHORIZED USERS FOR APPROVED PURPOSES. UNAUTHORIZED ACCESS TO ANY PROGRAM OR DATA ON THIS SYSTEM IS NOT PERMITTED, AND ANY UNAUTHORIZED ACCESS BEYOND THIS POINT MAY LEAD TO PROSECUTION. THIS SYSTEM MAY BE MONITORED AT ANY TIME FOR OPERATIONAL REASONS, THEREFORE, IF YOU ARE NOT AN AUTHORIZED USER, DO NOT ATTEMPT TO LOGIN. ALICE@kawc15.on.bell.ca's password: <ur> ######### ! enter Alice's password <sr> BOB_ON_KAWC09.pub | 751B | 751B/s | TOC: 00:00:01 | 100% ! <--- copy success KAWC09::BOB> ! user's DCL prompt ================================================================================ Step-04 set up file "[.ssh2]authorization." on the remote system note: 1) do this in the remote account you wish to use 2) don't use $CREATE if the file already exists (use $EDIT instead) ================================================================================ <sr> KAWC09::BOB> ! user's DCL prompt <ur> ssh ALICE@kawc15.on.bell.ca ! enter this command <sr> *** WARNING *** THE PROGRAMS AND DATA STORED ON THIS SYSTEM ARE LICENSED TO OR ARE PRIVATE PROPERTY OF THIS COMPANY AND ARE LAWFULLY AVAILABLE ONLY TO AUTHORIZED USERS FOR APPROVED PURPOSES. UNAUTHORIZED ACCESS TO ANY PROGRAM OR DATA ON THIS SYSTEM IS NOT PERMITTED, AND ANY UNAUTHORIZED ACCESS BEYOND THIS POINT MAY LEAD TO PROSECUTION. THIS SYSTEM MAY BE MONITORED AT ANY TIME FOR OPERATIONAL REASONS, THEREFORE, IF YOU ARE NOT AN AUTHORIZED USER, DO NOT ATTEMPT TO LOGIN. ALICE's password: <ur> ######### ! enter Alice's password <sr> Authentication successful. Last interactive login on Tuesday, 19-AUG-2008 11:30:44.51 Last non-interactive login on Tuesday, 19-AUG-2008 10:58:35.45 1 login failure since last successful login -i-in script: CSMIS$USER3:[ADMCSM.ALICE]LOGIN.COM;15 -i-on node : KAWC15 -i-exiting : login.com KAWC15::ALICE> ! remote user's DCL prompt <ur> cre [.ssh2]authorization. ! notice "no file extension" key BOB_ON_KAWC09.PUB ! entry for a public key file <ctrl-z> ! hist the ctrl-z key <sr> KAWC15::ALICE> ! <ur> log ! log out <sr> ALICE logged out at 19-AUG-2008 11:40:49.01 Connection to kawc15.on.bell.ca closed. KAWC09::BOB> ! local user's prompt
When you are finished your directories and files should look similar to this:
+---------------------------------------------------+---------------------------------------------------+
| User: BOB                                         | User: ALICE                                       |
| Node: KAWC09                                      | Node: KAWC15                                      |
| OS  : OpenVMS                                     | OS  : OpenVMS                                     |
| File: [.ssh2]BOB_ON_KAWC09     (private half)     | File:                                             | 
|       [.ssh2]BOB_ON_KAWC09.pub (public  half)     |       [.ssh2]BOB_ON_KAWC09.pub (public  half)     |
|       [.ssh2]identification.   (src control file) |       [.ssh2]authorization.    (dst control file) |
| # title: identification. | # title: authorization. |
| # notes: file of private keys | # notes: file of public keys |
| idkey BOB_ON_KAWC09 | key BOB_ON_KAWC09.pub | | # idkey NEXT PRIVATE KEY GOES HERE | # key NEXT PUBLIC KEY GOES HERE | +---------------------------------------------------+---------------------------------------------------+
================================================================================
Step-05
test the ssh2 connection (should no longer require a password)
================================================================================
<sr>	KAWC09::BOB>						! user's prompt
<ur>	ssh ALICE@kawc15.on.bell.ca				! connect to ALICE
<sr>	*** WARNING ***
	
	    THE  PROGRAMS  AND  DATA STORED ON THIS SYSTEM ARE LICENSED TO OR ARE
	    PRIVATE  PROPERTY  OF THIS COMPANY AND ARE LAWFULLY AVAILABLE ONLY TO
	    AUTHORIZED  USERS  FOR  APPROVED PURPOSES. UNAUTHORIZED ACCESS TO ANY
	    PROGRAM OR DATA ON THIS SYSTEM IS NOT PERMITTED, AND ANY UNAUTHORIZED
	    ACCESS  BEYOND THIS POINT MAY LEAD TO PROSECUTION. THIS SYSTEM MAY BE
	    MONITORED  AT ANY TIME FOR OPERATIONAL REASONS, THEREFORE, IF YOU ARE
	    NOT AN AUTHORIZED USER, DO NOT ATTEMPT TO LOGIN.
    
	Authentication successful.				! <--- success message

	    Last interactive login on Tuesday, 19-AUG-2008 11:40:17.32
	    Last non-interactive login on Tuesday, 19-AUG-2008 10:58:35.45
    
	-i-in script: CSMIS$USER3:[ADMCSM.ALICE]LOGIN.COM;15 	! <--- from script
	-i-on node  : KAWC15                                    ! <--- from script
	-i-exiting  : login.com                                 ! <--- from script
	KAWC15::ALICE>                                       	! <--- yippee
Caveat: If you were prompted to enter a password then you will need to do more debugging.
            This done by invoking $ssh with the /verbose switch (which defaults to /debug=2 )
            Try using /debug=4 or higher for more details.
            I use /debug=6 to locate configuration typos and other handshake errors.
================================================================================
Optional Step-06
Only necessary if you wish to allow connections in the reverse direction
================================================================================
repeat steps-01 through 04 above but in the reverse direction (alice to bob)
================================================================================

step-06a - create a pair of keys			for ALICE on KAWC15
step-06b - create/update file "[.ssh2]identification."	for ALICE on KAWC15
step-06c - copy ALICE's public key			to  BOB on KAWC09
step-06d - create/update file "[.ssh2]authorization."	for BOB on KAWC09

================================================================================
Optional Step-07 (for BOB on KAWC09)
create/update file: "[.ssh2]SSH2_CONFIG."
note: 1) unless specified from the command-line, these parameters will be used
      2) the second stanza is only necessary if someone tries to connect to
         kawc15 without using the full DNS name.  
================================================================================
kawc15.on.bell.ca:
        batchmode       Y
        user    ALICE
        allowedAuthentications  publickey
kawc15:
        batchmode       Y
        allowedAuthentications  publickey
        user    ALICE
        host    kawc15.on.bell.ca
        
================================================================================
Optional Step-08 (for ALICE on KAWC15)
create/update file: "[.ssh2]SSH2_CONFIG."
note: 1) unless specified from the command-line, these parameters will be used
      2) the second stanza is only necessary if someone tries to connect to
         kawc09 without using the full DNS name.  
================================================================================
kawc09.on.bell.ca:
        batchmode       Y
        user    BOB
        allowedAuthentications  publickey
kawc09:
        batchmode       Y
        allowedAuthentications  publickey
        user    BOB
        host    kawc09.on.bell.ca

One SFTP Account Didn't Survive a Stack Upgrade

I recently upgraded one system from TCPware 5.8-2 to TCPware 5.9-2 and one production SFTP account of several, refused to work (kept prompting for a password). Since my BOB and Alice accounts still worked, I initiated some verbose SSH connections between them then compared these with a verbose connection from BOB to the broken account. One of the error messages complained about file and directory access protections so I decided to compare the two accounts.

Good account "BOB" looked like this:
$ dir/prot/width=file=35

Directory CSMIS$ROOT3:[USR.ADMCSM.BOB.SSH2]

authorization.;2                     (RWD,RWD,,)
HOSTKEYS.DIR;1                       (RWD,RWD,,)
identification.;4                    (RWD,RWD,,)
RANDOM_SEED.;1                       (RWD,RWD,,)
SSH2_CONFIG.TEMPLATE;1               (RWD,RWD,,)
ALICE_ON_KAWC15.pub;1                (RWD,RWD,,)
BOB_ON_KAWC09.;1                     (RWD,RWD,,)
BOB_ON_KAWC09.pub;1                  (RWD,RWD,,) 
While the broken account looked like this:
$ dir/prot/width=file=35

Directory CSMIS$ROOT4:[CSMIS_ICT_FTP.DATA.SSH2]

AAA_HELP.TXT;1                       (RWED,RWED,RWED,RWE) <<<--- much too liberal
authorization.;5                     (RWED,RWED,RWED,RWE)
BL1CS9.pub;1                         (RWED,RWED,RWED,RWE)
D6BCMS.pub;2                         (RWED,RWED,RWED,RWE)
D7PCRW.pub;1                         (RWED,RWED,RWED,RWE)
DEMC5S.pub;1                         (RWED,RWED,RWED,RWE)
HOSTKEYS.DIR;1                       (RWED,RWED,RWED,RWE)
ict_ftp_ON_KAWC09.;1                 (RWED,RWED,RWED,RWE)
ict_ftp_ON_KAWC09.pub;1              (RWED,RWED,RWED,RWE)
identification.;4                    (RWED,RWED,RWED,RWE)
neil_ON_KAWC15.pub;1                 (RWED,RWED,RWED,RWE)
RANDOM_SEED.;1                       (RWED,RWED,RWED,RWE)
The Repairs
  1. To fix my problem, all the broken files were set to the same file protection settings as BOB.
    $set file *.*/protect=(s:rwd,o:rwd,g,w)/log
  2. The protection of this SSH2 directory (in it's parent) must also be set like so:
    $ dir/prot [-]ssh2.dir
    
    Directory CSMIS$ROOT3:[USR.ADMCSM.BOB]
    
    SSH2.DIR;1           (RWD,RWD,,)
    
    Total of 1 file.
Alternatively
  1. One alternative is to modify this file:
        SYS$SYSROOT:[TCPWARE.SSH2]SSHD2_CONFIG.
    changing line this line:
        StrictModes yes
    to this:
        StrictModes no
    but this would reduce security for all ssh2 connections on this platform. It makes more sense to set the file protections to less liberal.
  2. On the flip side, you could create a special config file in you transfer account:
        $edit [.ssh2]ssh2_conf.
    adding line:
        StrictModes no

Related Links

Configuring SSH2 for "Key Authentication" ( TCPIP Services for OpenVMS )

Step-0 (quick short cut)

As a short cut, we can create the necessary files and folders simply by connecting to the remote system like so:
legend:
	<ur>	= user response
	<sr>	= system response

===================================================================================================
Step-00 (only necessary on a new account)
Use SSH to interactively connect to another account (which will create necessary folders and files)
===================================================================================================
-----------------------------------------------------------------------------------
	connect to ALICE to create the necessary files and folders in Bob's account
-----------------------------------------------------------------------------------
<sr>	KAWC09::BOB>					! Bob's DCL prompt
<ur>	$ ssh ALICE@kawc98.on.bell.ca
<sr> bla...bla...bla... (connection verbage)
alice's password: <ur> ######## ! enter Alice's password <sr> bla...bla...bla... (login verbage) KAWC98::ALICE> ! Alice's DCL prompt ---------------------------------------------------------------------------------- connect back to BOB to create the necessary folders in Alice's account ---------------------------------------------------------------------------------- <ur> $ ssh BOB@kawc09.on.bell.ca <sr> <sr> bla...bla...bla... (connection verbage)
bob's password: <ur> ######## ! enter Bob's password <sr> bla...bla...bla... (login verbage) KAWC98::BOB> ! Alice's DCL prompt --------------------------------------------------------- <sr> KAWC09::BOB> ! Bob's DCL prompt <ur> log ! logout <sr> KAWC98::ALICE> ! Alice's DCL prompt <ur> log ! logout <sr> KAWC09::BOB> ! back where we started

Steps 1-4

legend:
	<ur>	= user response
	<sr>	= system response

================================================================================
Step-01
Interactively log into the local system as BOB then create a new key-pair
(surprisingly, you may only enter UNIX-style cli switches with this stack)
================================================================================
<sr>	-i-in script: CSMIS$USER3:[ADMCSM.BOB]LOGIN.COM;15	! from login script
	-i-on node  : KAWC09					! from login script
	-i-exiting  : login.com					! from login script
	KAWC09::BOB>						! user's DCL prompt
<ur>	ssh_keygen "-P" -t dsa ssh2/BOB_ON_KAWC09		! type this command
<sr>	Generating 2048-bit dsa key pair
	   2 oOo.oOo.oOo
	Key generated.
	2048-bit dsa, bob@kawc09.on.bell.ca, Mon Oct 27 2014 12:53:01
	Private key saved to ssh2/bob_on_kawc09			! private key stays here
	Public key saved to ssh2/bob_on_kawc09.pub		! public key to distribute
	KAWC09::BOB>						! user's DCL prompt

================================================================================
Step-02
Create file "[.ssh2]identification." (tells the client which keys are available)
Notes: 1. only use $CREATE if the file doesn't yet exist (otherwise use $EDIT)
       2. otherwise, add the line desired line to the existing file
       3. only add entries for private keys located in this directory (some of
          these public keys may have been copied here from other systems)
================================================================================
<sr>	KAWC09::BOB>
<ur>	cre [.ssh2]identification.	! notice "no file extension"
	idkey BOB_ON_KAWC09		! entry for a private key file
	<ctrl-z>			! hit the ctrl-z key
<sr>	KAWC09::BOB>			! user's DCL prompt

================================================================================
Step-03
Copy desired public key(s) to the destination account on remote system
Notes: 1. use $scp (secure copy) or $sftp (secure FTP)
       2. you will need a password for the remote account
       3. if you don't have access to it, then mail this key-file to
          someone at the remote system who can install it for you
       4. if you've read any books on spying or cryptography, this is the step
          where the ambassador delivers the code keys in a diplomatic pouch.
================================================================================
<sr>	KAWC09::BOB>
<ur>	scp ssh2/BOB_ON_KAWC09.pub - 
ALICE@kawc98.on.bell.ca:ssh2/BOB_ON_KAWC09.PUB ! only one colon <sr> @SYS$MANAGER:SECURITY_WARNING.TXT alice@kawc0f.on.bell.ca's password: <ur> ######### ! enter Alice's password <sr> bob_on_kawc09.pub | 1.2kB | 1.2 kB/s | TOC: 00:00:01 | 100% ! <--- copy success KAWC09::BOB> ! user's DCL prompt ================================================================================ Step-04 set up file "[.ssh2]authorization." on the remote system note: 1) do this in the remote account you wish to use 2) don't use $CREATE if the file already exists (use $EDIT instead) ================================================================================ <sr> KAWC09::BOB> ! user's DCL prompt <ur> ssh ALICE@kawc98.on.bell.ca ! enter this command <sr> @SYS$MANAGER:SECURITY_WARNING.TXT alice's password: ! <ur> ######## ! enter Alice's password Authentication successful. Last interactive login on Monday, 27-OCT-2014 08:55:16.75 Last non-interactive login on Monday, 27-OCT-2014 08:59:23.88 -i-in script: CSMIS$USER3:[ADMCSM.ALICE]LOGIN.COM;98 -i-on node : KAWC98 -i-exiting : login.com KAWC98::ALICE> ! remote user's DCL prompt <ur> cre [.ssh2]authorization. ! notice "no file extension" key BOB_ON_KAWC09.PUB ! entry for a public key file <ctrl-z> ! hist the ctrl-z key <sr> KAWC98::ALICE> ! <ur> log 2 ! log out <sr> ALICE logged out at 27-OCT-2014 09:15:31.60 Connection to kawc0f.on.bell.ca closed. KAWC09::BOB> ! local user's prompt

Step-5 (Test the connection)

================================================================================
Step-05
test the ssh2 connection (should no longer require a password)
================================================================================
<sr>	KAWC09::BOB>						! user's prompt
<ur>	ssh ALICE@kawc98.on.bell.ca				! connect to ALICE
<sr>	*** WARNING ***
	
	    THE  PROGRAMS  AND  DATA STORED ON THIS SYSTEM ARE LICENSED TO OR ARE
	    PRIVATE  PROPERTY  OF THIS COMPANY AND ARE LAWFULLY AVAILABLE ONLY TO
	    AUTHORIZED  USERS  FOR  APPROVED PURPOSES. UNAUTHORIZED ACCESS TO ANY
	    PROGRAM OR DATA ON THIS SYSTEM IS NOT PERMITTED, AND ANY UNAUTHORIZED
	    ACCESS  BEYOND THIS POINT MAY LEAD TO PROSECUTION. THIS SYSTEM MAY BE
	    MONITORED  AT ANY TIME FOR OPERATIONAL REASONS, THEREFORE, IF YOU ARE
	    NOT AN AUTHORIZED USER, DO NOT ATTEMPT TO LOGIN.
    
	Authentication successful.				! <--- success message

	    Last interactive login on Monday, 27-OCT-2014 09:17:03.16
	    Last non-interactive login on Monday, 27-OCT-2014 08:59:23.88
    
	-i-in script: CSMIS$USER3:[ADMCSM.ALICE]LOGIN.COM;15 	! <--- from script
	-i-on node  : KAWC98                                    ! <--- from script
	-i-exiting  : login.com                                 ! <--- from script
	KAWC98::ALICE>                                       	! <--- yippee

recommended optional step-6 (changing file protections)

================================================================================
Step-06
change file protections (many times required dependent upon other settings)
================================================================================
$set file [.ssh2]*.*/protect=(s:rwd,o:rwd,g,w)/log		!

Windows: Setting Up SSH (Secure Shell) For Key Authentication
(bypasses password authentication)

Many Windows users download GUI-based applications capable of doing SFTP. Then they run into problems and are forced to give up. If you want to go further you'll need to hack (install and play) with OpenSSH. The easiest free way to do this is to install Cygwin then run OpenSSH from that environment. If you can't get SSH working over port 22 (perhaps because a firewall or proxy server is blocking port 22) then SFTP will never work. 

SunOS-5.9 (a.k.a. Solaris 9)

Okay so setting up the TCPware flavor of SSH on an OpenVMS platform is pretty straight forward. SSH1 stuff goes into folder [.ssh] whilst SSH2 stuff goes into folder [.ssh2] and most stuff is set up with a text editor.

Connecting from OpenVMS to Solaris-9

I recently (2012-04-xx) ran into some problems setting up SSH2 on an older Solaris 9 box (I don't think this thing had been patched ever since it was installed in 2002). I guess our problems started by making the mistake of trying to translate TCPware concepts over to the the Sun box (creating a folder named .ssh2 then populating it with files like authorization etc.). After a couple of wasted hours I decided to peak at file /etc/ssh/ssh_config then execute man ssh , man ssh_config and man ssh-keygen

Caveat what follows may not be present on your Solaris-9 box so be careful

  1. On this Sun box, both SSH1 and SSH2 functions are handled in one user directory named .ssh and one system directory named /etc/ssh
     
  2. On this Sun box you just can't drop VMS public keys into the UNIX .ssh folder then edit an authorization file. You must use ssh-keygen to convert the public key from SSH2 format to OpenSSH format which is then appended to file authorized_keys like so:
    copy neil_ON_KAWC15_dsa_1024.pub from OpenVMS to UNIX            #
    copy neil_ON_KAWC15_rsa_1024.pub from OpenVMS to UNIX            #
    
    cat authorized_keys                                              # see what is in this file
    cp authorized_keys authorized_keys_backup                        # make a backup (once per session?)
    
    ssh-keygen -X -f neil_ON_KAWC15_dsa_1024.pub                     # convert format from SSH2 to OpenSSH (stdout)
    ssh-keygen -X -f neil_ON_KAWC15_dsa_1024.pub >> authorized_keys  # convert format from SSH2 to OpenSSH (append) 
    
    ssh-keygen -X -f neil_ON_KAWC15_rsa_1024.pub                     # convert format from SSH2 to OpenSSH (stdout)
    ssh-keygen -X -f neil_ON_KAWC15_rsa_1024.pub >> authorized_keys  # convert format from SSH2 to OpenSSH (append) 
    Note: even though the man pages say this will only work with RSA keys, it appears to work with DSA key as well (old documentation?)
     
  3. On this Sun box, RSA worked but DSA did not. If you've got root privs then you can make changes to /etc/ssh/ssh_config and they will take effect as soon as you restart the SSHD daemon. Changes can be made on a per-account basis by creating file $HOME/.ssh/config then adding nouns and verbs like so:
    #
    # extracted from "man ssh_config"
    #
    # The values can be changed in per-user configuration files $HOME/.ssh/config
    # or on the command line of ssh(1).
    #
    # Configuration data is parsed as follows:
    #  1. command line options
    #  2. user-specific file
    #  3. system-wide file /etc/ssh/ssh_config
    #
    # Any configuration value is only changed the first time it is set.
    # host-specific definitions should be at the beginning of the
    # configuration file, and defaults at the end.
    #
    DSAAuthentication yes
    RSAAuthentication yes
    #LogLevel VERBOSE       # only do this to debug problems
    #StrictModes no		# not valid on this OS
    #
    # Example (matches compiled in defaults):
    #
    # Host *
    #   ForwardAgent no
    #   ForwardX11 no
    #   PubkeyAuthentication yes
    #   PasswordAuthentication yes
    #   FallBackToRsh no
    #   UseRsh no
    #   BatchMode no
    #   CheckHostIP yes
    #   StrictHostKeyChecking ask
    #   EscapeChar ~
Caveat: do not enable BatchMode until everything is working properly. Enabling BatchMode will disable PasswordAuthetication
Hacking on Solaris-9

On this Solaris box, the man pages provide different information than found in the various apps

Help App
man ssh ssh -?
man ssh-keygen ssh-keygen -?
man scp scp -?
man sftp sftp -?
   
Connecting from Solaris-9 back to OpenVMS
Pushing files from Solaris-9 to VMS-5.5 (TCPware)
Solaris-9 to VMS-5.5 (TCPware) Transfer Tests
=============================================
scp junk.txt system@142.117.38.240:junk.txt                - works: (but VMS-5.x will upcase the filename)

Here, we want to drop a file into VMS subdirectory sys$login:[.ssh2]
====================================================================
scp junk.txt system@142.117.38.240:./ssh2/junk.txt         - works: (but VMS-5.x will upcase the filename)
scp junk.txt system@142.117.38.240:/[.ssh2]/               - fails: destination file will be no-name format like this ".;1" 
scp junk.txt system@142.117.38.240:/[.ssh2]/junk.txt       - fails: destination file will be no-name format like this ".;1"
scp junk.txt system@142.117.38.240:/[.ssh2]junk.txt        - works: (but VMS-5.x will upcase the filename)
scp junk.txt system@142.117.38.240:/[.ssh2]Junk.txt        - works: (but VMS-5.x will upcase the filename)
scp junk.txt system@142.117.38.240:/[.ssh2]*.*             - fails: no transfer (lost connection)
scp junk.txt system@142.117.38.240:/[.ssh2]                - fails: destination file will be no-name format like this ".;1"
scp junk.txt system@142.117.38.240:[.ssh2]*.*              - fails: no transfer (lost connection)
scp junk.txt system@142.117.38.240:[.ssh2]                 - fails: destination file is $8B.SSH2$8D;1 (not in folder)
scp junk.txt system@142.117.38.240:[.ssh2]junk.txt         - fails: destination file is $8B.SSH2$8DJUNK$5NTXT;1 (not in folder)

Here, we want to drop a file into VMS location disk$spc:[spc]
=============================================================
scp junk.txt system@142.117.38.240:/disk$spc/spc/junk.txt  - fails: does not work (but creates sub folder [.disk] which is empty)
                                                             note: the shell noticed "$" and attempted symbol substitution
scp junk.txt system@142.117.38.240:/disk\$spc/spc/junk.txt - works: (but VMS-5.x will upcase the filename)
                                                             note: "\" is used to escape "$"
scp junk.txt system@142.117.38.240:/spclib/junk.txt        - works: (but VMS-5.x will upcase the filename)
                                                             note: "spclib" is declared as a system-level logical like so:
                                                                   $ def/sys SPCLIB  $1$DIA5:[SPC]
scp junk.txt system@142.117.38.240:/spc\$lib/junk.txt      - works: (but VMS-5.x will upcase the filename)
                                                             note: "spc$lib" is declared as a system-level logical like so:
                                                                   $ def/sys SPC$LIB  $1$DIA5:[SPC]
Apparent Rules:
  1. you must always enter a destination file name
  2. you should always use UNIX notation even when sending to VMS (should not send square brackets; escape "$" with "\")
  3. whenever a path name is involved, you must begin a forward slash (or dot slash for a sub-folder)

Personal Comment: I think SFTP is preferable to SCP. That said, this old version of Solaris seems to have no way to force ASC-TEXT transfers from the command line so the conversion may need to be forced by setting a logical at the receiving end.

Internal Links


Back to OpenVMS
Back to Home
Neil Rieck
Kitchener - Waterloo - Cambridge, Ontario, Canada.