scp says "lost connection"
Georg Wittig
Hi,
I have a problem with my installation of scp: Whenever I try to copy a
file to a machine which doesn't have sshd running, I get an error
message "lost connection". Here's what scp says:
$ rcp -v myfile nonssh-host:/tmp
Executing: host nonssh-host, user (unspecified), command scp -v -t /tmp
SSH Version 1.2.17 [alpha-dec-osf3.2], protocol version 1.5.
Standard version. Does not use RSAREF.
Reading configuration data /usr/local/etc/ssh_config
ssh_connect: getuid 999 geteuid 0 anon 0
Connecting to nonssh-host [aaa.bbb.ccc.ddd] port 22.
Allocated local port 1022.
connect: Connection refused
Trying again...
Connecting to nonssh-host [aaa.bbb.ccc.ddd] port 22.
Allocated local port 1022.
connect: Connection refused
Trying again...
Connecting to nonssh-host [aaa.bbb.ccc.ddd] port 22.
Allocated local port 1022.
connect: Connection refused
Trying again...
Connecting to nonssh-host [aaa.bbb.ccc.ddd] port 22.
Allocated local port 1022.
connect: Connection refused
Secure connection to nonssh-host refused.
lost connection
The effect is identical on SOLARIS-25 machines, so I doubt it's an OSF
specific problem. Did I miscompile or misconfigure ssh(d), or is this
a bug in ssh/scp? The FAQ doesn't seems to help.
BTW, scp to a machine with a running sshd works fine. Also "ssh" to a
nonssh-host works fine (i.e. it tries -and succeeds with- traditional
rsh if the secure connection cannot be established).
Thanks for any hints,
--
Georg Wittig GMD email:Georg....@gmd.de
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are 3 types of people in this world,
those who are good at Math and those who are not.
Wolfgang Szoecs
In article <5a8780$9...@omega.gmd.de>,
wit...@omega.gmd.de (Georg Wittig) writes:
>Hi,
>
>I have a problem with my installation of scp: Whenever I try to copy a
>file to a machine which doesn't have sshd running, I get an error
>message "lost connection". Here's what scp says:
>
i have the same problem with every OS (HP-UX,Linux,IRIX) !
This happens very often, when i try to scp BIG files (5MB+)
..invoking scp with "-c none" helps a little bit, but not much.
..also, retrying the command works sometimes.
With big files (e.g. 15MB or more) it nearly never works.
The only interesting thing here is, that every try stops at a different point.
So i conclude, that this is a bug ! :-)
Regards Wolfgang
--
\----------------------------------------\ _ ______ |
\ Wolfgang Szoecs UKRV-Berlin, Germany \ / \____-=0`/|0`/__|
\ SMTP: wo...@ukrv.de \_______\Berlin / | / )
/ Augustenburger Platz 1 / `/-==_____/__|/__=-|
/ 13353 Berlin / * \ | |
/----------------------------------------/ (o)
Redistribution of this message via the Microsoft Network is prohibited
Jim Stewart
wo...@ukrv.de (Wolfgang Szoecs) writes:
>In article <5a8780$9...@omega.gmd.de>,
[...]
>i have the same problem with every OS (HP-UX,Linux,IRIX) !
>This happens very often, when i try to scp BIG files (5MB+)
>..invoking scp with "-c none" helps a little bit, but not much.
>..also, retrying the command works sometimes.
>With big files (e.g. 15MB or more) it nearly never works.
>The only interesting thing here is, that every try stops at a different point.
>
>So i conclude, that this is a bug ! :-)
I've seen this problem with 1.2.16 and 1.2.17 on SunOS 4.1.3_U1 and
Solaris 2.4, both patched with all Sun recommended patches. The problem is
identical..seemingly random failures in large transfers, with "lost
connection" (or "broken pipe" when using ssh in pipelines) being the only
error message recorded, even when using -v. I see the problem on even
smaller files. Using "-c none" causes the failures to occur later in the
transfer, but that's about the only difference. This makes SSH completely
useless for backups, and if you have to tranfer your root partition over the
net unencrypted, then what's the point in using SSH at all?
At least now I know I'm not the only one. My previous posts regarding this
were not acknowledged.
The problem may also exist on Linux. I was having similar failures with
1.2.16, but didn't look into it too much. I don't recall having had these
problems with 1.2.14, but I was not using SSH extensively at that time.
If anyone has a fix for this, it would be greatly appreciated. If not, could
the SSH team at least acknowledge the problem? I'd be happy to provide more
details, but SSH itself isn't giving any.
SSH is a great product, but in its current state it doesn't do me much good,
unless I want to sit around ripping my hair out in frustration.
Jim
--
+ Jim Stewart j...@cybercomm.net +
| Unix Systems Administrator http://www.cybercomm.net/ |
+ CyberComm Online Services telnet://cybercomm.net/ +
Thomas Koenig
In comp.security.ssh, j...@raven.cybercomm.net (Jim Stewart) wrote:
>I've seen this problem with 1.2.16 and 1.2.17 on SunOS 4.1.3_U1 and
>Solaris 2.4, both patched with all Sun recommended patches. The problem is
>identical..seemingly random failures in large transfers, with "lost
>connection" (or "broken pipe" when using ssh in pipelines) being the only
>error message recorded, even when using -v.
Same thing here; I also get aborting X connections when the rate of
graphicsdata transfer is very large.
This is with Linux 2.0.27.
Time for a FAQ entry, I think...
Jens Schweikhardt
In article <5bkqk8$a...@fg70.rz.uni-karlsruhe.de> Thomas...@ciw.uni-karlsruhe.de writes:
I could not agree more. One more data point:
same trouble on Solaris 2.5.1 after upgrading to 1.2.17.
The smallest file it happened with was about 80k.
Jens
--
Jens Schweikhardt <schw...@noc.dfn.de>
SIGSIG -- signature too long (core dumped)
Wojtek Pilorz
On 15 Jan 1997, Jim Stewart wrote:
> Date: 15 Jan 1997 12:14:13 -0500
> From: Jim Stewart <j...@raven.cybercomm.net>
> To: s...@clinet.fi
> Subject: Re: scp says "lost connection"
>
> wo...@ukrv.de (Wolfgang Szoecs) writes:
>
> >In article <5a8780$9...@omega.gmd.de>,
> [...]
>
> >i have the same problem with every OS (HP-UX,Linux,IRIX) !
> >This happens very often, when i try to scp BIG files (5MB+)
> >..invoking scp with "-c none" helps a little bit, but not much.
>
> >..also, retrying the command works sometimes.
>
> >With big files (e.g. 15MB or more) it nearly never works.
> >The only interesting thing here is, that every try stops at a different point.
> >
> >So i conclude, that this is a bug ! :-)
>
> I've seen this problem with 1.2.16 and 1.2.17 on SunOS 4.1.3_U1 and
> Solaris 2.4, both patched with all Sun recommended patches. The problem is
> identical..seemingly random failures in large transfers, with "lost
> connection" (or "broken pipe" when using ssh in pipelines) being the only
> error message recorded, even when using -v. I see the problem on even
> smaller files. Using "-c none" causes the failures to occur later in the
> transfer, but that's about the only difference. This makes SSH completely
> useless for backups, and if you have to tranfer your root partition over the
> net unencrypted, then what's the point in using SSH at all?
>
> At least now I know I'm not the only one. My previous posts regarding this
> were not acknowledged.
>
> The problem may also exist on Linux. I was having similar failures with
> 1.2.16, but didn't look into it too much. I don't recall having had these
> problems with 1.2.14, but I was not using SSH extensively at that time.
>
> If anyone has a fix for this, it would be greatly appreciated. If not, could
> the SSH team at least acknowledge the problem? I'd be happy to provide more
> details, but SSH itself isn't giving any.
>
> SSH is a great product, but in its current state it doesn't do me much good,
> unless I want to sit around ripping my hair out in frustration.
>
> Jim
>
> --
> + Jim Stewart j...@cybercomm.net +
> | Unix Systems Administrator http://www.cybercomm.net/ |
> + CyberComm Online Services telnet://cybercomm.net/ +
>
If you need just backups over the net, I would suggest using
plain idea cipher with conventional passwords;
I have used that for sending successfully several
hundred MB over local Ethernet network;
(By successfully I mean that I have checked MD5 checksums
on the fly and they were correct);
I used that with the simple public-domain
tcplisten/tcpconnect utilities;
If anyone is interested I could find URL for the C source
code of the program (as far as I remember it is
original IDEA reference source ...)
Regards,
Wojtek Pilorz
Wojtek...@bdk.lublin.pl
Jeff Reese
I am honestly not sure if it means anything, but I've got 1.2.17 running
on Solaris 2.4 and 2.5.1 and I transfer (for backup type reasons) 3
600Mb files each evening with no problem.....However, since I've been
busy none of these systems has any of the recommended patches. They all
are running only the straight O/S.........
Jens Schweikhardt wrote:
>
> In article <5bkqk8$a...@fg70.rz.uni-karlsruhe.de> Thomas...@ciw.uni-karlsruhe.de writes:
> :In comp.security.ssh, j...@raven.cybercomm.net (Jim Stewart) wrote:
> :
> :>I've seen this problem with 1.2.16 and 1.2.17 on SunOS 4.1.3_U1 and
> :>Solaris 2.4, both patched with all Sun recommended patches. The problem is
> :>identical..seemingly random failures in large transfers, with "lost
> :>connection" (or "broken pipe" when using ssh in pipelines) being the only
> :>error message recorded, even when using -v.
Mcgill Declan
I am also experiencing lost connections, specifically when forwarding
HTTP from WIN95 to LINUX 1.2.13/2.0.13. and/or DEC UNIX 4.0 ssh 1.2.17
It also leads to a total freeze of the WIN95 machine. CTRL-ALT-DEL and
the task list says ssh is not reacting.
Declan McGill
Softlab AG
Zygo Blaxell
In article <5bktor$egm$1...@news.belwue.de>,
Jens Schweikhardt <schw...@rubin.noc.dfn.de> wrote:
>In article <5bkqk8$a...@fg70.rz.uni-karlsruhe.de> Thomas...@ciw.uni-karlsruhe.de writes:
>:In comp.security.ssh, j...@raven.cybercomm.net (Jim Stewart) wrote:
>:
>:>I've seen this problem with 1.2.16 and 1.2.17 on SunOS 4.1.3_U1 and
>:>Solaris 2.4, both patched with all Sun recommended patches. The problem is
>:>identical..seemingly random failures in large transfers, with "lost
>:>connection" (or "broken pipe" when using ssh in pipelines) being the only
>:>error message recorded, even when using -v.
>:
>:Same thing here; I also get aborting X connections when the rate of
>:graphicsdata transfer is very large.
>:
>:This is with Linux 2.0.27.
>:
>:Time for a FAQ entry, I think...
>
>I could not agree more. One more data point:
>same trouble on Solaris 2.5.1 after upgrading to 1.2.17.
>The smallest file it happened with was about 80k.
We've been using ssh versions 1.2.13 to 1.2.17 on Linux 1.2.13
(coincidences are cute) to 2.0.27, with a SunOS and Solaris/X86 machine
in there from time to time. We transfer about 5-10 gigabytes per month
through ssh between machines on our internal network, carrying scp, login
traffic, X traffic, and several hundred hours of CD-quality sound data
(don't ask). Internal traffic is encrypted with arcfour but not
compressed; external traffic encrypted with IDEA and compressed at level 9.
We have experienced some "corrupted bytes on input stream" messages
(I forget the exact text), usually on backups (along with some headers,
it's mostly gigabytes of gzip -9 compressed data fed to ssh for arcfour
encryption and no compression). The occurrence of these errors is random,
with the average being somewhere around 1.5 gigabytes into the transfer.
We've noticed that all of the "corrupted bytes" messages happened on a few
specific machines. We replaced the motherboards on these machines and
the problems went away. FWIW, the machines did have other problems, usually
one or two bit errors on a 2-gig tape and the occasional random segfault
of a daemon every few days.
We were expecting this kind of problem because we got a couple of
mainboards that had a bit error in RAM every few *hours*. We don't buy
that brand any more.
--
Zygo Blaxell. Unix/soft/hardware/firewall/security guru. 10th place, ACM Intl
Prog Contest, 1995. Admin Linux+Solaris for food, Tshirts, anime. Pager: 1613
7608572. "I gave up $1000 to avoid working on windoze... *sigh*"-Amy Fong. "smb
is a microsoft toy, like a "child" protocol that never matured"-S Boisjoli.
Kolin E. Hand
>
> >
> > At least now I know I'm not the only one. My previous posts regarding this
> > were not acknowledged.
> >
>
> 10.01) both running SSH 1.2.17. Large x-fers barf with "lost connection"
> messages.
>
I hate to follow-up on my own posting of an "RE:", but I have another
observation. It seems that I do not see the "lost connection" message
when I "pull" files to the local machine. I only see the "lost connection"
when pushing files to a remote system.
Kolin
--
=======================================================================
Kolin E. Hand Computing and Communication
keh...@wizard.ucr.edu Unix Systems Group (USG)
Megalomaniac of wizard
=======================================================================
C. v. Stuckrad
On Fri, 17 Jan 1997, Kolin E. Hand wrote:
> when I "pull" files to the local machine. I only see the "lost connection"
> when pushing files to a remote system.
REALLY Something MUST be wrong! SUN-Sparc4 (SunOS 4.1.3, sun4m) gcc-2.7.2
((This may be a special case because I compress aonly zeroes ! but...))
PULLing a file works here too:
$ ssh -v -C kowalewsky echo HI 1\>\&2 \; buffer -s 10k -S 1M \< /dev/zero|
buffer -s 10k -S 1M > /dev/null
..... shows the runing transport indicator ...
But the following does NOT work. (PUSHing)
------------------------------- screenshot -------------------------------
$ buffer -s 10k -S 1M < /dev/zero | ssh -v -C server echo HI \; buffer -s 10k -S 1M \> /dev/null
SSH Version 1.2.17 [sparc-sun-sunos4.1.3], protocol version 1.5.
Standard version. Does not use RSAREF.
Reading configuration data /etc/ssh_config
ssh_connect: getuid 4603 geteuid 0 anon 0
Connecting to server [160.45.40.41] port 22.
Allocated local port 1021.
Connection established.
Remote protocol version 1.5, remote software version 1.2.17
Waiting for server public key.
Received server public key (768 bits) and host key (1024 bits).
Host 'server' is known and matches the host key.
Initializing random; seed file
$HOME/.ssh/random_seed
Encryption type: idea
Sent encrypted session key.
Received encrypted confirmation.
Trying rhosts or /etc/hosts.equiv with RSA host authentication.
Remote: Rhosts/hosts.equiv authentication refused: client user 'user',
server user 'user', client host 'client'.
Server refused our rhosts authentication or host key.
Connection to authentication agent opened.
Trying RSA authentication via agent with 'user@host'
Received RSA challenge from server.
Sending response to RSA challenge.
Remote: RSA authentication accepted.
RSA authentication accepted by server.
Requesting compression at level 6.
Enabling compression at level 6.
Requesting authentication agent forwarding.
Sending command: echo HI ; buffer -s 10k -S 1M > /dev/null
Entering interactive session.
HI
12K
Transferred: stdin 561152, stdout 16, stderr 0 bytes in 1.3 seconds
Bytes per second: stdin 429287.7, stdout 12.2, stderr 0.0
Exit status 0
compress outgoing: raw data 562025, compressed 3461, factor 0.01
compress incoming: raw data 37, compressed 41, factor 1.11
----------------------------------------------------------------------
Our tape-backup PUSHES, but uncompressed and unencrypted, THAT works.
(Compression and/or encryption were to slow for streaming tapes).
Stucki
Christoph von Stuckrad * * | talk to | <stu...@math.fu-berlin.de> \
Freie Universitaet Berlin |/_* | nickname | ...!unido!fub!leibniz!stucki|
Fachbereich Mathematik, EDV |\ * | 'stucki' | Tel:+49 30 838-7545{9|8} |
Arnimallee 2-6/14195 Berlin * * | on IRC | Fax:+49 30 838-5913 /
Kolin E. Hand
>
> At least now I know I'm not the only one. My previous posts regarding this
> were not acknowledged.
>
I've got the same problem between HP-UX machines here (HP-UX 9.05 and
10.01) both running SSH 1.2.17. Large x-fers barf with "lost connection"
messages.
Very frustrating.
Kolin
--
=======================================================================
Kolin E. Hand University of California, Riverside
Kolin...@ucr.edu UNIX Systems Group, Computing and Communications
=======================================================================
Tim Rylance
Kolin E. Hand said:
> I hate to follow-up on my own posting of an "RE:", but I have another
> observation. It seems that I do not see the "lost connection" message
> when I "pull" files to the local machine. I only see the "lost connection"
> when pushing files to a remote system.
I had a similar problem a few months ago rdist-ing files to various SunOS4
systems. Running sshd under trace, it seemed that sshd was quitting after
a write failed with EAGAIN. The manual page for write(2) on SunOS 4.1.3_U1
lists both EWOULDBLOCK and EAGAIN as indicating that a write would have
blocked, so I made the one-line change below and haven't had any problems
since.
*** ssh-1.2.16/serverloop.c- Fri Oct 4 14:00:42 1996
--- ssh-1.2.16/serverloop.c Mon Nov 18 16:25:57 1996
***************
*** 405,411 ****
buffer_len(&stdin_buffer));
if (len <= 0)
{
! if (errno != EWOULDBLOCK)
{
if (fdin == fdout)
shutdown(fdin, 1); /* We will no longer send. */
--- 405,411 ----
buffer_len(&stdin_buffer));
if (len <= 0)
{
! if (errno != EWOULDBLOCK && errno != EAGAIN)
{
if (fdin == fdout)
shutdown(fdin, 1); /* We will no longer send. */
--
Tim Rylance <t.ry...@elsevier.nl>
Tero Kivinen
Tim Rylance writes:
> I had a similar problem a few months ago rdist-ing files to various SunOS4
> systems. Running sshd under trace, it seemed that sshd was quitting after
> a write failed with EAGAIN. The manual page for write(2) on SunOS 4.1.3_U1
> lists both EWOULDBLOCK and EAGAIN as indicating that a write would have
> blocked, so I made the one-line change below and haven't had any problems
> since.
I already changed all the checks to check both EWOULDBLOCK and EAGAIN
earlier, and I have sent the patch to some who have complained about
this, but I haven't received any confirmation before, that it really
fixes the problem. The patch will be in next release anyway...
--
kiv...@iki.fi Work : +358-9-451 4032
Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-9-502 1573
Thomas Aeby
On Mon, 20 Jan 1997, Tim Rylance wrote:
> I had a similar problem a few months ago rdist-ing files to various SunOS4
> systems. Running sshd under trace, it seemed that sshd was quitting after
> a write failed with EAGAIN. The manual page for write(2) on SunOS 4.1.3_U1
> lists both EWOULDBLOCK and EAGAIN as indicating that a write would have
> blocked, so I made the one-line change below and haven't had any problems
> since.
> [diffs]
This patch seems to have solved the problem for me (ssh 1.2.17)!!!!
Thanks a lot!
Bye,
Tom
-----------------------------------------------------------
Thomas Aeby Ascom Telematic AG
Email: t...@abs.ascom.ch Unix System Administrator
Tel.: (CH) 031/999 7276 Fax: (CH) 031/999 7254
C. v. Stuckrad
On Mon, 20 Jan 1997, Tero Kivinen wrote:
> Tim Rylance writes:
> > I had a similar problem a few months ago rdist-ing files to various SunOS4
> > systems. Running sshd under trace, it seemed that sshd was quitting after
> > a write failed with EAGAIN. The manual page for write(2) on SunOS 4.1.3_U1
> > lists both EWOULDBLOCK and EAGAIN as indicating that a write would have
> > blocked, so I made the one-line change below and haven't had any problems
> > since.
>
> I already changed all the checks to check both EWOULDBLOCK and EAGAIN
> earlier, and I have sent the patch to some who have complained about
> this, but I haven't received any confirmation before, that it really
> fixes the problem. The patch will be in next release anyway...
I think I'm the one, who should have reacted :-))
I had no chance to test the patch before today, did it around (our) noon,
and since then not problems any more.. (as many connections as we like:-).
((There 'might be' a 'chance' left for the problem, as we could reproduce
the error only on two of 15 systems. But those two work fine now))
So I state here, that I strongly support the patch, and
I apologize being so late with it.