Re: scp problem

• Previous message: Darren Reed: "Securing ssh tunnels."
• In reply to: Crusty: "scp problem"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 24 Jun 2003 01:02:40 -0400 (EDT)
To: Crusty <c.tuck@telstra.com>

May be the account on the remote machine is expired due to inactivity

On Mon, 23 Jun 2003, Crusty wrote:

> I have searched for answers to my problem , but come up empty handed.
> The problem is that when using scp into a certain machine (Solaris 2.7
> running openssh_3.6.1)scp fails. It appears to work, i.e. fills the
> line with #'s (not the status line) and the file is never at the
> destination machine. Some background info, the machine was running an
> older version of ssh/ssl. I have just upgraded these two packages, but
> still have the same problem. I also have tcpd running, however I can
> ssh in from the same machines without a problem. The problem is only
> when trying to scp to that machine. When scp'ing from this machine to
> other machines it is OK. I have also upgraded another machine solaris
> machine with the same version open ssl/ssh, but get the same problem,
> thus I dont think it is related to a particular version mismatch of ssh.
> I have captured some debug in the hope that someone can help. machine1
> is the problem, fails with incoming scp from another machine
>
>
>
>
> user1@machine2[137] scp -v file1 machine1:/tmp/
> Executing: program /opt/OBSDssh/bin/ssh host machine1, user
> (unspecified), command scp -v -t /tmp/
> OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
> debug1: Reading configuration data /etc/ssh_config
> debug1: Applying options for *
> debug1: Rhosts Authentication disabled, originating port will not be
> trusted.
> debug1: restore_uid
> debug1: ssh_connect: getuid 1010 geteuid 1010 anon 1
> debug1: Connecting to machine1 port 22.
> debug1: temporarily_use_uid: 1010/10 (e=1010)
> debug1: restore_uid
> debug1: temporarily_use_uid: 1010/10 (e=1010)
> debug1: restore_uid
> debug1: Connection established.
> debug1: identity file /home/user1/.ssh/identity type -1
> debug1: identity file /home/user1/.ssh/id_rsa type -1
> debug1: identity file /home/user1/.ssh/id_dsa type -1
> debug1: Remote protocol version 1.99, remote software version
> OpenSSH_3.6.1p1
> debug1: match: OpenSSH_3.6.1p1 pat OpenSSH*
> Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.1p1
> 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: 126/256
> debug1: bits set: 1570/3191
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'machine1' is known and matches the RSA host key.
> debug1: Found key in /home/user1/.ssh/known_hosts:11
> debug1: bits set: 1596/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: /home/user1/.ssh/identity
> debug1: try privkey: /home/user1/.ssh/id_rsa
> debug1: try privkey: /home/user1/.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
> user1@machine1's password:
> debug1: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64)
> debug1: ssh-userauth2 successful: method password
> debug1: fd 5 setting O_NONBLOCK
> debug1: fd 6 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 /tmp/
> debug1: channel request 0: exec
> debug1: channel 0: open confirm rwindow 0 rmax 32768
> ###################################################################
> debug1: channel 0: read<=0 rfd 5 len 0
> debug1: channel 0: read failed
> debug1: channel 0: close_read
> debug1: channel 0: input open -> drain
> debug1: channel 0: ibuf empty
> debug1: channel 0: send eof
> debug1: channel 0: input drain -> closed
> /tmp
> user1@machine2[138] 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: 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: fd 1 clearing O_NONBLOCK
> debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.3 seconds
> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> debug1: Exit status 0
>
>
> Regards
> Crusty
>
> ----------------
> Powered by telstra.com
>
>
>
>

-- 
Asif Iqbal
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x8B686E08
There's no place like 127.0.0.1

• Previous message: Darren Reed: "Securing ssh tunnels."
• In reply to: Crusty: "scp problem"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]