[TriLUG] scp not working on my RH9 box.

bp bp at itchy.kicks-ass.org
Mon Sep 1 11:39:27 EDT 2003


The machine is one of my installs and I have full control over it.  I can 
appreciate the security concerns around using root but in a test 
environment the use of root is necessary to get things done in a timely 
fashion. (I setup & tear down environments weekly.  They are also deeply 
nested in their own subnet behind many fw's)

No error is displayed - it simply accepts the interactive passwd and the 
shell returns w/o transferring the file.  No error is sent to STOUT nor 
STERR.

Thanks - bp

On Sun, 31 Aug 2003, Ben Pitzer wrote:

> 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