OpenSSH scp issue

[Ken Penland_1]

Okay, this one is confusing me, hopefully someone has an easy answer. Our environment is HPUX 11i v1, and on most of our boxes we were running Tectia SSH. We are switching to OpenSSH however have run into a snag. We have some boxes in a DMZ that need to communicate with internal boxes, and to do this we have a box in the middle that handles transferring files from one box to the other.

so for instance if box A wants to talk to box B, but there is a firewall in between, we have box C set up to do the transfer via:
scp A:/file B:/file

once we switched to OpenSSH this no longer worked. I thought it was a problem because we have mixed tectia and openssh, but it is broken everywhere...for boxes that have converted to openssh, using the -vvv option I see the error:

debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.
lost connection

for boxes that are still running tectia (however our transfer box is openssh) we see:

usage: scp1-compat-srv (-t | -f) [-qQaAprvBCL] [-S path-to-ssh] [-o ssh-options] [-P port] [-c cipher] [-i identity] f1 f2; or: scp1-compat-srv (-t | -f) [options] f1 ... fn directory
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 1.2 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 1


if I try and break it up, it works just fine, for instance:

scp A:/file file
scp file B:/file

this works fine, its just when I try to go to two remote sites at once that it fails.

Thoughts?

[Steven E. Protter]

Shalom,

My thoughts is you need to generate new keys and distribute them. Then this configuration should work.

ssh-keygen -t dsa

Permission and all that.

SEP

[Ken Penland_1]

if keys were the issue though, wouldnt it fail and prompt for a password when I go to the indiviudal servers? both servers work individually without a password.

[Tim Nelson]

Are we sure that by doing scp A:file B:file that scp is not trying to do a third party transfer, e.g. directy from A to B ?

If so, then A needs to connect and auth to B before this will work. You mentioned FW in the way between A and B.

So, you may have to break it up as you mentioned. A to C, then C to B.

Just as a question, if you paid for Tectia then why not use your investment and call them for support ?

[Ken Penland_1]

thanks Tim, that is exactly what it looks like it is doing, like it is going to system A and trying to put the file to B directly, which will not work. Breaking it up is the work around we have as an option, but it works with Tectia being the point C, and openSSH's man page states: "Copies between two remote hosts are also permitted." So it seems to me that there should be a way for it to work, does this fail for everyone then?

And yes, we do currently have support for Tectia, but it isnt tectia that is broken, but rather once we switched to OpenSSH, we are dropping Tectia because of even more severe security related bugs that they have failed to fix in over a year.

[OldSchool]

"debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.
lost connection"

ok...it seems that either openssh doesn't recognize the existing keys, or its looking in the wrong place or????

serverC is doing scp a:something to b:something....so as noted earlier, a must be able to login to b, b to a (probably) and c to both a and b. what happens if you ssh from a to b, or vice versa?

I'd suggest, as also noted previously, that you regen / redistribute keys.

Also, did you have an key agent running anywhere supplying passphrases?

[Tim Nelson]

Can you manually scp from A to B without C in the loop ?

Your intial post lead me to believe that you wanted an A to C then C to B soltion due to a FW between A and B.

[Suraj K Sankari]

Hi,

I think it will be the right option to generate new keys sent it to all server.

create id_rsa.pub key with ssh-keygen
cat id_rsa.pub >authorized_keys
and sent the authorized_keys file serve b and c /home/user/.ssh/.

then try

Suraj

[David de Beer]

Have a similar setup at work, openssh does not seem to work that way, it will login to machine A, then scp from That machine to machine B and won't act as a 'postoffice'.

Kinda the same as ssh A ssh B, will login to machine A, then ssh to machine B.

scp A:/tmp/david B:/tmp/david requires that B have A's key in ~/.ssh/authorized_keys

host key verification failed - are you using the same key after switching? Otherwise delete (uncomment) the key from the ~/.ssh/known_hosts file. Check host A for host C's key, and host B for host A's key.

[OldSchool]

".... setup at work, openssh does not seem to work that way, it will login to machine A, then scp from That machine to machine B and won't act as a 'postoffice'."

exactly. thats what is supposed to happen, and is as documented for OpenSSH.

As far as Tectia, perhaps it did copy from A to C and from C on to A (acting as a relay). You would have to refer to the Tectia docs or support to find out.
A cursory review of their site seems to indicate that Tectia has non-standard features that may have created this relay capability, depending on which products are installed / available.