EFT Server SFTP Key Support

The EFT Server supports the following for SFTP keys:

Importing multiple keys stored in a single key file
Authentication of multiple keys stored in a single key file
Association of one or more keys to a user account
Assignment of the same key (or keys) to more than one user account.

Below is an illustration of a basic SFTP transport and SFTP Public Key authentication sequence.

During the client-server handshake, the server gets the ultimate say in which encryption cipher will be used out of the list of ciphers offered by the client and supported by the server. For example, assume the server has the following algorithm list:

aes256-cbc,twofish256-cbc,twofish-cbc,aes128-cbc,twofish128-cbc,cast128-cbc

And assume the client sends the following list:

blowfish-cbc,aes128-cbc,twofish128-cbc,cast128-cbc,3des-cbc,arcfour

Then the matching cipher will be aes128-cbc, because the server scans the client list from left to right and looks for the first matching algorithm on the server-side, from left to right. To force strong cipher usage, change the server-supported algorithms to a list that fits your security needs.

Clients often present a single key file that has one or more public keys (a message encrypted with a recipient's public key cannot be decrypted by anyone except the recipient possessing the corresponding private key. See Private Key) in it. Some servers read in the first key and ignore any other keys available in the file, which presents a problem if the public key associated with that user’s account is found further down in the public key file presented by the connecting user. It also presents a problem when the administrator attempts to import a bunch of keys all located in a single key file.

EFT Server evaluates where the delimiters are for each key and parses each key until no more keys are found. In the case of client authentication, once a match is made, there is no need to further parse the file (e.g., parse first one below, if no match, parse second one, etc., until it reaches the end of file).

EFT Server maps the selected key (name) to the key assigned to that user, so that when an authentication attempt occurs, it is compared to each mapped key, rather than just a single key. EFT Server does not hide already selected keys for different users. That is, if you assign keya.pub to user jsmith, you can then go and assign that same keya.pub to bjones as well.

When EFT Server imports a key file, each imported key is given the same name as chosen by the administrator upon importing the key. Same name keys are distinguished by their fingerprint and are displayed in the key manager. You can rename keys in the Key Manager.

All user account names mapped to a particular key are displayed in the Assigned column in the Key Manager. Multiple user->key assignments are displayed in comma-delimited format in the Assigned column in ascending alpha order. By default, when first importing the key, there are no assigned users; assignment occurs in the user account's Security tab. You can assign the same key to multiple users, multiple keys to the same user, and multiple keys to multiple users. If any key in the provided key file matches one of the keys mapped to a user who is attempting to authenticate, the user is authenticated and no further parsing of the key file is done.

Below is a sample .pub file containing multiple keys:

-----BEGIN RSA PUBLIC KEY-----

mcazCANrC+BCYIywA0I3TVmrv2FTMWo7bpB9rgJx7xGeAZ22JV4IMEI4eCkMor/B

9ADRUDsYDOKA3yZav3Q4yvG8Z3T+hhqJ2hBob+bj8M4e08C3VwmVRz4j4Y+DnvJo

HcKvvmRcd2GvWRN3Q3OQ+QePfaQnUkDxnEWd+mrX1kwGv96GPqmrFREjm0eT966B

qhPtyRa/gNkyoOnXV4/wsXPQb78UnfrFiM0N2CV7v7yj9koaod7p5CCx4ciw4

A5iEWdmInGcGHEgkP/LBuzOfwoXJWGCwttx0AP0FvZL3iplPmGnfKA==

-----END RSA PUBLIC KEY-----

-----BEGIN RSA PUBLIC KEY-----

mRwnVp5OR7FkLOpXEtxE/JBTvhaLDLFGKPHWxS8c4LYIiPHs/Z5arkCsfZbtZNUD

iPbj6QzjjNpAp1HvP0749+CTNTqFLnFAEj9d5YFxXLNWVjz8NwWwNSGH2hvuDOxR

WsixMQg7esHepAvuiwFRyehmhS7wadpdoXxz3dMIFLovxdrhZKSGCOJIUZk5bIjk

OtHn0RQwe8TXYPe3zJvK6s1ank6hPlyhLsqFhn7KueU75ABPV3U2SlboJUPy6DV+

Qk4/B1vcbn4s/Q8Wk1RGZJ5jrGvjT6GcSaQH7y7e4KLzLXlkiSuVFJAqr1nFYa9m

-----END RSA PUBLIC KEY-----

SSH Keys - Security Best Practices

You should not use the Server's key pair in the client, because doing so would involve sending the client the public and private key, creating a potential security vulnerability. It is also an atypical way of setting up public key authentication for one or more clients. The common practice is to create the key pair in each client and then make the client’s public key available to the Server administrator, who in turn should import the client's public key into the Server's trusted list.