6

from yesterday I have noticed that I can't connect via SSH to my OS X's SSH server anymore using the following command:

User-MBP:~ user$ ssh user@user-mbp

user is the user on the server, user-mbp is the name of my machine, as specified here in System Preferences > Sharing:

enter image description here

I have the following written under Remote Login: On:

To log in to this computer remotely, type "user@user-mbp".

But user-mbp seems to be unreachable, even ping doens't respond:

User-MBP:~ user$ ping user-mbp
ping: cannot resolve user-mbp: Unknown host

It is strange because I was able to connect typing user-mbp before, I remember. Also OS X is telling me to use that hostname for the SSH connection in System Preferences > Sharing, as I told.

I thought maybe something messed up the DNSResolver, even if I didn't touch anything, so I tried the following commands taken from the post DNS not resolving on Mac OS X:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

But they didn't help, so I am writing this post. I have Yosemite 10.10.4 installed. Also, recently I have installed Little Snitch, now I have uninstalled it, maybe it's because of it?

What can I do to re-enable my hostname and make it reachable again? (I know I can connect to the machine using the local address of the server instead, but I do want to use user-mbp cause the LAN IP is assigned dinamically).

Thanks for the attention!

Edit 1:

Still didn't resolve. I have also tried to restore my system to a previous state when everything worked (I booted the system in recovery mode (Cmd+R) and restored from a Time Machine backup (the SSH server which is supposed to be user-mbp runs on a MacBook Pro)), but it doesn't work anymore too! Now I start thinking that maybe it is a problem of the router I am using? Could it be possible?

Edit 2:

Here is the output of dig user-mbp.local issued on the client side:

; <<>> DiG 9.8.3-P1 <<>> user-mbp.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21043
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;user-mbp.local.        IN  A

;; AUTHORITY SECTION:
.           10800   IN  SOA a.root-servers.net. nstld.verisign-grs.com. 2015072802 1800 900 604800 86400

;; Query time: 169 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Jul 28 23:53:27 2015
;; MSG SIZE  rcvd: 109

There's a NXDOMAIN, so the hostname seems to not exist...

Edit 3:

Here is the content of resolve.conf:

#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
domain Home
nameserver 192.168.1.1

daniel Azuelos advised me to remove the line "domain Home" when we were chatting but it seems that whenever you remove that line, it reappears automatically...

Edit 4:

Here are the commands klanomath wrote about:

user-mbp:~ user$ dig _services._dns-sd._udp.local ptr @192.168.1.2 -p 5353

; <<>> DiG 9.8.3-P1 <<>> _services._dns-sd._udp.local ptr @192.168.1.2 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48322
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_services._dns-sd._udp.local.  IN  PTR

;; ANSWER SECTION:
_services._dns-sd._udp.local. 10 IN PTR _ssh._tcp.local.
_services._dns-sd._udp.local. 10 IN PTR _sftp-ssh._tcp.local.

;; Query time: 1 msec
;; SERVER: 192.168.1.2#5353(192.168.1.2)
;; WHEN: Wed Jul 29 21:44:37 2015
;; MSG SIZE  rcvd: 94

192.168.1.2 is the IP of the SSH server.

user-mbp:~ user$ dns-sd -B _ssh._tcp local
Browsing for _ssh._tcp.local
DATE: ---Wed 29 Jul 2015---
21:46:39.034  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
21:46:39.035  Add        2   6 local.               _ssh._tcp.           User’s MacBook Pro

I guess Bonjour is set up properly, isn't it?

However, the temporarily fix dns-sd -R user-mbp _ssh._tcp. local 22 seems to not working:

user-mbp:~ user$ dns-sd -R user-mbp _ssh._tcp. local 22
Registering Service user-mbp._ssh._tcp..local port 22
DATE: ---Wed 29 Jul 2015---
21:51:47.238  ...STARTING...
21:51:48.048  Got a reply for service user-mbp._ssh._tcp.local.: Name now registered and active

^C
user-mbp:~ user$ ssh user@user-mbp
ssh: Could not resolve hostname user-mbp: nodename nor servname provided, or not known
  • Please insert in your question: what you changed on your Mac yesterday. Clarify what do you mean by "restore my system to a previous state when everything worked"? Add the output of Terminal command hostname. – dan Jul 28 '15 at 20:55
  • hostname returns user-mbp, what I mean with when everything works is that I was able to run ssh user@user-mbp and it worked. That was just before I installed Little Snitch. Even here a funny thing, I have restored the system to that state (when everything worked) but it resulted to be a state when "everything was supposing to work", cause still doesn't. I hope I was clear. What could it be? – user3019105 Jul 28 '15 at 21:03
  • What did you do to "restore the system to that state"? – dan Jul 28 '15 at 21:07
  • I booted the system in recovery mode (Cmd+R) and restored from a Time Machine backup (the SSH server which is supposed to be user-mbp runs on a MacBook Pro) – user3019105 Jul 28 '15 at 21:16
  • Add this meaning in your question (improve it) because comments aren't here to stay just to help improve the real question. – dan Jul 28 '15 at 21:21
  • Which machine in your network is 192.168.1.1? – dan Jul 28 '15 at 21:25
  • It's the router – user3019105 Jul 28 '15 at 21:28
  • My guess is that either user-mbp isn’t broadcasting its hostname, or your router isn’t updating the DNS entry with the correct hostname. I’m afraid I’m not sure how to solve either, but might be useful to research around those ideas? – forquare Jul 28 '15 at 21:30
  • I have checked the router's setting and I found a DHCP record where the IP of the server on the LAN has the hostname user-mbp, can I force a broadcast of the hostname from the server? – user3019105 Jul 28 '15 at 21:42
  • Info from user3019105 to insert in the original question: there is a ghost searchdomain Home in the /etc/resolv.conf of user-mbp. – dan Jul 28 '15 at 22:36
  • Have you tried to ping user-mbp.local.? (Note the final dot in .local.!) – Kurt Pfeifle May 20 '16 at 21:42
  • @KurtPfeifle ping user-mbp.local works, and I can SSH into it, it's my machine. But why ping user-mbp used to work and now doesn't anymore? – user3019105 May 21 '16 at 06:59
  • If I knew, what (you?) changed in your network and your local system, I could answer this... – Kurt Pfeifle May 21 '16 at 07:54
  • What should I check? – user3019105 May 22 '16 at 10:52

2 Answers2

4

In your local network setup all services heavily rely on a properly working Bonjour service (dns-sd), because you have no local domain name service.

To detect propagated dns-sd services of a host use the following command (please replace "ip-address" below by the ip-address of your Mac named user-mbp; use ifconfig -a on that Mac to get it):

dig _services._dns-sd._udp.local ptr @ip-address -p 5353

The dig output of a well working Bonjour service of a host looks like this :

; <<>> DiG 9.8.5-P1 <<>> _services._dns-sd._udp.local ptr @192.168.177.9 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37167
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_services._dns-sd._udp.local.  IN  PTR

;; ANSWER SECTION:
_services._dns-sd._udp.local. 10 IN PTR _ssh._tcp.local.
_services._dns-sd._udp.local. 10 IN PTR _sftp-ssh._tcp.local.

;; Query time: 4 msec
;; SERVER: 192.168.177.9#5353(192.168.177.9)
;; WHEN: Wed Jul 29 02:00:16 CEST 2015
;; MSG SIZE  rcvd: 94

As you can see I have only one service enabled: ssh (+ sftp-ssh)

To detect and get the names of all local hosts providing a special service (in my example ssh, check for more services here) use:

dns-sd -B _ssh._tcp local

If you want to skip detection after a while just enter ctrlC.

My output:

Browsing for _ssh._tcp.local
Timestamp     A/R Flags if Domain     Service Type              Instance Name
2:51:05.778  Add     2  4 local.      _ssh._tcp.                MyMac

If you don't get a similar results, your dns-sd is broken and all other tools like ping, nslookup (and consequently all tools relying on that like ssh) will not work in your namespace since you don't have a local DNS-server as alternative. The DNS-server in your router (usually a DNS caching only server) as well as the DNS-servers of your ISP and the superior root servers know nothing about your local network and namespace.

To temporarily fix this (check man dns-sd) the following - executed on user-mbp - should work:

dns-sd -R user-mbp _ssh._tcp. local 22

You may even propagate a user and a password (I didn't test that and i don't know how that should work or how secure it is):

dns-sd -R user-mbp _ssh._tcp. local 22 u=<username> p=<password>

To permanently fix this, first update to 10.10.4 with the Combo Updater, check the search domain settings of your router's DHCP-server, delete all caches (e.g. with Onyx or Yosemite Cache Cleaner), use a *.local name (e.g. user-mbp.local instead of user-mbp) where appropriate (e.g. Sharing Prefs, shell), don't use "local" as search domain in your network prefs and then repair your Bonjour service with several answers provided here at stackexchange or if nothing helps alternatively set-up dnsmasq.


P.S. You should always use the full Bonjour-name (e.g. user-mbp.local) to address a local host/device using dns-sd. The reason to do so is the following:

A lot of routers provide a search domain for easier configuration if on-board DHCP is enabled or propagate an ISP connection specific domain name. Examples: The default search domain of my Fritz!Box is "fritz.box", the default search domain for some DLink routers seems to be "local".

If your Mac uses DHCP to assign an IP, the default search domain will be applied also. In my case pinging "myothermac" automatically appends ".fritz.box" and the host myothermac.fritz.box will be probed. If you don't have a DNS-server in your local network with a primary zone "fritz.box." containing a host with the name "myothermac", the command ping myothermac will fail. Unlike to ping myothermac.local, which should work if Bonjour is set-up properly.

Since most routers aren't Bonjour-aware, change any default search domain settings containing "*.local" or "local" or apparently some DLink routers with an empty search domain to something else like "happy.home" to avoid any conflicts with the Bonjour service.

klanomath
  • 66,391
  • 9
  • 130
  • 201
  • Nice technical answer! – dan Jul 29 '15 at 08:21
  • @klanomath Please, check my Edit 4, I have posted the output of the commands you told me to use. Also, OS X is already at version 10.10.4, so I guess there aren't any updates at the moment – user3019105 Jul 29 '15 at 18:56
  • @user3019105 your edit 4 may be miseading: you ran the advised dig command from the host user-mbp (running the ssh-server?) against itself (user-mbp = 192.168.1.2 = User's MacBook Pro)? If so try to run dig from a 2nd Mac or Linux machine against 192.168.1.2. Otherwise the dig result looks good and it's obvious that the temp fix didn't help because there was nothing to fix regarding dns-sd on 192.168.1.2. – klanomath Jul 29 '15 at 19:45
3

Append .local to your machine name.

If that works, and you don't want to have to do that, in System Preferences > Network > (Interface) > Advanced > DNS > Search Domains, add ".local".

user3439894
  • 58,676
Harv
  • 6,520
  • Thanks for the response, I have tried user-mbp.local but I still get ssh: Could not resolve hostname, the funny thing is that I was able to connect through user-mbp before... Could it be a problem of the router? Anything else I can do? – user3019105 Jul 28 '15 at 20:45
  • On the server end, type "hostname". What comes up? – Harv Jul 28 '15 at 20:46
  • user-mbp:~ user$ hostname gives user-mbp as it should. In fact, the hostname on the server is user-mbp, even scutil --get HostName returns user-mbp. It is really strange, isn't it? – user3019105 Jul 28 '15 at 20:50
  • Do a dig user-mbp.local from the client. I'm thinking DNS issue. Can you ping the IP? – Harv Jul 28 '15 at 20:51
  • I have posted the output in an edit of the original post. Yes I can ping the IP of the server on the LAN – user3019105 Jul 28 '15 at 20:58
  • DNS issue. Check your DNS server on the client, disable firewalls on both ends, make sure littlesnitch LaunchDaemon is unloaded, check DNS settings in the router. – Harv Jul 28 '15 at 21:00
  • Yes, I thought the same thing, DNS issue, but: OS X's Firewall for incoming connections is disabled, Little Snitch is not installed anymore, because I have restored the system from a Time Machine back up which where Little Snitch wasn't installed (I noticed this problem only after installing it) and I have logged in to the router settings, it is a router given to me by the provider, there's not so much about the DNS conf, what should I search for, I can tell that user-mbp is the hostname of the DHCP IP of the server. – user3019105 Jul 28 '15 at 21:14
  • About the DNS on the client. If I type nslookup user-mbp I get a NXDOMAIN, but if I type nslookup xxx.xxx.xxx.xxx where xxx.x... is the IP of the server, on the LAN I get name = User-MBP. – user3019105 Jul 28 '15 at 21:20
  • @Harv: I agree with you, this is only a DNS issue. The problem is local to the Mac. – dan Jul 28 '15 at 22:41
  • 1
    The super-correct way would be to say "Add .local. to your machine name." (Note the final dot, ., which tells all programs that this is the root node and makes sure it will not look for mbp-user.local.other.search.domain. but only for mbp-user.local.). – Kurt Pfeifle May 20 '16 at 21:40
  • On Windows, domains for ssh require an extension. Any extension will do. Plus needed to update C:\Windows\System32\drivers\etc\hosts with new host name including extension. – BruceJo Jan 29 '22 at 16:54