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.

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.