Andrew Wood wrote: > if I try and SSH into one of our internal servers > (which works from other clients) I get: > > and...@debian:/$ ssh a...@sambatest1.wrinehillvilla.local > ssh: Could not resolve hostname sambatest1.wrinehillvilla.local: > Name or service not known > > but if I do a DNS query it resolves:
I don't have any good suggestions but I would look in your
~/.ssh/config to see if there are any options set for this host that
would in some way affect things. I would run 'ssh -v' and look at the
output to see if there are any clues there.
As a workaround I would install connect-proxy and set up a
ProxyCommand.
$ sudo apt-get install connect-proxy
Then verify that connect will work and resolve the hostname. (Use
control-c to interrupt it to exit the program.)
$ connect sambatest1.wrinehillvilla.local 22
Then create a stanza in ~/.ssh/config similar to:
Host *.local
ProxyCommand connect %h %p
Then when you ssh to any host in that pseudo domain it will use the
connect program instead of the built in network code. This won't
necessarily tell you what is happening but may work around whatever
situation you find yourself in.
At this point a lot of people will jump in and suggest using 'nc'
(netcat) intead of 'connect'. But after using 'nc' a lot I always
found problems such as a lot of orphaned nc processes that never
exited or nc processes that were orphaned and consuming 100% cpu time.
It seems that nc by design is ignoring end-of-file in some cases and
for whatever reason I often hit those cases and would end up with ten
or twenty nc processes left behind. Using 'connect' avoided all of
those issues and I now highly recommend 'connect' over 'nc' for
exactly these types of applications.
Bob
signature.asc
Description: Digital signature
