thr3ads.net - openssh unix dev - 3.4p1: 'buffer_append_space: alloc 10506240 not supported' [Jul 2002]

If this information is useful, please help other people find it:
Share via:

Thomas Quinot

2002-Jul-01 21:51 UTC

3.4p1: 'buffer_append_space: alloc 10506240 not supported'

I have been trying to install 3.4p1 on a number of machines.
Servers on ia64 Linux, i386 Linux and SPARC Solaris are all working
like charms. On the other hand, I am having trouble at least with
HPUX 11, DEC OSF 5.1 and Unixware: on all those systems, sshd bails
out after authentication with an error in buffer_append_space.

Here is the output of sshd -d on the UnixWare machine
(uname -a: "UnixWare sofia 5 7.1.0 i386 x86at SCO UNIX_SVR5")

debug1: sshd version OpenSSH_3.4p1
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
Generating 768 bit RSA key.
RSA key generation complete.
debug1: Server will not fork when running in debugging mode.
Connection from 10.10.0.172 port 35503
debug1: Client protocol version 2.0; client software version
OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-1.99-OpenSSH_3.4p1
debug1: list_hostkey_types: ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 zlib
debug1: kex: server->client aes128-cbc hmac-md5 zlib
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: dh_gen_key: priv key bits set: 121/256
debug1: bits set: 1614/3191
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: bits set: 1588/3191
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user quinot service ssh-connection method
none
debug1: attempt 0 failures 0
Failed none for quinot from 10.10.0.172 port 35503 ssh2
Failed none for quinot from 10.10.0.172 port 35503 ssh2
debug1: userauth-request for user quinot service ssh-connection method
hostbased
debug1: attempt 1 failures 1
debug1: userauth_hostbased: cuser quinot chost vienna.int.domain.com.
pkalg s
sh-dss slen 55
debug1: temporarily_use_uid: 529/101 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 529/101 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 529/101 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 529/101 (e=0)
debug1: restore_uid
Failed hostbased for quinot from 10.10.0.172 port 35503 ssh2
debug1: userauth-request for user quinot service ssh-connection method
hostbased
debug1: attempt 2 failures 2
debug1: userauth_hostbased: cuser quinot chost vienna.int.domain.com.
pkalg s
sh-rsa slen 143
debug1: temporarily_use_uid: 529/101 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 529/101 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 529/101 (e=0)
debug1: restore_uid
debug1: ssh_rsa_verify: signature correct
Accepted hostbased for quinot from 10.10.0.172 port 35503 ssh2
Accepted hostbased for quinot from 10.10.0.172 port 35503 ssh2
debug1: monitor_child_preauth: quinot has been authenticated by
privileged proce
ss
debug1: newkeys: mode 0
debug1: newkeys: mode 1
debug1: Entering interactive session for SSH2.
debug1: fd 8 setting O_NONBLOCK
debug1: fd 10 setting O_NONBLOCK
debug1: server_init_dispatch_20
buffer_append_space: alloc 10506240 not supported
debug1: Calling cleanup 0x807e3ec(0x0)
debug1: Calling cleanup 0x807e3ec(0x0)

-- 
    Thomas.Quinot at Cuivre.FR.EU.ORG

Tim Rice

2002-Jul-02 00:35 UTC

head link

3.4p1: 'buffer_append_space: alloc 10506240 not supported'

On Mon, 1 Jul 2002, Thomas Quinot wrote:
> I have been trying to install 3.4p1 on a number of machines.
> Servers on ia64 Linux, i386 Linux and SPARC Solaris are all working
> like charms. On the other hand, I am having trouble at least with
> HPUX 11, DEC OSF 5.1 and Unixware: on all those systems, sshd bails
> out after authentication with an error in buffer_append_space.
>
> Here is the output of sshd -d on the UnixWare machine
> (uname -a: "UnixWare sofia 5 7.1.0 i386 x86at SCO UNIX_SVR5")
I can not duplicate this problem on any of my UnixWare boxes.
I have 2.03, 2.13, 7.1.1, & OpenUNIX 8.0.0 running fine here.

These lines in buffer.c are where it's stopping.
 if (buffer->alloc > 0xa00000)
         fatal("buffer_append_space: alloc %u not supported",
             buffer->alloc);
You are asking it to allocate 0xa05000.
Perhaps run truss(1) on sshd to see if that sheds any light on the problem
>
> debug1: sshd version OpenSSH_3.4p1
> debug1: private host key: #0 type 0 RSA1
> debug1: read PEM private key done: type RSA
> debug1: private host key: #1 type 1 RSA
> debug1: Bind to port 2222 on 0.0.0.0.
> Server listening on 0.0.0.0 port 2222.
> Generating 768 bit RSA key.
> RSA key generation complete.
> debug1: Server will not fork when running in debugging mode.
> Connection from 10.10.0.172 port 35503
> debug1: Client protocol version 2.0; client software version
> OpenSSH_3.4p1
> debug1: match: OpenSSH_3.4p1 pat OpenSSH*
> Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-1.99-OpenSSH_3.4p1
> debug1: list_hostkey_types: ssh-rsa
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: client->server aes128-cbc hmac-md5 zlib
> debug1: kex: server->client aes128-cbc hmac-md5 zlib
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
> debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
> debug1: dh_gen_key: priv key bits set: 121/256
> debug1: bits set: 1614/3191
> debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
> debug1: bits set: 1588/3191
> debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
> debug1: kex_derive_keys
> debug1: newkeys: mode 1
> debug1: Enabling compression at level 6.
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: waiting for SSH2_MSG_NEWKEYS
> debug1: newkeys: mode 0
> debug1: SSH2_MSG_NEWKEYS received
> debug1: KEX done
> debug1: userauth-request for user quinot service ssh-connection method
> none
> debug1: attempt 0 failures 0
> Failed none for quinot from 10.10.0.172 port 35503 ssh2
> Failed none for quinot from 10.10.0.172 port 35503 ssh2
> debug1: userauth-request for user quinot service ssh-connection method
> hostbased
> debug1: attempt 1 failures 1
> debug1: userauth_hostbased: cuser quinot chost vienna.int.domain.com.
> pkalg s
> sh-dss slen 55
> debug1: temporarily_use_uid: 529/101 (e=0)
> debug1: restore_uid
> debug1: temporarily_use_uid: 529/101 (e=0)
> debug1: restore_uid
> debug1: temporarily_use_uid: 529/101 (e=0)
> debug1: restore_uid
> debug1: temporarily_use_uid: 529/101 (e=0)
> debug1: restore_uid
> Failed hostbased for quinot from 10.10.0.172 port 35503 ssh2
> debug1: userauth-request for user quinot service ssh-connection method
> hostbased
> debug1: attempt 2 failures 2
> debug1: userauth_hostbased: cuser quinot chost vienna.int.domain.com.
> pkalg s
> sh-rsa slen 143
> debug1: temporarily_use_uid: 529/101 (e=0)
> debug1: restore_uid
> debug1: temporarily_use_uid: 529/101 (e=0)
> debug1: restore_uid
> debug1: temporarily_use_uid: 529/101 (e=0)
> debug1: restore_uid
> debug1: ssh_rsa_verify: signature correct
> Accepted hostbased for quinot from 10.10.0.172 port 35503 ssh2
> Accepted hostbased for quinot from 10.10.0.172 port 35503 ssh2
> debug1: monitor_child_preauth: quinot has been authenticated by
> privileged proce
> ss
> debug1: newkeys: mode 0
> debug1: newkeys: mode 1
> debug1: Entering interactive session for SSH2.
> debug1: fd 8 setting O_NONBLOCK
> debug1: fd 10 setting O_NONBLOCK
> debug1: server_init_dispatch_20
> buffer_append_space: alloc 10506240 not supported
> debug1: Calling cleanup 0x807e3ec(0x0)
> debug1: Calling cleanup 0x807e3ec(0x0)
>
>
-- 
Tim Rice				Multitalents	(707) 887-1469
tim at multitalents.net

Mihnea-Costin Grigore

2002-Jul-02 12:48 UTC

head link

3.4p1: 'buffer_append_space: alloc 10506240 not supported'

On Mon, 1 Jul 2002, Thomas Quinot wrote:
> I have been trying to install 3.4p1 on a number of machines.
> Servers on ia64 Linux, i386 Linux and SPARC Solaris are all working
> like charms. On the other hand, I am having trouble at least with
> HPUX 11, DEC OSF 5.1 and Unixware: on all those systems, sshd bails
> out after authentication with an error in buffer_append_space.
     I think this is the same problem that I encountered and written about
in the message from July 1st ("Memory allocation gone awry with OpenSSH
3.(3,4)p1")... It is the same pattern:

first we authenticate ok:
> debug1: monitor_child_preauth: quinot has been authenticated by
> privileged process
[...snip...]> buffer_append_space: alloc 10506240 not supported
Then the server tries to alloc. way too much memory and dies.
Obviously, this bug affects more systems and should be treated with some
attention... I'd be willing to help, as soon as someone points me in the
right direction (there are more details as to what I already tried/found
out, in the original message)...

Regards,

--
Mihnea-Costin Grigore          [ "Tenebus Ipsilo Ibinem Catehens" ]
E-mail: mgc8 at totalnet.ro       Home Page: http://mgc8.virtualave.net

Markus Friedl

2002-Jul-02 13:04 UTC

head link

3.4p1: 'buffer_append_space: alloc 10506240 not supported'

can you provide sshd -ddd output, too?

Seemingly Similar Threads

Search for more possibly parallel threads

openssh unix dev - Jul 2002 - 3.4p1: 'buffer_append_space: alloc 10506240 not supported'

3.4p1: 'buffer_append_space: alloc 10506240 not supported'

3.4p1: 'buffer_append_space: alloc 10506240 not supported'

3.4p1: 'buffer_append_space: alloc 10506240 not supported'

3.4p1: 'buffer_append_space: alloc 10506240 not supported'

Seemingly Similar Threads