two problems with OpenSSH and scp

two problems with OpenSSH and scp

Post by Sergey Mal » Tue, 05 Mar 2002 08:11:10



I've got two strange problemsm after installing OpenSSH 3.02.p1.
I have two machines running RH 6.2. Both have running the same version
of  OpenSSH, server has a sshd deamon running, started through the
inetd.
First, it appears that ftp connection between my machines on the local
network became **way** too slow after installing ssh. It's not like it
fails, but it takes much longer to get an ftp prompt. Why it might
happen and how I can trobubleshoot it?

Second problem started very recently after I've installed sybase
11.9.2 on my server with the corresponding user. Before scp worked
fine and now problems were seen. Now when I try to copy files between
machines using scp, it copies them and then hangs and continue to send
the same file over and over resulting in a very big target file. Does
anyone knows what could I changed in ssh configuration that caused
such a problem?

Thanks,

Sergey Malov

 
 
 

two problems with OpenSSH and scp

Post by iLia » Thu, 07 Mar 2002 15:42:13


Sergey,
I can only theorize on the problems. But, it actually sounds like some of
this may be coincidental.
It may be that you actually have network problems causing what you see.
SCP is, of course, encrypting the information across the wire. The higher
the encryption, the more data flowing.
If there are layer 1/2 problems on your network, such as collisions, or an
invalid duplex setting, then you are exponentially (well, maybe not that
bad)
increasing the chances of problems happening when using SCP. Meaning,
information that is NOT encrypted would have a less likely chance of havin
the collision or problem as it would take less data to send. BUT that is a
VERY vague statement as it depends on the length of the cable, size of the
frame (assuming Ethernet), etc. etc.
Of course, the reason I say it may be coincidence, is that you are having
the problem with FTP as well. And FTP should be plain, and simple.
To troubleshoot, I would definitely get a packet analyzer out and watch the
traffic. Something like Ethereal, tcpdump, or snoop (assuming you are using
the unices) and of course, Ethereal will work on the WIN32 platform.
You will need to look for CRC errors. I'd bet a dollar that is what is going
on ;-)


Quote:> I've got two strange problemsm after installing OpenSSH 3.02.p1.
> I have two machines running RH 6.2. Both have running the same version
> of  OpenSSH, server has a sshd deamon running, started through the
> inetd.
> First, it appears that ftp connection between my machines on the local
> network became **way** too slow after installing ssh. It's not like it
> fails, but it takes much longer to get an ftp prompt. Why it might
> happen and how I can trobubleshoot it?

> Second problem started very recently after I've installed sybase
> 11.9.2 on my server with the corresponding user. Before scp worked
> fine and now problems were seen. Now when I try to copy files between
> machines using scp, it copies them and then hangs and continue to send
> the same file over and over resulting in a very big target file. Does
> anyone knows what could I changed in ssh configuration that caused
> such a problem?

> Thanks,

> Sergey Malov


 
 
 

two problems with OpenSSH and scp

Post by iLia » Thu, 07 Mar 2002 15:57:04


And.....I will add....obviously you will not be able to decode the actual
traffic of the SCP'ed connection.
But, you need to look for re-transmits, failed TCP connections, collisions,
CRC errors, or anything that your
traffic analyzer will show you.
Start eliminating the layers of the OSI model to ensure it isn't an actual
network related problem. I'm not sure of your
level of expertise in this area, but it isn't uncommon to have a duplex
mismatch on a network, which will cause MASSIVE
collisions is you are on a switch. If you are on a hub, then it can be
similar depending on what type of nic you are using.

Well enough said.
iLiad


> Sergey,
> I can only theorize on the problems. But, it actually sounds like some of
> this may be coincidental.
> It may be that you actually have network problems causing what you see.
> SCP is, of course, encrypting the information across the wire. The higher
> the encryption, the more data flowing.
> If there are layer 1/2 problems on your network, such as collisions, or an
> invalid duplex setting, then you are exponentially (well, maybe not that
> bad)
> increasing the chances of problems happening when using SCP. Meaning,
> information that is NOT encrypted would have a less likely chance of havin
> the collision or problem as it would take less data to send. BUT that is a
> VERY vague statement as it depends on the length of the cable, size of the
> frame (assuming Ethernet), etc. etc.
> Of course, the reason I say it may be coincidence, is that you are having
> the problem with FTP as well. And FTP should be plain, and simple.
> To troubleshoot, I would definitely get a packet analyzer out and watch
the
> traffic. Something like Ethereal, tcpdump, or snoop (assuming you are
using
> the unices) and of course, Ethereal will work on the WIN32 platform.
> You will need to look for CRC errors. I'd bet a dollar that is what is
going
> on ;-)



> > I've got two strange problemsm after installing OpenSSH 3.02.p1.
> > I have two machines running RH 6.2. Both have running the same version
> > of  OpenSSH, server has a sshd deamon running, started through the
> > inetd.
> > First, it appears that ftp connection between my machines on the local
> > network became **way** too slow after installing ssh. It's not like it
> > fails, but it takes much longer to get an ftp prompt. Why it might
> > happen and how I can trobubleshoot it?

> > Second problem started very recently after I've installed sybase
> > 11.9.2 on my server with the corresponding user. Before scp worked
> > fine and now problems were seen. Now when I try to copy files between
> > machines using scp, it copies them and then hangs and continue to send
> > the same file over and over resulting in a very big target file. Does
> > anyone knows what could I changed in ssh configuration that caused
> > such a problem?

> > Thanks,

> > Sergey Malov

 
 
 

two problems with OpenSSH and scp

Post by Sergey Mal » Fri, 08 Mar 2002 03:38:50


Thanks for response, I thought I'll never get any :-).
Problem that most of what you've described I did and traffic still
look normal to me. I'will probably try to roll back changes to get
what I had before and then analyse traffic statistics before and after
changes.
Problem with scp (infinite coping) is very weird. I have local ssh
guru, he never saw anything like this.
Oh, well...

Thanks

Sergey


> And.....I will add....obviously you will not be able to decode the actual
> traffic of the SCP'ed connection.
> But, you need to look for re-transmits, failed TCP connections, collisions,
> CRC errors, or anything that your
> traffic analyzer will show you.
> Start eliminating the layers of the OSI model to ensure it isn't an actual
> network related problem. I'm not sure of your
> level of expertise in this area, but it isn't uncommon to have a duplex
> mismatch on a network, which will cause MASSIVE
> collisions is you are on a switch. If you are on a hub, then it can be
> similar depending on what type of nic you are using.

> Well enough said.
> iLiad



> > Sergey,
> > I can only theorize on the problems. But, it actually sounds like some of
> > this may be coincidental.
> > It may be that you actually have network problems causing what you see.
> > SCP is, of course, encrypting the information across the wire. The higher
> > the encryption, the more data flowing.
> > If there are layer 1/2 problems on your network, such as collisions, or an
> > invalid duplex setting, then you are exponentially (well, maybe not that
> > bad)
> > increasing the chances of problems happening when using SCP. Meaning,
> > information that is NOT encrypted would have a less likely chance of havin
> > the collision or problem as it would take less data to send. BUT that is a
> > VERY vague statement as it depends on the length of the cable, size of the
> > frame (assuming Ethernet), etc. etc.
> > Of course, the reason I say it may be coincidence, is that you are having
> > the problem with FTP as well. And FTP should be plain, and simple.
> > To troubleshoot, I would definitely get a packet analyzer out and watch
>  the
> > traffic. Something like Ethereal, tcpdump, or snoop (assuming you are
>  using
> > the unices) and of course, Ethereal will work on the WIN32 platform.
> > You will need to look for CRC errors. I'd bet a dollar that is what is
>  going
> > on ;-)

 
 
 

two problems with OpenSSH and scp

Post by Vigi » Sun, 14 Jul 2002 05:10:12


I have this problem on two separate networks. I can scp fine from A to B,
but when i scp from B to A the file transfers over and over on top of
itself!

Sergey Malov had the audacity to claim:

Quote:> Problem with scp (infinite coping) is very weird. I have local ssh guru,
> he never saw anything like this.

--

.

 
 
 

two problems with OpenSSH and scp

Post by Bob Tennen » Sun, 14 Jul 2002 06:10:27


 > I have this problem on two separate networks. I can scp fine from A to B,
 > but when i scp from B to A the file transfers over and over on top of
 > itself!

I suspect a problem with /etc/hosts on B.  If B has its own IP address
as the IP address of A, you would get this behavior.

 
 
 

two problems with OpenSSH and scp

Post by Vigi » Sun, 14 Jul 2002 09:00:38


While changing /etc/hosts had no effect, I don't particularly think it's
a network problem. As the verbose output below shows, scp seems to think
the size of the file is 17592186044416 bytes, while in actual fact it is
4413542 bytes.

Executing: program /usr/local/bin/ssh host auriga, user vigil, command scp -v -t ~
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090604f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to auriga [192.168.0.5] port 22.
debug1: Connection established.
debug1: identity file /home/vigil/.ssh/identity type -1
debug1: identity file /home/vigil/.ssh/id_rsa type -1
debug1: identity file /home/vigil/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
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: 128/256
debug1: bits set: 1577/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'auriga' is known and matches the RSA host key.
debug1: Found key in /home/vigil/.ssh/known_hosts:2
debug1: bits set: 1637/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,keyboard-interactive
debug1: next auth method to try is publickey
debug1: try privkey: /home/vigil/.ssh/identity
debug1: try privkey: /home/vigil/.ssh/id_rsa
debug1: try pubkey: /home/vigil/.ssh/id_dsa
debug1: input_userauth_pk_ok: pkalg ssh-dss blen 433 lastkey 0x8117068 hint 2
debug1: read PEM private key done: type DSA
debug1: ssh-userauth2 successful: method publickey
debug1: fd 4 setting O_NONBLOCK
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 command: scp -v -t ~
debug1: channel request 0: exec
debug1: channel 0: open confirm rwindow 0 rmax 32768
Sending file modes: C0600 17592186044416 httpd-2.0.39.tar.gz
httpd-2.0.39.tar.gz    0% |                             |   565 KB 8369:48:46 EThttpd-2.0.39.tar.gz    0% |                             |  1199 KB 7925:12:08 EThttpd-2.0.39.tar.gz    0% |                             |  1824 KB 7824:21:00 EThttpd-2.0.39.tar.gz    0% |                             |  2381 KB 7996:53:02 EThttpd-2.0.39.tar.gz    0% |                             |  3014 KB 7900:38:10 EThttpd-2.0.39.tar.gz    0% |                             |  3487 KB 8197:20:02 EThttpd-2.0.39.tar.gz    0% |                             |  3884 KB 8587:39:50 EThttpd-2.0.39.tar.gz    0% |                             |  4307 KB 8853:42:24 EThttpd-2.0.39.tar.gz    0% |                             |  4307 KB 9961:41:15 EThttpd-2.0.39.tar.gz    0% |                             |  4307 KB 11069:36:46 Ehttpd-2.0.39.tar.gz    0% |                             |  4307 KB 12177:44:19 Ehttpd-2.0.39.tar.gz    0% |                             |  4307 KB 13285:36:39 Ehttpd-2.0.39.tar.gz    0% |                             |  4307 KB  - stalled -debug1: channel_free: channel 0: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Killed by signal 2.
debug1: Calling cleanup 0x805f660(0x0)
debug1: Calling cleanup 0x806b080(0x0)

Bob Tennent had the audacity to claim:


>  > I have this problem on two separate networks. I can scp fine from A
>  > to B, but when i scp from B to A the file transfers over and over on
>  > top of itself!

> I suspect a problem with /etc/hosts on B.  If B has its own IP address
> as the IP address of A, you would get this behavior.

--

.

 
 
 

two problems with OpenSSH and scp

Post by E Wige » Mon, 15 Jul 2002 03:44:51



> I have this problem on two separate networks. I can scp fine from A to
> B, but when i scp from B to A the file transfers over and over on top of
> itself!

> Sergey Malov had the audacity to claim:

>> Problem with scp (infinite coping) is very weird. I have local ssh
>> guru, he never saw anything like this.

another reason it will do this is if you forget the : after the ip
address you are copying too.  For example
scp filename ip-address-of-target/home/user/

will copy file onto itself.

scp filename ip-address-of-target:/home/user

will copy the file to target ip address

Ed Wiget

 
 
 

two problems with OpenSSH and scp

Post by Vigi » Mon, 15 Jul 2002 12:17:25


It's not that. This thing will actually copy across the network but keep
on copying over and over resulting in a very big file. scp actually
thinks the file to copy is some seemingly random big number, like 17
gazillion bytes. The problem seems to be that scp thinks the file is a
size other than what it really is.

E Wiget had the audacity to claim:

Quote:> scp filename ip-address-of-target/home/user/

> will copy file onto itself.

> scp filename ip-address-of-target:/home/user

> will copy the file to target ip address

--

.

 
 
 

two problems with OpenSSH and scp

Post by Vigi » Mon, 15 Jul 2002 12:27:18


I hope you're following the thread 'scp broken in openssh-3.1.p1' in this
newsgroup ;-)

Sergey Malov had the audacity to claim:

Quote:> Problem with scp (infinite coping) is very weird.

--

.

 
 
 

1. scp, openssh and "scp: not found"

Hi!

I am having problems using scp between two hosts. rzstud2 is running
the non-free ssh 1.2.27, q.bofh.de is running openssh 1.2pre12 (I
should update ;-) ).


|Executing: host q.bofh.de, user mh, command scp -v -f ~/.bashrc
|SSH Version 1.2.27 [i686-unknown-linux], protocol version 1.5.
|Standard version.  Does not use RSAREF.
|rzstud2: Reading configuration data /etc/ssh_config
|rzstud2: ssh_connect: getuid 55708 geteuid 55708 anon 1
|rzstud2: Connecting to q.bofh.de [195.247.234.106] port 22.
|rzstud2: Connection established.
|rzstud2: Remote protocol version 1.5, remote software version OpenSSH-1.2
|rzstud2: Waiting for server public key.
|rzstud2: Received server public key (768 bits) and host key (1024 bits).
|rzstud2: Host 'q.bofh.de' is known and matches the host key.
|rzstud2: Initializing random; seed file /home/ws/uncu/.ssh/random_seed
|rzstud2: IDEA not supported, using 3des instead.
|rzstud2: Encryption type: 3des
|rzstud2: Sent encrypted session key.
|rzstud2: Installing crc compensation attack detector.
|rzstud2: Received encrypted confirmation.
|rzstud2: No agent.
|rzstud2: Doing password authentication.

|rzstud2: Sending command: scp -v -f ~/.bashrc
|rzstud2: Entering interactive session.
|bash: scp: command not found
|rzstud2: Transferred: stdin 1, stdout 29, stderr 0 bytes in 0.1 seconds
|rzstud2: Bytes per second: stdin 7.9, stdout 227.8, stderr 0.0
|rzstud2: Exit status 127
|rzstud2 uncu ~/tmp >

Looks like the local host is trying to invoke an scp process on the
remote side and the remote site can't find the scp binary. But it's
there (in /usr/local/bin/scp) and works when I invoke scp on the other
side.

What am I doing wrong?

Greetings
Marc

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber          |   " Questions are the         | Mailadresse im Header
Karlsruhe, Germany  |     Beginning of Wisdom "     | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

2. Matrox M3D Question for Bill Hoscheit

3. openssh scp problem

4. Please Help!!!

5. Problem with SCP with OpenSSH 2.3.0p1

6. WTB: PalmPilot Personal in Excellent Condition

7. Openssh 2.9.9p2 --with-pam chauthtok & scp problems (Solaris 2.7)

8. OpenSSH scp problem when used with Dante socks

9. Openssh 2.9: problems with scp

10. problems with scp from openssh to ssh

11. problem: infinite copying with scp (OpenSSH 3.02.p1)

12. problem with scp and OpenSSH on redhat