ssh client and default files

[Ángel Gutiérrez Rodríguez]

We have an issue when connecting to an ssh server:

ssh ro...@192.168.3.5
ro...@192.168.3.5's password:
dispatch_protocol_error: type 100 seq 9
buffer_get_ret: trying to get more bytes 4 than in buffer 0
buffer_get_int: buffer error

that gets solved with the client's option:

ForwardAgent no

I've tried to put that in /etc/ssh/ssh_config and in .ssh/config but

ssh ro...@192.168.3.5

gives the same error. Nonetheless, I am able to make it work with

ssh ro...@192.168.3.5 -F .ssh/config

I can see both files are read:

ssh -v ro...@192.168.3.5
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /root/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
....

Files are:
cat /root/.ssh/config
Host *
StrictHostKeyChecking no
ForwardAgent no

and

cat /etc/ssh/ssh_config
Host *
GSSAPIAuthentication yes
ForwardX11Trusted yes
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY
LC_MESSAGES
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
SendEnv LC_IDENTIFICATION LC_ALL
ForwardAgent no

Am I missing something?

Thanks in advance...

--
ÁGR

[Simon Tatham]

� ngel Gutiérrez Rodríguez <ange...@terra.es> wrote:
> dispatch_protocol_error: type 100 seq 9
> buffer_get_ret: trying to get more bytes 4 than in buffer 0
> buffer_get_int: buffer error
>
> that gets solved with the client's option:
>
> ForwardAgent no

'Type 100' might well refer to the SSH-2 protocol message that has
type code 100, which is SSH2_MSG_CHANNEL_FAILURE. That message might
well be generated in response to an attempt by the client to enable
agent forwarding; and that message should indeed contain four bytes
(the id of the channel on which a request failed) and it would be
erroneous for it to contain zero bytes instead (the client wouldn't be
able to tell which channel it referred to, in cases where more than
one was active).

So it looks to me as if this is a bug in your particular SSH server,
causing it to format SSH2_MSG_CHANNEL_FAILURE messages incorrectly by
failing to include the channel id. You don't mention what server
software you're using (though adding '-v' to your ssh command line
would at least show the version string it sent at startup), but
whatever it is, you should report this as a bug in that server
software.

The 'good' news is that if the server was _trying_ to send
SSH2_MSG_CHANNEL_FAILURE in response to your agent forwarding request,
that means it doesn't support agent forwarding anyway, so this bug
isn't preventing you from accessing functionality you would otherwise
have had.

> I've tried to put that in /etc/ssh/ssh_config and in .ssh/config but
> ssh ro...@192.168.3.5
> gives the same error. Nonetheless, I am able to make it work with
> ssh ro...@192.168.3.5 -F .ssh/config

[...]

You could try adding 'ForwardX11Trusted no' in your ~/.ssh/ssh_config
file. The 'ForwardX11Trusted yes' in /etc/ssh/ssh_config might be the
problem: a request for X forwarding also has the form of an SSH-2
channel request, so it might provoke the same server bug as
ForwardAgent.
--
Simon Tatham These are my opinions. There are many
<ana...@pobox.com> like them but these ones are mine.

[Ángel Gutiérrez Rodríguez]

Simon Tatham wrote:

> You could try adding 'ForwardX11Trusted no' in your ~/.ssh/ssh_config
> file. The 'ForwardX11Trusted yes' in /etc/ssh/ssh_config might be the
> problem: a request for X forwarding also has the form of an SSH-2
> channel request, so it might provoke the same server bug as
> ForwardAgent.

I'll try that tomorrow. As you say, my problem is buggy SSH server (in an HP
iLO card) that didn't have problem with older versions of ssh client but
when we updated our system to Scientific Linux 5 the problem appeared.

We have seen two solutions to our problem: the one i told in teh first post
and just unset the LANG enviroment variable (another one would be to update
the server firmware, of course).

What puzzled me was the behaviour of ssh; I would expect

ssh x@y

and

ssh x@y -F ~/.ssh/config

to give the same result.
--
ÁGR

[Ron]

Op 10-11-11 wk 45 01:21, Ángel Gutiérrez Rodríguez schreef:

> We have an issue when connecting to an ssh server:
>
> ssh ro...@192.168.3.5
> ro...@192.168.3.5's password:
> dispatch_protocol_error: type 100 seq 9
> buffer_get_ret: trying to get more bytes 4 than in buffer 0
> buffer_get_int: buffer error
>

Ever wanted to execute commands or scripts on 10,20, 30 or more servers
at the same time (within seconds) try DatacenterManager.
Also does automatic inventory of unix servers and trend analysis!

http://java-apps.org/content/show.php/DatacenterManager?content=144298

Amazing tool install under 5 secs and runs everywhere (Java)!