CentOS 7 einrichten: Leitfaden für Altsysteme

Datum der Veröffentlichung：8. Dezember 2020.

Aktualisiert: 29. Juli 2026

Überblick

Dieser historische Ablauf dokumentiert die Erstkonfiguration von CentOS 7.6 (1810). Bei neuen Systemen sind dieselben Ziele mit den aktuellen Werkzeugen und Sicherheitsvorgaben einer unterstützten Distribution umzusetzen.

1. Grundeinstellung

Dieser Abschnitt beschreibt die grundlegenden Einstellungen, die unmittelbar nach der Installation von CentOS erforderlich sind.

1-1. Überprüfen des Betriebssystems

Stellen Sie zunächst sicher, dass Sie das richtige Betriebssystem installiert haben.

[root@hostname ~]# cat /etc/redhat-release

CentOS Linux release 7.6.1810 (Core)

CentOS Linux Release 7.6.1810 (Core)" ist das installierte Betriebssystem. Prüfen Sie, ob sie korrekt ist.

1-2. Installieren des Tools

Unmittelbar nach der Installation können grundlegende Befehle wie ifconfig nicht ausgeführt werden. Daher wird die Installation so durchgeführt, dass grundlegende Netzwerk- und andere Befehle durch yum-Befehle ausgeführt werden können.

Bitte führen Sie dies bei Bedarf durch, da es möglich ist, die bereits installierte Software mit "yum -y update" zu modernisieren.

[root@hostname ~]# yum install -y net-tools

[root@hostname ~]# yum install -y wget

[root@hostname ~]# yum install -y tcpdump

[root@hostname ~]# yum install -y traceroute

net-tools: Der Befehl ifconfig und andere können nach der Installation verwendet werden.

wget ruft Ressourcen über Protokolle wie HTTP und HTTPS ab.

tcpdump zeichnet Netzwerkpakete auf und analysiert sie. Mitschnitte können vertrauliche Daten enthalten und benötigen passende Zugriffskontrollen.

traceroute untersucht den Netzwerkpfad zu einem Ziel; Filter können zu unvollständigen Ergebnissen führen.

1-3. Historische SELinux-Einstellung

Der ursprüngliche Ablauf deaktivierte SELinux. Das schwächt den Schutz des Hosts und ist für aktuelle Installationen nicht zu empfehlen. SELinux sollte im Enforcing-Modus bleiben; stattdessen sind Labels oder Richtlinienregeln zu korrigieren.

Falls eine kontrollierte Diagnose den Permissive-Modus erfordert, sollte die Umstellung nur vorübergehend erfolgen. Ablehnungen sind auszuwerten und anschließend ist der Enforcing-Modus wiederherzustellen. SELinux ist eine präventive Mandatory-Access-Control-Schicht und begrenzt zugleich die Auswirkungen einer Kompromittierung. Die folgenden Befehle dokumentieren ausschließlich das frühere CentOS-7-Verfahren.

Das historische Verfahren lautete:

[username@hostname ~]$ getenforce

Disabled

Wenn sie nicht deaktiviert ist, kann sie mit dem folgenden Verfahren geändert werden.

[username@hostname ~]$ vi /etc/selinux/config

SELINUX=enforcing

SELINUX=disabled

Das historische Beispiel ändert SELINUX, nicht SELINUXTYPE. Das Abschalten von SELinux entfernt jedoch eine wichtige Schutzschicht. Neue Systeme sollten enforcing beibehalten und stattdessen Kennzeichnungen oder Richtlinien der Anwendung korrigieren. Als Diagnose ist diese Änderung höchstens vorübergehend in einer isolierten Testumgebung vertretbar.

Die Einstellung wird nach einem Neustart wirksam. Vorher muss ein getesteter Konsolen- und Rollback-Zugang vorhanden sein.

1-4. zusätzlicher betrieblicher Nutzer

Für die tägliche Administration sollte ein namentliches, unprivilegiertes Konto verwendet werden. Rechte werden nur bei Bedarf über sudo oder su erhöht. Das begrenzt versehentliche Änderungen und verbessert die Nachvollziehbarkeit.

Auch auf einem privaten Lernserver ist eine dauerhafte Root-Anmeldung keine sichere Praxis. Konten und Verzeichnisrechte sollten nach dem Prinzip der geringsten Berechtigung getrennt werden; die entfernte Root-Anmeldung wird erst deaktiviert, nachdem ein alternatives Administratorkonto getestet wurde.

Nachfolgend finden Sie die Schritte zum Hinzufügen von Benutzern.

[root@hostname ~]# useradd xxxxxx

[root@hostname ~]# passwd xxxxxx

Hinweis: xxxxxx steht für das neue Konto. Verwenden Sie ein eindeutiges, ausreichend langes Passwort oder bevorzugt eine nach Richtlinie verwaltete SSH-Schlüsselanmeldung.

1-5. Root-Benutzerpasswort ändern

Wenn Sie nicht der Root-Benutzer sind, wechseln Sie mit su - zum Root-Benutzer und führen Sie den folgenden Befehl aus

[username@hostname ~]$ su -

[root@hostname ~]# passwd

Behalten Sie kein Initialpasswort bei und verwenden Sie keine verbreiteten Werte wie „root“, „password“ oder „1234“. Eine starre Empfehlung von acht Zeichen ist heute zu schwach: Passwörter sollten länger, eindeutig und unvorhersehbar sein. Ergänzend sind Schlüsselanmeldung, Rate-Limits und gegebenenfalls Mehrfaktor-Authentifizierung sinnvoll.

Öffentlich erreichbare Server werden unabhängig von ihrer Größe automatisiert angegriffen. Passwort- und Remote-Login-Richtlinien sind deshalb vor der Freigabe zu testen.

1-6. Konfiguration zum Verbot von Anmeldungen durch nicht betriebsbereite Benutzer (verbietet Anmeldungen durch den Benutzer root und andere Benutzer).

Beschränken Sie die Konten mit Remote-Zugang und deaktivieren Sie direkte Root-Anmeldungen. Root umgeht viele Berechtigungsgrenzen, schaltet aber nicht „alle Sicherheitsmaßnahmen“ aus; Netzwerkregeln, Protokollierung und Mandatory Access Control bleiben weiterhin relevant.

Das folgende ältere Beispiel beschränkt SSH mit AllowUsers. Halten Sie vor der Änderung eine zweite Sitzung offen und testen Sie das neue Konto einschließlich Rechteerhöhung, damit kein administrativer Zugriff verloren geht.

[username@hostname ~]$ su -

[root@hostname ~]# vi /etc/ssh/sshd_config

#LoginGraceTime 2m

#PermitRootLogin yes

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10

#LoginGraceTime 2m

PermitRootLogin no

AllowUsers xxxxxx

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10

Hinweis: xxxxxxxx ist der operative Benutzername, den Sie gerade hinzugefügt haben.

Wenn der Name "AllowUsers" falsch ist, kann sich niemand anmelden. Prüfen Sie daher die Benutzernamen sorgfältig.

Überprüfen Sie die Syntax und starten Sie sshd neu.

[root@hostname ~]# /usr/sbin/sshd -t

[root@hostname ~]# systemctl restart sshd

Lassen Sie die bestehende Sitzung geöffnet und prüfen Sie in einer zweiten Sitzung, ob das normale Konto sich anmelden und wie vorgesehen Rechte erhöhen kann. Erst danach wird verifiziert, dass die entfernte Root-Anmeldung abgewiesen wird.

1-7. Zeitsynchronisierung

Prüfen Sie, ob die Uhrzeit synchronisiert ist. Manchmal ist die Uhrzeit des Servers nicht synchronisiert, so dass Datum und Uhrzeit der Protokollausgabe zu einer anderen Zeit als erwartet ausgegeben werden und es lange dauert, das Problem zu analysieren.

Prüfen Sie den Start des Zeitsynchronisationsprozesses (chronyd). Überprüfen Sie den Status der Zeitsynchronisation. Beachten Sie, dass CentOS7 'chronyd' ist, aber früher 'ntpd', also seien Sie vorsichtig, wenn Sie auf 6 oder früher sind.

[root@hostname ~]# ps aux | grep chronyd

chrony     567  0.0  1.3 117804 13664 ?        SL    5月04   0:04 /usr/sbin/chronyd

root     32489  0.0  0.0 112732   972 pts/1    S+   16:30   0:00 grep --color=auto chronyd

[root@hostname ~]# timedatectl

      Local time: Tag (des Monats) 2020-11-29 16:30:43 JST

  Universal time: Tag (des Monats) 2020-11-29 07:30:43 UTC

        RTC time: Tag (des Monats) 2020-11-29 07:30:43

       Time zone: Asia/Tokyo (JST, +0900)

     NTP enabled: yes

NTP synchronized: yes

 RTC in local TZ: no

      DST active: n/a

Es ist OK, wenn 'Lokale Zeit' mit der aktuellen Zeit übereinstimmt, 'NTP aktiviert' ist und 'NTP synchronisiert' ist.

1-8. Historische SSH-Schlüsselkonfiguration

SSH-Public-Key-Authentifizierung verringert bei korrekter Schlüssel- und Rechteverwaltung das Risiko von Passwortangriffen.

Das ursprüngliche Beispiel erzeugt einen RSA-2048-Privatschlüssel ohne Passphrase auf dem Server und kopiert ihn anschließend zum Client. Heute sollte ein Ed25519-Schlüssel auf einem vertrauenswürdigen Client erzeugt, nach Möglichkeit mit einer Passphrase geschützt und nur der öffentliche Schlüssel auf dem Server installiert werden. Vor dem Abschalten der Passwortanmeldung ist eine zweite Sitzung zu testen.

Die folgenden Befehle bleiben als historischer Ablauf erhalten.

[username@hostname ~]$ su - xxxxxx

[xxxxxx@hostname ~]$ ssh-keygen -t rsa -b 2048

xxxxxx steht für das zusätzliche Konto. Bei diesem veralteten serverseitigen Ablauf erzeugt das Bestätigen aller Vorgaben einen unverschlüsselten privaten Schlüssel. Eine Passphrase verschlüsselt den gespeicherten privaten Schlüssel; sie macht aus der Public-Key-Anmeldung keine serverseitige Passwortanmeldung. Neue Schlüssel sollten auf einem vertrauenswürdigen Client erzeugt werden und dort verbleiben.

Überprüfen Sie dann, ob der Schlüssel erstellt wurde.

[xxxxxx@hostname ~]$ ll /home/xxxxxx/.ssh

Der ursprüngliche Ablauf prüfte auf den privaten Schlüssel id_rsa und den öffentlichen Schlüssel id_rsa.pub. Anschließend benannte er den öffentlichen Schlüssel um und verschob den privaten Schlüssel zum Herunterladen:

[xxxxxx@hostname ~]$ mv /home/xxxxxx/.ssh/id_rsa.pub /home/xxxxxx/.ssh/authorized_keys

[xxxxxx@hostname ~]$ mv /home/xxxxxx/.ssh/id_rsa /home/xxxxxx/id_rsa

Das Erzeugen und Übertragen eines privaten Schlüssels auf dem Server bleibt nur als historischer Kontext erhalten und sollte bei neuen Installationen nicht übernommen werden. Das Originalverfahren löschte die Serverkopie nach der Übertragung:

[xxxxxx@hostname ~]$ rm /home/xxxxxx/id_rsa

Vor dem Abschalten der Passwortanmeldung muss die Public-Key-Anmeldung in einer zweiten Sitzung getestet und ein unabhängiger Wiederherstellungsweg bestätigt werden.

[username@hostname ~]$ su -

[root@hostname ~]# vi /etc/ssh/sshd_config

PasswordAuthentication yes

PasswordAuthentication no

Überprüfen Sie die Syntax und starten Sie sshd neu.

[root@hostname ~]# /usr/sbin/sshd -t

[root@hostname ~]# systemctl restart sshd

Damit ist die Einrichtung der Schlüsselauthentifizierung abgeschlossen.

2. Zusammenfassung

Die ursprüngliche Checkliste behandelte Betriebssystemprüfung, Werkzeuge, Administratorkonten, SSH-Zugriff und Zeitsynchronisierung.

Sie ist keine aktuelle Produktionsgrundlage. Maßgeblich sind die Sicherheitsvorgaben einer unterstützten Distribution; SELinux und Firewall bleiben aktiv und Zugriffsänderungen benötigen einen getesteten Rückweg.