Generating Keys for SSH Tectia

[scottalanmiller]

In some businesses we see OpenSSH replaced with SSHTectia, not a practice that I recommend. Tectia is not free, has far fewer “eyes” checking it, is supported by one small vendor rather than all of the major UNIX vendors and is far more difficult to use and support. But, with caveats out of the way, let’s look at actually using Tectia for key management.

First we generate a key, in our example our user will be “sftpuser” for simplicity:

# /opt/SSHtectia/util/generate_keys sftpuser

This one line will automatically generate our public and private RSA keys. Easy enough. But where did they go? Check the output of the command, it will tell you. Unlike OpenSSH which uses a structure involving the user’s home directory and a hidden .ssh directory within it, Tectia uses a central key repository under /etc/opt/SSHtectia/keys/ with a separate folder for each user under there.

So in this particular example, our keys will have shown up under /etc/opt/SSHtectia/keys/sftpuser/. This system is easier for an administrator to manage but it shifts effort from individual users to the administrator which can be far from ideal. Also inside this folder you will notice that there are authorization and identification files. These files are used to list keys to accept on behalf of this user id and which keys to use to represent this user id respectively.

So if your goal is to share out your public key to other systems simply copy the .pub key file that was just generated here. Likely this will be id_rsa_2048_a.pub but this can vary based on settings. If you need to look it up to be sure, look in the identification file for more information.

If you want to allow other systems to connect to this one using a key then we will need to copy the appropriate public key supplied by those systems into this directory (assuming that they want to log in as sftpuser.) We will assume that they will be logging in from a server named snoopy and that the remote use is named francois and that they aptly named their key snoopy_francois.pub for clarity (had the system actually been charliebrown and the user’s name maggie this would have be extremely confusing to say the least.)

We will need to open the authorization file and add the following like to allow that key, once copied into the local folder, to used for logging in to the sftpuser account:

Key snoopy_francois.pub

And that is all that we need. At this point remote connections to that key should be working. However, we may want to restrict this key to only work from snoopy. To do that we will add an “Optiona” line directly following the “Key” line in our authorization file like so:

Options allow-from="snoopy.peanuts.com"

And we are done. Working with Tectia is less straightforward than working with OpenSSH and far less documented or tested but it is relatively straightforward once you get used to the central folder repository approach. Look in the /etc/opt/SSHtectia/keys/ folder to see what users on your system have had keys generated for them. User accounts having no folders in this location have no keys.

Originally found on my Linux blog at: https://web.archive.org/web/20140823021548/http://www.scottalanmiller.com/linux/2011/08/05/generating-keys-for-ssh-tectia/