Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a windows server using CoreFTPServer and any connections to any SFTP site on it are giving a type 2 (protocol error). This seems to be for any connection made to the server from any user or IP.

Error: Server sent disconnect message
Error: type 2 (protocol error)
Error: "key check failed"
Error: Could not connect to server

Does anyone know why the connections are being blocked?



share|improve this question

We came across the same issue and we could solve it by eliminating all Linefeed-Characters and comments from the public key file on the CoreFTP-Server.

If you generate the key with PuTTY Key Generator, copy the pure key string into a text-file instead of using the "Save public key" button.

share|improve this answer

I ran into this from the client side of a CoreFTP Server and was able to connect by telling the OpenSSH client to not try any key authentication via:

sftp -oPubkeyAuthentication=no user@url
share|improve this answer

You should probably add a little more detail to that question:
Are those error messages reported by the connecting client or in a server log file?
Has the server previously worked correctly or is this a new installation that is failing?
What SFTP client(s) are you using to try access the server?
Are you trying to use key based authentication, password-interactive, or some other form of authentication?

The error "key check failed" could mean that either the client is trying to connect with an invalid key, or that the server is set for key based access only and the client is trying to authenticate using another method (such as "password interactive").

I've never used CoreFTPServer (I used OpenSSH on both Linux and Windows (via cygwin in the case of Windows though there are other ports available too)) but if key based authentication has previously been working and suddenly stopped check the file and directory ownership and permissions for the key files on the server - a common issue people see with OpenSSH is that it will refuse to use keys that are stored in an insecure manner (i.e. in a world writeable directory).

If the client is reporting this error apparently before there has been any attempt to authenticate then it could be reacting to the server's fingerprint not being recognised (i.e. it is a new install or has been changed in some significant way that altered the server's identity). Though I would expect the work "fingerprint" to be used if this was the problem rather than "key", some people get the terms mixed up so the software could be using the wrong term in the error message.

share|improve this answer
It would be useful to know if the system's even up and running. Try "telnet coreftpserver 22" and check you get an SSH banner; if you don't, no amount of key analysis or fingerprinting will help, you don't have a running server. – MadHatter Nov 4 '10 at 16:30

What client are you using for testing ? Anyway I would try doublechecking the problem with PSFTP and WinSCP.

If the error persists you might want to increase logging - there are lots of different key-checks which could've gone wrong.

A common error might include that the Hosts Key has changed. I remember CFTPS doing this daily so you might want to check your %TEMP% Directory for cftpskey.pem and see if it differs from what your clients saved. (Remember SSH doesn't like changing Hostkeys).

If I'm correct you should prevent this problem from happening by setting the cftpskey.pem to read-only. Because the keys seem already out of sync I recommand resetting the Host Cache on client-side.

For putty / psftp you will find them in the System Registry under

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.