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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > 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 [EMAIL PROTECTED]:/ 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 [EMAIL PROTECTED]:~/ > > 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 > > [EMAIL PROTECTED]'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 > > > > -- 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
