Core FTP

I have created a public and private key (no password) and am trying to connect without the use of a password. Is this possible? I only want those that have the private key to be able to connect to the server, which of course has the public key.

I have tried to enter no password at all (on the server and client), but that doesn't allow a connection.

I have also tried enabling Allow key authentication under Domain properties, but then I cannot connect at all, even if I supply the correct password.

I am using the Core FTP client to connect.

In the site profile in Core FTP, Advanced -> General -> Don't prompt for user id....

Thanks for the reply. On the client I've tried checking don't prompt for id if blank (I also removed the username) as you suggested, but while it do longer prompts for the credentials it gives an error stating Login/password/privatekey error.

Since there is now no username specified for the site I'm guessing that the matching of the keys dumps the user into the correct directory. Unfortunately, I cannot get that far. If I again specify the username and a password I can connect fine - I see that the keys match as well. Removing the password starts the credentials prompting again. Removing the username gives that error that I described above. I do have Allow key authentication enabled on the server side.

My apologies, I should have indicated, (client site) Advanced -> General -> Don't prompt for password when empty....

Like you mentioned, the userid is required in order to identify which key to use on the server side.

Okay, I went back and tried that again and I can connect without using a password - the password field on both the server and the client are left blank.

However I noticed that although I have specified a public key in the user profile on the server I can connect even though the private key is not indicated on the client. From my understanding this should deny access. On the server I have tried enabling the options for Allow key authentication and Key authentication only, but they do not seem to have any impact. The user profile does not have the User does not require key authentication option unchecked. So essentially access to the directory is wide open.

I think I must be missing how to enforce the use of the private key (by the client) in order to connect on the server.

I also noticed that when I specify the private key in the client I get a prompted for credentials. When I remove the key I can log in without being challenged. The public key is loaded into the user profile on the server.

If the "Key authentication only" was selected, and the server user had a public key, but no private key was specified by the client, it would not login (in tests I ran here). The server needs to be restarted when selecting this option, which may have been why you could still log in.

It does appear that if the user has no password, and key authentication is selected but *not* required, Core FTP Server should check the public key, and/or notify the operator that a public key is highly recommended or essentially anonymous access could result upon guess of the user-id.

Either way this does require a fix, which will be in build 413 and greater.

This fix only applies to Core FTP Server setups that don't have the "key authentication only" option selected in the domain setup, and want to use key authentication as a method of login verification, with a blank password for the user.


Additional FYI:

You can setup Core FTP Server to have key authentication be required ("key authentication only" option), but make exceptions for a user(s) by checking the "user does not require key authentication" in their security settings. This essentially allows user authentication without having it required for all users, and does not require an upgrade to build 413 for users wishing to setup users with key authentication and blank passwords.

Using the method that you described under Additional FYI worked perfectly. Everything is up and running as expected now for users with and without key authentication.

Also, not restarting the service during testing was really tripping me up, thanks for that suggestion.

Thank you for you help.