ssh server disconnecting after MSG_KEXINIT - SSH

This is a discussion on ssh server disconnecting after MSG_KEXINIT - SSH ; Here's the Wireshark capture file: http://www.frostjedi.com/terra/dev/ssh2 disconnect.pcap As you can see, the server closes the connection after I send my MSG_KEXINIT and I haven't a clue why. All the algorithms the client says it supports are among the ones the ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: ssh server disconnecting after MSG_KEXINIT

  1. ssh server disconnecting after MSG_KEXINIT

    Here's the Wireshark capture file:

    http://www.frostjedi.com/terra/dev/ssh2 disconnect.pcap

    As you can see, the server closes the connection after I send my
    MSG_KEXINIT and I haven't a clue why. All the algorithms the client
    says it supports are among the ones the server says it supports...

    Any ideas?


  2. Re: ssh server disconnecting after MSG_KEXINIT

    yawnmoth wrote:
    > As you can see, the server closes the connection after I send my
    > MSG_KEXINIT and I haven't a clue why. All the algorithms the client
    > says it supports are among the ones the server says it supports...
    >
    > Any ideas?


    Examine the system logs on the server side. There's a good chance
    the server is actually _stating_ in those logs why it closed the
    connection, in which case by far the easiest way to find out why it
    closed the connection is to read what it said!

    Failing that, try running the server in debugging mode, or going
    through the server source code with a debugger. Any of these methods
    is liable to teach you more than staring at the exchanged messages
    and hoping to have an insight :-)
    --
    Simon Tatham "Happiness is having a large, warm, loving,
    caring, close-knit family in another city."

  3. Re: ssh server disconnecting after MSG_KEXINIT

    On Jun 29, 3:19 am, Simon Tatham wrote:
    >
    >
    > Examine the system logs on the server side. There's a good chance
    > the server is actually _stating_ in those logs why it closed the
    > connection, in which case by far the easiest way to find out why it
    > closed the connection is to read what it said!
    >
    > Failing that, try running the server in debugging mode, or going
    > through the server source code with a debugger. Any of these methods
    > is liable to teach you more than staring at the exchanged messages
    > and hoping to have an insight :-)

    The server is shell.sourceforge.net. I don't have access to the logs
    or the ability to run the server in debug mode.

    I can connect to the SSH servers I've set up locally just fine, too
    (using freesshd for Windows). It's just shell.sourceforge.net that
    I'm having problems with...


  4. Re: ssh server disconnecting after MSG_KEXINIT

    yawnmoth wrote:
    > The server is shell.sourceforge.net. I don't have access to the logs
    > or the ability to run the server in debug mode.


    Hmm. In that case, I suppose your only recourse is to try gradual
    modification. Find a client which you know _can_ connect to that
    server, and hack your client to reproduce their KEXINIT exactly.
    (Don't worry about what happens if you end up selecting a crypto
    primitive that you're not prepared to deal with; all you care about
    for the moment is finding out whether the connection is immediately
    dropped.) Then gradually add and remove pieces from the KEXINIT
    until it turns back into the one you were sending yourself, and see
    at what point it starts dropping the connection. That should narrow
    down the problem.
    --
    Simon Tatham "Every person has a thinking part that wonders what
    the part that isn't thinking isn't thinking about."

  5. Re: ssh server disconnecting after MSG_KEXINIT

    On Jun 29, 6:11 pm, Simon Tatham wrote:
    > yawnmoth wrote:
    > > The server is shell.sourceforge.net. I don't have access to the logs
    > > or the ability to run the server in debug mode.

    >
    > Hmm. In that case, I suppose your only recourse is to try gradual
    > modification. Find a client which you know _can_ connect to that
    > server, and hack your client to reproduce their KEXINIT exactly.
    > (Don't worry about what happens if you end up selecting a crypto
    > primitive that you're not prepared to deal with; all you care about
    > for the moment is finding out whether the connection is immediately
    > dropped.) Then gradually add and remove pieces from the KEXINIT
    > until it turns back into the one you were sending yourself, and see
    > at what point it starts dropping the connection. That should narrow
    > down the problem.


    It turns out that the problem was the construction of the binary
    packet. The packet in the above *.pcap file didn't have a length that
    was a multiple of 8, as required per the SSH specs. Some SSH clients
    (and the Wireshark dissectors) don't care, while others (OpenSSH), I
    guess, do.

    Thanks


+ Reply to Thread