All commands in this section are shown using sshg3 and scpg3 from the machine running Tectia Client. 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 on Unix, or in the
%APPDATA%\SSH\UserKeys
and
%APPDATA%\SSH\UserCertificates
directories on Windows.
You can also add other directory locations for keys on the Keys
and Certificates page of the Tectia Connections Configuration GUI. See Managing Keys and Certificates. On
Unix, you can use 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
, on Unix in your
$HOME/.ssh2
directory, or on Windows in your
%APPDATA%\SSH
directory.
Edit it with your favorite text editor to include the following line
(replace id_rsa_2048_a
with the file name of the private key):
IdKey id_rsa_2048_a
The keys are assumed to be in the same directory with the
identification
file, but also an absolute or a relative path can
be given. For example, on Windows:
IdKey UserKeys\id_rsa_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 "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
.
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 id_rsa_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 id_rsa_2048_a.pub ServerUser@tectia4x_server:.ssh2/
Tectia Server for IBM z/OS:
The public key must be converted to the EBCDIC format. This can be done
by including the scpg3
dst-site
command-line option, or the
sftpg3 site commands in the file transfer command. For more
information on the site parameters, see Site Command.
Use SCP to upload your public key to the server (by default to the
$HOME/.ssh2
directory):
$ scpg3 --dst-site="C=ISO8859-1,D=IBM-1047,X=TEXT" id_rsa_2048_a.pub \ ServerUser@tectia_zos:$HOME/.ssh2/
OpenSSH server on Unix:
Use SCP to upload your public key to the server, to your
$HOME/.ssh
directory:
$ scpg3 id_rsa_2048_a.pub ServerUser@open_unix:.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_rsa_2048_a.pub >> \ .ssh2/authorization"
On a Windows server:
$ sshg3 ServerUser@tectia4x_win "cmd /c echo Key id_rsa_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_rsa_2048_a.pub
This directs Tectia Server to use id_rsa_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_rsa_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.