Backup problems using ssh because of host identification to a NAT - SSH

This is a discussion on Backup problems using ssh because of host identification to a NAT - SSH ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Backup problems using ssh because of host identification to a NAT

  1. Backup problems using ssh because of host identification to a NAT

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

    All of this is using OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL
    0x0090701f on RedHat EL3.

    Thanks

  2. Re: Backup problems using ssh because of host identification to a NAT


    "Pham Nuwen" 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




  3. Re: Backup problems using ssh because of host identification to a NAT

    In article Pham Nuwen
    writes:
    >
    >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.


    This problem has been discussed here a number of times in the past, see
    e.g.
    http://groups.google.com/group/comp....a23d1dbedc9379
    for a solution.

    --Per Hedeland
    per@hedeland.org

+ Reply to Thread