Unfortunately, I think you may have gone a step too far in abstracting the data in your post. Three questions:
1) what are the filenames you're attempting this with? Have you tried it with something like "test.txt" as opposed to perhaps something like "A very korn-fusing f!le,name"? It would help to be able to rule out shell expansion from odd characters in the filename as the culprit.
2) What files exist, if any, in your .ssh directory? Have you attempted to setup public-key authentication between these hosts? Do you have a authorized_keys or authorized_keys2 file?
3) Is there anything particularly strange in your login scripts? The fact that you can ssh to the remote host successfully and don't mention any other wierd login-related problems leads me to believe this isn't an issue, but it doesn't hurt to ask.


Tip: create some test files with a few lines of bogus data each, call them "test1.txt" and "test2.txt". Attempt to scp them from machine to machine. Post the precise output, obfuscating only the usernames and hostnames if you must. Do an "ls -la" before and after each attempted scp. Another thing to try would be remote single-command execution - i.e. to do an ls of the remote host, do it in your session as "ssh hismachine ls -la <filename>". This has the added benefit of showing you if your running into issues w/ shell expansion or space confusion from funny file names.

Aaron S. Joyner

Brian A. Henning wrote:

Hello all,
 I've recently encountered this problem in a few places, and was wondering
if anyone had some insight or could tell me where to look for the solution.

scp doesn't like me.  Here are a couple example scenarios involving my
personal RH7.3 box and another host.  For simplicity, we'll call mine "mine"
and the other "his."

Example 1:  his runs RH8.0, or possibly FC1 (I helped him upgrade, but I
forget whether this scenario occurred before or after the upgrade).  I am
physically at his.

his% scp [EMAIL PROTECTED]:~/some_file_that_exists .
Password: ********
/etc/bashrc processed   # <-- that is an echo in my /etc/bashrc, put in to
help troubleshoot
                             some odd environment issues
his% _
(nothing happens--the file is not transferred...so I try:)
his% ssh [EMAIL PROTECTED]
[EMAIL PROTECTED]'s password: ********
/etc/profile processed  # <-- also have this for the same reason as
mentioned above
/etc/bashrc processed   # <-- as mentioned above
A fortune (in my ~/.bashrc)
the uptime (likewise)
[EMAIL PROTECTED] scp some_file_that_exists [EMAIL PROTECTED]:~
[EMAIL PROTECTED]'s password: ********
[EMAIL PROTECTED] _
(still nothing happens; the file is not transferred..  so I give up on scp
and put the file in my public_html directory and get it that way)

Example 2: his runs FC1. I am physically at mine, ssh'd into his.

[EMAIL PROTECTED] scp [EMAIL PROTECTED]:~/some_file_that_exists .
[EMAIL PROTECTED]'s password: ********
/etc/bashrc processed
[EMAIL PROTECTED] _
(nothing--no transfer occurs, so I try on mine:)
mine% scp some_file_that_exists [EMAIL PROTECTED]:~
[EMAIL PROTECTED]'s password: ********
some_file_that_exists  100% |*****************************| 38980
00:00
mine% _
(and it works, but only when initiated from mine, as shown)

What causes this?  I tried an scp -v, and there's a ton of output, very
little of which indicates the problem that is actually occurring.  In fact,
comparing that to the same -v output of a successful transfer (the second
half of Example 2) only confuses me further, as it seems that the debug
output is the same..

Could it be the output from /etc/bashrc is somehow confusing the process?

Thanks in advance.

~Brian




-- 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

Reply via email to