Ich persönlich sehe das mit ssh inzwischen recht entspannt.
Langes, sicheres Passwort, das man sich gut merken kann und nirgendwo aufschreiben muss und gut ist.
Man sollte sich eher um die Löcher sorgen, die durch die Anwendungen und den Webserver entstehen.
Langes, sicheres Passwort, das man sich gut merken kann und nirgendwo aufschreiben muss und gut ist.
Sehe ich ähnlich und bin auch selber ein fan von username max 12 - password min 32 und dann auch ohne GroßSonderZahl Schikanen aber SSHkeys sind einfach so bequem und mit bookmarks in Tramp unschlagbar.
so port 22 ist dicht - wireguard vpn ist up und local machine IP die einzige erlaubte
ich hab soviel gelernt in den letzten 24 stunden - Vielen Dank! 
den gepinnten thread von Bud hab ich in eine lokale referenz html konvertiert - wunderbar
server admin MaulHeld meldet sich zum Dienst.
Mir ist das Grundrauschen ehrlich gesagt Wumpe. Wenn der Rest abgesichert ist, gibt es keinen wirklichen Grund den SSH Port zu ändern, imho.
Wenn der Rest abgesichert ist, gibt es keinen wirklichen Grund den SSH Port zu ändern
Hast ja recht aber anomalien fallen bei klarer Sicht eher auf und wenn dann mal irgendetwas in der konfiguration beim basteln vermasselt wird hat man die 3 sekunden länger zum reparieren als wenn die standard luke mit heruntergelassenen Hosen dasteht. 
Ich ändere auch überall wo möglich den default Port vom sshd. Dann sind wirklich nur interessante Dinge im Log zu sehen. Hilft auch bei eventuellen ZeroDay Lücken, die sicher zuerst default Ports im Visier haben, außer man wird gezielt anvisiert. So gehe ich mit vielen Diensten um, bei denen man den Port ohne Nachteile ändern kann.
Und ich sag mal so: die zusätzliche "Maskierung" schadet in den meisten Fällen nicht. Bisher fahre ich damit sehr gut.
wenn man nun nur von einer maschine...
Man kann auch mehrere IPs freischalten.
Einige hier verwenden alternativ einen Jumphost:
PC/Handy/sonstiges > Jumphost > Server
Der Jumphost ist besonders gut abgesichert und nur dessen IP ist auf dem Zielserver für Remotesitzungen freigegeben.
Ich selbst profitiere mit so einem Jumphost auch vom schnellen Peering bei netcup. Einer meiner Server über'm Atlantik ist mit der TeIekom sonst zu lahm - mit netcup Jumphost hab ich volle Geschwindigkeit.
Wenn ich dich richtig verstanden habe, möchtest du dich per WireGuard mit mehreren unterschiedlichen Clients zu deinem WireGuard Server verbinden? Falls ja, einfach zusätzliche Peers einrichten
möchtest du dich per WireGuard mit mehreren unterschiedlichen Clients
Nein - ich wollte wissen wie ich ein backup erstellen muss damit ich, wenn der computer ins wasser fällt, meine sshkey wireguard vpn Verbindung auf einem anderen Computer wiederherstellen kann - intuitiv würde ich sagen ich sollte den .ssh Ordner extern speichern. Vielleicht reicht das?
so richtig habe ich es nicht verstanden. In erster Linie muss du nur die /etc/wireguard/wg0 sichern. Deinen SSH Private Key haste ja local zu liegen. Bei einem neuen Server Wireguard neu installieren und die wg0.conf zurücksichern und deinen Public Key wieder in die authorized_keys einfügen .
es geht nur um den client - meine local.machine - der virtuelle Server wird doch nicht ins wasser fallen ... Ich denke also .wireguard confs und .ssh ordner auf den Stick und fertig ist die Luzie. müsste reichen.
ich hab ja local nur die wireguard-tools glaub ich - nix in /etc
nebenbei bemerkt ist das sehr befriedigend sich um einen kleinen Server zu kümmern - hätte ich nicht gedacht.
Ich scheine meinen Server mit einer ganz anderen Philosophie zu verwalten:
– Ich schütze die Webdienste mit Basic-Auth, jeder Dienst hat sein eigenes Passwort. Gleichzeitig antwortet der Webserver auf alle Hostnamen, die Basic-Auth-Anmeldeinformationen anfordern.
– Ich habe fast alle gängigen Ports mit portspoof[1] geöffnet.
Die Idee ist: Ich verzichte auf zusätzliche Anstrengungen, um Grundrauschen zu reduzieren, gebe dem Angreifer aber gleichzeitig genug Grundrauschen, damit er aufgibt.
Honeypot wäre vielleicht ein besserer Ansatz, aber warum sollten mich die Script-Kiddies interessieren
gebe dem Angreifer aber gleichzeitig genug Grundrauschen, damit er aufgibt.
hört sich gut an wobei ich gedacht hätte das jeder bot erst aufgibt wenn er die 200 MB Traffic anfragen durch hat. Aber wenn das dem Server keine Arbeit macht, keine basic auth Schwäche besteht und kein echter Dienst versehentlich exponiert ist … wunderbare Strategie. Ich bin ja auch für KI Einsatz bei telemarketing Anrufen und so weiter
Ich habe fast alle gängigen Ports mit portspoof[1] geöffnet.
Ein interessantes Sicherheitskonzept, die Angriffsfläche eines Servers zu vergrößern anstatt zu verkleinern, mit einer seit mehr als 10 Jahren nicht mehr aktualisierten Software.
gebe dem Angreifer aber gleichzeitig genug Grundrauschen, damit er aufgibt
Das nennt sich dann wohl 'Security by perseverance'.
An dieser Stelle herzliche Grüße an alle DDoS-Angreifer, weiche dank Drop-Rules nicht mal wissen, ob auf meiner IP überhaupt ein aktiver Dienst läuft. Das dürfte auch für die Tauschbörse interessant sein.
Ein interessantes Sicherheitskonzept, die Angriffsfläche eines Servers zu vergrößern anstatt zu verkleinern, mit einer seit mehr als 10 Jahren nicht mehr aktualisierten Software.
genau das habe ich auch gedacht
Honeypot wäre vielleicht ein besserer Ansatz, aber warum sollten mich die Script-Kiddies interessieren
Ich habe mal eine zeitlang einen Honeypot auf Port 22 betrieben. (Und ssh verlegt)
Dabei habe ich dann kurze Zitate aus "Warten auf Godot" als Serverantwort zurückgegeben.
genau das habe ich auch gedacht
wenn du die installer-doku befolgst, ist es ein zwei jahre altes, ein-einzelner-unprivilegierter-port-honeypot-im-user-space-projekt.
und ziemlich genial, wie ich finde. 
Mag sein. Ich gehe eher den Weg, nur Ports zu öffnen, die tatsächlich nötig sind. Der Rest wird konsequent geschlossen.
