I ran into the exact same problem and found a thread about a Mac mini having DNS issues on Apple's Discussions extremely helpful.
The crux of the issue: mDNSResponder seems to occasionally change the order of the DNS servers it queries and so if it queries your ISP's DNS servers first it won't get a proper record (or if you're using split DNS you'll get your public IP).
The best fix for this is to ensure (as you did) that only the required DNS servers are listed in your DNS settings. This may require removing the ISP DNS servers from your DHCP (as I had to do as well - all requests are forwarded through the local DNS server anyway).
The reason utilities like dig and nslookup will succeed as normal is they are using BIND and /etc/resolv.conf directly unlike the rest of the operating system.
For reference in Snow Leopard the DNS cache is now stored by mDNSResponder and in order to clear it you need to restart the process using sudo killall -HUP mDNSResponder. You can get more info (logging, dump internal state, etc.) by using different flags to the killall command.
"sudo killall -USR1 mDNSResponder" to enable operation logging.
"sudo killall -USR2 mDNSResponder" to enable packet logging.
"sudo killall -HUP mDNSResponder" to clear the DNS cache.
"sudo killall -INFO mDNSResponder" to dump mDNSRepsonder's internal state.
Source: Snoop Dogg on that same thread.
Don't use a password. Generate a passphrase-less SSH key and push it to your VM.
If you already have an SSH key, you can skip this step…
Just hit Enter for the key and both passphrases:
$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
Copy your keys to the target server:
$ ssh-copy-id id@server
id@server's password:
Now try logging into the machine, with ssh 'id@server', and check-in:
.ssh/authorized_keys
Note: If you don't have .ssh dir and authorized_keys file, you need to create it first
to make sure we haven’t added extra keys that you weren’t expecting.
Finally, check to log in…
$ ssh id@server
id@server:~$
You may also want to look into using ssh-agent if you want to try keeping your keys protected with a passphrase.
Best Answer
The
knife-sshplugin uses theipaddressattribute on each node. You might like to check the value of this attribute on your nodes. If it's incorrect, nonexistent, or unreachable from where you are running knife, you will get connection errors like the above.