›

Failed to create a new ssh channel

ajohnson
edited November 2015 in Acrosync for Windows
I'm running into this error quite frequently (uploading Windows -> FreeNAS). "Failed to create a new ssh channel"
Usually running the sync again (sometimes it takes 2 or 3 tries) works, but it gets to be an annoyance. Do you have any suggestions on debugging this?

Comments

  • ajohnson
    edited November 2015
    I know this is a a bit hacky, but would you consider providing a test build of acrosync for me that puts a for loop around 237-240 here and retries libssh2_channel_open_session() 3 or 4 times?

    Something like below. 
    int ii = 0;
    while (++ii <= 4) {
    d_channel = libssh2_channel_open_session(d_session);
    if(d_channel) break;
    }
    if (!d_channel) {
    LOG_FATAL(SSH_CREATE) << "Failed to create a new ssh channel after " << ii << " tries" << LOG_END
    }


    I know it's a bit hacky but I'm curious if this will resolve things. There's nothing particularly exotic about my ssh server (It's FreeNAS, which runs openssh's sshd). If for example there is some crappy interaction between libssh2/acrosync on the client end and certain versions of openssh on the server, and all it takes to make these kinds of connections more reliable is a for loop on the client end, I'd rather see that than have to hack up ssh on all of my servers or do some kind of deep debugging session with sshd to figure out what's going on here.

    That said if you have some other suggestion instead, I'm all ears!
  • gchen
    If you install the new 1.5 version from here:


    and change the registry value HKCU\Software\Acrosync\AcrosyncClient\UseLibssh from 0 to 1,  Acrosync will use the libssh library rather than libssh2 after restart (a log message will say 'the libssh dll has been loaded').

    I don't know why libssh2_channel_open_session could fail, but maybe libssh does not have this issue.

  • ajohnson
    edited November 2015
    The 64 bit build crashes on launch for me. 32-bit doesn't, so I switched to that for now. Let me know how i can help you with the crash.
    This switch to 32-bit necessitated that I export my Acrosync profiles and reimport them with 32-bit regedit so they're under the Wow6432Node (or whatever it's called) in the registry. I really hate the registry for commandline tools, because you can never feel 100% confident about the input state to the program being what you expect (unless you dump all the settings to stdout at startup or something).
    The json import/export can't come soon enough. Please make sure json supports all settings, including things like UseLibssh. If I still have to set one or two things in the registry to have a working setup, that would somewhat defeat the purpose.

    Once I finished switching to the 32-bit build and enabled UseLibssh and ran acrosync, it's clearly using it:
    INFO 11/17/15 18:57:13 ACROSYNC_SERVICE The libssh dll has been loaded

    But I get an authentication error. I'm using public key authentication. If I switch back to UseLibssh = 0 and run acrosync again it connects fine, so it appears public key auth might be broken with libssh.
    I had to switch to password authentication for now, which does work, but is not preferred.

    Thanks!

    Summary:
    64-bit crashes, 32-bit runs.
    Public key auth seems broken with libssh.
    Please add commandline to pass in json soon and include all settings :)
  • ajohnson
    edited November 2015
    I was able to resolve the crashes with 1.5_527 by uninstalling acrosync and completely deleting all the Acrosync related registry keys then recreating my profiles in the GUI. Naturally this fed my hatred of the registry even more.

    Unfortunately, the original issue still happens with libssh.

    I ran sshd -dd on the server, and based on the ouput it would appear that server is timing out the client. Here's the tail of the log:
    debug2: channel 0: request keepalive@openssh.com confirm 1
    debug2: tcpwinsz: 65700 for connection: 4
    debug2: tcpwinsz: 65700 for connection: 4
    debug2: channel 0: request keepalive@openssh.com confirm 1
    debug2: tcpwinsz: 65700 for connection: 4
    debug2: tcpwinsz: 65700 for connection: 4
    Timeout, client not responding.
    debug1: do_cleanup
    debug1: do_cleanup
    debug1: PAM: cleanup
    debug1: PAM: closing session
    debug1: PAM: deleting credentials
    [exit]
    It gets timed out while acrosync is building the index, which can take a good bit of time if there are a lot of files. Maybe acrosync should send some packets periodically to keep the connection alive while it's building the index?

    In the meantime, I think I've fixed this on the server side by tweaking the ClientAliveCountMax and ClientAliveInterval settings. I'm now back using libssh2 and it's working so far.
  • ajohnson
    Long thread here, so just to be clear -
    It'd be ideal if acrosync did whatever necessary to keepalive the connection while it's building the index. ssh server idle timeouts may vary from server to server, and not everyone will have the permission or knowledge to tweak timeout values on the server.
  • gchen
    Thank you for tracking down the issue.  Yes, I need to add keep alive messages during the indexing of the local directory.
  • gchen
    Also, I tested libssh with public key authentication.  Both RSA and DSA keys worked fine.  Don't know why it failed in your test.
Sign In or Register to comment.