Can't connect to any remote SSH/SFTP servers

You need to click 'next' to bring up the additional fields 'Link type' and 'Server'. You need to choose the right type of server. In my case I was using a rapsberry pi and the server was LINUX (Debian).

It took me about 30 tries to get the right, BVRDE crashed about 10 times but onces you get the right combination remember to take a screenshot to remember it.

Situation is even worse -- even the latest cryptlib 3441 does not support aes*-ctr ciphers, so the IDE with built-in ssh/sftp won't work with any recent linux distro that is shipped with openssh built wihtout openssl because such sshd won't offer any ciphers other than aes*-ctr and some thing called chacha. I discovered this problem by debugging the IDE -- the following lines is where this error is obtained from criptolib:
CHAR szError[200] = { 0 };
int ccbSize = sizeof(szError) - 1;
clib.cryptGetAttributeString(cryptSession, CRYPT_ATTRIBUTE_ERRORMESSAGE, szError, &ccbSize);
then it is even distributed among subscribers using m_pCallback->BroadcastLine(VT100_RED, ...) call, but seems there are no subscribers. So what you get is generic error based on some sort of cryptlib errorcode to win32 errorcode translation.

Are there any plans to switch to libssh2 which seems to support ssh communication much better?

openssh sources:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/cipher.c?rev=1.112&content-type=text/x-cvsweb-markup
see how ciphers are defined:

static const struct sshcipher ciphers[] = {

#ifdef WITH_OPENSSL
    { "3des-cbc",       8, 24, 0, 0, CFLAG_CBC, EVP_des_ede3_cbc },
    { "aes128-cbc",     16, 16, 0, 0, CFLAG_CBC, EVP_aes_128_cbc },
    { "aes192-cbc",     16, 24, 0, 0, CFLAG_CBC, EVP_aes_192_cbc },
    { "aes256-cbc",     16, 32, 0, 0, CFLAG_CBC, EVP_aes_256_cbc },
    { "rijndael-cbc@lysator.liu.se",
                16, 32, 0, 0, CFLAG_CBC, EVP_aes_256_cbc },
    { "aes128-ctr",     16, 16, 0, 0, 0, EVP_aes_128_ctr },
    { "aes192-ctr",     16, 24, 0, 0, 0, EVP_aes_192_ctr },
    { "aes256-ctr",     16, 32, 0, 0, 0, EVP_aes_256_ctr },
    { "aes128-gcm@openssh.com",
                16, 16, 12, 16, 0, EVP_aes_128_gcm },
    { "aes256-gcm@openssh.com",
                16, 32, 12, 16, 0, EVP_aes_256_gcm },
#else
    { "aes128-ctr",     16, 16, 0, 0, CFLAG_AESCTR, NULL },
    { "aes192-ctr",     16, 24, 0, 0, CFLAG_AESCTR, NULL },
    { "aes256-ctr",     16, 32, 0, 0, CFLAG_AESCTR, NULL },
#endif
    { "chacha20-poly1305@openssh.com",
                8, 64, 0, 16, CFLAG_CHACHAPOLY, NULL },
    { "none",       8, 0, 0, 0, CFLAG_NONE, NULL },

    { NULL,         0, 0, 0, 0, 0, NULL }
};

so if it's compiled without WITH_OPENSSL, the only ciphers are aes*-ctr

The following discussion sounds like CTR and openssh's own implementation of GCM will be the only block ciphers available in FIPS 140-2 compliant openssh based systems
https://www.linuxquestions.org/questions/linux-security-4/what-steps-do-i-take-to-make-my-openssh-server-fips-140-2-compliant-4175619523/

Hi,

Thanks for the info.
It looks like Cryptlib authors are aware of the aes-ctr being problematic, but I am not sure what the status really is for its support. In the Cryptlib ssh2_cry.c source file I found the following comment:

/* Some versions of SSH want to use AES-CTR instead of AES-CBC, which is a 
   pain to deal with because it's not a standard encryption mode for
   cryptlib (or much of anything else).  To deal with this we synthesise it
   from ECB mode */

If I understand correct, the initial problem described in the top of this thread has been resolved, and your problem is related only to linux versions that have a stripped sshd. Or do you have popular LINUX distribution that exhibit this problem?

Maybe it is time to investigate how much work it is to transition to libssh or openssh libraries in BVRDE.

regards
bjarke

bjarke,

It is CentOS 7.6 running the latest opensshd. It's possible that the configuration is altered to disable the other cyphers, or it's just binary compiled without WITH_OPENSSL option.

As of Cryptlib - I contacted author and sent him patch that makes AES-CTR available for SSH connections. With versions up to 3.4.4.1 it's not available.
Author replied that he is aware of that problem and already got his own fix. It's unclearthough whether and when he's going to publish it.

Hello
In my clone of DVRDE 1.4 (see also https://sourceforge.net/p/bvrde/discussion/373758/thread/121f949328/), I've changed the SSH engine from cryptlib to libssh, and it supports the latest ciphers also, so no SSH connectivity issues. Let me know if you are interested.

@Balazs Szekely, Sir, would you mind sharing your version/Clone of BVRDE 1.4 with me please ? As I have indicated in the issue I have raised recently, I am having trouble connecting to my Ubuntu (WSL) from Windows 10 through sftp/ssh. Can you pls help ?
Thank You.

Try with this version shared at https://drive.google.com/drive/folders/1wg6NccWwl2_TDpCzJiNYZ9X_LZL3wj1Z?usp=sharing