Re: Backup problems using ssh because of host identification to a NAT
From: Nico Kadel-Garcia (nkadel_at_comcast.net)
Date: 11/22/05
- Next message: Kyler Laird: "Re: Port Forwarding over Unreliable Connections"
- Previous message: Nico Kadel-Garcia: "Re: Unable to authenticate after upgrading"
- In reply to: Pham Nuwen: "Backup problems using ssh because of host identification to a NAT"
- Next in thread: Per Hedeland: "Re: Backup problems using ssh because of host identification to a NAT"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 22 Nov 2005 11:44:10 -0500
"Pham Nuwen" <none@none.com> wrote in message
news:XCHgf.126942$S4.107387@edtnps84...
> Hello,
>
> Well I've scoured the documentation, the web, and this newsgroup, and
> haven't been able to find the answer to what bone headed thing I'm doing
> wrong.
>
> The situation in a nutshell is that I have a server (let's call it
> something original like 'A' 8-) ) in location A, and server B & C in
> location B behind a firewall. The fact that what I'm trying to do is
> ultimately do some rsyncs from A to B&C, is I think neither here nor
> there, I'm hung up on SSH authentication issues.
>
> A badly done diagram:
>
>
> [A]--[firewall]----[Private Line]----[firewall]---[B]
> |--[C]
>
> Because B & C are behind a single IP they are running on different ports.
> (1022 & 2022 respectively) The keys are all setup correctly, and I have
> tested that they work individually to allow A to connect to either B or C.
> The problem is the known_hosts file. If I add B then I can no longer
> connect to C, because it complains about the potential MiM attack. If I
> add C to known_hosts then it complains if I try to connect to B. I played
> with StrictHostKeyChecking in the ssh_config file, but even set to no, it
> doesn't do what I need.
>
> How do I set it up so that ssh will either let both hosts be in the
> known_hosts file, or that it will still connect, even with the potential
> MiM attack (I don't care if it warns about it, but I want it to go ahead
> and connect anyways).
There are a dozen ways. The easiest is to copy the host keys from B to C,
which is somewhat offensive to folks who believe that hostkey verification
is useful and important, but it can be done in seconds.
Another dirty trick, if the material being synced to B and C matches, is to
first sync to B, then send a command to B to sync between B and C directly.
That takes a lot of the traffic off of the connection between C and the
outside world and may be a lot faster.
> All of this is using OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL
> 0x0090701f on RedHat EL3.
>
> Thanks
- Next message: Kyler Laird: "Re: Port Forwarding over Unreliable Connections"
- Previous message: Nico Kadel-Garcia: "Re: Unable to authenticate after upgrading"
- In reply to: Pham Nuwen: "Backup problems using ssh because of host identification to a NAT"
- Next in thread: Per Hedeland: "Re: Backup problems using ssh because of host identification to a NAT"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]