Uploading Public Keys from z/OS to Remote Host

All commands in this section are shown using sshg3 and scpg3 from the machine running Tectia client tools for z/OS. Server-side configuration can also be done by logging in to the remote server and entering the commands locally.

To enable public-key authentication with your key pair:

Place your keys in a directory where the Connection Broker can locate them.
By default, the Connection Broker attempts to use each key found in the $HOME/.ssh2 directory.
You can also add other directory locations for keys using the general/key-stores/key-store element in the ssh-broker-config.xml file. See the section called “Key Store Configuration Examples”.
(Optional) Create an identification file.
Using the identification file is not necessary if all your keys are stored in the default directory and you allow all of them to be used for public-key and/or certificate authentication. If the identification file does not exist, the Connection Broker attempts to use each key found in the default directory. If the identification file exists, the keys listed in it are attempted first.
Create a file called identification in your $HOME/.ssh2 directory, for example:
```
$ cd $HOME/.ssh2
$ echo "IdKey id_dsa_2048_a" >> identification
```
You now have an identification file that consists of one line that denotes the file containing your private key:
```
IdKey       id_dsa_2048_a
```
The identification file can contain several key IDs. For more information on the syntax of the identification file, see $HOME/.ssh2/identification.
Connect to Server using some other authentication method and create a .ssh2 (and .ssh2/authorized_keys), or a .ssh directory under your home directory if it does not exist already.
Depending on the server version the remote host is running, run one of the following commands:
- Tectia Server on Unix or z/OS:
```
$ sshg3 ServerUser@tectia_server mkdir .ssh2
```
  If you do not want to use an authorization file on Tectia Server 5.x or later on Unix, create also the authorized_keys directory:
```
$ sshg3 ServerUser@tectia_unix mkdir .ssh2/authorized_keys
```
- Tectia Server on Windows:
```
$ sshg3 ServerUser@tectia_win "cmd /c mkdir .ssh2"
```
  If you do not want to use an authorization file on Tectia Server 5.x or later on Windows, create also the authorized_keys directory:
```
$ sshg3 ServerUser@tectia_win mkdir "cmd /c mkdir .ssh2/authorized_keys"
```
- OpenSSH server on Unix or z/OS:
```
$ sshg3 ServerUser@open_server mkdir .ssh
```
Copy the public key to Server.
Keys created with the ssh-keygen-g3 on z/OS are stored in the EBCDIC format. When the public key is transferred to a Unix or Windows server, it must be converted to the ASCII format. This can be done by specifying the -a option with scpg3.
If public-key authentication is configured between mainframe servers, conversion is not needed.
Depending on the server version the remote host is running, do one of the following actions:
- Tectia Server 5.x or later on Unix and Windows:
  Use SCP to upload your public key to the server, to your authorized_keys directory (by default $HOME/.ssh2/authorized_keys on Unix servers, or %USERPROFILE%\.ssh2\authorized_keys on Windows servers):
```
$ scpg3 -a id_dsa_2048_a.pub ServerUser@tectia_server:.ssh2/authorized_keys/
```
- Tectia Server 4.x on Unix and Windows:
  Use SCP to upload your public key to the server (by default to the $HOME/.ssh2 directory on Unix and to the %USERPROFILE%\.ssh2 directory on Windows servers):
```
$ scpg3 -a id_dsa_2048_a.pub ServerUser@tectia4x_server:.ssh2/
```
- Tectia Server for IBM z/OS:
  Use SCP to upload your public key to the server (by default to the $HOME/.ssh2 directory):
```
$ scpg3 id_dsa_2048_a.pub ServerUser@tectia_zos:˜/.ssh2/
```
- OpenSSH server on Unix:
  Use SCP to upload your public key to the server, to your $HOME/.ssh directory:
```
$ scpg3 -a id_dsa_2048_a.pub ServerUser@open_unix:.ssh/
```
- OpenSSH server on z/OS:
  Use SCP to upload your public key to the server, to your $HOME/.ssh directory:
```
$ scpg3 -a id_dsa_2048_a.pub ServerUser@open_zos:.ssh/
```
Create an authorization or authorized_keys file on Server.
Depending on the server version the remote host is running, do one of the following actions:
- Tectia Server 5.x or later on Unix and Windows do not require an authorization file if the public keys are stored in the user's authorized_keys directory. However, an authorization file may be optionally used. See instructions for creating the file below in the Tectia Server 4.x information.
- Tectia Server 4.x on Unix and Windows and Tectia Server for IBM z/OS require an authorization file stored in the user's .ssh2 directory. The authorization file specifies the public keys that are authorized for login.
  Add the key entry to the authorization file. On a Unix or z/OS server:
```
$ sshg3 ServerUser@tectia_server "echo Key id_dsa_2048_a.pub >> \
.ssh2/authorization"
```
  On a Windows server:
```
$ sshg3 ServerUser@tectia4x_win "cmd /c echo Key id_dsa_2048_a.pub >> \
.ssh2/authorization"
```
  An example authorization file is shown below (by default $HOME/.ssh2/authorization on Unix and z/OS servers, and %USERPROFILE%\.ssh2\authorization on Windows servers):
```
Key     id_dsa_2048_a.pub
```
  This directs Tectia Server to use id_dsa_2048_a.pub as a valid public key when authorizing your login.
- OpenSSH server requires that the public key is converted to the OpenSSH public-key file format and stored in the authorized_keys file in the user's .ssh directory.
  Convert the public key to the OpenSSH public key file format on the server and append it to your $HOME/.ssh/authorized_keys file. This can be done with a remote command on an OpenSSH server as follows:
```
$ sshg3 ServerUser@open_server "ssh-keygen -i -f id_dsa_2048_a.pub >> \
.ssh/authorized_keys"
```
Make sure that public-key authentication is enabled in the ssh-broker-config.xml file (it is enabled by default).
```
<authentication-methods>
  <auth-publickey />
...
</authentication-methods>
```
Other authentication methods can be listed in the configuration file as well. Place the least interactive method first.

Assuming Server is configured to allow public-key authentication to your account, you should now be able to log in from Client to Server using public-key authentication.

Try to log in:

Client$ sshg3 Server

You should be prompted for the passphrase of the private key. After you have entered the passphrase, a Secure Shell connection will be established.