Perché Ubuntu non può accedere al mio Raspberry Pi attraverso la LAN?

Ok, di recente ho ottenuto un Raspberry Pi e l'ho collegato al mio Wi-Fi: ho abilitato SSH e installato Hiawatha e ho potuto accedervi dal mio desktop, che a quel tempo eseguiva Puppy Linux.

Potrei anche accedervi bene quando avviato in Windows (PuTTY su Win XP Pro,) e anche il Netbook potrebbe accedervi tramite PuTTY. (Win 7 Starter)

Tuttavia, quando ho avviato Ubuntu, tutte le connessioni SSH, HTTP e HTTPS sono state rifiutate. Per confermare che era Ubuntu, e solo Ubuntu, che stava avendo i problemi di connessione, ho riavviato Puppy Linux - ben collegato e Windows - ben collegato. Il Netbook potrebbe connettersi a tutti e 3 i servizi senza problemi. Fu solo Ubuntu che disse che la connessione si rifiutava.

Vorrei sapere cosa c'è che non va: ho già fatto tutte le operazioni di base per la risoluzione dei problemi: riavvio di RPi, riavvio del computer, riavvio del router wireless, ecc. Raspberry Pi non ha Firewall abilitato e il mio router offre tutti i dispositivi collegati Accesso illimitato LAN l'uno all'altro. Ho fatto test approfonditi e Ubuntu ha dimostrato, senza ombra di dubbio, di essere l'unico a non voler connettersi.

AGGIORNAMENTO: Ho appena provato ad accedere tramite il mio IP esterno e tutto funziona senza problemi su Ubuntu! Tuttavia, Ubuntu non è ancora possibile accedere al Pi da qualsiasi cosa locali, e ho appena ri-confermato che il mio altro sistema operativo può . Penso che sia strano che Ubuntu abbia difficoltà a connettersi localmente (a differenza di altri miei sistemi operativi), ma sta semplicemente accedendo al Pi tramite il mio IP esterno ..

AGGIORNAMENTO 2: La disabilitazione del firewall mi consente di accedere al dispositivo, ma la password viene segnalata come errata ogni . singolo . tempo . Ho provato a digitarlo in Gedit, quindi a trascinarlo nel prompt della password durante il login SSH e si autorizza durante l'accesso pi@jamestheawesomedude.cu.cc, ma NON durante l'accesso pi@192.168.2.128. Questo è incredibilmente frustrante.

Quindi fino a quando non l'hai ufwabilitato con le impostazioni predefinite sul tuo computer Ubuntu la connessione è sempre stata segnalata Connection refused. Dopo aver disabilitato il ufwclient sul client, viene stabilita la connessione ma la password viene sempre rifiutata?

Immagino che in questo caso il tuo problema è che l' 192.168.2.128ip viene reindirizzato al tuo computer Ubuntu client e in realtà ti stai collegando al sshserver in esecuzione sul tuo computer Ubuntu. Questo spiegherebbe:

• Perché sei in grado di connetterti da Internet.

• Perché la tua connessione è stata rifiutata quando il firewall era attivo sul tuo client Ubuntu.

• Perché la connessione non viene più rifiutata con il firewall client disattivato.

• Perché ora viene stabilita la connessione, ma l'autenticazione fallisce.

Per risolvere questo caso:

• Controllare la chiave host del server ssh -v pi@192.168.2.128sia per una connessione locale che per una connessione Internet. Segnala la stessa chiave?

• Oppure mentre ti connetti da locale e sei pronto a digitare la tua password, da un altro terminale: sudo netstat -tupane vedi se una connessione è stabilita sshdsu Ubuntu.

Anche se questo caso spiegherebbe tutto, ma è così strano che ho dei dubbi sul fatto che questo è il tuo problema.

È del tutto possibile che la tua macchina Ubuntu ottenga un indirizzo IP di rete diverso da quello previsto. Prova quanto segue:

• Sul raspi, controllare il suo indirizzo IP con ifconfig | grep 192.168
• sulla macchina Ubuntu, controlla il suo indirizzo IP con ifconfig | grep 192.168

Per poter parlare tra loro sulla tua rete locale, entrambi dovrebbero usare la stessa sottorete - guarda la terza sezione dell'indirizzo IP per vedere se lo sono. Nel tuo caso, dovrebbero essere entrambi nella sottorete 192.168.2. *.

Assicurati che abbiano effettivamente anche indirizzi IP diversi . Ciò può sembrare ovvio, ma può accadere se uno di essi utilizza DHCP e l'altro è impostato staticamente.

In questo caso, esegui il seguente comando per vedere dove dovrebbero essere diretti i tuoi pacchetti:

route -n

Cerca nell'output la sottorete di destinazione che si applica al tuo raspberry pi. Dovrebbero esserci solo 3 righe:

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

Se hai più file o le cose stanno andando in punti strani, allora questa è la risposta.

La mia ipotesi è che la tua connessione SSH stia finendo per colpire un server SSH diverso da quello sul tuo Raspberry Pi, motivo per cui la modifica del firewall Ubuntu ha interessato e i tuoi accessi non funzionano.

Secondo quanto contenuto nel tuo PasteBin, la "connessione rifiutata" indica che stai ricevendo un reset TCP da qualunque cosa si trovi a quell'indirizzo IP.

Controllo di integrità: durante la risoluzione dei problemi, DISATTIVARE ufw.

Con il firewall del desktop disattivato, è possibile eseguire il ping del Pi dal desktop? Puoi eseguire il ping del desktop dal tuo Pi?

Dopo aver provato il ping in entrambe le direzioni, guarda l'output di 'arp -n' su entrambe le macchine. Si vedono reciprocamente gli indirizzi MAC (hardware Ethernet) o qualcosa sta reindirizzando / intercettando il traffico?

Se è possibile eseguire il ping in entrambe le direzioni e 'arp -n' indica che vengono utilizzati gli indirizzi MAC corretti (controllare 'ifconfig' sulla macchina opposta), il passo successivo è esaminare /var/log/auth.log sul Pi. Dovrebbe dirti cosa c'è che non va nel tentativo di connessione.

Se quanto sopra non aiuta, mostraci l'output dei seguenti comandi sul Pi:

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

E sul tuo desktop:

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

Vedo un po 'di tutto ciò incollato nei commenti sopra, ma è importante innanzitutto afferrare il firewall. Se riesci a farlo funzionare con il firewall spento, puoi procedere alla risoluzione dei problemi delle regole del firewall.

Inoltre, anche se hai come target un indirizzo IP, le impostazioni DNS sono ancora importanti perché SSH utilizza DNS durante la convalida della chiave host.

Elimina il ~/.ssh/known_hostsfile e riprova. Se in precedenza era presente un host con lo stesso indirizzo IP accessibile ssh, è possibile mantenere un'impronta digitale non valida

Su Ubuntu 13.10, non sono riuscito a lanciarmi sul mio pi, quando in precedenza avrei potuto su 13.04 e Mint 16. Quando ci provavo

ssh -vvv user@host

Ho ottenuto :

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

Mi sono imbattuto in un suggerimento che diceva di impostare MTU per la macchina (non il pi) su 1200 anziché automatico. Ho fatto questo, spento -> quindi sul mio wifi e collegato al primo tentativo con ssh a PI. Spero che questo aiuti qualcuno.