Kein Zugriff mehr auf SSH

[Richard]

Hallo,

ich habe hier einen Downloadserver auf Basis von Raspbian Jessie auf dem Raspberry Pi. Ich habe von der SD-Karte ein Image mit dd erstellt und mal Rasbian Stretch ausprobiert. Jetzt habe ich das Image zurückgespielt und den Pi wieder gestartet. Alles geht (die Webinterface von nzbget, sabnzbd und Samba) bis auf den Zugriff per SSH. Versuche ich mich per SSH zu verbinden kommt

Code: Alles auswählen

ssh_exchange_identification: read: Connection reset by peer

Es spielt keine Rolle ob ich einfach 'ssh user@ip-adresse' eingeben oder per 'ssh -i /pfad/zur/schluesseldatei user@ip-adresse'. Die Meldung ist immer die gleiche. Ich habe das jetzt mehrfach versucht, immer mit dem gleichen Resultat.

Mit 'ssh -vv' kommt diese Meldung. Ich hatte schon versucht direkt am Pi die 'authorized_keys' zu löschen, ohne Ergebnis:

Code: Alles auswählen

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.10.23" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.10.23 [192.168.10.23] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/ich/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ich/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ich/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ich/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ich/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ich/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ich/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ich/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
ssh_exchange_identification: read: Connection reset by peer

[rendegast]

Bei Deinem Zurückspielen ist scheinbar
/home/ich/.ssh/
nicht wiederhergestellt worden.

[Richard]

Doch ist da. Da war ja die 'authorized_keys' drin die ich gelöscht hab. Außerdem ging vorher auf trotz Schlüsselpaar die Verbindung per Passworteingabe.

[Richard]

EDIT
Ich hatte übersehen, das ist der Homeordner des Clienten. Hab da die Dateien "known_hosts" und known_host_old" gelöscht und die Verbindung erneut versucht, weiterhin ohne Erfolg.

[MSfree]

1. befindet sich serverseitig eine Datei namens authorized_keys in ~/.ssh?
2. befindet sich clientseitig eine Datei namens id_rsa in ~/.ssh?

Wenn 1. oder 2. nicht erfüllt ist, wird das Login nicht funktionieren.

Ausserdem müssen authorized_keys (= Public Key) und id_rsa (= Private Key) zusammenpassen. Wenn das nicht gegeben ist, erzeuge ein neues Schlüsselpar mit ssh-keygen.

[Richard]

Die Dateien sind vorhanden und passen zusammen. Das erklärt aber nicht wieso es auch über die Passworteingabe nicht geht, bzw. es kommt ja gar nicht zur Passworteingabe wenn ich einfach

Code: Alles auswählen

ssh user@i-adresse

also ohne Schlüsseldateien ausführe.

Ich habe auch schon das hier https://drjohnstechtalk.com/blog/2015/0 ... pberry-pi/ versucht, auch wieder mir dem gleichen Ergebnis.

Kann es irgendwie mit dem Port zusammen hängen?

In anderen Beiträgen im Netz wurden andere Abfragen gefordert. Er scheint den SSH-Server dennoch irgendwie zu finden.

ip neigh show
192.168.10.23 dev enp3s0 lladdr b8:27:eb:49:c3:10 REACHABLE
192.168.10.1 dev enp3s0 lladdr 34:81:c4:fe:e5:59 REACHABLE

arp -av
? (192.168.10.23) auf b8:27:eb:49:c3:10 [ether] auf enp3s0
? (192.168.10.1) auf 34:81:c4:fe:e5:59 [ether] auf enp3s0
Einträge: 2 Ignoriert: 0 Gefunden: 2

[mat6937]

Das erklärt aber nicht wieso es auch über die Passworteingabe nicht geht, bzw. es kommt ja gar nicht zur Passworteingabe wenn ich einfach

Ist dein PI mit einem Router verbunden (... per Kabel oder per WLAN)? Wenn ja, was ist das für ein Router?

[Richard]

Ja, per Kabel an einer Fritzbox 7490.

Das Problem besteht aber auch wenn ich den Pi an einem Monitor anschließe - da hab ich dann aber kein LAN-Kabel in der Nähe - und 'ssh localhost' ausführe. Auch da kommt die Fehlermeldung.

[mat6937]

Ja, per Kabel an einer Fritzbox 7490.

Das Problem besteht aber auch wenn ich den Pi an einem Monitor anschließe - ...

Ist die Passwort-authentication lt. sshd_config zulässig? Evtl. mal:

Code: Alles auswählen

sudo tcpdump -c 50 -vvveni enp3s0 port 22

auf dem PI (oder auf dem Ubuntu-Client; dann anderes Interface) starten und schauen mit welchen flags, die Verbindung bei "Passwort-authentication" abgelehnt wird btw. nicht zustande kommt.

[Richard]

Da kommt

Code: Alles auswählen

tcpdump: enp3s0: No such device exists
(SIOCGIFHWADDR: No such device)

oder auf dem Ubuntu-Client; dann anderes Interface

Das geht ja nicht, ich bekomme ja keine Verbindung.

[mat6937]

Da kommt

Code: Alles auswählen

tcpdump: enp3s0: No such device exists
(SIOCGIFHWADDR: No such device)

Naja, schau mit "ifconfig" oder mit "ip a", welches das zuständige Interface ist.

oder auf dem Ubuntu-Client; dann anderes Interface

Das geht ja nicht, ich bekomme ja keine Verbindung.

Lt. einem deiner Beiträge doch. Wie ist auf dem Ubuntu-Client, die Ausgabe von:

Code: Alles auswählen

nc -zv 192.168.10.23 22

?

[Richard]

Ich hab das jetzt mit 'eth0' ausgeführt, hoffe das ist was du meinst:

Code: Alles auswählen

sudo tcpdump -c 50 -vveni eth0 port 22
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:54:17.146168 6c:f0:49:e6:db:00 > b8:27:eb:49:c3:10, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 53845, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.21.55960 > 192.168.10.23.22: Flags [S], cksum 0xac6f (correct), seq 3566816041, win 29200, options [mss 1460,sackOK,TS val 1415548 ecr 0,nop,wscale 7], length 0
10:54:17.146921 b8:27:eb:49:c3:10 > 6c:f0:49:e6:db:00, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.23.22 > 192.168.10.21.55960: Flags [S.], cksum 0x95ab (incorrect -> 0x13cd), seq 3615692972, ack 3566816042, win 28960, options [mss 1460,sackOK,TS val 108881 ecr 1415548,nop,wscale 6], length 0
10:54:17.148166 6c:f0:49:e6:db:00 > b8:27:eb:49:c3:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53846, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.21.55960 > 192.168.10.23.22: Flags [.], cksum 0xb2d2 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 1415549 ecr 108881], length 0
10:54:17.148169 6c:f0:49:e6:db:00 > b8:27:eb:49:c3:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53847, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.21.55960 > 192.168.10.23.22: Flags [F.], cksum 0xb2d1 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 1415549 ecr 108881], length 0
10:54:17.158010 b8:27:eb:49:c3:10 > 6c:f0:49:e6:db:00, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 45567, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.23.22 > 192.168.10.21.55960: Flags [.], cksum 0x95a3 (incorrect -> 0xb1ef), seq 1, ack 2, win 453, options [nop,nop,TS val 108883 ecr 1415549], length 0
10:54:22.386660 b8:27:eb:49:c3:10 > 6c:f0:49:e6:db:00, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 45568, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.23.22 > 192.168.10.21.55960: Flags [F.], cksum 0x95a3 (incorrect -> 0xafe4), seq 1, ack 2, win 453, options [nop,nop,TS val 109405 ecr 1415549], length 0
10:54:22.387823 6c:f0:49:e6:db:00 > b8:27:eb:49:c3:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 64712, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.21.55960 > 192.168.10.23.22: Flags [.], cksum 0xaba6 (correct), seq 2, ack 2, win 229, options [nop,nop,TS val 1416859 ecr 109405], length 0
10:54:28.161219 6c:f0:49:e6:db:00 > b8:27:eb:49:c3:10, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 49074, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.21.55962 > 192.168.10.23.22: Flags [S], cksum 0x28c5 (correct), seq 2099059596, win 29200, options [mss 1460,sackOK,TS val 1418302 ecr 0,nop,wscale 7], length 0
10:54:28.162087 b8:27:eb:49:c3:10 > 6c:f0:49:e6:db:00, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.23.22 > 192.168.10.21.55962: Flags [S.], cksum 0x95ab (incorrect -> 0x0243), seq 3305551034, ack 2099059597, win 28960, options [mss 1460,sackOK,TS val 109983 ecr 1418302,nop,wscale 6], length 0
10:54:28.163195 6c:f0:49:e6:db:00 > b8:27:eb:49:c3:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 49075, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.21.55962 > 192.168.10.23.22: Flags [.], cksum 0xa148 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 1418303 ecr 109983], length 0
10:54:28.164144 6c:f0:49:e6:db:00 > b8:27:eb:49:c3:10, ethertype IPv4 (0x0800), length 107: (tos 0x0, ttl 64, id 49076, offset 0, flags [DF], proto TCP (6), length 93)
    192.168.10.21.55962 > 192.168.10.23.22: Flags [P.], cksum 0x7cef (correct), seq 1:42, ack 1, win 229, options [nop,nop,TS val 1418303 ecr 109983], length 41
10:54:28.164787 b8:27:eb:49:c3:10 > 6c:f0:49:e6:db:00, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 6436, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.23.22 > 192.168.10.21.55962: Flags [.], cksum 0x95a3 (incorrect -> 0xa03f), seq 1, ack 42, win 453, options [nop,nop,TS val 109983 ecr 1418303], length 0
10:54:33.426252 b8:27:eb:49:c3:10 > 6c:f0:49:e6:db:00, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 6437, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.23.22 > 192.168.10.21.55962: Flags [R.], cksum 0x95a3 (incorrect -> 0x9e2d), seq 1, ack 42, win 453, options [nop,nop,TS val 110509 ecr 1418303], length 0

Das andere bringt

nc -zv 192.168.10.23 22
Connection to 192.168.10.23 22 port [tcp/ssh] succeeded!

Er scheint eine Verbindung zu bekommen. SSH geht aber weiterhin nicht.

[owl102]

Die Dateien sind vorhanden und passen zusammen.

Es scheint mir, daß ssh anderer Meinung ist:

debug1: identity file /home/ich/.ssh/id_rsa type -1

AFAIK bedeutet -1, daß die Datei entweder nicht vorhanden ist oder nicht die erwünschten Rechte aufweist. (AFAIK sollte bei einem RSA Key hier 1 und nicht -1 stehen.)

Was sagt (unter deinem Ubuntu):

Code: Alles auswählen

ls -al ~/.ssh

?

[Richard]

ls -al ~/.ssh
drwx------ 2 ich ich 4096 Sep 22 12:27 .
drwxr-xr-x 66 ich ich 12288 Sep 22 10:11 ..
-rw------- 1 ich ich 1675 Okt 21 2016 id_rsa
-rw------- 1 ich ich 1996 Sep 21 20:27 known_hosts
-rw------- 1 ich ich 2218 Sep 15 21:40 known_hosts.old

Ich habe aber die "id_rsa" nie für die Verbindung per Schlüsselpaar zum Pi genutzt, da ich noch eine Kopie der Datei als "~/.raspbian" abgespeichert hatte und die Verbindung per

xfce4-terminal -e "ssh -i /home/ich/.raspbian pi@192.168.10.23"

aufgebaut habe. Dieser Einzeiler liegt in einem Skript im Homeordner den ich nur doppelt anklicke.

Das erklärt aber nicht, wieso es auch ohne Schlüsseldatei nicht geht, einfach per

ssh pi@192.168.10.23

Das sollte doch immer, unabhängig von passenden oder nicht passenden, Schlüsselpaaren gehen. Auch habe ich die Ordner ~/.ssh am Client und am Server komplett leer gemacht und s funktionierte dennoch nicht. Werden hier noch an anderer Stelle irgendwelche Daten gespeichert?

[MSfree]

Das sollte doch immer, unabhängig von passenden oder nicht passenden, Schlüsselpaaren gehen. Auch habe ich die Ordner ~/.ssh am Client und am Server komplett leer gemacht und s funktionierte dennoch nicht. Werden hier noch an anderer Stelle irgendwelche Daten gespeichert?

Die Frage ist, wie der SSH-Server konfiguriert ist. Den kann man nämlich so einstellen, daß er Logins ausschließlich über Schlüsselpaare zuläßt (der übliche Default). In dem Fall wäre das Löschen aller Schlüssel auf Client und Server ziemlich dumm, weil du dich damit aussperren würdest.

Wenn du zulassen willst, daß du dich per User/Passwort einloggen kannst, mußt du auf dem Server in der Datei /etc/ssh/sshd_config den Paramter PasswordAuthentication auf yes setzen oder ggfls. eine Zeile einfügen:

Code: Alles auswählen

PasswordAuthentication yes

Danach ist der ssh-Server neu zu starten:

Code: Alles auswählen

systemctl restart ssh.service

Damit kannst du dich dann als User am Pi anmelden, root darf dann aber immer noch nicht.
Das bewerkstelligt man, indem man in die o.g. Datei noch PermitRootLogin yes einträgt. Aus Sicherheitsgründen sollte man aber auf Login mit User/Passwort zugunsten von Schlüsselpaaren verzichten und PermitRootLogin sollte man erstrecht nicht erlauben.

OK, in isolierten LANs und wenn man weiß, was man macht, was meinem Eindruck nach bei dir eher nicht so der Fall ist, kann man es auch zulassen.

[Richard]

Von mir selbst wurde der SSH-Server überhaupt nicht konfiguriert, der läuft so wie er mit Raspbian mitgeliefert wurde.

PasswordAuthentication yes

steht im übrigen so drin, sollte also gehen. Zumal es ja vor dem dd-Backup fast 2 Jahre so lief.

OK, in isolierten LANs und wenn man weiß, was man macht, was meinem Eindruck nach bei dir eher nicht so der Fall ist, kann man es auch zulassen.

Mag sein, dass ich kein Linux-Profi bin, aber ich habe hier ein dd-Image erstellt (also SSH lief) und das wiederhergestellt und danach lief es nicht. Es hat keinerlei Änderungen am Server gegeben und dennoch funktioniert es nicht. Ich wüsste nicht was ich hier falsch gemacht haben könnte. Der Login geht ja auch von anderen Clienten (Laptop und Tablet mit JuiceSSH) nicht mehr mit Passworteingabe. Das Problem kann eigentlich nur am Server liegen.

[mat6937]

Es hat keinerlei Änderungen am Server gegeben und dennoch funktioniert es nicht. Ich wüsste nicht was ich hier falsch gemacht haben könnte.

Die Ausgaben von tcpdump, die Du gepostet hast zeigen bei der einen Anmeldung ein vom ssh-Client initiiertes fin+ack (Beenden der Verbindung)

Code: Alles auswählen

10:54:17.148169 6c:f0:49:e6:db:00 > b8:27:eb:49:c3:10, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 53847, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.21.55960 > 192.168.10.23.22: Flags [F.], cksum 0xb2d1 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 1415549 ecr 108881], length 0

und bei der anderen Anmeldung, ein vom ssh-Server gesendetes reset+ack (auch für das Beenden der Verbindung:

Code: Alles auswählen

10:54:33.426252 b8:27:eb:49:c3:10 > 6c:f0:49:e6:db:00, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 6437, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.23.22 > 192.168.10.21.55962: Flags [R.], cksum 0x95a3 (incorrect -> 0x9e2d), seq 1, ack 42, win 453, options [nop,nop,TS val 110509 ecr 1418303], length 0

Weißt Du noch ob bzw. wie sich diese 2 Verbindungsversuche evtl. unterschieden haben?

[Richard]

Ich hab eigentlich nur 2 verschiedene Verbindungsarten gemacht.

ssh pi@ip-adresse

und

ssh -i schluesseldatei pi@ip-adresse

Das könnten die unterschiedlichen Versuche gewesen sein.

[mat6937]

Das könnten die unterschiedlichen Versuche gewesen sein.

Versuch mal mit folgenden 2 Zeilen:

Code: Alles auswählen

IPQoS cs0 cs0
UsePAM no

in der sshd_config deines PI.

Code: Alles auswählen

sudo systemctl daemon-reload
sudo systemctl restart ssh

nach der Änderung/Ergänzung, auf dem PI ausführen.

[Richard]

Hat leider auch nichts geändert.

[Richard]

@ mat6937

Ich danke dir für die Zeit die du investiert hast, aber ich habe jetzt Raspbian Jessie erneut installiert.