¿Por qué Ubuntu no puede acceder a mi Raspberry Pi a través de LAN?

De acuerdo, recientemente obtuve una Raspberry Pi, y la conecté a mi Wi-Fi: habilité el SSH e instalé Hiawatha, y pude acceder a él perfectamente desde mi Escritorio, que estaba ejecutando Puppy Linux en ese momento.

También pude acceder bien cuando arranqué en Windows (PuTTY en Win XP Pro) y el Netbook también pudo acceder a través de PuTTY. (Gana 7 Starter)

Sin embargo, cuando inicié en Ubuntu, se rechazaron todas las conexiones SSH, HTTP y HTTPS. Para confirmar que era Ubuntu, y solo Ubuntu, el que tenía problemas de conexión, reinicié en Puppy Linux, bien conectado, y en Windows, bien conectado. El Netbook podría conectarse a los 3 servicios sin problemas tampoco. Fue solo Ubuntu que dicha conexión se negó.

Me gustaría saber qué está mal: ya hice toda la solución de problemas básica: reiniciar el RPi, reiniciar mi computadora, reiniciar el enrutador inalámbrico, etc. El Raspberry Pi no tiene Firewall habilitado, y mi enrutador ofrece todos los dispositivos conectados a LAN sin restricciones de acceso el uno al otro. He realizado pruebas exhaustivas , y se ha demostrado que Ubuntu, sin lugar a dudas, es el único que no está dispuesto a conectarse.

ACTUALIZACIÓN: ¡Acabo de probar el acceso a través de mi IP externa, y todo funciona sin problemas en Ubuntu! Sin embargo, Ubuntu todavía no puede acceder a Pi desde nada local, y acabo de volver a confirmar que mis otros sistemas operativos sí pueden . Creo que es extraño que Ubuntu tenga problemas para conectarse localmente (a diferencia de mis otros sistemas operativos), pero está bien acceder al Pi a través de mi IP externa.

ACTUALIZACIÓN 2: Deshabilitar mi firewall me permite acceder al dispositivo, pero la contraseña informa que es incorrecta cada vez . sola . tiempo . Intenté escribirlo en Gedit, luego lo arrastré y solté en la solicitud de contraseña durante el inicio de sesión SSH, y autoriza al acceder [email protected], pero NO al acceder [email protected]. Esto es increíblemente frustrante.

Entonces, hasta que haya ufwhabilitado la configuración predeterminada en su máquina Ubuntu, la conexión siempre informó Connection refused. Después de deshabilitar el ufwcliente, ¿se establece la conexión pero siempre se rechaza la contraseña?

Supongo que en ese caso su problema es que la 192.168.2.128IP se enruta de nuevo a su máquina Ubuntu cliente, y en realidad se está conectando al sshservidor que se ejecuta en su máquina Ubuntu. Esto explicaría:

• ¿Por qué puede conectarse desde Internet?

• Por qué se rechazó su conexión cuando el firewall estaba activado en su cliente Ubuntu.

• Por qué la conexión ya no se rechaza con el firewall del cliente desactivado.

• ¿Por qué ahora se establece la conexión, pero la autenticación falla?

Para solucionar este caso:

• Verifique la clave de host del servidor con ssh -v [email protected]una conexión local y una conexión a Internet. ¿Informa la misma clave?

• O mientras se conecta desde local, y se le pide que escriba su contraseña, desde otro terminal: sudo netstat -tupany vea si se establece una conexión con el sshden su Ubuntu.

Aunque este caso explicaría todo, pero es tan extraño que tengo dudas de que este sea tu problema.

Es completamente posible que su máquina ubuntu obtenga una dirección IP de red diferente a la esperada. Intenta lo siguiente:

• En el raspi, verifique su dirección IP con ifconfig | grep 192.168
• en la máquina ubuntu, verifique su dirección IP con ifconfig | grep 192.168

Para poder comunicarse entre sí en su red local, ambos deben usar la misma subred; mire la tercera sección de la dirección IP para ver si lo están haciendo. En su caso, ambos deberían estar en la subred 192.168.2. *.

Asegúrese de que también tengan diferentes direcciones IP. Esto puede parecer obvio, pero puede suceder si uno de ellos usa DHCP y el otro está configurado estáticamente.

Si todo se verifica, ejecuta el siguiente comando para ver a dónde se supone que van tus paquetes:

route -n

Busque en la salida la subred de destino que se aplica a su raspberry pi. Realmente debería haber solo 3 filas:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0

Si tiene más filas o las cosas van a lugares extraños, entonces esa es la respuesta.

Supongo que su conexión ssh está terminando golpeando un servidor SSH diferente del que está en su raspberry pi, por lo que el cambio del firewall de ubuntu lo afectó y sus inicios de sesión no funcionan.

Según lo que hay en su PasteBin, la "conexión rechazada" indica que está obteniendo un restablecimiento de TCP desde lo que sea que esté en esa dirección IP.

Comprobación de cordura: durante la resolución de problemas, DESACTIVA ufw.

Con su firewall de escritorio deshabilitado, ¿puede hacer ping al Pi desde su escritorio? ¿Puedes hacer ping al escritorio desde tu Pi?

Después de intentar hacer ping en ambas direcciones, observe la salida de 'arp -n' en ambas máquinas. ¿Ven las direcciones MAC (hardware de Ethernet) del otro o hay algo que redirige / intercepta el tráfico?

Si puede hacer ping en ambas direcciones y 'arp -n' indica que se están utilizando las direcciones MAC adecuadas (marque 'ifconfig' en la máquina opuesta), el siguiente paso es examinar /var/log/auth.log en el Pi. Debería decirte qué hay de malo con el intento de conexión.

Si lo anterior no ayuda, muéstrenos el resultado de los siguientes comandos en el Pi:

sudo ifconfig -a
cat /etc/resolv.conf
arp -n
netstat -rn
sudo iptables-save
sudo grep ssh /var/log/auth.log | tail -50

Y en tu escritorio:

sudo ifconfig -a
cat /etc/resolv.conf
arp -n
netstat -rn
sudo iptables-save

Veo algo de esto pegado en los comentarios anteriores, pero es importante agarrar todo con el firewall desactivado, primero. Si puede hacer que funcione con el firewall desactivado, entonces puede proceder a la resolución de problemas de las reglas de su firewall.

Además, incluso si está apuntando a una dirección IP, la configuración de DNS sigue siendo importante porque SSH usa DNS durante la validación de la clave de host.

Elimine el ~/.ssh/known_hostsarchivo e intente nuevamente. Si anteriormente había un host con la misma dirección IP ssh accesible, puede mantener una huella digital no válida

En Ubuntu 13.10, no pude hacer ssh a mi pi, cuando pude previamente en 13.04 y Mint 16. Al intentar

ssh -vvv user@host

Tengo :

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

Me encontré con una sugerencia que decía establecer MTU para la máquina (no la pi) a 1200 en lugar de automático. Hice esto, apagué -> luego en mi wifi, y me conecté con ssh a PI en el primer intento. Espero que esto ayude a alguien.