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. – daniel Azuelos 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"? – daniel Azuelos 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. – daniel Azuelos Jul 28 '15 at 21:21

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.

  • Nice technical answer! – daniel Azuelos Jul 29 '15 at 8: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

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".

  • 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
  • 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

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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