SFTP Key Support

(Requires the SFTP module in EFT SMB/Express) EFT supports the following actions for SFTP key support:

  • 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, EFT gets the ultimate say in which encryption cipher will be used out of the list of ciphers offered by the client and supported by EFT. For example, assume EFT 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 EFT scans the client list from left to right and looks for the first matching algorithm on EFT, from left to right. To force strong cipher usage, change EFT-supported algorithms to a list that fits your security needs.

Clients often present a single key file that has one or more public keys 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 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 parse the file further (e.g., parse first one below, if no match, parse second one, etc., until it reaches the end of file).

EFT 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 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 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 EFT's key pair in the client, because doing so would involve sending the client the public and private key, potentially creating a 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 EFT administrator, who in turn should import the client's public key into EFT's trusted list.

SFTP KEX ciphers

EFT supports the following KEX ciphers:

  • diffie-hellman-group-exhange-sha256

  • diffie-hellman-group14-sha1

  • diffie-hellman-group-exchange-sha1

  • diffie-hellman-group1-sha1

Related Topics