Putty psftp connection problem...

[Tom Kristen Hansen]

I have installed OpenSSH ver. 3.5p1 under Solaris 9
(Solaris SSH was first removed). The source for this
installation is from www.sunfreeware.com.

I now have problems to access this server from my
Putty clients - i get the following error;
'Fatal: unable to initialise SFTP: could not connect'

Can anyone help me with this problem ?

Tom Kristen Hansen
EDB Teamco AS
Norway

[Richard E. Silverman]

Do some debugging first. Use sftp -v. Have you even started the SSH server?

--
Richard Silverman
sl...@shore.net

[Tom Kristen Hansen]

I have done some debugging, everything apart from sftp scp works fine, and
the sshd_config file seems
to be ok.

One new thing in this installation of OpenSSH, is that it now uses a user
sshd. As i can see under the
OpenSSH FAQ, this user must not have any shell output - something i have
tested - which can
interrupt sftp and scp.

Do anyone have a clue ?

"Richard E. Silverman" <sl...@shore.net> wrote in message
news:m1lhecr...@syrinx.oankali.net...

[Richard E. Silverman]

>>>>> "TKH" == Tom Kristen Hansen <tok...@hotmail.com> writes:

TKH> I have done some debugging, everything apart from sftp scp works
TKH> fine, and the sshd_config file seems to be ok.

TKH> ... Do anyone have a clue ?

You have still given no details for anyone to have a clue *about*. Post
the output of sftp -v and sshd -d, for a start.

--
Richard Silverman
sl...@shore.net

[Tom Kristen Hansen]

Here are the output off the sftp -v
---
Connecting to <host>
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to <host> [<host>] port 22.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.5p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 131/256
debug1: bits set: 1555/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '<host>' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:1
debug1: bits set: 1616/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /.ssh/id_rsa
debug1: try privkey: /.ssh/id_dsa
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue:
publickey,password,keyboard-interactive
debug1: next auth method to try is password
root@<host> password:
debug1: ssh-userauth2 successful: method password
debug1: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: Sending subsystem: sftp
debug1: channel request 0: subsystem
debug1: channel 0: open confirm rwindow 0 rmax 32768
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -> closed
debug1: channel 0: rcvd close
debug1: channel 0: close_read
debug1: channel 0: input open -> closed
debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 137
Connection closed

and sshd -d
---
debug1: sshd version OpenSSH_3.5p1
Could not load host key: /usr/local/etc/ssh_host_key
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
Disabling protocol version 1. Could not load host key
debug1: Bind to port 22 on ::.
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
Cannot bind any address.

Tom Kristen Hansen

"Richard E. Silverman" <sl...@shore.net> wrote in message

news:m1l3coa...@syrinx.oankali.net...

[Richard E. Silverman]

We need the output of an instance of sshd -d which participates in the
connection in question -- not just a random one you start up which
immediately dies because you're already running an sshd on that port, and
has nothing to do with the problem at hand.

--
Richard Silverman
sl...@shore.net

[John Doe]

On Fri, 03 Jan 2003 15:06:18 -0500, Richard E. Silverman wrote:

>
> We need the output of an instance of sshd -d which participates in the
> connection in question -- not just a random one you start up which
> immediately dies because you're already running an sshd on that port, and
> has nothing to do with the problem at hand.

I've noticed this exact same problem as the O.P. and sent an e-mail about
this to the openssh-unix-dev and putty mailinglists.

I have since found the cause of the problem, and a work-around (which I do
not like, but for the time being)

Disable privilege-seperation on OpenSSH, and psftp will work again.

psftp seems to be the only client bothered by this, since openssh's sftp
(on unix and cygwin) seem to be working great no matter if privsep is on
or off.

Mark Janssen
maniac at maniac dot nl

[John Doe]

By the way, here is the original message I sent to the openssh and putty
lists:

------------

Hi List(s)

A customer of mine reported that sftp didn't work for them. It seems to
work just fine for me on that system, and after checking into it I
noticed that the customer used psftp, while I use sftp from either
cygwin or the linux version from openssh.

The openssh version of sftp works in all cases, priv-sep on or off.
However, the putty psftp breaks as soon as I turn on priv-sep (which is
on by default on openssh3.5).

I've tried this on 3.5 and today's snapshot of openssh.
I've tried with versions of putty from 0.52 to today's snapshot

On the unix system (i've tested aix433 and linux) the sshd reports the
following (sshd -D -d -d -d)

Jan 20 14:41:59 dhu1_boot sshd[9580]: Server listening on 0.0.0.0 port
22.
Jan 20 14:42:11 dhu1_boot sshd[15502]: Accepted password for maniac from
10.x.y.z port 2972 ssh2
Jan 20 14:42:12 dhu1_boot sshd[16546]: fatal: buffer_append_space: alloc
10506240 not supported

On the putty side I get the following message after entering the
password or passphrase when connecting to a server with priv-sep turned
on:

Fatal: unable to initialise SFTP: could not connect

----------

Mark Janssen

[Bryan Dongray]

I had the same "buffer_append_space: alloc ..." error.
After sifting through the openssh code, it seems when ssh v2 is used
with compression, a never ending loop requesting memory occurs.
When it gets to just over 10Mb, the sshd code decides enough's enough,
and exits.

The workaround is to either force using the ssh v1 protocol, or deny
use of compression with v2.

For those who know how to fix either zlib or openssh, I got as far
as compress.c in the buffer_uncompress() routine, which calls inflate()
part of the zlib library (which is why I didn't go any further).
I'm using openssh-3.5p1, openssl-0.9.7a, zlib-1.1.4 for sshd compiled
with gcc on a SGI IRIX system, and was connecting from RedHat7.3 Linux
default install ssh code. If that makes any difference?
I see John Doe below has the same problem on different platforms.

[Darren Tucker]

In article <3E72EB15...@dongrays.com>,

Bryan Dongray <b...@dongrays.com> wrote:
>I had the same "buffer_append_space: alloc ..." error.
>After sifting through the openssh code, it seems when ssh v2 is used
>with compression, a never ending loop requesting memory occurs.
>When it gets to just over 10Mb, the sshd code decides enough's enough,
>and exits.

There have been reports of problems like this with zlib-1.1.3 which
were cured by upgrading to zlib-1.1.4 and re-building.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

[Bryan Dongray]

Darren Tucker wrote:
> Bryan Dongray <b...@dongrays.com> wrote:
> >I had the same "buffer_append_space: alloc ..." error.
> >After sifting through the openssh code, it seems when ssh v2 is used
> >with compression, a never ending loop requesting memory occurs.
> >When it gets to just over 10Mb, the sshd code decides enough's enough,
> >and exits.
>
> There have been reports of problems like this with zlib-1.1.3 which
> were cured by upgrading to zlib-1.1.4 and re-building.

But I am using zlib-1.1.4 (see my previous post).
I've no problem since I have a workaround, I'm hoping this info helps
others to have a workaround until the experts can track this down.