OpenVMS Notes: Configuring SSH2 for SFTP, SCP, etc.

The information presented here is intended for educational use by qualified OpenVMS technologists.
The information presented here is provided free of charge, as-is, with no warranty of any kind.

Introduction to SSH / SSH2 (caveat: nothing to do with SSL)
Configuring SSH for "Key Authentication" ( TCPware )
- OpenVMS Keystroke Examples
- example assumptions
- caveats
- Demo commands and responses
  - step 01 - Bob creates a public-private pair of keys
  - step 02 - Bob creates a control-file named "identification."
  - step 03 - Bob copies his public key to Alice
  - step 04 - Alice creates a control-file named "authorization."
  - directories - how things look so far
  - step 05 - test the connection "Bob to Alice"
  - step 06 - optional steps to allow "Alice to connect to Bob"
  - step 07 - optional steps for batch (non-interactive) use by Bob
  - step 08 - optional steps for batch (non-interactive) use by Alice
- One SFTP account broke after a Stack Upgrade
  - Coles Notes summary: file protections were "too liberal"
Configuring SSH for "Key Authentication" ( TCPIP Services for OpenVMS )
- demo commands and responses
  - step 0 : first-time initial shortcut
  - steps 1-4 : creating the files
  - step 5 : test the connection
  - step 6 : changing file protections
Configuring SSH for "Key Authentication" ( MultiNet )
- One human-caused problem with SFTP
Windows - Setting up SSH2
SunOS-5.9 (a.k.a. Solaris 9)
- OpenVMS to Solaris-9
- Hacking with Solaris-9
- Solaris-9 to OpenVMS
- Sending Files from Solaris-9 to VMS-5.5-2 (running TCPware-5.9-2)
CentOS-7.5 (and higher)
Links

Edit: 2021-11-05 (fixed some grammar)

SSH and SSH2

SSH (colloquially known as SSH-1)
- is the original Secure SHell technology developed in 1995
- it is only based upon RSA Keys
- has been exploited due to some known weaknesses
- update: in 2019 you will usually find SSH disabled. You should only enable it to interface with older systems unable to upgrade to SSH2
SSH-2 is a subsequent technology developed in 2006.
- it can use either DSA or RSA keys
- update: in 2019 you will usually find DSA disabled. It is better to use RSA with a larger key
SSH-1.99 is the name of the IETF certified server technology to support both SSH-1 and SSH-2
- developed after SSH-2.1

Modes

In default out-of-the-box mode, these technologies encrypt your ssh-based connection to conceal everything including the connect password. Most interactive users (using an ssh client but not a telnet) will not need to go beyond this mode.
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 associated with the account in the remote OS). This is a prerequisite for doing autonomous non-interactive (batch) transfers from programs like SFTP. Initially the far-end administrator will provide you with a 24-hour temporary account and password which will only be used to setup the SFTP account.
If you like, you can encode a pass-phrase in your private key (this will foil an evil system admin on your client platform) but this is not allowed when setting up Secure Shell for use with autonomous non-interactive (batch) transfers.

Related Utilities

Programs like SFTP-SFTP2 (secure FTP), SCP-SCP2 (secure copy), and RSYNC on UNIX/Linux systems all rely upon SSH/SSH2 which means that this underlying technology must first be working properly
- If you can't make a Secure Shell connection (by typing: ssh user@server.domain.tld ) then nothing else will work.
- I just (2015-08-20) learned that missing one or two additional steps during SSH setup can still prevent SFTP from working. Click here to learn more
A few more details:
- when you open an SFTP connection, a special FTP client on your end first creates an SSH tunnel on port 22 (includes various authentication schemes)
- once the tunnel is set up, it is used to issue commands to a special FTP server program at the remote end

Configuring SSH for "Key Authentication" ( TCPware )

SFTP is based upon SSH so you had better get SSH (or SSH2) working properly before you attempt your first SFTP transfer.

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. So you must use a public-private key.

The easiest way to setup the target account is to first log into it (do not do it from an admin account like root or system).

Caveat: If you disregard this suggestion
then attempt to create these files with a privileged account,
then make a single typo while doing so,
certain utilities (like SSHKEYGEN) will attach newly created keys to YOUR PRIV account rather than target account you are attempting to modify.
In many instances, the far-end account manager will not have these skills so you will need to do all this yourself. The far-end account manager will usually create an account with a 24-hour password then you will be responsible for logging into the remote account to get this stuff working in the allotted time.
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 older systems still use it.
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.
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 was notified
Update (2011-09-15): PSC fixed most problems fixed with ECO kit SSH_V592P030 but SSHKEYGEN still defaults to RSA
Update (2012-04-xx): SSHKEYGEN in ECO kit SSH_V592P040 defaults to DSA so now everything is right with the world
1. this command used to default to RSA encryption:
  
  $ sshkeygen /ssh2/nopass
2. this command used to throw a stack dump unless KEYTYPE is specified:
  
  $ sshkeygen /ssh2/nopass/keys=[.ssh2]yada
3. but this command always appeared to work properly:
  
  $ sshkeygen /ssh2/nopass/keys=[.ssh2]yada/keytype=dsa
So from this point on, these notes will always specify the KEYTYPE whether required 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 some time while troubleshooting. 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.

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

SSH Key Size:
- Generating 1024-bit keys on Alpha or Itanium seem to require no time at all (a few seconds)
- It doesn't matter if you are on "a real VAX" or an emulation like "Charon-VAX on a fast Xeon-Class x86-64 server", generating keys larger than 512-bits seem to take a ridiculous amount of time (many minutes)
  Caveat: When on VAX (a 32-bit technology), if your destination server requires public keys larger than 512 try 768 before you jump to 1024.

Keystroke Examples (TCPware on OpenVMS)

Example Assumptions:

this procedure is for the TCPware stack
user BOB is on node kawc09.on.bell.ca and his DCL prompt is KAWC09::BOB>
user ALICE is on node kawc15.on.bell.ca and her DCL prompt is KAWC15::ALICE>
user BOB wants to autonomously log onto account ALICE using only SSH Key Authentication because there is no way to hand-off passwords to SSH or SFTP or SCP from within a script.
BOB will generate a pair of SSH2 keys. Even though he only needs the private-half, he will keep both halves in his local account but will need to copy the public-half into the destination account of ALICE. This means that he either:
1. needs to know the OS password associated with the ALICE account
  or
2. needs to find another way to get the public-half of the key to ALICE (sneaker net; email, whatever)
  
  This it the place in cinema/film where the embassy courier delivers "the codes" via a diplomatic pouch
Once the key halves are in place, a password will not be required to connect. Why? The public-private key pair are now considered "the password". This relationship can be ended by either party deleting one of the key-halves. (or deleting the associated line-entry in file identification. on the source side or in file authorization. on the destination side)
the majority of testing below is done with SSH (secure shell)
after you get SSH working you'll discover that SFTP and SFTP2 and SCP and SCP2 will now work auto-magically

Block Diagram #1 (to enable a connection from BOB to ALICE)

This is how everything will look when we are done
+---------------------------------------------------+---------------------------------------------------+
| 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 private-key-file-2             |              key public-key-file-2                |
|              idkey private-key-file-3             |              key public-key-file-3                | 
|	       # idkey NEXT PRIVATE KEY GOES HERE   |		   # key NEXT PUBLIC KEY GOES HERE      |
+---------------------------------------------------+---------------------------------------------------+
Notes:
1) Only one key-pair is required to encrypt the connection in both directions
   (assuming we are not referring to "digital signing" which involves two key-pairs)
2) When BOB connects to Alice, BOB only uses private keys and Alice only uses public keys
3) Therefore, the public key file on BOB's side is not used by BOB. But it needs to be copied to Alice.
   (do not delete it; you may need to resend it, or you may wish to reuse it elsewhere)

Caveats:

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.
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 (at the VMS end) 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
------------------------------------------------------------------------
<ur>	set file/prot=[S:rwd,O:rwd,G,W] [.SSH2]*.*			! restrict permissions
<sr>	KAWC09::BOB>							! DO THIS EVERY STEP
<ur>    set file/prot=[S:rwed,O:rwed,G,W] SSH2.dir			!
<sr>	KAWC09::BOB>							!

================================================================================
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
	idkey second-entry-goes-here	! optional
	<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
	key second-entry-goes-here				!
	<ctrl-z>						! hit 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 private-key-file-2             |		   key public-key-file-2		|
|              idkey private-key-file-3             |		   key public-key-file-3		| 
|	       # 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 is done by invoking ssh client with the /verbose switch (which defaults to /debug=2 )
             Try using /debug=4 or higher for more details.
             I sometimes 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

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
```

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

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.

On the flip side, you could create a special config file in you transfer account:
    $edit [.ssh2]ssh2_conf.
adding line:
    StrictModes no

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

this demo assumes server file TCPIP$SSH_DEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG.; has already been configured on the target system
this demo assumes user BOB on node KAWC09 wants to send files to ALICE on node KAWC98 without being authenticated by SYSUAF (after this initial procedure)
there are no files in this account other than the DCL script "login.com"
first log into account BOB.

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		!

Configuring SSH for "Key Authentication" ( MultiNet )

As you might expect, SSH setup on MultiNet is almost identical to TCPware so I won't add anything else to this section unless I stumble on something noteworthy

so go back to the TCPware section to learn how to setup the directories and files
Caveat:
- In most stacks everything is turned on by default and this is probably a bad idea
- In MultiNet everything is turned off by default (hooray)
- If you intend to enable ssh2 then you must create file "sshd2_config." from "sshd2_config.template"
  - if you are really serious about security (spy agencies, financial institutions, etc.), the host sys-admin will be setting up all accounts by requesting public key files be mailed in advance. In this case your config file must contain something like this: "RequiredAuthentications publickey"
  - for the rest of us, the initial connect will be done by a client connecting with a password who is then responsible for storing the public keys. In this case your config file must contain something similar to this: "AllowedAuthentications publickey,password" (you can set this rule for all users -OR- attach the rule to a specific user)
- If you intend to enable ssh1 then you must create file "sshd_config." from "sshd_config.template" but most people systems do not enable ssh1
- First you must create host keys like so:
  - caveat: consider creating keys larger than 1024 bits
  - sshkeygen /ssh2 /host
  - sshkeygen /ssh1 /host (optional)
- Each user on this system must also create user keys like so
  - caveat: consider creating keys larger than 1024 bits
  - sshkeygen /ssh2
  - sshkeygen /ssh1 (optional)
- I suggest you read the docs (especially for files like "sshd2_conf.") but the following instructions should get you over the hump:
  - set default multinet
  - copy sshd2_config.template [.ssh2]sshd2_config.;
  - edit [.ssh2]sshd2_config.;
    enable these lines:
         VerboseLogging yes
         Ciphers AnyStdCipher
         RequireReverseMapping yes    (only do this when DNS is enabled and working)
         Allow users neil, steve, dave   (only do this if the server is connected to the public internet)
         AllowSHosts *\.domain\.ext    (only do this if the server is connected to the public internet)
         PermitRootLogin no
- If SSH still does not work then
  - attempt an ssh connection from another system using verbose (or triple verbose)
    - perhaps something is still not enabled
    - perhaps the client and server could not agree on common cypher
- If SFTP still does not work then
  - inspect file "[.ssh2]sshd2_config." (the SFTP definition is near the bottom in the applications section; it must be present and enabled)

One human-caused problem with SSH-SFTP

It seems that I am always being interrupted at work, and that happened during the initial SSH configuration of MultiNet on my new Itanium (rx2800-i2)
A day later I got back to MultiNet and began playing with SSH2 which appeared to work both inbound as well as outbound. However, while outbound SFTP connections worked properly, inbound SFTP sessions (which require that SSH and SSH2 be properly configured) did not.

The client always failed with this partial message

Disconnected; protocol error (Protocol error: packet too long:

So I dropped the message, as-is, into a Google search only to discover that lots of people had seen this error message over the years with various stacks on almost all operating systems but no one had posted a satisfactory fix which is why I am documenting it now.
I won't tell you about all the things I did to debug this problem except to say that most things failed
- forcing the receiving SFTP client to create a log file failed (did not create a file; more on this in a moment)
- connecting via SFTP from another system with debug=6 did help somewhat
- enabling verbose login (both SSH and SSH2) pointed me in the correct direction

Solution

This problem is caused when either SSH or SSH2 are enabled in the SSH SERVER but the corresponding server config templates are not copied into the production SSH2 folder
- caveats/notes:
  - depending upon which files are missing
    - you might see the problem with SFTP but not SFTP2
    - you might see the problem with SFTP2 but not SFTP
    - you might see the problem with both
  - I have verified this failure mode with two other stacks which makes me think this problem exists in all stacks on all machines (although the exact error text may change)
  - the number following with error message is usually meaningless because SFTP was never initialized (which is why the packet was too long; nothing to receive it)
  - this is probably a security feature more than a bug
    - installation scripts on older stacks enable-then-copy these files for you. While this makes the purchaser happy it also introduces a potential security hole the sysadmin may not be aware of until it is too late
    - installation scripts on newer stacks appear to not enable-then-copy these files (which I think is the desired way to go in this security-conscious world)
check out the following screen scrape:

legend:	<ur>	user response
	<sr>	system response
----------------------------------------------------------------------------------
	This Alpha is running TCPIP Services
	====================================
	(just making a client connection)
	---
<sr>	KAWC09::Neil>
<ur>	sftp2 kawc0u.on.bell.ca
<sr>
	Welcome to HP OpenVMS Industry Standard 64 Operating System, Version V8.4    
	neil@kawc0u.on.bell.ca's password:
<ur>	BlaBlaBla
<sr> 
	Disconnected; protocol error (Protocol error: packet too long: 314820071.).

	Warning: child process (/sys$system/tcpip$ssh_ssh2) exited with code 131.

	%TCPIP-E-SSH_FC_ERROR, error in ssh file transfer operation
	KAWC09::Neil>
----------------------------------------------------------------------------------
	Jump over to the Itanium which is running MultiNet 5.4
	======================================================
	Here I will only copy/rename two template files (on OpenVMS you must
	copy with a semicolon to prevent the OS from defaulting the extension)
	---
<sr>	KAWC09::Neil>
<ur>	set def MULTINET_ROOT:[MULTINET]
<sr>	KAWC09::Neil>
<ur>	dir [...]*.template
<sr>	KAWC09::Neil>
<ur>	copy SSHD_CONFIG.TEMPLATE MULTINET_SPECIFIC_ROOT:[MULTINET.SSH2]SSHD_CONFIG.;
<sr>	KAWC09::Neil>
<ur>	copy SSHD2_CONFIG.TEMPLATE MULTINET_SPECIFIC_ROOT:[MULTINET.SSH2]SSHD2_CONFIG.;
<sr>	KAWC09::Neil>
----------------------------------------------------------------------------------
	Jump back to the Alpha 
	======================
	(repeating the previously broken connect command)
	---
<sr>	KAWC09::Neil>
<ur>	sftp2 kawc0u.on.bell.ca
<sr>
	Welcome to HP OpenVMS Industry Standard 64 Operating System, Version V8.4    
	neil@kawc0u.on.bell.ca's password:
<ur>	BlaBlaBla
<sr>	sftp> 
----------------------------------------------------------------------------------
Additional Notes: 

examining MULTINET_ROOT:[MULTINET.SSH]SSHD.LOG shows the proof

	debug[000000E0]: (16:06:52)Ssh2Common/SSHCOMMON.C;1:730: num_channels now 1
	debug[000000E0]: (16:06:52)Ssh2ChannelSession/SSHCHSERVER.C;2:1292: Allocating pty.
	debug[000000E0]: (16:06:52)Pty-VMS/PTY-VMS.C;2:286: VMS device _FTA19: created and 
	allocated to user neil
	SSHD 0019[000000E0]: WARNING: SSHD2: Subsystem sftp not defined
	%SYSTEM-?-ILLPAGCNT, illegal page count parameter
	  NEIL         job terminated at 20-AUG-2015 16:06:52.52
	  Accounting information:
	  Buffered I/O count:                193      Peak working set size:      14208
	  Direct I/O count:                  219      Peak virtual size:         194704
	  Page faults:                       915      Mounted volumes:                0
	  Charged CPU time:        0 00:00:00.10      Elapsed time:       0 00:00:08.55

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 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.

http://sshwindows.sourceforge.net/ - minimal Cygwin installation with OpenSSH server and client utilities
http://sourceforge.net/projects/sshwindows/ - An installer for a minimal installation of the Cygwin environment suitable for running an OpenSSH server on the Windows platform
http://www.openssh.com/
http://www.openssh.com/windows.html
http://www.cygwin.com/ - POSIX software on top of Windows

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 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 read the online help via the manual pages: man ssh , man ssh_config and man ssh-keygen

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

On this Sun box, both SSH1 and SSH2 functions are handled in one user directory named .ssh and one system directory named /etc/ssh

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_rsa_1024.pub from OpenVMS to UNIX            # copy the public half of rsa

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_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)

On this Sun box, RSA keys worked but DSA keys did not because DSA is being phased out. But if you must use DSA keys and 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 SSH 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 PasswordAuthentication

Hacking on Solaris-9

On this Solaris box, the man pages provide much more information than is 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

if you haven't done so, generate a pair of RSA keys like so (DSA is being phased out):

ssh-keygen -t rsa -b 512 -f vitria77_on_dm4c6h                    # generate a new key pair

Note that the Solaris public key file will be in OpenSSH format and needs to be converted to SSH2 format before sending to OpenVMS

cat              vitria77_on_dm4c6h.pub                           # see OpenSSH formatted file
ssh-keygen -e -f vitria77_on_dm4c6h.pub                           # convert pub key to IETF format (stdout)
ssh-keygen -e -f vitria77_on_dm4c6h.pub > vitria77_on_dm4c6h.ietf # convert pub key to IETF format (file)
ssh-keygen -x -f vitria77_on_dm4c6h.pub                           # just hacking here
ssh-keygen -x -f vitria77_on_dm4c6h.pub > vitria77_on_dm4c6h.ssh2 # convert pub key to SSH2 format (file)
cmp              vitria77_on_dm4c6h.ietf  vitria77_on_dm4c6h.ssh2 # these files are identical

Now copy the ietf public key file to the VMS box

scp vitria77_on_dm4c6h.ietf account@vms-host.bell.ca:vitria77_on_dm4c6h.ietf

Now connect to the remote VMS system,
then move the ietf public key file into folder [.ssh2]
then append the line "key vitria77_on_dm4c6h.ietf" to file authorization. as described above.

Optional: if you still cannot connect from UNIX to OpenVMS without entering a password, then place the following lines into file $HOME/.ssh/config

#
Host *
#Host vms-host.bell.ca
#
        StrictHostKeyChecking no
        PubkeyAuthentication yes
        PasswordAuthentication yes
#
#       this next line does not appear to work (so is disabled)
#
#       IdentityFile2 $HOME/.ssh/vitria77_on_dm4c6h
        IdentityFile2            vitria77_on_dm4c6h
        LogLevel DEBUG
#

If logging is set up properly, then inspect /var/log/authlog with tail

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:

you must always enter a destination file name
you should always use UNIX notation even when sending to VMS (should not send square brackets; escape "$" with "\")
whenever a path name is involved, you must begin a forward slash (or dot slash for a sub-folder)
BTW: this is a forward slash "\" while this is a backslash "/"

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.

CentOS-7.5 and higher

Caveat: why is this here? I have run into instances where I need to connect an SFTP-client on OpenVMS to SFTP-server on CentOS

Time does not stand still for mankind or machine so it should be no surprise that many of the filenames described above have been changed. Your best path forward is to read the man pages (eg. man ssh) of the target system as well as the connecting system. For example:

Linux server side:

the file named "authorization" described above in the OpenVMS section has been renamed "authorized_keys" and is used by both ssh + ssh2 connections when enabled in "/etc/ssh/sshd_config" which is the system-wide server configuration.
it appears that modern SSH implementations have done away with the "key" keyword which points to a pubic key file. You now must append the contents of your public key file into this file
-AND-
you may have some difficulty using public key files generated by other versions of sshkeygen that look like this:
```
---- BEGIN SSH2 PUBLIC KEY ----
Subject: custodian
Comment: "1024-bit rsa, custodian@kawc09.on.bell.ca, Mon Apr 27 2020 1\
5:04:52"
AAAAB3NzaC1yc2EAAAADAQABAAAAgQCCzJ164AeNAjTafmfVeaqAzrP8sbqYnXKSWew/WG
wam+0sLBdWByrCDpZkb4NKOSCI3njJZzsQ7bkAVdaRpRl2CdZ/nuU6VeJ0f9KHAgzDKDDn
TRo1p4o2LdIBnNeNVtCXlDH4EwRB89ZQj9kjLSlCrAmtxoOlSb6jIKq2n7XpPQ==
---- END SSH2 PUBLIC KEY ----
```
Why? File "~/.ssh/authorized_keys" on Linux currently requires that the public key sit on a single line with no superfluous information or control characters like this:
```
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCC..........PQ== optional-comment
```

public key import-export demos

#!/bin/bash
# title   : gen-test-keys.sh
# author  : Neil Rieck
# edit    : 2020-04-30
# platform: CentOS-7.7
# ==========================
#
rm neil_test_key*
#
# create rsa key pair
#   private key defaults to PEM
#   public key defaults to one-liner
ssh-keygen -f neil_test_key1 -t rsa -b 1024 -N ""
#
# create rsa key pair
#   private key is forced to new format with "-o" (valid with OpenSSH 6.5) 
#   public key defaults to one-liner
ssh-keygen -f neil_test_key9 -o     -b 1024 -N ""
#
# convert public key for export to another system
ssh-keygen -e -f neil_test_key1.pub  > neil_test_key_export.pub
#
# convert public key imported from another system
ssh-keygen -i -f neil_test_key_export.pub > neil_test_key_import.pub
#
# compare imported result to original (only comments are different)
diff -s neil_test_key1.pub neil_test_key_import.pub
#
# let's see the mess
ls -la neil_test_key*

Linux client side:
- "identification" described above in the OpenVMS section has been renamed "identity" and is used by ssh + ssh2 connections when enabled in "/etc/ssh/ssh_config" which is the system-wide client configuration (notice the missing 'd')
- it appears that modern implementations have done away with the "idkey" keyword which points to a private key file. You now must append the contents of your private key into the file (strangely, this does not need to be on a single line like the public half just described)

Click here to learn more: Linux Notes: SSH2