ssh-Zugriff zu einem shared webspace absichern/kontrollieren

Hoi,
ausser einem starken pw fällt mir leider nichts weiteres ein. Ein vserver ist mir zu teuer.
Ich habe zu meinem shared webspace eine Konsole, jedoch kein root-Recht,
Ich kann über eine externe Testseite schauen, wie es serverseitig mit der ssh-Konfig aussieht, aber eben nur schauen.
Als allermindeste würde mit schon ein Zugriffsprotokoll reichen. Dazu sehe ich aber nichts in meinem online webspace-tool und ssh temp. deaktivieren geht hier auch nicht.
Hat jemand eine Idee? Ist allgemein, daher ohne details.

Warum solltest du mehr als ein gutes Passwort bzgl. SSH-Absicherung benötigen? Dein Provider kümmert sich und das sollte dir reichen. Und wenn nicht dann brauchst du eben einenen eigenen Server. Sei froh, dass du nicht mit FTP oder irgendwelchen unsicheren Webkonsolen arbeiten musst. Zudem wer sollte deinen Account und dann auch noch über SSH hacken? Dann wohl eher über die Anwendung Nextcloud selbst. Du nutzt 2FA in Nextcloud?

Vielleicht kannst du statt eines Passwortes auch SSH-Keys verwenden. Das wäre weit sicherer.

Ich empfehle die Verwendung eines Zertifikates für den ssh-Zugriff, wenn der Hoster dies erlaubt. Siehe hierzu:

https://itwelt.org/anleitungen-howto/linux-740817696/343-ssh-mit-key-authentifizierung-einrichten

1 Like

2fa habe ich natürlich, login über Zertifikat geht leider nicht.

Na ja, dann musst Du dir sicherlich kaum Sorgen machen, dass alleine das Knacken des Kennwortes schon einen Systemzugriff erlaubt. Damit bist Du meines Erachtens schon sehr viel besser aufgestellt als die meisten Anwender.

Danke erst mal ihr beiden.
Zu dem ssh-Zertifikat: ich sehe im WinSCP schon gar kein
/etc/ssh/sshd_config, habe ja auch kein root-Recht
/home/.ssh hätte ich ja.

@j-ed, wie meinst du das?
Wenn jemand mein ssh pw und login-Daten hat (oder den Kundenportal-login), liest man nicht selten, dann hat er den zentralsten Ort meiner nextcloud-Webseite.

Aber ich sehe schon, ein login über ein eigenes ssh-Zertifikat wäre eine Lösung.
Ist das Systembedingt auf einem shared host überhaupt möglich?
Oder überall eine 2FA.

Was bleibt mir da noch übrig zu unternehmen mit meinem günstigen shared host, alles was 100%ig in meiner eigenen Hand liegt: Daten clientseitig verschlüsseln und regelmäßig saubere, versionierte Backups vom home durchführen.
Ein vserver ist auch kein Allheilmittel, den muss man erst mal selber konfigurieren.

Um einen per Schlüssel abgesicherten Zugriff einzurrichten braucht es keinen Zugriff auf die Datei /etc/ssh/sshd_config, da alle relevanten Dateien im Unterverzeichnis .ssh in Deinem Home-Verzeichnis abgelegt werden. Hier wird beschrieben wie dies mit WinSCP einzurichten ist:

https://winscp.net/eng/docs/guide_public_key

Du schreibst, dass Du 2FA für den SSH-Zugriff eingerichtet hast, dass heißt einen Anmeldung ist nur mittels des Kennwortes und einem zweiten Faktor (2FA), wie z.B. einer PIN oder einer Authenticator-App, möglich. Selbst wenn somit Dein Kennwort in die falschen Hände gerät ist keine Anmeldung möglich, da hierzu der zweite Faktor eingegeben werden muss.

Wenn ich eine 2fa für ssh hätte, hätte ich diesen post gar nicht eröffnet.
Gibts für ssh überhaupt 2fa.
Ich müsste dem server „sagen“, dass ich keine pw Authentifikation möchte, ohne Zugriff auf die server-sshd_config geht das wohl schlecht.

Ich wollte nur Möglichkeiten bezüglich ssh Sicherheit ausloten, wie erwartet nichts Neues auf einem shared host.

SSH-Keys sind Schlüssel und somit eine Art zweiter Faktor ohne ersten Faktor.

Na ja, dann soltest Du demnächst Deine Frage präziser formulieren :wink: Natürlich gibt es eine 2FA-Möglichkeit für SSH, sonst hätte ich ja nicht angenommen dass Du dieses meinen würdest. Siehe z.B.

https://www.thomas-krenn.com/de/wiki/SSH-Login_mit_2-Faktor-Authentifizierung_absichern

Na ja, dies ist schon sehr großzügig interpretiert :wink: Der Schlüssel wird als Alternative zu einem Kennwort verwendet und NICHT als Ergänzung. Somit kann man hier genau genommen nicht von einer 2FA-Authentifizierung sprechen. Eine weitere Besonderheit einer 2FA-Authentifizierung ist auch, dass der zweite Faktor über einen alternativen Kommunikationsweg verifiziert wird, was in diesem Fall ebenfalls nicht gegeben ist.

Naja. Aber der Private Key verlässt den Client auch nie im Gegensatz zum Passwort.

Wir drehen uns im Kreis, lassen wir es!
Im ersten Post steht: “…jedoch kein root-Recht…”
Alle Verlinkungen verlangen ein $ sudo ...

Ich kann aber folgendes festhalten: auf einem shared host sind folgende Punkte vermutlich bei jedem Anbieter ungenügend. Das hat erst mal nichts mit einer vernünftigen nextcloud Installation zu tun, die lässt sich fast immer gut absichern, wie ich sehe, zumindest mit 2FA.

Aber der Sicherheitsknackpunkt liegt hier:

  1. Kundenlogin (Webadmin), 2FA fehlt fast immer -> schlecht, da mit einem Kundenlogin sowieso alles offen ist!!!
  2. ssh, login nur mit pw -> schlecht, da mit einem ssh-Zugriff alles offen liegt.
  3. womöglich habe ich gerade nicht mehr parat.

Ja. Aber viele Anwender wollen es einfach und billig.

@devnull, für den Betreiber sind das 2 Serverinstallationen:

  1. für ssh $ sudo apt install libpam-google-authenticator
  2. für den Kundenlogin wie bei nextcloud oder 1. mit verwenden, wenn möglich

wo ist da ein Problem; es ist einfach nur die Faulheit vieler Webhostinganbieter (hier explizit nicht nur shared).
Ich sehe den Aufwand ja selber bei meiner nextcloud-Inst., 2FA für alle bedingungslos fordern oder optional aktivieren. Das sind paar Klicks und die 2FA Software sollte alles im besten Fall selber erledigen. Und ich kenne auch den Teufel im Detail, den ich bei meiner Inst. jedoch noch nicht erkennen konnte.
Naturgemäß entsteht dies doch nicht ganz magisch, etwas Aufwand ist schon notwendig, aber dieser Aufwand ist im Vergleich zur entstehenden Sicherheit der Benutzer fast vernachlässigbar.
Aber was will ich hier überhaupt? Bevor Benutzer nicht die Notwendigkeit einer 2FA erkennen und dafür kämpfen, ändert sich nichts - dies sollte eigentlich ein Pflicht-Teil der DSGVO sein. DSGVO Verantwortliche sind aber in vielen Bereichen eher überfordert und agieren mit DSGVO-Beschlüssen sogar gegen Benutzer.

1 Like