Damien wrote:> Could you redo your traces with "-v -v -v" set? Best send the
report to
> openssh-unix-dev at mindrot.org so it isn't just myself looking at it.
Attached are a number of log files from a problem I'm seeing with
DSA/authorized_keys2 when operating ssh strictly with Protocol
2. Damien has not been able to reproduce it with his RSA setup.
When my server has more than X entries in authorized_keys2, the ssh
connection is rejected, whereas when that pubkey is in the first X,
the connection works fine. All that I am doing in between is
shuffling the order of the pubkeys. On one machine, X=2, on the
machine I did this logging on, X=3.
There's a nice, clear error message in the server's auth.log:
Dec 19 11:10:26 cabrio sshd[23206]: fatal: buffer_get: trying to get
more bytes 128 than in buffer 91
which has to be a useful clue. Files in the attached tarball:
auth.log-cabrio - server /var/log/auth.log
log_auth2cabrio.1stposn - failed ssh login, logged via:
ssh -v -v -v -4 cabrio 2> log_auth2cabrio.1stposn
log_auth2cabrio.4thposn - successful ssh login, same command line,
except for logfilename and ordering of pubkeys in
cabrio:/home/arnim/.ssh/authorized_keys2
ssh_config-fox - client /etc/ssh/ssh_config
sshd_config-cabrio - server /etc/ssh/sshd_config
Note that this example is done between a RedHat client and a Debian
server, but I have seen the same fault with an OBSD 3.0 server and
other clients.
I hope this is sufficient to motivate someone to have a poke at the
buffer_get code... Any other information on the circumstance is
available upon request.
Arnim.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auth2log.tar.gz
Type: application/x-gzip
Size: 3724 bytes
Desc:
Url :
http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20011219/5f763c99/attachment.bin
