Beiträge von toe

    Zitat von fLoo;10658

    (...) für sowas bezahlt man sonst entweder ne Stange Geld oder man baut es sich selbst :rolleyes:

    Ich hab da von dieser Open-Source Sache gehoert, die momentan total in sein soll ;)

    Nix fuer ungut, ist nachvollziehbar, wenn du deine Sourcen nicht rausgeben willst. Wobei es (und ich bezweifel nicht, dass du das selbst weiszt) eine Vielzahl von sehr guten Projekten gibt, die das anders sehen.

    *husthustlinuxhust* :D

    Hab den Uebeltaeter gefunden:

    Code
    hostname:~# aptitude why portmap
    i   lighttpd Hängt ab  libfam0
    i A libfam0  Empfiehlt fam (= 2.7.0-13.3)
    i A fam      Hängt ab  portmap

    Fam kann also weg und portmap verschwindet dann auch gleich...

    nmap hat mir einen offenen Port angezeigt, den ich nicht zuordnen konnte.

    Die Oeffnung des Ports war nicht beabsichtigt, offenbar laesst der sich per Eintrag in der /etc/default/portmap schlieszen bzw. auf localhost beschraenken.

    Spricht da etwas dagegen? Oder besser eine Filterregel?

    Code
    hostname:~# netstat -tulpen
    Aktive Internetverbindungen (Nur Server)
    Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
    tcp        0      0 127.0.0.1:12525         0.0.0.0:*               LISTEN      0          447265150   15168/policyd-weigh
    tcp        0      0 188.40.*.*:111       0.0.0.0:*               LISTEN      0          253126832   19323/portmap
    tcp        0      0 188.40.*.*:143       0.0.0.0:*               LISTEN      0          107315948   3496/imap-login
    tcp        0      0 188.40.*.*:24        0.0.0.0:*               LISTEN      0          107315597   8463/sshd
    tcp        0      0 188.40.*.*:25        0.0.0.0:*               LISTEN      0          447271429   15322/master
    tcp        0      0 188.40.*.*:993       0.0.0.0:*               LISTEN      0          107315949   3496/imap-login
    udp        0      0 188.40.*.*:111       0.0.0.0:*                           0          253126831   19323/portmap

    Da erstmal alles laufen soll, bevor ich die Domain(s) auf meinen vServer schalte, habe ich in den letzten Tagen die verschiedenen Dienste ueber die Domain mein_hostname.yourvserver.net getestet.

    Gerade eben habe ich jedoch festgestellt, dass die Domain nicht mehr erreichbar ist.

    Zitat

    toe@nintropan:~$ ping v***************.yourvserver.net
    ping: unknown host v***************.yourvserver.net

    Per IP komme ich aber nach wie vor an den vServer.

    Weisz jemand Rat?

    Wuesste ich aus dem Stegreif nicht.

    Ich wuerde da auf jeden Fall zu Redundanz raten. Ich habe bei mir auf Laptop, Desktop und Homeserver jeweils einen RSA-Schluessel (also insgesamt drei). Alle drei RSA-Schluessel sind in der ~/.ssh/authorized_keys des vServers eingetragen.

    Falls mir mal eine der drei Kisten abraucht, habe ich also noch zwei weitere gueltige Schluessel, mit denen ich an den Server rankomme.

    Ein Login unter vservercontrolpanel.de ist nicht moeglich.

    Ich habe ausprobiert:

    Kundennummer, Ursprungspasswort
    Kundennummer, geaendertes root-Passwort

    Zitat

    Please check your login data! Either username or password were incorrect!

    Bei der Erstinstallation fehlen Public Keys. Nicht weiter wild, aber doch irgendwo unschoen ;)

    Danke fuer deinen Kommentar.

    Pro Rechner (Desktop, Laptop, ...) habe ich einen RSA-Schluessel. Diese habe ich mittels ssh-copy-id zur ~/.ssh/authorized_keys des vServers hinzugefuegt.

    ~/.ssh/id_rsa
    ~/.ssh/id_rsa.pub

    Dadurch, dass die RSA-Schluessel jeweils im Standardpfad liegen, spare ich mir uebrigens die -i Option mit expliziter Schluesselangabe.

    Eine Beschraenkung auf RSA-Authentifizierung habe ich mir auch schon ueberlegt (Punkt 3 der Zusammenfassung). Falls mir nix mehr einfaellt, was dagegenspraeche, werde ich das auch entsprechend umstellen.

    Eine feste IP kommt fuer mich nicht in Frage. Ich gehe von sehr vielen verschiedenen Netzen (Hochschule, Zuhause, Eltern, Freunde, ...) aus online. Darueber hinaus haben die meisten der Netze dynamische IPs.

    Benutze seit Jahren ausschlieszlich Linux und habe jetzt meinen ersten vServer bestellt.

    Ich werde hier mal reinschreiben, was meine ersten Schritte waren und sind. Einerseits als Hilfestellung fuer andere Anfaenger, andererseits um evtl. hilfreiche Kommentare von euch zu bekommen.

    • Login, Passwortaenderung:
      user@workstation:~$ ssh root@my_vserver
      root@my_vserver:~# passwd
    • Anlegen eines normalen Benutzers:
      root@my_vserver:~# adduser my_user
      root@my_vserver:~# exit
    • RSA-Key hinzufuegen:
      user@workstation:~$ ssh-copy-id my_user@my_vserver
    • Testen:
      user@workstation:~$ ssh my_user@my_vserver
      my_user@my_vserver:~$ su -
      root@my_vserver:~# exit
      my_user@my_vserver:~$ exit
    • SSHD-Konfiguration anpassen
      user@workstation:~$ ssh my_user@my_vserver
      my_user@my_vserver:~$ su -
      root@my_vserver:~# vi /etc/sshd_config

      • Zeile aendern: PermitRootLogin no
      • Zeile hinzufuegen: Port 24
        (prinzipiell beliebig; empfehlenswert ist ein unbenutzter Standardport, damit man auch von Rechnern hinter restriktiven Firewalls (Arbeitsplatz, Hochschule, ...) aus zum Server durchkommt)
      • Zeile aendern/hinzufuegen: MaxStartups 3:30:10
        (Die Werte im Beispiel bedeuten, dass 2 (= 1. Wert minus 1) "unauthenticated" (also im Login-Stadium befindliche) sshd-Verbindungen immer erlaubt sind. Ab der 3. (= 1. Wert) Verbindung wird mit einer Wahrscheinlichkeit von 30% (2. Wert) die Verbindung abgelehnt. Diese Wahrscheinlichkeit steigt linear an, bis bei 10 (3. Wert) offenen Verbindungen jeder weitere Verbindungsversuch zu 100% abgelehnt wird.)
    • neue Konfiguration laden und sshd neu starten:
      root@my_vserver:~# /etc/init.d/ssh reload
      root@my_vserver:~# /etc/init.d/ssh restart
    • Testen in neuer Shell. Die bestehende Shell-Verbindung nicht trennen, bevor sichergestellt ist, dass die Konfigurationsaenderung erfolgreich war und funktionsfaehig ist.
      user@workstation:~$ ssh -p 24 my_user@my_vserver
      my_user@my_vserver:~$ su -
      root@my_vserver:~# vi /etc/sshd_config

      • Zeile "Port 22" auskommentieren
    • neue Konfiguration laden und sshd neu starten:
      root@my_vserver:~# /etc/init.d/ssh reload
      root@my_vserver:~# /etc/init.d/ssh restart
    • Passwort-Authentifizierung deaktivieren
      user@workstation:~$ ssh -p 24 my_user@my_vserver
      my_user@my_vserver:~$ su -
      root@my_vserver:~# vi /etc/sshd_config

      • Zeile auskommentieren/aendern: PasswordAuthentication no
    • neue Konfiguration laden und sshd neu starten:
      root@my_vserver:~# /etc/init.d/ssh reload
      root@my_vserver:~# /etc/init.d/ssh restart

    Zusammenfassung:

    • SSH laeuft ueber einen alternativen Port (reduziert die Anzahl an Brute-Force-Angriffen drastisch)
    • root-Login ist per SSH nicht mehr moeglich
    • Authentifizierung ausschl. per RSA-Key
    • Beschraenkte Anzahl gleichzeitiger Login-Vorgaenge (weniger Serverauslastung durch massenhafte Loginversuche)

    Habe ich etwas wichtiges vergessen? Sollte ich irgendwas anderes machen? Kommentare?

    Ich habe bei mir auf dem Laptop den Mountpoint /custom-config, an dem ich eine kleine Partition einbinde, auf welcher die geaenderten Dateien des /etc-Baums liegen. Auf diese Dateien setze ich dann anschlieszend Symlinks.

    mv {,/custom-config}/etc/datei.conf
    ln -s {/custom-config,}/etc/datei.conf

    Da das fuer Dinge wie die Konfiguration des wpa_supplicant super lief, wurde irgendwann ein Automatismus draus.

    Problematisch wurde es dann beim naechsten Reboot, nachdem ich die /etc/fstab ueberarbeitet hatte :D

    Henne-Ei-Problem: Der Symlink zeigte auf den Mountpoint einer nicht-eingebundenen Partition. Auf dieser Partition waren jedoch die Informationen gespeichert, was wo einzubinden ist ;)