SSH Key / root Login

[Legolas]

Hallo zusammen,

ich hab da eine Verständnissfrage. Ein Freund hat mir erklärt das es ein Mehr an Sicherheit gibt wenn man den Zugang zu einem Server bei einem Provider, z. B. Hetzner, mit einem SSH Key absichert. Nun hab ich das mal ausprobiert. klappt prima. Der User root existiert ja aber trotzdem. Hat der dann standarmässig kein Passwort? Wenn man sich von Rechnern aus aus einloggen will auf denen der private Key nicht vorhanden ist wird ja ein Passwort verlangt. Soll man dem root dann vorsichtshalber trotzdem noch ein PW vergeben?

Danke
SW

 

[pc_user123]

Ja. Immer dem Root ein Passwort vergeben. Und nicht verlieren

 

[SirKhan]

Root sollte auch ein Passwort haben.
Wenn das mit den login via SSH-Key funktioniert, kann man, um die Sicherheit weiter zu erhöhen, den Login via Passwort auch komplett abschalten. Dazu in der /etc/ssh/sshd_config PasswordAuthentication auf no umstellen (siehe auch z.B. hier).
Dann aber entweder sicherstellen, dass der andere Account auch genug Rechte hat um das System zu verwalten (z.B. via sudo), oder auch beim root-Account den public-key für das SSH-Key-Login hinterlegen. Also vor deaktivierung des Passwortlogins ^^
Und evtl. noch einen weiteren Rechner autorisieren. Oder den eigenen private-Key sicher sichern. Nur um sicher zu gehen.

 

[0x8100]

Hat der dann standarmässig kein Passwort?

bei einigen distributionen ist der passwortzugang für root deaktiviert:

# grep root /etc/shadow
root:*:15478:0:99999:7:::

also "*" statt einen hashes. siehe https://linux.die.net/man/5/shadow:

If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means).

in dem fall braucht man kein passwort setzen - der login ist einfach nicht möglich und es kann auch kein passwort verloren gehen. grundsätzlich sollte man sich nie direkt als root einloggen.

 

[foofoobar]

Wird blöd wenn man sich die sudoers zerschießt und keinen richtigen/vollständigen physikalischen Zugang zu der Maschine hat.

So kann man sich lustige PWs generieren:

openssl rand 32 -base64

 

[Joshinator]

Ich würde dem Root generell den SSH Login deaktivieren, keiner sollte sich direkt als Root einloggen können (weder der Admin, noch ein Angreifer).
Also per PermitRootLogin in der sshd config auf no.

Die User die root-rechte brauchen können das per sudo pro Befehl machen.
Nochmal ein extra Sicherheitslayer, erst muss sich ein normaler User mit Username + Key einloggen, und dann gibts Root-Rechte nur per Passwort pro Befehl.

 

[Legolas]

Ok,

nutzt jemand von Euch auch blocklist.de?

Danke
SW

 

[andy_m4]

nutzt jemand von Euch auch blocklist.de?

Kann man im Prinzip machen. Man sollte aber die Liste sicherheitshalber nicht blind übernehmen, weil es sonst versehentlich passieren kann, das man sich selbst aussperrt. Bevor man die "applied" sollte man gucken, ob da IP-Adressen aus dem Kreis dabei sind, aus dem man selbst potentiell drauf zugreifen will.
Und man muss auch gucken, welche Dienste (also Ports) man damit zu macht. Bei ssh brauchst Du nur auf Dich selbst gucken. Aber wenn Du z.B. einen Webserver drauf laufen hast, wo noch andere Leute außer der drauf zugreifen, dann muss Du auch da natürlich gucken das die nicht versehentlich ausgesperrt werden.

Ein alter Trick sich gegen ssh-Angriffe zu schützen, der aber nach wie vor noch seine Wirkung erzielt ist, den SSHd-Daemon auf nen anderen Port als Standardport 22 lauschen zu lassen (vor der Änderung aber gucken, das der Alternativport auch in der etwaig vorhandenen Paketfilter/Friweall-Config frei ist; sonst kann man nicht mehr rein).
Ne weitere Möglichkeit ist das Port-Knocking. Das der Port überhaupt erst geöffnet wird, wenn man ne bestimmte Paketfolge hinschickt. Sonst erscheint der als closed. Das lässt dann so angriffsvorbereitende Portscans in die Irre führen.

Paketfilter/Firewall-Änderungen haben natürlich immer das Potential, das man sich versehentlich selbst aussperrt. Im Idealfall kannst Du Deinen Server sowohl über IPv4 als auch IPv6 erreichen. Dann kannst Du via IPv6 Änderungen der IPv4-Regeln machen und umgekehrt.

 

[netzgestaltung]

Fail2Ban wäre da noch zu erwähnen. Der Port 22 lässt sich ggf auch bei einer vorgeschaltenen Firewall/Router appliance sperren und dafür eine Port-Weiterleitung über einen beliebigen (nicht häufig genutzten) Port eintragen(zb 22222)

 

[Legolas]

Fail2ban nutze ich schon. Wg. dem Port ist mein Problem das ich per SSH aus unterschiedlichen Netzen auf die Maschine zugreifen muss und da ist das mit höheren Ports manchmal schwierig weil die manchen Netzen nicht offen sind

 

[andy_m4]

Maschine zugreifen muss und da ist das mit höheren Ports manchmal schwierig weil die manchen Netzen nicht offen sind

Es muss ja nicht zwangsläufig ein höher Port sein. Du kannst Dir ja im Prinzip ein beliebigen Port aussuchen der nicht für was Anderes benutzt wird.
Aber ja. Man muss natürlich auf die Gegebenheiten gucken.

 

[0x8100]

wenn es denn ssh mit passwort sein muss, dann sollte man auch 2fa machen -> https://wiki.archlinux.org/title/Google_Authenticator damit hat man auch gleich ein rate-limiting, falls fail2ban noch nicht laufen sollte.

 

[Iqra]

Actually...

... Root kann durchaus KEIN Passwort(read: ein ungültiges) haben, wenn man den als nologin konfiguriert (wie auch immer) und dann sudo ordentlich einrichtet. Natürlich kann man root erst "ausmachen" NACHDEM sudo richtig konfiguriert ist.
Dazu zB einen dedizierten User anlegen, der als Admin dienen soll, und den dann auch nur dafür verwenden und nur für diesen "sudo root" erlauben.

SSH erlaubt es außerdem, einmal für den root Account und einmal für alle anderen den Zugang zu konfigurieren, insbesondere in der Form, daß eine Anmeldung über SSH entweder gar nicht geht (für root) oder daß es nur mit dieser-oder-jener Anmeldeform geht ("nur mit pubkey").

Ein root hat nicht über die Leitung zu gehen, auch nicht mit SSH, nicht mit key und erst recht nicht mit Paßwort. Daher idealerweise rootlogin auf no setzen, mit dem "normalen" Benutzer per pubkey anmelden (den Rest ausstellen, aber dann den privkey gut festhalten) und dann wenn man verbunden ist, mit sudo in den richtigen Kontext wechseln.