Ausgesperrt bei ssh?

[debiator]

Hi,

ich hoffe, es ist nicht das, was ich befürchte...
Beim Härten vom Server habe ich bei der Firewall alles soweit bedacht.
Bei der sshd.conf habe ich vermutlich aber irgendwas verbockt.

Ich habe die Anmeldung via keys und sie ist gelaufen und hat funktioniert.
Zwei Sachen, die damit zu tun haben könnte sind:

- 600 Rechte auf den Ordner mit den Keys
- explizite Useranmedung mit dem entsprechenden Usernamen.

Kann es sein, dass durch die 600, der User nicht mehr auf die Keyverifikation zugreifen kann und deswegen "permission denied (public key)" erscheint?

Dann wäre die Sache völlig verbockt und ich muss den Server neu aufsetzen, richtig?

Grüße
deb

[MSfree]

Kann es sein, dass durch die 600, der User nicht mehr auf die Keyverifikation zugreifen kann und deswegen "permission denied (public key)" erscheint?

Ja. Der Order sollte

Code: Alles auswählen

ls -ld .ssh/
drwx------ 2 root root 4096 Oct 18 21:27 .ssh/

sein.

Der Ordner muß also neben den Lese- und Schreib-Bit auch das Executable-Bit gesetzt haben.

Dann wäre die Sache völlig verbockt und ich muss den Server neu aufsetzen, richtig?

Nein, es sollte reichen, das Executable-Bit zu setzen.

[debiator]

danke schon mal!

ah, ich meine 0600 nicht 600

Folgendes habe ich vor Kurzem gesetzt:
chown root:root /etc/ssh/sshd_config
chmod og-rwx /etc/ssh/sshd_config
Das dürfte kein Problem geben, aber vermutlich Folgendes:

https://moisesmsf.github.io/hdcb/5-Acce ... onfigured/

Vielleicht ist das der Grund... war wohl zu schnell, ohne zu verstehen, inwiefern ich meinen user irgendwo raauswerfe.

Ich habe noch Zugang über die Konsole vom Provider, von daher, kanns noch richten... müsste nur wissen was

#Edit:
ssh für root ist gesperrt, ich verbinde mit einem user mit key.
Die Frage ist, wie der obige Skript das beeinflusst hat bzw. inwiefern.
Die Syntax und die Logik der Rechteverteilung verstehe ich noch recht wenig, muss ich zugeben.

[HumiNi]

ah, ich meine 0600 nicht 600

Ich denke, MSfree hat die wesentlichen Voraussetzungen genannt.

[debiator]

ok, ich habs!!

Es war der Eintrag
AllowUsers meinusername
in der sshd_conf

Stimmt die Syntax nicht?
Wie kann ich für einen user den Zugang restriktiv erlauben?

[MSfree]

ah, ich meine 0600 nicht 600

Leserecht = 4
Schreibrecht = 2
Executable = 1

6 = 4 + 2, also Lesen und Schreiben. Wenn es zusätzlich ausführbar sein soll 4 + 2 + 1 = 7.

Folgendes habe ich vor Kurzem gesetzt:
chown root:root /etc/ssh/sshd_config

Die Dateien gehören ohnehin root, das war also wirkungslos, hat also nichts geändert.

chmod og-rwx /etc/ssh/sshd_config

Die Datei ist bei mit "-rw-r--r--", was 4 + 2, 4, 4 entspricht, also 644. Solange die Datei nur für root beschreibbar ist, hast du kein Sicherheitsloch. In der Datei stehen auch keine Geheimnisse, die darf also ruhig von jederman lesbar sein. Der SSH-Dienst müßte aber (ohne Garantie) auch mit deinem chmod funktionieren.

Du hast aber vermutlich, das schließe ich aus deinem ersten Post, dem .ssh-Verzeichnis deines Benutzers das Execute-Bit entzogen, und dann klappt die Anmeldung garantiert nicht mehr, weil auf die Schlüsseldatei deines Benutzers nicht mehr zugegriffen werden kann.

Ich habe noch Zugang über die Konsole vom Provider, von daher, kanns noch richten... müsste nur wissen was

Du mußt eigentlich nur in deinem Benutzerverzeichnis

Code: Alles auswählen

chmod 700 .ssh

ausführen.

[debiator]

siehe oben, habs editiert und dein Beitrag erst jetzt gelesen.

Mit den Rechten muss ich mich wirklich mal vertieft befassen, ich kapiere sie einfach nicht nach zick mal lesen über die Jahre.
Vor allem der Sinn dessen wer auf was wann zugreifen darf, muss, soll oder nicht.
Aber das ist ein extra Thema.

Auf jeden Fall war der AllowUsers meinusername der Ausschlussfaktor meines Users.

[cosinus]

Wenn du grundsätzlich die Anmeldung nur via Key erlaubst, dann musst du dir klar sein, dass mit dem Verlust des Schlüssels, nichts mehr machen kannst. Ich finde es dann auch eher unsinnig noch die Anmeldung von User einzuschränken, wenn man per Passwort eh grundsätzlich nicht mehr reinkommt.

Um was für ein System geht es hier eigentlich? Testkiste daheim? Oder gemieteter Rootserver in irgendeinem RZ?

[debiator]

ist ein öffentlicher VPS, von daher macht es schon sinn den Passwortzugang zu cuten. Und wie es aussieht, komme ich eh über die Console vom Provider rein. Verstehe zwar nicht ganz warum, aber gut.

[cosinus]

ist ein öffentlicher VPS, von daher macht es schon sinn den Passwortzugang zu cuten. Und wie es aussieht, komme ich eh über die Console vom Provider rein. Verstehe zwar nicht ganz warum, aber gut.

Dann wäre vllt fail2ban besser?

Ich würde es so machen: root login verbieten, man kann nur mit User rein. Der darf es auch gerne per Passwort. fail2ban checkt dann auf fehlgeschlagene Loginversuche und sperrt dann die IP-Adressen nach zB zwei fehlgeschlagenen Versuchen.

Variante B: Grundsätzlich kein Login per Passwort erlauben. Dann musst du aber höllisch auf deine Keys aufpassen und auch eine vernünftige Verwaltung einführen. Wie viele User werden denn da eingerichtet, die ssh machen sollen?

[mat6937]

... nur mit User rein. Der darf es auch gerne per Passwort. fail2ban checkt dann auf fehlgeschlagene Loginversuche und sperrt dann die IP-Adressen nach zB zwei fehlgeschlagenen Versuchen.

BTW: fail2ban bis auch in Linux der sshd z. B. diese Konfigurationsmöglichkeiten hat:

Code: Alles auswählen

PerSourceMaxStartups 2
PerSourcePenalties authfail:300s max-sources4:3 min:3s refuseconnection:120s
PerSourcePenaltyExemptList 192.168.178.41,192.168.178.55
# ...
Match Invalid-User User <normaler_user>
	RefuseConnection yes

Code: Alles auswählen

:~$ sshd -V
OpenSSH_9.9, ...

[debiator]

Dann wäre vllt fail2ban besser?

der läuft bereits.
Feineinstellung habe ich noch nicht gemacht.

Ich würde es so machen: root login verbieten, man kann nur mit User rein. Der darf es auch gerne per Passwort. fail2ban checkt dann auf fehlgeschlagene Loginversuche und sperrt dann die IP-Adressen nach zB zwei fehlgeschlagenen Versuchen.

Klar, wäre auch ne Möglichkeit, aber wie es aussieht, kann ich eh über die Konsole vom Provider rein (vermutlich kann man bei einem VPS VNC und X11 gar nicht sperren??)
Dennoch muss ich natürlich auf die Keys aufpassen, klar.

Wie viele User werden denn da eingerichtet, die ssh machen sollen?

nur ich, also nichts Komplexes