Не можете використовувати ім’я машини для входу за допомогою SSH більше на Yosemite, як це виправити?


6

з вчорашнього дня я помітив, що більше не можу підключитися через SSH до SSH-сервера моєї ОС X за допомогою наступної команди:

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

user - це користувач на сервері, user-mbp - це ім'я моєї машини, як зазначено тут у System Preferences > Sharing:

введіть тут опис зображення

У мене написано наступне Remote Login: On:

Щоб увійти на цей комп'ютер віддалено, введіть " user @ user-mbp ".

Але це user-mbpздається недосяжним, навіть пінг не відповідає:

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

Це дивно, бо я міг підключити введення тексту user-mbpраніше, пам’ятаю. Крім того, OS X каже мені використовувати це ім'я хоста для з'єднання SSH System Preferences > Sharing, як я вже сказав.

Я подумав, що, можливо, щось зіпсувало DNSResolver, навіть якщо я нічого не торкнувся, тому я спробував такі команди, взяті з поста DNS, що не вирішуються на 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

Але вони не допомогли, тому я пишу цей пост. У мене встановлено Yosemite 10.10.4. Також нещодавно я встановив Little Snitch, тепер я його видалив, можливо, це через нього?

Що я можу зробити, щоб знову ввімкнути своє ім’я хоста та зробити його знову доступним? (Я знаю, що я можу підключитися до машини за допомогою локальної адреси сервера, але я хочу використовувати, user-mbpтому що IP-адреса локальної мережі призначається динамічно).

Дякую за увагу!

Редагувати 1:

Ще не вирішили. Я також намагався відновити свою систему до попереднього стану, коли все працювало (я завантажував систему в режимі відновлення (Cmd + R) і відновлювався з резервної копії Time Machine (сервер SSH, який повинен бути користувачем-mbp, працює на MacBook Pro)), але він також не працює! Тепер я починаю думати, що, можливо, це проблема маршрутизатора, яким я користуюся? Чи можливо це було можливо?

Редагувати 2 :

Ось вихід dig user-mbp.localвиданих на стороні клієнта:

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

Існує NXDOMAIN, тому ім'я хоста, здається, не існує ...

Редагувати 3:

Ось вміст резолюції.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

Даніель Азуелос порадив мені видалити рядок "Домашній домен", коли ми спілкувалися в чаті, але, здається, що кожного разу, коли ви видалите цю лінію, вона знову з'являється автоматично ...

Редагувати 4 :

Ось команди, про які писав кланомат :

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 - IP-адреса сервера SSH.

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

Я думаю, Бонжур налаштований належним чином, чи не так?

Однак тимчасове виправлення, dns-sd -R user-mbp _ssh._tcp. local 22здається, не працює:

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

Будь ласка, введіть у своєму запитанні: що ви змінили на своєму Mac вчора. Поясніть, що ви маєте на увазі під "відновленням моєї системи до попереднього стану, коли все працювало"? Додайте вихід Terminalкоманди hostname.
дан

hostnameповертається user-mbp, я маю на увазі when everything worksте, що я зміг бігати, ssh user@user-mbpі це спрацювало. Це було якраз до того, як я встановив Маленький сніг. Навіть тут дивна річ, я відновив систему до такого стану (коли все працювало), але це призвело до стану, коли "все гадало, що працює", бо все одно це не відбувається. Сподіваюся, мені було зрозуміло. Що це може бути?
користувач3019105

Що ви зробили, щоб "відновити систему до такого стану"?
дан

Я завантажив систему в режимі відновлення (Cmd + R) і відновив з резервної копії Time Machine (SSH-сервер, який повинен user-mbpпрацювати на MacBook Pro)
user3019105

Додайте це значення у своє запитання (вдосконаліть його), оскільки коментарі не для того, щоб допомогти покращити справжнє запитання.
дан

Відповіді:


3

У налаштуваннях локальної мережі всі сервіси в значній мірі покладаються на належну роботу служби Bonjour (dns-sd), оскільки у вас немає служби локальних доменних імен.

Для виявлення розповсюджених служб dns-sd хоста скористайтеся наступною командою (будь ласка, замініть "ip-адресу" нижче ip-адресою вашого Mac на ім'я user-mbp; використовуйте ifconfig -aна цьому Mac, щоб отримати його):

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

Вихід копання добре працюючої послуги Bonjour хоста виглядає так:

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

Як ви бачите, у мене включена лише одна послуга: ssh (+ sftp-ssh)

Щоб виявити і отримати імена всіх місцевих хостів, які надають спеціальну послугу (у моєму прикладі ssh, перевірте, чи немає тут більше послуг ), використовуйте:

dns-sd -B _ssh._tcp local

Якщо ви хочете пропустити виявлення через деякий час, просто введіть ctrlC.

Мій вихід:

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

Якщо ви не отримаєте подібних результатів, ваш dns-sd порушений, а всі інші інструменти, такі як ping, nslookup (і, отже, всі інструменти, на які покладається ssh), не працюватимуть у вашій області імен, оскільки у вас немає локального DNS -сервер як альтернатива. DNS-сервер у вашому маршрутизаторі (як правило, DNS-сервер кешування), а також DNS-сервери вашого провайдера і вищі кореневі сервери нічого не знають про вашу локальну мережу та простір імен.

Щоб тимчасово виправити це (перевірте man dns-sd), слід працювати наступне - виконане на user-mbp:

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

Ви навіть можете поширити користувача та пароль (я цього не перевіряв, і я не знаю, як це має працювати чи наскільки це безпечно):

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

Щоб назавжди виправити це, спочатку оновіть до 10.10.4 за допомогою Combo Updater, перевірте налаштування пошукового домену DHCP-сервера вашого маршрутизатора, видаліть усі кеші (наприклад, за допомогою Онікс або Yosemite Cache Cleaner), використовуйте ім'я * .local (наприклад, користувач -mbp.local замість user-mbp), де це доречно (наприклад, обмін Prefs, оболонка), не використовуйте "local" як пошуковий домен у ваших мережних префіксах, а потім не ремонтуйте свою послугу Bonjour з кількома відповідями, наданими тут на stackexchange або якщо нічого допомагає альтернативно налаштувати dnsmasq .


PS Ви завжди повинні використовувати повне ім'я Bonjour (наприклад, user-mbp.local) для адреси локального хоста / пристрою за допомогою dns-sd. Причиною цього є:

Багато маршрутизаторів надають пошуковий домен для полегшення конфігурації, якщо вбудований DHCP включений або розповсюджується конкретне ім'я домену, пов'язане з провайдером. Приклади: Домен пошуку за замовчуванням мого Fritz! Box - це "fritz.box", пошуковий домен за замовчуванням для деяких маршрутизаторів DLink, здається, "локальний".

Якщо ваш Mac використовує DHCP для призначення IP-адреси, також буде застосовано домен пошуку за замовчуванням. У моєму випадку pinging "myothermac" автоматично додає ".fritz.box", і хост myothermac.fritz.box буде досліджений. Якщо у вашій локальній мережі немає DNS-сервера з первинною зоною "fritz.box." що містить хост з назвою "myothermac", команда ping myothermacне вдасться. На відміну від того ping myothermac.local, що має працювати, якщо Bonjour налаштований належним чином.

Оскільки більшість маршрутизаторів не знають Bonjour, змініть налаштування пошукового домену за замовчуванням, що містять "* .local" або "local" або, мабуть, деякі маршрутизатори DLink з порожнім пошуковим доменом на щось інше, наприклад "happy.home", щоб уникнути конфліктів із послуга Bonjour.


Приємна технічна відповідь!
дан

@klanomath Будь ласка, перевірте мою редакцію 4, я опублікував вихід команд, які ви мені сказали використовувати. Крім того, OS X вже є у версії 10.10.4, тому, мабуть, оновлень наразі немає
user3019105

@ user3019105 ваша редакція 4 може бути помилковою: ви запустили рекомендовану команду dig від хостового користувача-mbp (запуск ssh-сервера?) проти себе (user-mbp = 192.168.1.2 = користувач MacBook Pro)? Якщо так, спробуйте запустити копати з другої машини Mac або Linux проти 192.168.1.2. Інакше результат копання виглядає добре, і очевидно, що виправлення тимчасового режиму не допомогло, оскільки нічого не виправлено щодо dns-sd на 192.168.1.2.
кланомат

2

Додайте .local до назви машини.

Якщо це працює, і вам не потрібно цього робити, в системних налаштуваннях> Мережа> (Інтерфейс)> Додатково> DNS> Пошук доменів, додайте ".local".


Дякую за відповідь, я спробував, user-mbp.localале все одно отримую ssh: Could not resolve hostname, найсмішніше, що я зміг підключитися user-mbpраніше ... Чи може це бути проблема маршрутизатора? Що ще я можу зробити?
користувач3019105

На кінці сервера введіть "ім'я хоста". Що виходить?
Харв

user-mbp:~ user$ hostnameдає user-mbp як слід. Насправді ім'я хоста на сервері є user-mbp, навіть scutil --get HostNameповертає user-mbp . Це дійсно дивно, чи не так?
користувач3019105

Робіть копати user-mbp.local від клієнта. Я думаю, що проблема DNS. Ви можете пінг IP?
Харв

1
Супер правильним способом було б сказати "Додати .local.до імені машини". (Зверніть увагу на заключну крапку, .яка повідомляє всім програмам, що це кореневий вузол, і гарантує, що він буде шукати не mbp-user.local.other.search.domain.лише, а лише mbp-user.local.).
Курт Пфайфл
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.