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.
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
- this command used to default to RSA encryption:
$ sshkeygen /ssh2/nopass
- this command used to throw a stack dump unless KEYTYPE is specified:
$ sshkeygen /ssh2/nopass/keys=[.ssh2]yada
- but this command always appeared to work properly:
$ sshkeygen /ssh2/nopass/keys=[.ssh2]yada/keytype=dsa
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.
- this command used to default to RSA encryption:
- 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.
- Generating 1024-bit keys on Alpha or Itanium seem to require no time at all (a few seconds)
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:
- needs to know the OS password associated with the ALICE account
or - 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
- needs to know the OS password associated with the ALICE account
- 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)
- 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
- On VMS-to-VMS connections, case is almost always irrelevant because everything is up-cased behind the scenes.
- On UNIX-to-VMS connections case is also almost irrelevant (at the VMS end) because everything is up-cased behind the
scenes.
- 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.
- On VMS-to-VMS connections, case is almost always irrelevant because everything is up-cased behind the scenes.
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.
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.
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
- $mu config/server
- enable ssh (misleading since nothing will be enabled until you set parameters)
- select ssh
- set parameter
- enable-ssh2
- enable-ssh1 (this step is optional but not recommended)
- save
- restart (will not knock down existing network connections)
- 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
- attempt an ssh connection from another system using verbose (or triple verbose)
- 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)
- depending upon which files are missing
- caveats/notes:
- 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 1debug[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 ~
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
Links
- Internal to this site:
- External
- https://en.wikipedia.org/wiki/Secure_Shell
- http://www.snailbook.com/faq/ssh-1-vs-2.auto.html - What's the difference between versions 1 and 2 of the SSH protocol?
Back to HomeNeil Rieck
Waterloo, Ontario, Canada. /div>