Kein Zugriff mehr auf SSH

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Richard
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Kein Zugriff mehr auf SSH

Beitrag von Richard » 21.09.2017 20:31:34

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
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Kein Zugriff mehr auf SSH

Beitrag von rendegast » 21.09.2017 20:44:43

Bei Deinem Zurückspielen ist scheinbar
/home/ich/.ssh/
nicht wiederhergestellt worden.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Richard
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 21.09.2017 20:55:35

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
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 22.09.2017 09:26:53

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.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Kein Zugriff mehr auf SSH

Beitrag von MSfree » 22.09.2017 09:45:33

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
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 22.09.2017 09:50:25

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
Beiträge: 2926
Registriert: 09.12.2014 10:44:00

Re: Kein Zugriff mehr auf SSH

Beitrag von mat6937 » 22.09.2017 10:03:33

Richard hat geschrieben: ↑ zum Beitrag ↑
22.09.2017 09:50:25
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
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 22.09.2017 10:07:02

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
Beiträge: 2926
Registriert: 09.12.2014 10:44:00

Re: Kein Zugriff mehr auf SSH

Beitrag von mat6937 » 22.09.2017 10:12:56

Richard hat geschrieben: ↑ zum Beitrag ↑
22.09.2017 10:07:02
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
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 22.09.2017 10:39:10

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
Beiträge: 2926
Registriert: 09.12.2014 10:44:00

Re: Kein Zugriff mehr auf SSH

Beitrag von mat6937 » 22.09.2017 10:42:35

Richard hat geschrieben: ↑ zum Beitrag ↑
22.09.2017 10:39:10
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.
Richard hat geschrieben: ↑ zum Beitrag ↑
22.09.2017 10:39:10
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
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 22.09.2017 10:57:07

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

Re: Kein Zugriff mehr auf SSH

Beitrag von owl102 » 22.09.2017 11:09:58

Richard hat geschrieben: ↑ zum Beitrag ↑
22.09.2017 09:50:25
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
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 22.09.2017 12:31:38

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?

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: Kein Zugriff mehr auf SSH

Beitrag von MSfree » 22.09.2017 13:30:16

Richard hat geschrieben: ↑ zum Beitrag ↑
22.09.2017 12:31:38
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
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 22.09.2017 13:47:31

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
Beiträge: 2926
Registriert: 09.12.2014 10:44:00

Re: Kein Zugriff mehr auf SSH

Beitrag von mat6937 » 22.09.2017 14:33:05

Richard hat geschrieben: ↑ zum Beitrag ↑
22.09.2017 13:47:31
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
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 22.09.2017 15:57:18

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
Beiträge: 2926
Registriert: 09.12.2014 10:44:00

Re: Kein Zugriff mehr auf SSH

Beitrag von mat6937 » 22.09.2017 16:31:28

Richard hat geschrieben: ↑ zum Beitrag ↑
22.09.2017 15:57:18
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
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 22.09.2017 20:51:37

Hat leider auch nichts geändert.

Richard
Beiträge: 639
Registriert: 11.10.2012 14:18:37
Lizenz eigener Beiträge: GNU General Public License

Re: Kein Zugriff mehr auf SSH

Beitrag von Richard » 23.09.2017 19:17:26

@ mat6937

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

Antworten