|
Re: amrecover and ssh could not resolve hostname
2008-03-29 17:47:39
Dustin J. Mitchell wrote:
On Fri, Mar 28, 2008 at 5:57 PM, Oscar Ricardo Silva
<osilva AT scuff.cc.utexas DOT edu> wrote:
/usr/local/amanda25/sbin/amrecover -C dailytoo
AMRECOVER Version 2.5.2p1. Contacting server on amanda.tn.utexas.edu ...
[request failed: amanda.tn.utexas.edu: ssh could not resolve hostname]
...
It's not really an issue with resolving the hostname. DNS is setup correctly
and I can ssh from the client to the server and from the server to the backup.
While running amrecover I see no queries being sent to the servers listed in
resolv.conf. Even inserting the host into /etc/hosts doesn't help. I've
looked
through the list archives and someone ran into this problem in October 2006 but
have not seen any other mentions of it.
You're right that this isn't from ssh. The message should probably be
something like "ssh_security: could not resolve hostname". What's
happening is that the ssh security driver is trying to resolve the
hostname to its canonical name before passing it to 'ssh'. This is
done via a call to getaddrinfo with AI_CANONNAME set, which will
usually do a forward-and-reverse lookup to determine the actual name
of the host.
On a lark, I ran:
$ host amanda.tn.utexas.edu
amanda.tn.utexas.edu has address 172.16.124.162
Which is a leak of a private (RFC1918) address from a public DNS
server. I had been expecting it not to resolve for me, or alternately
to resolve to an IP in one of utexas's public netblocks, in which case
I could test the reverse DNS. Anyway, I expect that the given IP
isn't translating back to anything, which is causing the error.
Hopefully this is the hint you need to get this working. I'll make a
note to fix up the error message a bit.
Son of a .... (kicking self) ... I think I figured out the problem. It was a
combination of two things. I ran tcpdump on the client to see what it was doing
and saw a bunch of AAAA queries. Considering we're not running IPv6 I thought
it curious those queries were being made. I decided to recompile amanda without
IPv6 support and then I got a different error, this time something about
Permission Denied, blah, blah, blah. That's when I realized I had added the
client's key incorrectly to the server's authorized_keys file. It wasn't the
key issue alone but recompiling seem to have fixed the problem.
Now I'm able to run amrecover and communicate with the server.
Oscar
|
|
|
