Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

If i ssh to my remote OpenWrt router ["via DynDNS"]

  1. I get the message

    @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
    
  2. Ok, i delete the old line in ~/.ssh/known_hosts, add the new one

  3. But my password wasn't accepted (even though I copy+pasted the good password)

  4. But: if someone reboots the remote router it says:

    @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
    
  5. Ok, again, I delete the line in ~/.ssh/known_hosts, add the new one [the old one??], and presto! I can log in!

Why?

Is this because a dyndns update failed, and I'm trying to log in to the wrong IP? And if the router is rebooted, the dyndns IP will be updated, so that the IP is correct, and I can log in? Is that why it says “host identification failed”?

It happened for the 3rd time... I don't know what's exactly is going on.

share|improve this question
    
Please make a bit more effort formatting your posts. This one was barely readable. –  Gilles Mar 22 '11 at 22:19

2 Answers 2

up vote 1 down vote accepted

Your theory is basically right, in that your issue is caused by dyndns. More precisely, your issue is caused by having a dynamic IP address; dyndns makes things easier but not completely seamless.

When your router receives a new dynamic IP address (because it rebooted, or because your provider disconnected you for any reason¹) [step 1, step 4], you need to log in to the new IP. When your router connects, it sends a message to your dyndns provider notifying it of the address change. When you run ssh johnny8888.dyndns.example.com, the ssh client looks up the IP address corresponding to johnny8888.dyndns.example.com.

DNS information takes some time to propagate, because it is heavily cached. For typical dyndns use, the delay is a few minutes. So if you try to connect soon after an IP address change, you might still reach the old IP address [step 3], which is now attributed to a different machine. If this machine runs an ssh server, you get the remote host identification changed warning.

Add CheckHostIP No to your ~/.ssh/config, under the section for your router. Then ssh won't check the key associated with your IP address (which is useless since you have a dynamic address), only the key associated with your host name (which won't change).

Note that most of the time, you will not get the remote host identification change warning. You only get it if you try to log into somebody else's machine, or tried to in the past. (Your tries would be accidental, when you were unlucky to try connecting after an IP address change and before the DNS update had propagated.)

¹ Many ISPs disconnect each client every day or every few days, because this facilitates their load balancing. You can reconnect instantly, but may get a different IP address.

share|improve this answer
    
I don't agree with adding "CheckHostIP No" to his config. He really doesn't want to even attempt to authenticate to a host if the keys of the SSH server he's connecting to doesn't match. If he sees a warning, he should abort the login attempt right away! –  Yves Junqueira Mar 22 '11 at 22:24
1  
@Yves: No, I maintain that in this case CheckHostIP No improves security. As you can see, the asker is now simply ignoring the warning. It would be better to reduce the number of spurious warnings. Ssh will check the key associated with the host name anyway, so the additional IP check is not useful. –  Gilles Mar 22 '11 at 22:30

Yes, I believe you answered your own question. See Gilles' answer above.

But most importantly, I'd recommend making your dyndns updates run more frequently. If possible, it would be ideal that a dyndns update run as soon your IP changes but I'm not sure if openwrt provides this functionality.

share|improve this answer
1  
Openwrt does support immediate dyndns updates (at least my variant does). The problem is the delay in DNS propagation, and that's imposed by the dyndns provider (and even if the dyndns provider was willing to accept a ridiculously low TTL, DNS caches in the way might not). –  Gilles Mar 22 '11 at 22:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.