RootServer, absichern (user: root für SSH sperren?)

[bastilein]

Hallo ich besitze einen OpenSuse Rootserver, den ich aktuell zuHause angebunden habe,
nun würde ich gern den user Root Sperren? (geht dasüberhaupt?)

ich finde das root ein user ist den jeder "Hacker" als erstes Versucht als user anzurufen und das PW rauszufinden,

nun würde ich den user Root gerne sperren,
und z.b User: XyzP234 als root user anlegen,
oder evtl. als normalen user und über su root mir die rootrechte holen falls ich sie den zu Wartung und Sec Updates brauche.

nun Meine Frage
geht das das man den User root sperrt so das er nicht mehr direkt über SSH erreichbar ist ?
und wie lege ich einen neuen User an, der zu 100% nicht von Plesk gelöscht wird? und SSH Rechte erhält.

Über ein Kleines HowTo würde ich mich freuen,
ich Arbeite mich aktuell langsam an die RootServer Kenntnisse herran.


System: OpenSuse10.3
MySql: 5.x
Plesk 9.x

MFG Basti

[bastilein]

das hilft mir schon viel weiter, werde das heut abend gleich mal probieren ;)

und wie erstelle ich einen user der nicht von Plesk gelöscht wird?
alle user die ich versuchte mit yast anzulegen, wurden nach einem neustart von plesk oder dem system entfernt... :?

und wenn ich direkt nach einrichten des users versuchte mit SU auf ihn zu wechseln erhielt ich die information, shellzugriff mit diesem User nicht erlaubt

[Roger Wilco]

Benutze `useradd` um einen Benutzer hinzuzufügen und `passwd` um ein gültiges Passwort zuzuweisen. Welche Meldungen erhältst du, nachdem du den Benutzer angelegt hast und versuchst dich mit ihm einzuloggen?

[bastilein]

^mit useradd bleibt der user erhalten ;)

wenn ich yast nutze leider nîcht,

da kommt kein fehler, aber wenn Plesk nen rehash macht oder nen reset aller verwalteten Dienste
ist der user einfach weg ;)


aber mit Useradd bleibt er ;))

ty

[bastilein]

Ich weiss ja nicht, was an Deiner Pleskinstallation nicht stimmt, aber normal ist das auf jeden Fall, nicht.

in diese
hmm ist nur ne Testversion mit OpenSuse 10.3 aufgesetzt auf einem HomeServer, kann sein das da einiges Falsch ist, aber wie gesagt möchte mich erst einarbeiten bevor ich mir einen Virtual oder sogar RootServer zulege, und zum üben reicht das eben ;)


zum RootSperren:

Code: Select all

PermitRootLogin no
AllowUsers <Benutzer>

muss ich da jeden User mit einem Komma Trennen? und für rootlogin auf yes umstellen?


also z.b.

Code: Select all

PermitRootLogin yes
AllowUsers <testuser123; testuser234; testuser567>

und was bringt mir der OpenSSH Public Key Authentication ? http://sial.org/howto/openssh/publickey-auth/
ist das nötig ? was bringt es mir genau? wie funktioniert es?

[daemotron]

Code: Select all

PermitRootLogin no
AllowUsers <Benutzer>

muss ich da jeden User mit einem Komma Trennen? und für rootlogin auf yes umstellen?

Nein, mit Leerzeichen trennen (siehe man sshd_config). Also z. B.

Code: Select all

AllowUsers xyz abc def

PermitRootLogin auf no lassen (engl. "to permit" = "erlauben"), um den Direktzugriff für root zu unterbinden.

und was bringt mir der OpenSSH Public Key Authentication ? http://sial.org/howto/openssh/publickey-auth/
ist das nötig ? was bringt es mir genau? wie funktioniert es?

Die meisten Brute Force Angriffe versuchen, Passwörter zu erraten. Wenn Dein Server gar keine Passwort-Authentifizierung unterstützt, laufen diese Angriffe schon mal komplett ins leere. Sollte mal jemand tatsächlich versuchen, einen Key zu erraten, zeugt das von mangelnder Intelligenz: Bei ausreichend groß gewählter Schlüssellänge (2048 oder 4096 Bit) dauert ein Brute Force auf den Schlüssel im Schnitt mehrere Milliarden Jahre. Grundsätzlich gilt aber bei Keys dasselbe wie bei Passwörtern: den geheimen Schlüssel bloß nicht irgendwo rumliegen lassen...

Organisatorisch liegt der Vorteil darin, dass Du ein Schlüsselpaar für viele Server verwenden kannst. Zusammen mit ssh-agent brauchst Du das Entsperr-Passwort auch nur einmal eingeben, danach funktionieren SSH-Verbindungen (incl. SCP und SFTP) aus dem Stand ohne Angabe eines Kennworts. Außerdem erspart es Dir, regelmäßig neue, lange, komplizierte Passwörter auswendig zu lernen.

[bastilein]

oh ok, das mit dem auth key hört sich überzeugend an, aber da habe ich jetzt sehr viel respekt davor...
kann ich mich da komplett ausperren wenn ich mit dem auto key einrichten was falsch mache?
wäre dann über nen HowTo in deutsch doch etwas erfreuter :oops:

[daemotron]

Dafür haben wir doch unser Wiki :D
Einfach mal die folgenden beiden Abschnitte beachten:
http://www.rootforum.org/wiki/FreeBSD_m ... er_anlegen
http://www.rootforum.org/wiki/FreeBSD_m ... _absichern

oder hier:
http://www.rootforum.org/wiki/Gentoo_Ha ... figurieren
http://www.rootforum.org/wiki/Gentoo_Ha ... er_anlegen
(wobei ich lieber den Schlüssel per PuTTYGen erzeugen würde und den Public Key auf den Server kopieren würde - alles andere ist bei produktiven Systemen im Netz ein unnötiges Risiko)

P. S. natürlich kann man sich aussperren, wenn man Fehler bei der SSHd-Konfiguration macht. Deswegen würde ich
a) immer eine SSH-Session offen lassen
b) die laufende Konfigurationsdatei nicht platt überschreiben, sondern kopieren
c) erst mal das generierten Schlüsselpaar testen - PubKey-Auth funktioniert i. d. R. auch schon ohne Änderungen an der sshd_config.

[rudelgurke]

Zum Thema "selbst aussperren" - bevor die Konfiguration geändert wurde SSHD neu starten - normalerweise dürfte die Verbindung aktiv bleiben - noch mit den alten Einstellungen.
Ist dies der Fall, die Konfiguration entsprechend ändern, dann SSHD neu starten und den Login versuchen - so hat man wenigstens noch die Chance eine entsprechend falsche Konfiguration zu bearbeiten.
Alternativ könnte man einen Cronjob aufsetzen der eine gesicherte Konfiguration als Backup einspielt und SSHD neu startet - vielleicht aller 5 Minuten damit genügend Zeit ist diesen Cronjob zu beenden wenn alles gut geht - dass vor allem machen wenn alles gut geht !
Etwas einfaches wie:

Code: Select all

#!/bin/sh
if [ ! -f /root/sshd_backed_up ];
 mv /etc/ssh/sshd_config_working /etc/ssh/sshd_config
 /etc/init.d/sshd restart
 touch /root/sshd_backed_up
fi

Dürfte schon reichen - hier wird eine kleine temporäre Datei angelegt die, falls sie existiert, an der bestehenden Konfiguration nichts ändert.

Dass bitte nur als Workaround sehen - keinesfalls zum täglichen Arbeiten geeignet um Fehler auszuschließen :)