Re: scp problem

From: Asif Iqbal (iqbala_at_qwestip.net)
Date: 06/24/03

  • Next message: Brian Hatch: "Re: Securing ssh tunnels."
    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
    

  • Next message: Brian Hatch: "Re: Securing ssh tunnels."

    Relevant Pages