Raspberry Pi: SSH Zugang absichern

[@HDSpaceFox]

genial. das werd ich nachher mal direkt einrichten. :)

[@DieSonneSchicktKeineRechnug]

Super Erklärt, tolle Stimme!

[@SandrovonMatterhorn]

Cooles Video. Was man ergänzend noch hinzufügen könnte wäre in der /etc/ssh/sshd_config die Zeile AllowUser pi auf diese Weise darf sich nur der User pi (optional auch jeder weitere, dort eingetragene) noch per ssh aufschalten, alle anderen werden geblockt. Darüber hinaus würde ich auch die Zeile PermitRootLogin von 'yes' auf 'no' stellen, um auf diese Weise sicher zu stellen, dass man sich aus der Ferne nicht gleich als Root aufschalten kann. Ist vielleicht ein wenig paranoid, aber so mancher Admin schläft damit besser ;-)

[@joergdor8991]

PasswordAuth aus-, und keyonlyAuth einschalten sollte ausreichen. Das mit nur "pi" erlauben, ist eher Augenwischerei. Und wer total paranoid ist, der sollte sich mal fail2ban ansehen. Ups in dem Vid gings ja darum. Finde videotuts zu consolendingen immer noch skurril

[@Gagootron]

kann ich jetzt ohne Probleme den Port 22 an meinem Router an den pi weiterleiten? Also gibt es noch Probleme mit der Sicherheit?

[@KaiserAlbion]

hallo ich habe eine frage ich habe mir auf mein pi die wlanrouter packet draufgemacht und das geht auch bloß in der konfig steht für die wlan schnittstelle eine statiche ip kann ich das auch noch für die lan schnittstelle machen

[@mints.2305]

Ich möchte jetzt auch auf allen Rechnern/Betriebssystemen die Taskleiste an den oberen Bildschirmrand befördern, das ist einfach wie SV schon sagte viel ergonomischer und geht schneller!

[@Sonnentau1]

Komisch... ich habe die Änderungen in /etc/ssh/sshd_config 3fach überprüft, PI neu gestartet, geschaut ob die Änderungen wirksam waren und kann mich trotzdem noch mit User pi und passwort über SSH (Putty) anmelden... Jemand eine Idee woran das liegen könnte?

[@Flumi287]

+Sonnentau1 hast du vielleicht in der sshd_config vor dem punkt PasswordAuthentication eine # wenn ja musst du diese entfernen war bei mir der Fall!

[@Sonnentau1]

+Flumi Vielen Dank, dass war die Lösung!

[@SheratanLP]

Wünsche dir schöne Feiertage. :)

[@PlainStudios]

Und wie ist das mit anderen Benutzern? So braucht ja jeder Benutzer einen Key, oder? Und wie läuft das dann bei SFTP?

[@Bishop06618]

Ist es nicht logischer den Key auf dem Client zu generieren und dann mit ssh ssh-copy-id direkt nach ~/.ssh/authorized_keys2 zu kopieren? (Ist zumindest unter Linux der gaengige Weg. Weiss jetzt allerdings nicht, ob es einen aenlichen Befehl unter Windows gibt.) Noch ein kleiner Tipp: Wenn du sehr viel mit Putty arbeitest, kannst du dir das staendige Eingeben der Passphrase sparen, wenn du nach dem Windowsstart einen Doppelklick auf die ppk-Datei machst. Putty startet dann einen Agent, der sich in der Taskleiste einnistet. Der gibt dann schnell Zugriff auf alle gespeicherten Zugaenge. Beim Verlassen des Rechners sollte man den Agent dann aber auch zur Sicherheit beenden.

[@Ridehammershadow]

Hallo Andreas Das Video ist super jedoch bin ich Linuxnutzer und weiss nicht wie ich in der bash, wenn ich den Befehl "ssh pi@raspberry" benutze trotzdem den key einlesen kann.. Wäre nett wenn du es für Linux auch erklären könntest.. Danke Raffael

[@berndlukatschek1066]

***** Warum überträgt ihr den private key (geheimen Schlüssel)? Das widerspricht der Idee von Public-Key-Kryptosystemen. Wenn der Benutzer sowieso schon Putty gen startet kann er das Generieren auch dort machen und dann nur den public key (öffentlichen Schlüssel) an den Server übertragen. Weitere Details: Dies würde kein Sicherheitsproblem sein, wenn das Netz zur Übertragungszeit nicht angegriffen wird oder der Übertragungskanal sicher ist. Kann man im eigenen Netzwerk vielleicht annehmen, aber für das Internet kann man das nicht garantieren. Ohne SFTP würde der geheime Schlüssel (unser super langes geheimes Password) nur von dem Passwort geschützt, das wir bei der Generierung gesetzt haben. Wenn dies nicht gesetzt ist, dann übertragen wir den geheimen Schlüssel unverschlüsselt über das Internet. Somit kann ein Angreifer den geheimen Schlüssel mitlesen und verwenden. Generell ist das Übertragen des geheimen Schlüssel nicht notwendig und sollte auch nicht übertragen werden! Danke für die UsePAM no Option, das war mir nicht bekannt.

[@netrix64]

***** warum sollte man UsePAM auf no setzen bei meinem PI für das dazu das er die Sprache nicht mehr einstellt, denn das scheint über PAM zu laufen. (wenn man "locale" eingibt steht da "LANG=" und bei den LC_ stand bei den meisten POSIX.

[@stivi0798]

ist mit diser möglichkeit auch noch desktopremote möglich und wenn ja wie?

[@GeoStreber]

Könntet ihr mal zeigen, wie man nen Raspberry Pi als Repetier-Server einrichtet? Hab mir vor nicht all zu langer Zeit nen RepRap zugelegt, kann den aber nur verwenden, wenn mein PC läuft. Mit nem Raspi als Repetier-Server hätte ich das Problem nicht. Ich weis, ist ein ziemlich spezifisches Problem, aber wenn ihr mal Lust und Zeit habt....

[@Hannibal215000]

authorized_keys sollte anstelle von authorized_keys2 (depricated since 2001) verwendet werden, seit dem SSH-Protocol v2 Standard ist. Inzwischen gibt es auch praktisch keine SSH-Systeme mehr die so veraltet sind, also kann man sich das gleich abgewöhnen.

[@Pitschi1992]

Super Hinweis, Dankeschön!

[@randlereloaded]

wenn man den benutzer für den key mal hat kann man millionen mal das pw falsch eingeben... kann man das auch noch limitieren?

[@LeonMarzahn-t6n]

randle reloaded apt-get install fail2ban sperrt die ip nach 3 versuchen für 10 minuten ( einstellbar)

[@randlereloaded]

PsychoPflanze hab es jetzt über die anmeldezeit (20sek. ohne gültigem pw-> disconnect) geregelt und zusätzlich mit f2b. danke ;)

[@LeonMarzahn-t6n]

:P

[@tobias7166]

Ich habe alles wie im Video beschrieben gemacht kann mich aber trotzdem noch mit meinem Nutzername und pw einloggen? Jemand eine idee?

[@TheJonathanMMM]

@SemperVideo Was bringt den PAM auf No zu stellen? Ich nutze selbst nur den Account Pi als login

[@rhiji4583]

wie übertrage ich den private key *sicher* über das Internet? reicht scp oder muss ich da was besonderes beachten? Diffie-Hellman oder so?

[@andreasisaakme]

scp oder sftp sollte ausreichen.

[@Daniel-odanio]

Wie macht man diese Methode wieder Rückgängig?

[@dreamscreencast]

@Ridehammershadow LP Jupp, was auch für ein Unix Derivat wie OSX gilt. Wär Super wenn das noch erklärt wird.

[@mulchi01]

@Ridehammershadowl LP, Dreamscreencast - Dreambox Video Tutorials, Tips, Reviews and more Zumindestens unter Linux gibt es für so ziemlich jeden Terminal Befehl ein Handbuch, zu englisch manual. Der Befehl dafür lautet "man". man ssh gibt also normalerweise die Erklärung des Befehls. Um den Key auf der Kommandozeile speziell anzugeben wird die -i option verwendet, damit lautet der Befehl: ssh pi@raspberry-i ~/.ssh/wie_auch_immer.key Edit: Ein Leerzeichen im Befehl vergessen …

[@dreamscreencast]

mulchi01 Merci

[@bjornrichter4866]

***** bei 10:03 sagt ihr, man muss den ssh-Server neu starten und startet den ganzen Pi neu. Eigentlich hätte doch das hier gereicht: $ sudo service ssh restart oder, falls 'service' nicht vorhanden ist: $ sudo /etc/init.d/ssh restart Korrigiert mich bitte, wenn ich falsch liege, ich habe kein Pi aber so sollte es auf jedem Linux (zumindest Debian basiert) funktionieren

[@dd8pz]

Anmerkung: servuce ssh restart Hat keine Auswirkungen auf bestehende ssh-Session. Die neuen Einstellungen haben nur eine Wirkung auf neue Session. Fazit: Wenn bei übertragen des Public-Keys etwas Schief läuft, kann man sich leicht ausspeeren. Aber dann hat man immer noch durch offene ssh-Verbindung Zugriff auf die sshd_conf.

[@IronflashDE]

Ubuntu oder Windows?

[@seishinryohosha]

Für Linux User: Lokal erstmal die Schlüssel erzeugen: Mittels ssh-copy-id -i relativer/pfad/ident_file user@host wird der Schlüssel automatisch in die authorized_keys von host geschrieben. Anstatt ftp zu benutzen gibt es scp oder sftp (Quasi ftp via ssh) Gibt noch andere Möglichkeiten um es einzudämmen, wie z.b. IP-Range festlegen (Geht im SSHD sowie in der Firewall) Knocking fail2ban etc.

[@simonhaas1243]

Hi @SemperVideo mal wieder ein super Video, danke. Mir ist aber aufgefallen, dass der SFTP Zugang noch über Passwort funktioniert, aber eben auch per keyfile. Wie kann man für SFTP den Passwort-Zugang noch deaktivieren? Hierzu habe ich nichts im Netz gefunden.

[@M4lock]

Ist der 4069bit schlüssel denn noch uptodate ?

[@Pitschi1992]

Ja, eine Schlüssellänge von 4096bit sollte einige Jahre, wenn nicht Jahrzehnte sicher sein. Solch ein Schlüssel zu "brute forcen" dauert nahezu ewig, und ein potentieller Hacker wird sich sicher ein leichteres Ziel suchen. Angabe aber ohne Gewähr, da man heutzutage ja nie weiß, was es in Zukunft noch so an "Neuerungen" im Informatikbereich gibt ;-) Man sollte sich auf jeden Fall noch mit dem Thema "fail2ban" auseinander setzen, um die Sicherheit weiter zu erhöhen.

[@Ridehammershadow]

Ok danke @mulchi101 Unter Linux ist es z.B ssh -i privatekey.txt pi@raspberrypi richtig nh ?

[@amgnico]

Danke für das Video ;)

[@janh.]

Und wenn wir schon dabei sind können wir es auch gleich ganz übertreiben und noch den ssh daemon mit port knocking aktivieren bzw deaktivieren. Vielleicht könnt ihr dazu ja auch noch mal ein Video machen.

[@adrianmallinger]

Kannst du noch ein Video dazu machen wir man das auf Linux / Ubuntu einstellen kann? Merci

[@minilord11]

Würde mich freuen wenn Sie mehr Videos in Richtung Sicherheit mit dem Pi machen auch mit Apache etc...

[@cyberrichter]

Ich weis nicht, ob es anderen genauso geht. Ich habe PuTTy von der Seite www.chiark.greenend.org.uk/ runtergeladen und es war eine einfache Exe die bei mir nun auf dem Desktop liegt. Ich habe kein Verzeichnis, wo ich den Generator finden könnte. Was nun?

[@cyberrichter]

...hat sich erledigt. Auf der Gleichen Seite gibt es den Generator auch zum seperaten download.

[@dunmorogh8063]

Hallo, könnten Sie bitte auch ein Passwort-Tutorial machen für einen Linux Client (z.B: Linux Mint/Ubuntu) welcher auf das Pi zugreifen will (ohne Putty rein über das Terminal) ?

[@mineyannikde]

Wir können den SSH Server auch Neustarten während wir verbunden sind.

[@Lennscape]

*sehr hilfreich*

[@TutorialNerdzzz]

service restart sshd hätte geklappt , aber ohne sudo und dann manuell mit dem user passwort bestätigen , habe ich so gemacht und es hat geklappt

[@jarrinocmd2876]

Jippi :D Ich weiß wie du heißt!!

[@edi9892]

Das könnte auch noch interessant werden: www.spiegel.de/netzwelt/web/tor-betreiber-verlieren-wichtige-server-a-1009945.html Bin gespannt auf weitere Neuigkeiten...

[@Mat2095]

Weitere mögliche Absicherungen: - Einen anderen Port für SSH (nicht 22) verwenden - In der sshd_config PermitRootLogin auf no stellen - Vor allem wenn man den pi aus dem Internet erreichen kann: fail2ban!

[@mulchi01]

Leider hatte ich schon Kontakt mit einigen tablet apps (git clients in dem Fall), die sich partout nicht auf einen anderen Port umstellen ließen. Port 22 zu ändern war in meinem Fall also nicht drin. Aber mit dem Rest gehe ich konform.

[@Mat2095]

mulchi01 Schade. Bei mir war das kein Problem, ich nutze SSH nur mit Putty für Windows und S60 sowie FileZilla, da lässt sich der Port ohne Probleme umstellen.

[@泉こなた-t2q]

Das ändern des SSH port bring 0 mehr Sicherheit , da man sehr leich nach diese port scannen kann

[@mulchi01]

泉こなた Damit hast du natürlich recht, aber die wenigsten automatisierten Versuche die ich beobachtet habe, haben gescannt. Die suchen nicht nach Servern die von Leuten betrieben werden, die wissen was sie tun. Da werden einfach die IP Adressen durchgegangen und versucht die einfachen, schlecht konfigurierten Server zu erwischen. Und wenn Port 22 nicht antwortet, gehen die einfach weiter. Alles andere würde bedeuten, daß sie nicht einfach ihre Passwortliste gegen den ssh Port schmeißen können um zu sehen ob nicht eins davon passt sondern ernsthafte, aufwändige Angriffe zu fahren. Aber ja, jemand der geziehlt versucht in dein Netzwerk über ssh einzudringen, den wird ein verschobener Port nicht aufhalten.

[@SheratanLP]

Wäre es nicht einfacher sich ein 10er Passwort zu merken und das dann sooft wiederholen, wie man glaubt, daß es nötig ist ? Bei 4000er PW also 400 Mal. :)

[@SheratanLP]

sewagii Ich wollte damit nur darauf hinweisen, daß es doch auch einfachere Wege gibt ein langes Passwort zu erstellen das man sich auch merken kann, selbst wenn es extrem lang ist. Ob nun 4000 Zeichen Sinn machen oder nicht, steht auf einem ganz anderen Blatt.

[@MegaAtHome]

diese doofen Raspberry-Videos nerven mich hart

[@user-gp7zt8sm4w]

weil du keinen hast :D

[@martingerlach_1990]

Besser als RSA sind ECDSA und ED25519. Man kann diese Verschlüsselungsarten mit "-t" oder mit "--type" als Verschlüsselungsart oder Verschlüsselungstyp, also als Parameter angeben. Ein Beispiel wäre: ssh-keygen -N hostname.local -t ed25519.