RE: dispatch_protocol_error - openssh

This is a discussion on RE: dispatch_protocol_error - openssh ; Quoting Spydr : > okay - let me provide link as a reference after I explain - type 5 is ssh1 > response to authentication attempt with a shared secret (SSH_AUTH_TIS) seq 5 > means something is wrong with the ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: RE: dispatch_protocol_error

  1. RE: dispatch_protocol_error

    Quoting Spydr :

    > okay - let me provide link as a reference after I explain - type 5 is ssh1
    > response to authentication attempt with a shared secret (SSH_AUTH_TIS) seq 5
    > means something is wrong with the user string
    >
    > http://mia.ece.uic.edu/cgi-bin/lxr/h...=openssh-3.5p1
    >
    >
    > review the SSH1.h for additional types and seq responses. Typically, this is
    > a result of a miss configuration on the client. Looks like from the logs
    > provide remote host got the public key for your machine, opened the session
    > to authenticate the user but the user string didn't match an authorized
    > account
    >
    >
    >
    > -----Original Message-----
    > From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com] On
    > Behalf Of Dewey Hylton
    > Sent: Thursday, July 24, 2008 2:44 PM
    > To: secureshell@securityfocus.com
    > Subject: dispatch_protocol_error
    >
    > i'm getting the following error in syslog:
    >
    > Jul 24 11:40:22 possible-rogue-laptop sshd[19041]: Accepted publickey for
    > dewey from 127.0.0.1 port 40876 ssh2 Jul 24 11:40:22 possible-rogue-laptop
    > sshd[19044]: (pam_unix) session opened for user dewey by (uid=0) Jul 24
    > 11:40:22 possible-rogue-laptop sshd[19044]: dispatch_protocol_error: type
    > 5 seq 5
    >
    >
    > this happens on different target hosts running freebsd/openbsd/linux and
    > differing openssh versions; the sequence number is dynamic, but the type is
    > not.
    >
    > ssh key-based logins from openssh client via ssh-agent works fine. the
    > problem is only evident when attempting the same from paramiko (python ssh
    > client).
    >
    > while the problem may be with how i'm controlling the python client, i don't
    > know where to look or what to try because i haven't yet found what
    > "dispatch_protocol_error: type 5" means.
    >
    > can someone shed some light on this?


    excellent pointer, thanks for the lead. i'll start working in that direction.
    the interesting thing is that i *thought* the server config had ssh1 disabled.


  2. RE: dispatch_protocol_error

    Quoting Dewey Hylton :

    > Quoting Spydr :
    >
    > > okay - let me provide link as a reference after I explain - type 5 is ssh1
    > > response to authentication attempt with a shared secret (SSH_AUTH_TIS) seq

    > 5
    > > means something is wrong with the user string
    > >
    > > http://mia.ece.uic.edu/cgi-bin/lxr/h...=openssh-3.5p1
    > >
    > >
    > > review the SSH1.h for additional types and seq responses. Typically, this

    > is
    > > a result of a miss configuration on the client. Looks like from the logs
    > > provide remote host got the public key for your machine, opened the

    > session
    > > to authenticate the user but the user string didn't match an authorized
    > > account
    > >
    > >
    > >
    > > -----Original Message-----
    > > From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]

    > On
    > > Behalf Of Dewey Hylton
    > > Sent: Thursday, July 24, 2008 2:44 PM
    > > To: secureshell@securityfocus.com
    > > Subject: dispatch_protocol_error
    > >
    > > i'm getting the following error in syslog:
    > >
    > > Jul 24 11:40:22 possible-rogue-laptop sshd[19041]: Accepted publickey for
    > > dewey from 127.0.0.1 port 40876 ssh2 Jul 24 11:40:22 possible-rogue-laptop
    > > sshd[19044]: (pam_unix) session opened for user dewey by (uid=0) Jul 24
    > > 11:40:22 possible-rogue-laptop sshd[19044]: dispatch_protocol_error: type
    > > 5 seq 5
    > >
    > >
    > > this happens on different target hosts running freebsd/openbsd/linux and
    > > differing openssh versions; the sequence number is dynamic, but the type

    > is
    > > not.
    > >
    > > ssh key-based logins from openssh client via ssh-agent works fine. the
    > > problem is only evident when attempting the same from paramiko (python ssh
    > > client).
    > >
    > > while the problem may be with how i'm controlling the python client, i

    > don't
    > > know where to look or what to try because i haven't yet found what
    > > "dispatch_protocol_error: type 5" means.
    > >
    > > can someone shed some light on this?

    >
    > excellent pointer, thanks for the lead. i'll start working in that
    > direction.
    > the interesting thing is that i *thought* the server config had ssh1
    > disabled.


    i was right; ssh1 is disabled across all my hosts.

    another interesting point:
    the "seq" output appears to alternate between "type 5 seq 5" and "type 5 seq 13"
    .... i'm largely unfamiliar with C, so i still haven't tracked down exactly what
    that means and what causes it.


  3. RE: dispatch_protocol_error

    Quoting Dewey Hylton :

    > Quoting Dewey Hylton :
    >
    > > Quoting Spydr :
    > >
    > > > okay - let me provide link as a reference after I explain - type 5 is

    > ssh1
    > > > response to authentication attempt with a shared secret (SSH_AUTH_TIS)

    > seq
    > > 5
    > > > means something is wrong with the user string
    > > >
    > > > http://mia.ece.uic.edu/cgi-bin/lxr/h...=openssh-3.5p1
    > > >
    > > >
    > > > review the SSH1.h for additional types and seq responses. Typically,

    > this
    > > is
    > > > a result of a miss configuration on the client. Looks like from the logs
    > > > provide remote host got the public key for your machine, opened the

    > > session
    > > > to authenticate the user but the user string didn't match an authorized
    > > > account
    > > >
    > > >
    > > >
    > > > -----Original Message-----
    > > > From: listbounce@securityfocus.com [mailto:listbounce@securityfocus.com]

    > > On
    > > > Behalf Of Dewey Hylton
    > > > Sent: Thursday, July 24, 2008 2:44 PM
    > > > To: secureshell@securityfocus.com
    > > > Subject: dispatch_protocol_error
    > > >
    > > > i'm getting the following error in syslog:
    > > >
    > > > Jul 24 11:40:22 possible-rogue-laptop sshd[19041]: Accepted publickey

    > for
    > > > dewey from 127.0.0.1 port 40876 ssh2 Jul 24 11:40:22

    > possible-rogue-laptop
    > > > sshd[19044]: (pam_unix) session opened for user dewey by (uid=0) Jul 24
    > > > 11:40:22 possible-rogue-laptop sshd[19044]: dispatch_protocol_error:

    > type
    > > > 5 seq 5
    > > >
    > > >
    > > > this happens on different target hosts running freebsd/openbsd/linux and
    > > > differing openssh versions; the sequence number is dynamic, but the type

    > > is
    > > > not.
    > > >
    > > > ssh key-based logins from openssh client via ssh-agent works fine. the
    > > > problem is only evident when attempting the same from paramiko (python

    > ssh
    > > > client).
    > > >
    > > > while the problem may be with how i'm controlling the python client, i

    > > don't
    > > > know where to look or what to try because i haven't yet found what
    > > > "dispatch_protocol_error: type 5" means.
    > > >
    > > > can someone shed some light on this?

    > >
    > > excellent pointer, thanks for the lead. i'll start working in that
    > > direction.
    > > the interesting thing is that i *thought* the server config had ssh1
    > > disabled.

    >
    > i was right; ssh1 is disabled across all my hosts.
    >
    > another interesting point:
    > the "seq" output appears to alternate between "type 5 seq 5" and "type 5 seq
    > 13"
    > ... i'm largely unfamiliar with C, so i still haven't tracked down exactly
    > what
    > that means and what causes it.


    i found the culprit (it was my fault of course) and am sending this out for
    documentation purposes just in case some other poor soul ends up in my shoes.

    basically, i was looping through the keys available through my agent. the
    problem occurred when i successfully authenticated - and then tried the next
    agent key instead of exiting the loop. once a break was inserted at the correct
    point in the loop, everything seemed to work just fine.


+ Reply to Thread