Zugriffsversuche über ssh

[ebusynsyn]

Sind diese Zeiten nicht vorbei?

nicht in der Schweiz...

 

[metalworker]

Also das mit den Zwangsrouter ist echt mies .
Aber nicht das riesen Thema.

Ich würde es da mit der Bridge machen und einfach die Fritte dann als Gateway nehmen.
Mit WG als VPN Lösung bist da schon ganz gut dabei.
Und es ist immer besser das direkt im Gateway zu machen , bzw wenn als eigenes Gerät , dann mit Unterschiedlichen Netzwerkports.

Ganz davon ab. Ganz ganz wichtig sind gute Backups , durchdacht und Trojaner sicher.

 

[pr498te]

Ich persoenlich mag es auch nicht wenn jemand staendig an meiner Tuer ruettelt - auch wenn ich weiss dass nur reinkommt wer einen privaten (ssh)Schuessel hat.

Danke für die vielen Antworten!
Ich nutze nicht den Standard-Port für SSH und zudem ist SSH regelmäßig bei mir deaktiviert. Aber ab und an muß ich SSH auch wieder aktivieren, wenn ich mit PUTTY aufs System zugreife.
SSH mit Key schau ich mir mal an; ist sicherlich ein Option!

 

[framp]

SSH mit Key schau ich mir mal an; ist sicherlich ein Option!

Sorry. Das ist ein Muss !

 

[Ronny1978]

Das sehe ich nicht so. Wenn nur der Zugang von "innen" da ist und auch nur sehr sporadisch gebraucht, dann geht es schon ohne SSH Key. Man muss es nicht immer "übertreiben".

 

[framp]

Wenn nur interner Zugang notwendig ist bin ich bei Dir. Aber jeglicher externer Zugriff muss per Keys geschützt sein. Egal wie kompliziert dass PWD ist.
Aber selbst da ist es nützlich da man dann ohne UID und PWD Eingabe sofort auf den System ist.

 

[Ronny1978]

Aber jeglicher externer Zugriff muss per Keys geschützt sein

Da gebe ich dir recht. Aber interne Server öffne ich NIE nach außen mit Port 22 (SSH). Dann immer über die VPN gehen und gleich noch den SSH Port abändern.

 

[Tommes]

Ich mach das mit den Keys in erster Linie aus reiner Faulheit, damit ich nicht immer das Passwort von Hand eingeben muss. Auch nutze ich u.a. ein rsync-Script für diverse, unbeaufsichtigte Backups, die ebenfalls auf solch einen Key zurückgreifen. Aber auch bei mir alles nur intern. Extern würde ich SSH niemalsnie freigeben. Dafür nutze ich ausschließlich VPN.

 

[framp]

Ich mach das mit den Keys in erster Linie aus reiner Faulheit, damit ich nicht immer das Passwort von Hand eingeben muss.

Exakt mein Grund warum ich auch lokal keys nutze

 

[pr498te]

Hier hat unser Forenmitglied @Tommes doch eine schöne Anleitung gemacht

https://github.com/toafez/Tutorials/blob/main/SynologyNAS/ssh_from_os_to_nas.md

https://m.youtube.com/watch?v=VjoWjX_8E3Q

Danke für den Hinweis! Ich bin streng nach der Anleitung vorgegangen, leider ohne Erfolg! Ich werde immer noch nach einem Passwort gefragt. Ich habe bereits bei tommes angefragt, aber er kann mir auch nicht weiterhelfen. Sein Basissystem scheint Linux zu sein, ich komme von Windows10. Ob das den Unterschied macht - keine Ahnung! Ist da vielleicht ein Windows-User, der die Anleitung erfolgreich umgesetzt hat?

 

[framp]

Duch einen nur durch keys moeglichen Zugang verhinderst Du nicht dass Leute aus dem Internet bei Dir an der Tuer ruetteln.
Das musst Du ignorieren und akzeptieren mit dem Wissen dass sie so lange Ruetteln koennen wies sie wollen und nie Erfolg haben werden.

Es gibt Moeglichkeiten dieses Ruetteln zu beschraenken mit fail2ban. Das ist aber in meinen Augen overkill und kannst Du Dir sparen.

Keep cool - accept das Ruetteln - und schlafe gut.

 

[Tommes]

Ich habe bereits bei tommes angefragt, aber er kann mir auch nicht weiterhelfen.

Ich wollte damit nur den Support per PN abwürgen, weil für sowas das öffentliche Forum da ist. Auch halte ich die YouTube Kommentar-Funktion für weniger geeignet, um eine mögliche Lösung für dein Problem zu erarbeiten. Hier würde ich vielleicht nur das Ergebnis kommentieren.

Ich bin streng nach der Anleitung vorgegangen...

... und hast alle Eingaben, Dateinamen, etc. überprüft und kontrolliert? Ist dein Problem schon während des Verbindungsaufbaues mit deinem Administrator-Konto der DS aufgetaucht, oder erst, als du dich mit dem Benutzer root verbinden wolltest? Ich habe in der Videobeschreibung des YouTube-Videos einen Link geteilt, worin der beschriebene Vorgang nochmal schriftlich aufzeigt wird *klick* Vielleicht nutzt du dieses nochmal zum Abgleich deiner Eingaben.

Und ja, ich bin mittlerweile auf Linux Mint umgestiegen, habe aber noch Windows 11 im Dual Boot auf meinem Laptop laufen. Dort habe ich bereits vor längerer Zeit die SSH-Verbindungen u.a. zu meinem Synology NAS eingerichtet und kann diese sowohl über die PowerShell als auch über WSL problemlos erreichen. Das Einzige, was ich aktuell nicht mehr konkret beantworten kann, ist die Frage, ob bzw. man wie man unter Windows die Ordner- und Dateirechte richtig setzt bzw. setzten muss. Hier könnte evtl. die Möglichkeit bestehen, das ich das damals alles über WLS erstellt habe und im Anschluss daran dann halt auch die SSH-Verbindung über die PowerShell funktionierte. Das müsste ich selbst noch mal bei mir testen.

Ich werf gleich mal Windows 11 an und teste...

Duch einen nur durch keys moeglichen Zugang verhinderst Du nicht dass Leute aus dem Internet bei Dir an der Tuer ruetteln.

Da hat @framp natürlich vollkommen recht. Das Rütteln an der Tür verhinderst du damit nicht. Die Public Key Authentifizierung bewirkt hier nur, dass man noch viel fester und deutlich länger an der Tür rütteln müsste um am Ende vielleicht festzustellen, das man sie gar nicht auf bekommt.

Tommes

 

[Tommes]

Hm... also... wenn ich in der Windows PowerShell versuche die RSA-Keys mit dem Befehl...

ssh-keygen -b 4096 -t rsa -f ~/.ssh/id_rsa

... zu erzeugen, erhalte ich folgende Fehlermeldung (rot markiert)...

PS C:\Users\tommes> ssh-keygen -b 4096 -t rsa -f ~/.ssh/id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Saving key "~/.ssh/id_rsa" failed: No such file or directory

Wenn ich anstatt des Tilde-Zeichens ~/ den kompletten Pfad zu meinem Benutzer-Home-Ordner angebe, dann passiert Folgendes...

PS C:\Users\tommes> ssh-keygen -b 4096 -t rsa -f c:/Users/tommes/.ssh/id_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in c:/Users/tommes/.ssh/id_rsa
Your public key has been saved in c:/Users/tommes/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:k+PIkJt310ZIoeBopWe4MxTt5BmdfGyC1BjWgyVxXDs tommes@Windows-V17-IIL
The key's randomart image is:
+---[RSA 4096]----+
| .oB&++. . |
| *B*X.+o . |
| =++o.=E . |
| . ++. + . |
| + o S . . |
| o = o o o |
| o + o . o |
| . . . . |
| |
+----[SHA256]-----+

... somit hätten wir bereits einen ersten möglichen Fehler. Komisch ist halt nur, das man den kompletten Pfad nur bei der Erstellung des RSA-Keys angeben muss, ansonsten reicht hier das Tilde-Zeichen ~/ aus. Im weiteren Verlauf meines Tests konnte ich keine weiteren Probleme mehr feststellen, sondern alles so abarbeiten wie im YouTube Video bzw. in der Videobeschreibung vorgegeben. Hiervon ausgenommen sind nur die Ordner- und Dateirechte. Windows scheint das wohl egal zu sein. Keine Ahnung. Ist halt Windows

Ich hoffe, das dir das weiter hilft.

Tommes

Nachtrag: Ich bin mit der PowerShell nicht sehr vertraut, lese aber z.B. grade, das es eigentlich nicht c:/Users/tommes/.ssh sondern wohl eher C:\Users\tommes/.ssh heißt, auch wenn ersteres funktioniert hat. Auch gibt es in der PowerShell wohl den Wert $env:USERPROFILE, was wohl das Pondon zu ~/ sein soll. Keine Ahnung. Da bin ich raus, versuche aber, das in der Videobeschreibung zu ergänzen.

 

[Benie]

Würde sich das mit Putty evtl. anders verhalten als auf der Windows Shell?

 

[Tommes]

Putty baut ja eine Verbindung zu einem Remote-System auf und agiert somit nicht lokal. Von daher wäre die PowerShell schon die richtige Wahl... oder halt WSL

Anderseits lässt sich mit Putty und puttygen natürlich auch eine SSH-Public-Key Verbindung zu einem Remoteserver herstellen, aber das war ja nicht Kern meines Videos.

 

[Hagen2000]

das es eigentlich nicht c:/Users/tommes/.ssh sondern wohl eher C:\Users\tommes/.ssh heißt

Windows akzeptiert beide Schreibweisen, das sollte also egal sein. Wobei Du auch den letzten Slash (vor .ssh) auch noch durch einen Backslash ersetzen könntest.

Statt des Tilde-Zeichens könntest Du generell $HOME verwenden, das funktioniert bei mir auch auf der PowerShell. Windows ist ein bisschen eigen, was die Expansion der Kommandozeile betrifft. Soweit ich mich erinnere, muss das jedes Programm selbst machen und es wird nicht auf Shell-Ebene durchgeführt.

 

[Hagen2000]

Solange auf dem NAS die Passwortauthentifizierung nicht abgeschaltet wird, können Brute Force-Attacken natürlich immer noch erfolgreich sein. Die Public-Key-Authentifizierung bringt in dieser Konstellation erst einmal nur einen Komfortgewinn.

 

[framp]

Solange auf dem NAS die Passwortauthentifizierung nicht abgeschaltet wird, können Brute Force-Attacken natürlich immer noch erfolgreich sein.

Das meinte ich eigentlich mit Login ist nur mit key moeglich. Ist aber gut das noch einmal ausdrueckich zu erwaehnen.

 

[Tommes]

Da habt ihr beide natürlich absolut recht bezüglich der Passwortauthentifizierung. Da ich aber meine Finger nie wirklich still halten und es somit durchaus mal passieren kann, dass ich ein System bzw. Teile davon schrotte, lasse ich in meinem internen LAN die Passwortauthentifizierung als Notnagel immer noch eingeschaltet.

 

[pr498te]

... somit hätten wir bereits einen ersten möglichen Fehler. Komisch ist halt nur, das man den kompletten Pfad nur bei der Erstellung des RSA-Keys angeben muss, ansonsten reicht hier das Tilde-Zeichen ~/ aus. Im weiteren Verlauf meines Tests konnte ich keine weiteren Probleme mehr feststellen, sondern alles so abarbeiten wie im YouTube Video bzw. in der Videobeschreibung vorgegeben. Hiervon ausgenommen sind nur die Ordner- und Dateirechte. Windows scheint das wohl egal zu sein. Keine Ahnung. Ist halt Windows

Ja, mit dem Tilde-Zeichen bin ich auch nicht weiter gekommen, ich mußte den voll qualifizierten Verzeichnisnamen angeben. Die Schlüssel sind dann auch in dem Verzeichnis C:\Users\[NAME]\.ssh gelandet. Soweit alles gut!

Mir ist noch aufgefallen, dass Du auf beiden System einen identischen Benutzernamen tommes verwendest - ich verwende unterschiedliche Namen. Das sollte aber nach meinem Verständnis nicht das Problem sein. Entscheiden ist doch, dass die Schlüssel korrekt erstellt und auf den kommunizierenden Systemen gefunden werden.