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: 2012-05-20 (updated after problems connecting to VMS from Solaris-9)

Menu

SSH and SSH2

Modes

  1. In default out-of-the-box mode, these technologies encrypt your connection to conceal everything, including your initial login password.
  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)
  3. If you like, you can encode a password in your private key (this will foil and evil sys op on your system) but this is not allowed when setting up Secure Shell for automated (batch) transfers.  

OpenVMS: Setting Up SSH2 (Secure Shell) for "Key Authentication"
(legally bypassing SYSUAF-based "Password Authentication")
for the TCPware stack.

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 program or 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 cryptology are Bob and Alice so I created accounts SSH_BOB and SSH_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 Screen Captures

================================================================================
Step-01
Interactively log into the local system as SSH_BOB then create a new key-pair
================================================================================
-i-in script: CSMIS$USER3:[ADMCSM.SSH_BOB]LOGIN.COM;15     ! from login script
-i-on node  : KAWC09                                       ! from login script
-i-exiting  : login.com                                    ! from login script
KAWC09::SSH_BOB>                                           ! user's DCL prompt

KAWC09::SSH_BOB> sshkeygen /ssh2/keys=[.ssh2]SSH_BOB_on_kawc09/nopass/keytype=dsa ! enter this command
Generating 1024-bit dsa key pair
   1 oOo.oOo.oOo
Key generated.
1024-bit dsa, SSH_BOB@kawc09.on.bell.ca, Tue Aug 19 2008 10:37:30
Private key saved to [.SSH2]ssh_bob_on_kawc09              ! private key stays here
Public key saved to [.SSH2]ssh_bob_on_kawc09.pub           ! public key to distribute

KAWC09::SSH_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 (use $EDIT instead)
       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)
================================================================================
KAWC09::SSH_BOB> cre [.ssh2]identification.                ! this file has no extension
idkey SSH_BOB_on_kawc09                                    ! entry for a private key file
<--- hit <ctrl-z> here                                     ! save the file
KAWC09::SSH_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 $ftp (because $copy only works with DECnet)
       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.
================================================================================
KAWC09::SSH_BOB> scp [.ssh2]ssh_bob_on_kawc09.pub - 
  "SSH_ALICE@kawc15.on.bell.ca::[.ssh2]ssh_bob_on_kawc09.pub" 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)? yes Host key saved to CSMIS$USER3:[ADMCSM.SSH_BOB.SSH2.HOSTKEYS]key_22_kawc15_on_bell_ca.pub host key for kawc15.on.bell.ca, accepted by SSH_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. SSH_ALICE@kawc15.on.bell.ca's password: ######### ssh_bob_on_kawc09.pub | 751B | 751B/s | TOC: 00:00:01 | 100% <--- copy success KAWC09::SSH_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) ================================================================================ KAWC09::SSH_BOB> ! user's DCL prompt KAWC09::SSH_BOB> ssh SSH_ALICE@kawc15.on.bell.ca ! enter this command *** 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. SSH_ALICE's password: ######### 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.SSH_ALICE]LOGIN.COM;15 -i-on node : KAWC15 -i-exiting : login.com KAWC15::SSH_ALICE> ! remote user's DCL prompt KAWC15::SSH_ALICE> cre [.ssh2]authorization. ! this file has no extension key ssh_bob_on_kawc09.pub ! entry for a public key file <--- hit <ctrl-z> here ! save the file KAWC15::SSH_ALICE> log ! log out SSH_ALICE logged out at 19-AUG-2008 11:40:49.01 Connection to kawc15.on.bell.ca closed. KAWC09::SSH_BOB> ! local user's prompt

When you are finished your directories and files should look similar to this:
 
SSH_BOB (on node: KAWC09) Files:
[.ssh2] file names: file contents: notes:
identification.

#
# title: identification.
#
idkey ssh_bob_on_kawc09
idkey entry2
idkey entry3
1) this file name has no file extension
2) this file contains a list of private keys to offer



offer this private key when we connect elsewhere
(or this one)
(or this one)
authorization.

#
# title: authorization.
#
key entry1.pub
key entry2.pub
key entry3.pub
1) this file name has no file extension
2) file contains a list of public keys to accept



accept this public key when someone connects here
(or this one)
(or this one)
ssh_bob_on_kawc09.

private key data
1) this file has no file extension
2) this file was created here
3) it is picked up by the stack after reading "identification."
ssh_bob_on_kawc09.pub public key data 1) this file has a .pub file extension
2) this file was created here but is copied elsewhere

SSH_ALICE (on node: KAWC15) Files:
[.ssh2] file names: file contents: notes:
identification.

#
# title: identification.
#
idkey entry1
idkey entry2
idkey entry3
1) this file name has no file extension
2) this file contains a list of private keys



offer this private key when we connect elsewhere
(or this one)
(or this one)
authorization.

#
# title: authorization.
#
key ssh_bob_on_kawc09.pub
key entry2.pub
key entry3.pub
1) this file name has no file extension
2) this file contains a list of public keys



accept this public key when someone connects here
(or this one)
(or this one)
ssh_bob_on_kawc09.pub public key data 1) this file was copied here from (SSH_BOB on KAWC09)
2) it is picked up by the stack after reading "authorization."
================================================================================
Step-05
test the ssh2 connection (should no longer require a password)
================================================================================
KAWC09::SSH_BOB>                                         ! user's prompt
KAWC09::SSH_BOB> ssh SSH_ALICE@kawc15.on.bell.ca         ! connect to SSH_ALICE

*** 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.SSH_ALICE]LOGIN.COM;15 ! <--- from script
-i-on node  : KAWC15                                     ! <--- from script
-i-exiting  : login.com                                  ! <--- from script
KAWC15::SSH_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-061 - create a pair of keys                       for SSH_ALICE on KAWC15
step-062 - create/update file "[.ssh2]identification." for SSH_ALICE on KAWC15
step-063 - copy SSH_ALICE's public key                 to  SSH_BOB on KAWC09
step-064 - create/update file "[.ssh2]authorization."  for SSH_BOB on KAWC09

When you are finished your directories and files should look similar to this:
SSH_ALICE (on node: KAWC15) Files:
[.ssh2] file names: file contents: notes:
identification.

#
# title: identification.
#
idkey ssh_alice_on_kawc15
idkey entry2
idkey entry3
1) this file has no file extension
2) this file contains a list of private keys



offer this private key when we connect elsewhere
(or this one)
(or this one)
authorization.

#
# title: authorization.
#
key ssh_bob_on_kawc09.pub
key entry2.pub
key entry3.pub
1) this file has no file extension
2) this file contains a list of public keys



accept this public key when someone connects here
(or this one)
(or this one)
ssh_alice_on_kawc15.

private key data
1) this file has no file extension
2) this file was created here
3) it is picked up by the stack after reading "identification."
ssh_alice_on_kawc15.pub public key data 1) this file has a .pub file extension
2) this file was created here but is copied elsewhere
ssh_bob_on_kawc09.pub public key data 1) this file was copied here from (SSH_BOB on KAWC09)
2) it is picked up by the stack after reading "authorization."

SSH_BOB (on node: KAWC09) Files:
[.ssh2] file names: file contents: notes:
identification.

#
# title: identification.
#
idkey ssh_bob_on_kawc09
idkey entry2
idkey entry3
1) this file has no file extension
2) this file contains a list of private keys



offer this private key when we connect elsewhere
(or this one)
(or this one)
authorization.

#
# title: authorization.
#
key
ssh_alice_on_kawc15.pub
key entry2.pub
key entry3.pub
1) this file has no file extension
2) file contains a list of public keys



accept this public key when someone connects here
(or this one)
(or this one)
ssh_bob_on_kawc09. private key data 1) this file has no file extension
2) this file was created here
3) it is picked up by the stack after reading "identification."
ssh_bob_on_kawc09.pub public key data 1) this file has a .pub file extension
2) this file was created here but is copied elsewhere
ssh_alice_on_kawc15.pub public key data 1) this file was copied here from (SSH_ALICE on KAWC15)
2) it is picked up by the stack after reading "authorization."
 
================================================================================
Optional Step-07 (for SSH_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    SSH_ALICE
        allowedAuthentications  publickey
kawc15:
        batchmode       Y
        allowedAuthentications  publickey
        user    SSH_ALICE
        host    kawc15.on.bell.ca
        
================================================================================
Optional Step-08 (for SSH_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    SSH_BOB
        allowedAuthentications  publickey
kawc09:
        batchmode       Y
        allowedAuthentications  publickey
        user    SSH_BOB
        host    kawc09.on.bell.ca

One SFTP Account Didn't Survive the Upgrade

I recently upgraded my 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 "SSL_BOB" looked like this:
$ dir/prot/width=file=35

Directory CSMIS$ROOT3:[USR.ADMCSM.SSH_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,,)
ssh_alice_on_kawc15.pub;1            (RWD,RWD,,)
ssh_bob_on_kawc09.;1                 (RWD,RWD,,)
ssh_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 SSH_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.SSH_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 (OpenVMS)

Related Links (Common)

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.