[TriLUG] scp not working on my RH9 box.

Ben Pitzer uncleben at mindspring.com
Sun Aug 31 10:29:30 EDT 2003


First, the remote host should have the keyboard interactive login feature
disabled, as it is a potential security risk.  Second, ssh should always use
type 2, also as a security precaution.

That being said, and recognizing that it's something that you may have no
control over whatsoever, here's something to try.  Instead of a / at the end
of your scp command, try just a '.'.  So the command would be:

	scp rm-users itimfs:.

It could be a matter of file naming.  Basically, the '.' specifies that you
want to keep the file name.  Just using the / probably does the same thing,
but I find that it's not necessary, unless you're trying to put something in
a directory other than your $HOME.  If you want it in the root directory,
try this:

	scp rm-users itimfs:/.

Also, doing this as root (if you are) is also less than advisable.  root
logins should be disabled on any SSH host.  Again, as a security issue.

Finally, if these don't work, I'd ask you to include the simple error that
you receive when trying to do this, minus all the debug stuff.  While that's
helpful, it didn't include the actual error that the scp command threw to
you in the shell, that I could see.  It looks like you're connecting, doing
the key exchange, and initiating the socket just fine, but that something
happens during the file transfer portion, possibly a permissions error, or a
'file not found' error.  The error thrown to STDOUT might be helpful there.

HTH.

Regards,
Ben Pitzer

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

"Those that can give up essential liberty to obtain a little temporary
safety
 deserve neither liberty nor safety."
 --Ben Franklin--




> -----Original Message-----
> From: trilug-bounces at trilug.org [mailto:trilug-bounces at trilug.org]On
> Behalf Of bp
> Sent: Friday, August 29, 2003 12:29 PM
> To: Triangle Linux Users Group discussion list
> Subject: Re: [TriLUG] scp not working on my RH9 box.
>
>
> On Fri, 29 Aug 2003, Joseph Tate wrote:
>
> > Do it with user at itmfs:/ and send the output.  It's trying to log you in
> > as root on the remote host.  That may be ok, but it could be that
> > external root logins are disabled.
> >
> > Log into your RHL 9 box and tail -f /var/log/secure while you do it to
> > see if there's a problem on that end.
> >
> > Joseph
> >
>
> scp exists on the itimfs box.  Results are the same for a user on the
> machine too.  Thinking that my config may be botched up...
> -bp
>
> linux1$ scp -v rm-users bpevans at itimfs:~/
> Executing: program /usr/bin/ssh host itimfs, user bpevans, command scp -v
> -t ~/
> OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Rhosts Authentication disabled, originating port will not be
> trusted.
> debug1: ssh_connect: needpriv 0
> debug1: Connecting to itimfs [9.42.9.58] port 22.
> debug1: Connection established.
> debug1: identity file /root/.ssh/identity type -1
> debug1: identity file /root/.ssh/id_rsa type -1
> debug1: identity file /root/.ssh/id_dsa type -1
> debug1: Remote protocol version 1.99, 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: 143/256
> debug1: bits set: 1603/3191
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'itimfs' is known and matches the RSA host key.
> debug1: Found key in /root/.ssh/known_hosts:2
> debug1: bits set: 1584/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: /root/.ssh/identity
> debug1: try privkey: /root/.ssh/id_rsa
> debug1: try privkey: /root/.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
> bpevans at itimfs's password:
> debug1: ssh-userauth2 successful: method password
> 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
> Welcome to itimfs.!
> debug1: channel 0: read<=0 rfd 4 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
> 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.1 seconds
> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> debug1: Exit status 0
>
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
> TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc
>




More information about the TriLUG mailing list