Vorab: Ich bin bezüglich Linux noch ein „Lernender“. Habt bitte Geduld mit mir…
Mein Vorhaben: Ich möchte gerne einen personenbezogenen Admin-User einrichten, mit dem ich auch per SSH auf den Server komme (und dass dann zertifikatsbasiert ohne PW). Den User habe ich mir auf der WebGUI als globaler Admin angelegt, komme aber damit nicht per SSH auf den Server, da hier anscheinend nur root erlaubt ist.
Und da komme ich nicht weiter: Wo genau ist denn geregelt, wer per SSH drauf darf? Ich habe dazu weder unter /etc/ssh noch unter /etc/security noch unter pam etwas gefunden. Das Forum gab mir auch nichts her.
danke für die Erklärung, das werde ich dann so machen. Ist es sinnvoll, die Passwort-Authentifizierung für root dann komplett abzuschalten?
Das heißt also ich habe das missverstanden, der SSH-Zugriff ist gar nicht auf root begrenzt, es gibt nur einfach per Standard keine anderen für User gedachte Systembenutzer (und sollte es auch nicht geben), richtig?
Manche werden jetzt schreiben ja, ich denke aber, dass das keine zusaetzliche Sicherheit bringt, vorausgesetzt Du hast kein Passwort wie „1234“. Wenn Du Dein System ernsthaft sicherer machen willst, dann schiebe den ssh-Port von 22 auf irgendwas ueber 40000, dann findet ihn niemand, denn im Falle einer gravierenden Sicherheitsluecke im Open SSH-Server (ja, da war doch gerade was mit xz utils, gerade nochmal gut gegangen) fliegt uns das Internet sowieso um die Ohren, aber erstmal nur die Server, die auf Port 22 lauschen. Auf Port 40tausendirgendwas kommt kein Portscanner vorbei, da nimmt man lieber die tiefhaengenden Fruechte. Firewall anpassen dann aber nicht vergessen, man schliesst sich ja gerne selbst aus.
Auch dort wird der mobile Teil des keys (Zertifikat) mittels eines Passworts geschützt.
Denke damit ist der Public Key gemeint, der ist lediglich Teil eines Zertifikats. Hier sehe ich eigentlich ueberhaupt kein Zertifikat, denn bei zertifikatsbasierter Authentifizierung wird das Zertifikat und somit auch der darin befindliche und fuer die Authentifizierung benutzte Public Key von der CA signiert. CA sehe ich hier auch keine.
erstmal mußt du unterscheiden zwischen Login (per Keyboard am Rechner) und SSH Login.
Beim ssh Login sollte in jedem Fall dafür gesorgt werden, dass der keyboard (Passwort) Login abgeschaltet ist: nur ssh keys sollten erlaubt sein.
Und nein: der Zugriff per SSH ist nicht auf root begrenzt: tatsächlich ist im Default der Zugriff per SSH durch root nicht erlaubt. Wenn das bei dir geht, dann wurde das geändert in eurem System.
Du könntest einen weiteren Nutzer anlegen (unter ubuntu server) und diesenmit seinem eigenen ssh key reingehen lassen (einfach das entsprechende Verzeichnis erschaffen: ~/.ssh mit den richtigen rechten und den richtigen ssh-key Teil in die authorized_keys reinlegen: auch hier sind die Rechte essentiell!) und diesen Nutzer ann in die sudoers aufnehmen: er könnte dann, nach login per SSH mittels
sudo su
quasi zum root werden.
es reicht eigentlich den Weiterleitungsport in der OPNsense von 22 → 22 auf 40123->22 zusetzen: da brauchst du an der ssh config im Server nix machen
Ja, das hält viele BOTs erstmal ab.
Und wegen dem wiki Artikel: ja, das könnte exakter formuliert werden.
ich bin mir relativ sicher, dass das in der Grund- Config der lmn7-Appliance (7.0 als wir aufgesetzt haben) so drin war, wir haben es jedenfalls nicht geändert. Ich weiß nicht, wie andere arbeiten, aber wir sind eigentlich nur per Putty auf dem Server… (Allerdings nur aus dem LAN, von außen nicht erreichbar.)
Mir geht’s um den direkten Zugriff aus dem Schulnetz und um alle Server draussen. Die OPNsense hat bei uns keine grosse Funktion, Internet ist sowieso immer fuer alle offen und Angriffe kommen wenn, dann von innen, Linuxmuster ist von aussen nicht erreichbar.
Und wieso? Ich halte das nach wie vor fuer einen Mythos, so dumm kann kein Passwort gewaehlt sein, dass ein Bot das durchprobiert bekommt. Exploits auf ungepatchte Sicherheitsluecken sind nach wie vor das Hauptproblem. Pack von mir aus noch fail2ban dazu, wenn Dich die root-Versuche in /var/log/auth.log stoeren.
Jegliche Tipps um ssh sicherer zu machen beginnen aus meiner Sicht mit dem Verschieben von Port 22, dann ist das auch erledigt und fail2ban kriegt auch nix mehr zu tun.
Du kriegst ja auch bei jedem root-Server draussen erstmal ein root-Passwort per Mail geschickt.
Ich glaube uebrigens auch, dass der root-Login in der sshd_config per default erlaubt war, kann mich da aber taeuschen.
Zumindest bei nackten root-Servern wie bei Hetzner etc.
Das ist auf jeden Fall zu empfehlen.
Ich habe mir mal ein Script geschrieben, was mir die verwendeten User-Namen und die angreifenden IPs ausgibt.
VG Andreas
Ich würde mal sagen, dass wenn ich beim Provisioning in der Cloud Console einen SSH Schlüssel hinterlege, dann wird auch ein Schlüssel verwendet.
Es ist einfach nicht State of the art Passwörter zu verwenden. Ein Passwort kann einfach abhanden kommen. Ein Passwortgeschützter Schlüssel hingegen ist nicht so einfach auszuspionieren. Aber ich sehe schon, die richtigen Experten sind hier vorhande. Bei der IT Security gibt es nicht die EINE Funktion die alles sicher gestaltet.
Ihr könnt das aber alle handhaben wie ihr wollt, ist halt unprofessionel
Port verschieben kann man schon machen, das hält einem wie du schon richtig sagst viele Scanner vom Hals. Gegen einen gezielten Angriff hilft das aber nicht, ich kann ja prüfen auf welchen Port dein SSH Dienst lauscht.
Ich selbst mache das nicht oft aus Bequemlichkeit. Da ich den Login auf Schlüssel beschränke, sehe ich da kein Problem, schaden würde es aber auch nicht.
Man kann auch einen GeoBlocking konfigurieren, schlägt in eine ähnliche Kerbe wie das verschieben des Ports. Ich kann auch den Root Login generell verbieten. So muss ein Angreifer auch noch den Usernamen in Erfahrung bringen. Als dieser User angemeldet kann ich mich dann als Root anmelden.
Schlussendlich muss man sich der Angriffsvektoren bewusst sein und abwägen wie viel Aufwand einem die Sicherheit Wert ist.
Das schöne beim Verwenden von SSH Schlüsseln ist aber, dass es überhaupt nicht unbequem ist. Der Nutzerlogin entsperrt dir die Keychain, die wiederum den passwortgeschützten SSH Schlüssel. Uch muss gar kein Passwort eingeben wenn ich mich auf einen Server verbinde und habe dennoch eine erhöhte Sicherheit.
Habe ich mir bei meinem root-Server auch schon öfters überlegt, nur manchmal haben wir auch Leute die nicht in der BRD sitzen. Aber bei öffentlichen Schulen, halte ich das schon für eine gute Maßnahme.
Der sollte immer verboten sein!
Genau, in Kombination mit verbotenem root-Login ist das schon recht sicher. Dann noch mit fail2ban absichern und es ist schon eine Grundsicherheit gegeben.
Wenn ich mir meine „Auswertungen“ immer mal wieder anschaue, wird es mit root kaum versucht.
Wer Interesse an meinem bzw. zwei Scripte hat, gerne PM.
Es liest die /var/log/auth.log aus, per grep werden User und IP seperiert und dann an mich per Mail(cronjob) geschickt.
Ist mehr Spielerei …
VG Andreas
Ich hab draussen auf einem Server portsentry laufen und seit bestimmt 10 Jahren keinen einzigen Portscan auf einem Port > 50000 gehabt, sprich der ssh-Server wurde nicht ein einziges Mal da oben gescannt, das laufende fail2ban hat genau nichts zu tun auf dem ssh-Port.
Das was Du da so schreibst steht in jedem „Expertenhandbuch“, dummerweise fliegt der der ganze Scheiss um die Ohren wenn es einen Exploit fuer den ssh-Server gibt und die Gefahr ist um ein Vielfaches hoeher als dass das root-Passwort „abhanden“ kommt.
Natuerlich kann man die Gefahr eines Exploits fuer Open SSH herunterspielen, aber nach der XZ-Sache gerade wird Dir das keiner mehr glauben, die Expertenhandbuecher muessen also erweitert werden.
Wenn ich die Analyse der xz-Backdoor jetzt richtig verstanden habe, funktioniert sie sowieso nur bei Schluesselauthentifizierung und nicht bei der mit Passwoertern, nur mal so nebenei.
Wann war das so? 1998?