6 votos

Ya no se puede usar el nombre de la máquina para iniciar sesión con SSH en Yosemite, ¿cómo solucionarlo?

Desde ayer he notado que ya no puedo conectarme vía SSH al servidor SSH de mi OS X usando el siguiente comando:

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

usuario es el usuario en el servidor, usuario-mbp es el nombre de mi máquina, como se especifica aquí en System Preferences > Sharing :

enter image description here

Tengo lo siguiente escrito en Remote Login: On :

Para entrar en este ordenador de forma remota, escriba " usuario@usuario-mbp ".

Pero user-mbp parece ser inalcanzable, incluso el ping no responde:

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

Es extraño porque pude conectarme escribiendo user-mbp antes, lo recuerdo. También OS X me dice que use ese nombre de host para la conexión SSH en System Preferences > Sharing como le dije.

He pensado que quizás algo ha estropeado el DNSResolver, aunque no haya tocado nada, así que he probado los siguientes comandos sacados del post El DNS no se resuelve en 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

Pero no ayudaron, así que estoy escribiendo este post. Tengo instalado Yosemite 10.10.4. Además, recientemente he instalado Little Snitch, ahora lo he desinstalado, ¿quizás sea por eso?

¿Qué puedo hacer para volver a habilitar mi nombre de host y hacerlo accesible de nuevo? (Sé que puedo conectarme a la máquina usando la dirección local del servidor, pero quiero usar user-mbp porque la IP de la LAN se asigna dinámicamente).

Gracias por la atención.

Editar 1:

Sigue sin resolverse. También he intentado restaurar mi sistema a un estado anterior en el que todo funcionaba (he arrancado el sistema en modo de recuperación (Cmd+R) y he restaurado desde una copia de seguridad de Time Machine (el servidor SSH que se supone que es usuario-mbp funciona en un MacBook Pro)), ¡pero tampoco funciona ya! Ahora empiezo a pensar que tal vez es un problema del router que estoy usando? ¿Podría ser posible?

Edición 2 :

Esta es la salida de dig user-mbp.local emitido en el lado del cliente:

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

Hay un NXDOMAIN, por lo que el nombre de host parece no existir...

Edita 3:

Este es el contenido de 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 me aconsejó quitar la línea "domain Home" cuando estuvimos chateando pero parece que siempre que quitas esa línea, vuelve a aparecer automáticamente...

Edición 4 :

Estos son los comandos klanomath escribió sobre:

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 es la IP del servidor 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

Supongo que Bonjour está bien configurado, ¿no?

Sin embargo, el arreglo temporal dns-sd -R user-mbp _ssh._tcp. local 22 parece que no funciona:

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

0 votos

Por favor, inserte en su pregunta: lo que ha cambiado en su Mac ayer. Aclare qué quiere decir con "restaurar mi sistema a un estado anterior cuando todo funcionaba". Añade la salida de Terminal comando hostname .

0 votos

hostname devuelve user-mbp Lo que quiero decir con when everything works es que pude ejecutar ssh user@user-mbp y funcionó. Eso fue justo antes de instalar Little Snitch. Incluso aquí una cosa curiosa, he restaurado el sistema a ese estado (cuando todo funcionaba) pero resultó ser un estado cuando "se suponía que todo funcionaba", porque todavía no lo hace. Espero haber sido claro. ¿Qué puede ser?

0 votos

¿Qué hiciste para "restaurar el sistema a ese estado"?

4voto

klanomath Puntos 19587

En la configuración de su red local, todos los servicios dependen en gran medida de un servicio Bonjour que funcione correctamente (dns-sd), ya que no tiene un servicio de nombres de dominio local.

Para detectar la propagación de los servicios dns-sd de un host utilice el siguiente comando (por favor, sustituya "dirección-ip" por la dirección-ip de su Mac llamada user-mbp; utilice ifconfig -a en ese Mac para conseguirlo):

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

La salida de la excavación de un servicio Bonjour de un host que funciona bien tiene este aspecto:

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

Como puedes ver sólo tengo un servicio habilitado: ssh (+ sftp-ssh)

Para detectar y obtener los nombres de todos los hosts locales que proporcionan un servicio especial (en mi ejemplo ssh, comprueba más servicios aquí ):

dns-sd -B _ssh._tcp local

Si quieres saltarte la detección después de un tiempo sólo tienes que introducir ctrlC .

Mi salida:

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

Si no obtienes resultados similares, tu dns-sd está roto y todas las demás herramientas como ping, nslookup (y en consecuencia todas las herramientas que dependen de eso como ssh) no funcionan en su espacio de nombres ya que no tiene un servidor DNS local como alternativa. El servidor DNS de su router (normalmente un servidor de caché DNS solamente) así como los servidores DNS de su ISP y los servidores Root superiores no saben nada de su red local y espacio de nombres.

Para solucionar esto temporalmente (compruebe man dns-sd ) lo siguiente - ejecutado en user-mbp - debería funcionar:

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

Incluso puede propagar un usuario y una contraseña (no he probado eso y no sé cómo debe funcionar o cuán seguro es):

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

Para solucionar esto de forma permanente, primero actualice a 10.10.4 con el Combo Updater, compruebe la configuración del dominio de búsqueda del servidor DHCP de su router, borre todas las cachés (por ejemplo, con Onyx o el limpiador de caché de Yosemite), utilice un nombre *.local (por ejemplo, user-mbp.local en lugar de user-mbp) donde sea apropiado (por ejemplo, Sharing Prefs, shell), no utilice "local" como dominio de búsqueda en sus preferencias de red y luego repare su servicio Bonjour con varias respuestas proporcionadas aquí en stackexchange o si nada ayuda alternativamente configure dnsmasq .


P.D. Siempre debes usar el nombre Bonjour completo (por ejemplo, usuario-mbp.local) para dirigirte a un host/dispositivo local usando dns-sd. La razón para hacerlo es la siguiente:

Muchos routers proporcionan un dominio de búsqueda para facilitar la configuración si el DHCP de a bordo está activado o propagan un nombre de dominio específico de la conexión ISP. Ejemplos: El dominio de búsqueda por defecto de mi Fritz!Box es "fritz.box", el dominio de búsqueda por defecto de algunos routers DLink parece ser "local".

Si su Mac utiliza DHCP para asignar una IP, también se aplicará el dominio de búsqueda por defecto. En mi caso, al hacer ping a "myothermac" se añade automáticamente ".fritz.box" y se sondea el host myothermac.fritz.box. Si no tienes un servidor DNS en tu red local con una zona primaria "fritz.box." que contenga un host con el nombre "myothermac", el comando ping myothermac fallará. A diferencia de la ping myothermac.local que debería funcionar si Bonjour está configurado correctamente.

Dado que la mayoría de los routers no son compatibles con Bonjour, cambia cualquier configuración de dominio de búsqueda por defecto que contenga "*.local" o "local" o, aparentemente, algunos routers DLink con un dominio de búsqueda vacío a algo más como "happy.home" para evitar cualquier conflicto con el servicio Bonjour.

0 votos

Buena respuesta técnica.

0 votos

@klanomath Por favor, revisa mi Edición 4, he publicado la salida de los comandos que me dijiste que usara. Además, OS X ya está en la versión 10.10.4, así que supongo que no hay ninguna actualización por el momento

0 votos

@user3019105 su edición 4 puede ser errónea: ¿ejecutó el comando dig aconsejado desde el host user-mbp (ejecutando el servidor ssh?) contra sí mismo (user-mbp = 192.168.1.2 = MacBook Pro del usuario)? Si es así, intente ejecutar dig desde una segunda máquina Mac o Linux contra 192.168.1.2. Si no es así, el resultado de dig se ve bien y es obvio que el arreglo temporal no ayudó porque no había nada que arreglar con respecto a dns-sd en 192.168.1.2.

3voto

bdonlan Puntos 508

Añade .local al nombre de tu máquina.

Si eso funciona, y no quieres tener que hacerlo, en Preferencias del Sistema > Red > (Interfaz) > Avanzado > DNS > Buscar dominios, añade ".local".

0 votos

Gracias por la respuesta, he intentado user-mbp.local pero sigo teniendo ssh: Could not resolve hostname lo curioso es que pude conectarme a través de user-mbp antes... ¿Podría ser un problema del router? ¿Puedo hacer algo más?

0 votos

En el extremo del servidor, escriba "hostname". ¿Qué aparece?

0 votos

user-mbp:~ user$ hostname da usuario-mbp como debería. De hecho, el nombre del servidor es user-mbp Incluso scutil --get HostName devuelve usuario-mbp . Es realmente extraño, ¿no?

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X