Wir haben jetzt ein rudimentäres System, das mit dem vorher gewählten schwachen root Password recht unsicher ist. Bevor wir uns also im System ein wenig umschauen, sichern wir das als erstes mal ab.
Dafür loggen wir uns auf der Konsole ein und nehmen uns die Konfigurationsdatei für den SSH Server vor.
SSH = Secure Shell
Debian GNU/Linux 10 gateway tty1
gateway login: root (enter)
Password: ( Das Passwort wird jetzt hier eingegeben, es wird aber nichts erscheinen, (enter) loggt Dich ein)
diverse Infos zum System und zum letzten Login
root@gateway:~#
Meine Kommentare im Terminal schreibe ich ab sofort in (Grün)….heisst alles grün ist bei Dir nicht da.
Direkt der nächste Schritt bringt uns mit einem neuen Programm zusammen, dem Editor. Auch Editoren gibt es viele. Ehrlich gesagt weiss ich nicht mal welche im Debian alle dabei sind, aber wir werden hier nur zwei behandeln.
vi ( sprich wie-ei ) und nano.
Aber genug davon, wir werden hier ausschliesslich mit nano klarkommen, ein kleiner und einfacher Editor.
Zunächst brauchen wir ein paar Definitionen für unsere Tastatur:
3 Tastaturen möchte ich jetzt mal definieren, Deutsch/Östereich, Schweiz, Mac.
2 Tasten müssen für nano definiert sein:
Die Shift-taste, Umschalt-taste ist für alle gleich, die Großschreibtaste.
Die Control-taste ist bei allen anders benamst.
Strg in Deutschland und Österreich ( für String glaube ich )
Ctrl in der Schweiz, und
control^ auf dem Mac
Beide Tasten werden bei nano benutzt um die Optionen aufzurufen.
Wir bearbeiten eine Datei mit nano indem wir den Befehl „nano“ gefolgt von einem Leerzeichen und der Datei, die wir bearbeiten wollen, eingeben.
Dabei kann der Name der Datei alleine stehen, wenn wir uns im Verzeichnis befinden in dem die Datei liegt, andernfalls muss die Datei mit ihrem absoluten Pfad angegeben werden.
root@gateway:~#nano /etc/ssh/sshd_config (enter)
Nach dem Doppelpunkt steht hier die Tilde (~), die uns sagt: wir befinden uns in unserem Heimverzeichnis. In diesem Fall /root
Die Datei, die wir bearbeiten wollen liegt im Verzeichnis /etc/ssh und heisst sshd_config
Der absolute Pfad zeichnet sich durch den / ( Slash ) vor dem ersten Verzeichnis etc aus.
Ein relativer Pfad würde sich durch den fehlenden / ( Slash ) vor dem ersten Verzeichnis auszeichnen und ergo in
/root/etc/ssh suchen, nichts finden und eine Fehlermeldung ausgeben.
Hab ich schon vor dem weissen Kaninchen gewarnt?
Ihr merkt schon, es ist nicht nur Arbeit, es schreit auch nach Konzentration.
Unsereiner schafft es locker einen Text dreimal zu lesen, ohne das auffällt. daß das gewünschte Komma eigentlich ein Punkt ist.
Dein Rechner kann Dir das übel nehmen, gleich beim ersten Anlauf.
Da ich jetzt von der Konsole nichts hierhin kopiert bekomme, wieder ein paar Screenshots:
Konfigurationsdateien kommen in der Regel mit Versionshinweisen und ein paar Erläuterungen am Anfang daher.
Eine vorläufige Regel lautet ferner, eine Raute ( # ) am Anfang einer Zeile kommentiert diese, was heisst, daß das Programm, welches hier konfiguriert wird diese Zeile erstens
ignoriert
und zweitens eventuell
die dort angegebenen Standardwerte verwendet.
Solltest Du im Netz die Anweisung lesen eine
“Zeile auszukommentieren“
heisst das also Du sollst die # am Zeilenanfang löschen und damit diese Zeile für ein Programm lesbar machen.
Im unteren Bereich sind die Optionen eingeblendet:
control + x = beendet das Programm/schliesst die Datei
control + o = speichert unsere letzten Änderungen – mit Nachfrage zum Dateinamen, neuer möglich
control + r = öffnet eine weitere Datei
control + v = rollt einen Bildschirminhalt runter
control + y = rollt einen Bildschirminhalt hoch
rechts,links,hoch,runter bewegt den Curser
die anderen Optionen erklären sich fast von selber, beim hüpfen zu Zeile X benötigen wir für den _ noch die Shifttaste, sehr hilfreich, wenn man weiss in welche Zeile man will, control+w fragt nach einem Suchbegriff.
Nun einmal control + v und mit dem Curser hinter die # bei PermitRootLogin
diese entfernen und dann als nächstes die Standardeinstellung verändern:
control + e springt übrigens ans Zeilenende
control + a an den Zeilenanfang
und das so ziemlich überall….
Nun control + o für speichern, mit (enter) bestätigen,
( wenn man den Dateinamen nicht verändern will ) dann
control + x für schliessen.
Dann starten wir den SSH Server einmal neu um die Änderungen zu übernehmen.
root@gateway:~#systemctl restart ssh (enter)
Nun könnten wir uns via SSH mit unserem Debian verbinden, wenn wir denn die IP-Adresse wüssten.
Alle Netzwerkinfos unseres Rechners auf einen Blick:
4 Netzwerkwerkschnittstellen sind aufgeführt:
1: lo
das Loopbackinterface ( ein feiner Suchbegriff ), hier spricht das System mit sich selbst.
2: erste Schnittstelle
die wollen wir wissen, hier hängt unser Plasterouter und hat unserem gateway die IP 10.0.2.180 gegeben. Ausserdem sehen wir hier die IPv6 Adresse und die MAC-Adresse.
3. und 4. im Moment egal
Nun öffnen wir ein Terminalprogramm auf unserem Lieblingsrechner, wir erinnern uns? Terminal auf Ubuntu oder Apple, Putty auf Windows….
Und nun ist auch Schluss mit Screenshots, wir geben ein:
ich@meinpc~# ssh [email protected] (enter)
The authenticity of host ‚10.0.2.180 (10.0.2.180)‘ can’t be established.
ECDSA key fingerprint is SHA256:iWdsbki0YJxjTRbTZtMdtpnD4BeO/sETX4Zcp96aQ0Y.
Are you sure you want to continue connecting (yes/no)?
Was soll das jetzt heissen?
Mit SSH bauen wir eine verschlüsselte Verbindung auf, genauer mit einem SHA256 Schlüssel. Beim Schlüsselaustausch sagt uns unser PC jetzt, das er gateway mit der IP nicht kennt.
Wir verstehen das, sind uns aber sicher, das alles seine Richtigkeit hat.
yes (enter)
Jetzt passiert folgendes:
Unser PC trägt genau diesen Schlüssel in eine Datei known_hosts ein und wird diese Frage nicht mehr stellen.
Was soll das?
Angenommen ein Angreifer würde versuchen sich zwischen uns und unseren Server zu mogeln ( man-in-the-middle ) und eine Verbindung vortäuschen indem er alle unsere Befehle entgegennimmt um sie dann an den Server weiterzugeben um uns dann wieder das Feedback des Servers zu vermitteln.
Da unser PC aber den originalen Schlüssel unseres Servers bereits kennt und gespeichert hat, würde das sofort in einer Warnung enden.
SSH ist also genau solange eine sichere Verbindung, wie alle beteiligten Systeme sauber sind. Unser LieblingsPC kann hier also auch schnell eine Schwachstelle werden. Ein braver Admin sichert seinen Verwaltungsrechner genauso ab wie seine Server!
Mein Verwaltungsaccount ( auf dem Verwaltungrechner ich@meinPC ):
wird nicht geteilt
hat ein starkes Passwort
ist kein Administratoraccount
Die Festplatte des Rechner ist verschlüsselt
Der Rechner
hat ein verschlüsseltes Backup
ist immer mit allen Updates versorgt
bekommt niemals Software aus zweifelhaften Quellen installiert
[email protected]’s password: sieht man wieder nicht (enter)
Linux gateway 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64
The programs included with the Debian GNU/Linux system are free software;individual files in /usr/share/doc/*/copyright.permitted by applicable law.
Last login: Fri Oct 18 17:47:36 2019
root@gateway:~#
und wir sind drin.
Ab jetzt haben wir die Maus, Copy&Paste, das ganze Programm.
Dem rechte Maustasteklicker sei jetzt noch ans Herz gelegt:
Strg + c = kopiere
Strg + v = füge ein
Strg + x = schneide aus
Ferner sind die Pfeil hoch und runter Taste mit einer „scroll“ Funktion belegt, mit der sich durch alle vorherigen Befehle bzw. Eingaben „blättern“ lässt.
Ergänzend wird im Hintergrund die Datei .bash_history geführt, welche sich mit einfach
history
aufrufen lässt. ( wie war das noch mit dem Befehl letztens? In der history steht es…)
Um das Kapitel „erste Schritte“ abzuschliessen werden wir jetzt folgendes tun:
1. Das root Password ändern ( auf ein richtig gutes! )
2. Den Benutzer „user“ und sein Homeverzeichnis löschen
3. Ein RSA Schlüsselpaar für unseren Verwaltungsrechner erstellen
4. Diesem Verwaltungsrechner damit den passwortlosen Zugang ermöglichen
5. Die SSH config wieder abhärten
6. Grub in den Bootsektor der zweiten Platte kopieren
7. Den IPv6 Stack abschalten
8. Die Bash ein wenig verändern
root@gateway:~# passwd ist der Befehl um das Passwort zu ändern
Bevor wir das aber tun, stellen wir ein paar Dinge sicher.
1. Wir sind noch an der Konsole angemeldet
2. Wir haben das Passwort irgendwie gesichert.
An dieser Stelle darf ich einen Passwortmanager empfehlen. Er kann alle unsere Passwörter mit allen dazugehörigen Informationen verschlüsselt ablegen. Er kann gute Passwörter generieren und man braucht fortan nur noch zwei Passwörter die man sich merken muß: Sein Benutzerkennwort am PC und das Passwort für den Passworttresor. Das man am besten für nichts und garnichts dasselbe Passwort verwendet brauche ich hier nicht extra zu erwähnen?
Es gibt gute und schlechte Passwortmanager, die Guten kosten in der Regel.
Es ist natürlich auch in Ordnung, wenn man seine Passwörter auf Papier festhält, nur sollte man dieses Papier dann auch an einem sicheren Ort aufbewahren, es sollte ordentlich und lesbar geführt sein.
Eine weitere Möglichkeit ist die Sammlung von verschlüsselten PDF’s.
Man macht sich sozusagen seinen eigenen Passworttresor.
Erstelle einen Ordner auf den nur Du Zugriff hast. Erstelle dort eine Vorlage mit Deinem Textprogramm mit den Vorgaben, z.B. Rechner; Account; Passwort; IP; Webseite; usw….
Nun wird die Vorlage gespeichert und dann alle Infos eingetragen.
Dann als PDF mit eindeutigem Namen und Passwort exportieren.
Dann die Vorlage ohne! zu speichern wieder schliessen, die eingetragenen Werte dürfen nicht im Dokument verbleiben.
Die Verschlüsselung von PDF ist nicht wirklich sicher, die Header verbleiben im Klartext und auch das Verhalten der verschiedenen Reader ist mitunter sehr unsensibel. Der Einsatz dieser Variante erfordert Umsicht des Nutzers!
Die PDF sollten den lesegeschützten Ordner nie verlassen; Sie sollten nie in Browsern oder unzuverlässigen Readern geöffnet werden.
Nun zu unserem Passwort. Für sensible Maschinen darf man, ohne sich paranoid zu fühlen, Passwörter mit einer Länge von 16 – 32 Zeichen vergeben.
dHErc;kMPNM7PMaU
ist doch ein feines Passwort, oder? Jetzt ist auch klar, warum wir am Anfang ein schlechtes vergeben haben, denn wenn alles glatt läuft, müssen wir dieses Passwort höchstens einmal eingeben.
Im PWM oder im PDF. Von dort oder vom Passwortmanager aus kopieren wir es direkt ins Terminal:
root@gateway:~# passwd ab hier spare ich uns jetzt das enter
Geben Sie ein neues Passwort ein:wir kopieren unser neues Passwort hierhin, und man wird wieder nichts sehen, ein letztesmal – enter
Geben Sie das neue Passwort erneut ein:wir kopieren unser neues Passwort erneut hierhin, und man wird wieder nichts sehen, ein allerletztesmal – enter
passwd: Passwort erfolgreich geändert
root@gateway:~# userdel user löscht den Benutzer user
root@gateway:~# rm -r /home/user löscht das Benutzerverzeichnis
root@gateway:~#
wenn als Ergebnis wieder kommentarlos der Prompt erscheint hat das System den Befehl ausgeführt, nur Fehler werden gemeldet.
Jetzt erstellen wir das RSA Schlüsselpaar
Wir bleiben weiterhin überall, auf Konsole und im Terminal eingeloggt! Wir wollen uns nicht aus versehen aussperren und wir wollen auch nicht das lange Passwort eingeben müssen.
Dazu machen wir auf unserem PC ein weiteres Terminalfenster auf.
Für Windows gibt es diese Option nur innerhalb des SSH-client Programms, z.B. PUTTY. Eine Anleitung dazu HIER.
ich@meinPC:~# ssh-keygen -b 4098 erzeugt das Schlüsselpaar, -b 4098 verdoppelt die Schlüsselstärke
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ich/.ssh/id_rsa): es wird standard wie angeben gespeichert, man kann hier einen anderen Speicherort angeben, das wollen wir aber nicht – also leer lassen und nur bestätigen
Created directory ‚/home/ich/.ssh‘.
Enter passphrase (empty for no passphrase):nein, machen wir jetzt nicht, nur enter
Enter same passphrase again:wieder leerlassen, enter
Your identification has been saved in /home/ich/.ssh/id_rsa.
Your public key has been saved in /home/ich/.ssh/id_rsa.pub.
The key fingerprint is:SHA256:HqWwtGbvZjsmXA6CMEEbf2/Qx0XfOMxrGygyQpfE1HM ich@meinPC
The key’s randomart image is:
hier kommt jetzt eine Art Konsolen Barcode, interessiert uns nicht
ich@meinPC:~#cat .ssh/id_rsa.pub das schauen wir uns jetzt an, „cat“ ist das zauberwort um sich den gesamten Dateiinhalt anzeigen zu lassen, ausserdem beachte man hier die Verwendung des relativen Pfads, .ssh ohne vorgestelltes /
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQMsA+vPgxN4Kr8sqyif8KSig0lKxi0EldzKrYQfOkXcf7zobaeDYqJKcyNUDxNozLXvGgWfbYZxGDcLc9r8KgV5HlO42c1RL/EsUi21k3Kyx4X5w0nxmnFTWd/gvc3RSnVgwBL6Sl9yf2IOYHt7p35pK/FdzxX7Ydc9ym2Ig25FORoN7hq3Rewk/tRbyIsv0K1+i+GP9f1q7ZUMeex2BZHVpogqpzjXlblwlM46+vGJf8/JVJuuEwwGcZgyTgsjSwtvt/fJj6pxB1VtMjYszFHGyq3eowaCPodi3iY00da2qQdA8vfTCAOodhPOKKRuH/saQxuVIxtftwLeR2KS6OQqvMjVF6eq9IPTLrYZesV2NXjbes4B2rrO/XNMCmd5qALu7h1naZyGOAG7H0iQpVutffSLY3gQRqvLXddAhHiX9j0TazmOAwu+5S5sSKnwTvtPl9f49+YrKcCSo3dhG3o5tIfPeLOYgPUZ59uKsdRrDizzFGtNeAteVTp5JwDvi9LeWtdtOd9n2Gd0iFpjCqF0i3PrzlaLAX3MmhcviE1EeDB5RNMtRrMRIEF/rhJuYoxgJq7x7Yg3Pcdi9gu0qtOK0vWCgEIj4yzhSVASXFjdDLDkttDxktGazIJ23p9E/RTGD/ZRzieNIyUtIfa1mzTPT+Ov5uq1EnGzPOTI7KPPfQ== ich@meinPC
ich@meinPC:~#
Das sieht doch schonmal gut aus!
Was haben wir jetzt hier?
id_rsa.pub ist unser öffentlicher Schlüssel, den können wir getrost rumliegen lassen, damit kann keiner was anfangen; solange er nicht auch unseren geheimen privaten Schlüssel id_rsa dazu hat.
Diese Verschlüsselung können wir uns im Prinzip wie Schloß und Schlüssel vorstellen, wir bauen unseren öffentlichen Schlüssel quasi als Schloß auf dem Server ein, und fortan haben wir mit unserem privaten Schlüssel einfachen, aber sehr sicheren Zugang.
Wir markieren den gesamten Schlüssel von ssh-rsa ….bis …== ich@meinPC mit der Maus und kopieren ihn in die Zwischenablage mit control + c.
Dann gehen wir wieder zum Terminalfenster für unser gateway und erstellen folgende Datei:
root@gateway:~# mkdir .ssh erstellt das (versteckte) Verzeichnis .ssh
root@gateway:~# nano .ssh/authorized_keys
nun erscheint im Gegensatz zu vorhin bei der sshd_config eine leere Datei -weil diese Datei neu ist. Wir fügen nun den Inhalt unserer Zwischenablage mit control + v ein. Jetzt muss! der oben kopierte Schlüssel in einer einzigen Zeile in dieser Datei stehen. Dann mit control+o / control+x speichern und schliessen
Zurück zum Fenster unseres Terminals am eigenen PC
ich@meinPC:~#ssh [email protected] muss uns jetzt ohne Passwortabfrage hereinlassen
Die Konfiguration des SSH-Servers ist jetzt das letzte Türchen das noch abgesichert werden muss. Dazu öffnen wir wieder die sshd_config
root@gateway:~# nano /etc/ssh/sshd_config
wir bearbeiten die folgenden Zeilen
PermitRootLogin without-password
und ein root Zugang ist nur noch ohne Passwort möglich
PasswordAuthentication no
und auch ein normaler Benutzer kann sich nicht mehr mit Passwort anmelden, und ja, es gibt zwar keinen, aber hier geht es ums Prinzip
X11Forwarding no
X11 ist das Fenstersystem im Linux, auch das haben wir nicht installiert, trotzdem verbieten wir das
(speichern und schliessen)
root@gateway:~#systemctl restart ssh
Ein letzter Test im zweiten Fenster ob die passwortlose Anmeldung geht.
Jetzt können wir uns entspannt an der Konsole abmelden mit
control+d
den Monitor ausschalten, Tastatur und Monitor abbauen und wieder wegstellen.
Ab sofort arbeitet unser Server „headless“.
Bevor wir es vergessen, installieren wir den Bootloader GRUB nun schnell auf die zweite Platte.
root@gateway:~#grub-install /dev/sdb
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
root@gateway:~#update-grub
Linux-Abbild gefunden: /boot/vmlinuz-4.19.0-6-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.19.0-6-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.19.0-5-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.19.0-5-amd64
erledigt
root@gateway:~#
Was ist jetzt passiert?
Warum machen wir das überhaupt? Haben wir nicht ein Raid1 das alles spiegelt?
Ja und Nein.
Hätten wir das Raidsystem nicht über die Installationsroutine, sondern mit dem Partitionierungsprogramm „fdisk“ und der Raidverwaltung „mdadm“ eingerichtet, dann hätten wir gesehen, daß die Blockverteilung des Dateisystems erst bei Block 2048 anfängt.
Vereinfacht gesagt befindet sich dort die Information wie der Rechner zu starten ist und dieser Bereich ist nicht Bestandteil des eigentlichen Raidsystems. Gleichwohl befindet sich der Ordner /boot auf dem Raid und ist gespiegelt. Fällt aber jetzt die erste Platte aus, hat der Rechner beim Start keine Informationen mehr wie er booten soll und startet eben nicht.
Diese Informationen haben wir jetzt auf diesen Bereich der zweiten Platte geschrieben, zu erkennen an der Info Linux-Abbild gefunden usw.
Warum zwei, bzw vier?
Ein Linuxsystem startet immer mit zwei Dateien, dem eigentlichen Kernel, vmlinuz, sowie der dazugehörigen initrd.
Da wir unser Debian mit einem netinstall.iso installiert haben, war dort zunächst ein älterer Kernel verbaut, 4.19.0-5-amd64, der im Laufe der online Installation ein upgrade auf den aktuellen Kernel 4.19.0-6-amd64 erhalten hat.
Debian behält aber immer als Fallback den älteren Kernel und kann im Notfall auch darauf zurückgreifen, wenn mit dem neuen Kernel beim Systemstart etwas nicht stimmen sollte. Beim nächsten Kernel upgrade auf 4.19.0-7-amd64 wird Debian Dich darauf aufmerksam machen, daß der 5er nun nicht mehr gebraucht wird und Du ihn entfernen kannst.
Das werde ich aber später, wenn das ganz aktuell ansteht, wieder auf den Teller ziehen….
Jetzt können wir uns erstmal sicher sein, daß das System auch bootet, wenn die erste Platte ausfällt.
Wer das testen möchte, sollte das vielleicht nicht an der aktuellen Maschine tun, dort wird dann sofort die Reserveplatte eingebunden und es stehen einige zusätzliche Aktionen an um das wieder in den aktuellen Zustand zu bringen. Auch die kommen später auf den Teller wenn unser gateway läuft.
Wer es trotzdem testen möchte, kann/soll das aber gerne auf einem weiteren Rechner, oder, einfacher, auf einer virtuellen Maschine machen.
Kümmern wir uns nun um den IPv6 Stack, die Fähigkeit unseres Servers mit IPv6 Adressen umzugehen. Warum wollen wir das abschalten?
Machen wir einen kurzen Abstecher in die Welt der IP-Adressen.
Jeder Rechner der irgendwie im Netzwerk agieren möchte, braucht mindestens eine IP-Adresse. Rechner erreichen sich nur über IP-Adressen, Namen wie gateway.erstes.netz, debian.org usw. sind nur für uns Menschen gemacht und werden im Hintergrund von sogenannten DNS, Domain Name Servern allesamt in ihre zugehörigen IP-Adressen übersetzt – erst dann kann der eine Rechner den anderen erreichen.
Wir haben es hier mit zwei grundverschiedenen IP-konzepten zu tun:
IPv4 und IPv6
Unsere Netzwerke laufen seit ihrer Urzeit ganz prima mit IPv4 und der mehr oder weniger einzige Grund für IPv6 war – es gibt zuwenige IPv4 Adressen.
Kaum jemand hat zuhause eine feste IP-Adresse, unsere Mobiltelefone hängen alle mit privaten, vom Provider zugeteilten Adressen im Netz und werden geNATet.
Auf das und die Struktur einer IPv4 Adresse kommen wir später zurück.
IPv6 beseitigt nun den Mangel an Adressen, und das gleich so rabiat, das wir uns darum wohl nie wieder Gedanken machen müssen.
Die Vorstellung, 4 Milliarden IP-Adressen könnten mal knapp werden, kam 1976 keinem in den Sinn, und diesen Fehler wollte man wohl nicht wiederholen. Hätte man damals das Konzept um nur einen 256er Block erweitert, müssten wir uns heute wohl noch nicht mit dem Thema herumschlagen.
Na, wenn das dann so toll neu ist, warum wollen wir das dann abschalten?
Zwei Gründe:
Das gesamte Konzept IPv6 ist äusserst komplex und es gibt Leute, die behaupten, daß es keinen einzigen Menschen gibt, der das in aller Tragweite versteht.
Die Adressen sind lang, schlecht zu merken und bringen uns im Heimnetz keinerlei Vorteile. Im Gegenteil, sie machen alles viel komplizierter, denn wir wollen ja die Kontrolle zurück.
Zweitens müssten wir, wenn wir IPv6 zulassen, alles doppelt machen.
Ok, einen zweiten DHCP für IPv6 bräuchte es nicht, aber ey nee…wirklich nich.
Unser Plasterouter darf seine IPv6-fähigkeiten aber natürlich behalten, sofern er diese hat. Manche Provider, Unity Media z.B., lassen garnichts anderes mehr zu.
Vielleicht wird der Tag kommen, wo wir das auch haben wollen. Aber jetzt ist es noch auf absehbare Zeit im Heimnetz völlig überflüssig, und solange die Provider sich weigern uns die mit IPv6 möglichen eigenen, festen IP-Adressen zu geben ist es eh eher eine Farce was da abläuft. Ausserdem ist es auch überhaupt nicht klar, ob wir nicht früher oder später eine ganz neue Lösung bekommen werden, – ich würde das begrüßen. Ein Suchbegriff dazu wäre RINA. Ebenso steht aber auch die Befürchtung einer dritten parallelen IP-Struktur „New IP“ in den Startlöchern. Was auch immer irgendwann über uns kommt; im Heimnetz werden wir noch lange mit IPv4 ganz wunderbar klarkommen.
Rufen wir uns das ip a wieder ins Gedächtnis, damit bekommen wir Informationen über all unsere Netzwerkschnittstellen
root@gateway:~#ip a
2: enp0s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:1c:42:32:6e:93 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.180/24 brd 10.0.2.255 scope global dynamic enp0s5
valid_lft 10701sec preferred_lft 10701sec
inet6 fe80::21c:42ff:fe32:6e93/64 scope link
valid_lft forever preferred_lft forever
Was sagen uns jetzt die Infos über unsere primäre Schnittstelle enp0s5?
Die Schnittstelle ist aktiv ( UP ) und händelt eine Paketgröße (MTU) von 1500
link/ether gibt uns die MAC-Adresse (00:1c:42:32:6e:93) und den Broadcast (brd) – hier für uns nicht wichtig
inet ist die IPv4-Adresse (10.0.2.180) und der Broadcast (10.0.2.255) beides von unserem Plasterouter zugeteilt, und zwar
valid_lft gültig für 10701 Sekunden. Bevor diese Zeit abläuft schreit unser Rechner nach einer neuen IP, und zwar auf dem Broadcast 10.0.2.255, was heisst, das ganze Netz wird diesen Schrei hören, unser Plasterouter wird ziemlich sofort antworten und unserem Rechner erneut diese Adresse für 10701 Sekunden anbieten, unser Rechner wird sie nehmen, usw.usf.
inet6 fe80::21c:42ff:fe32:6e93/64 ist unsere IPv6-Adresse und
valid_lft forever – für immer gültig.
Ich denke mit fe80::21c:42ff:fe32:6e93/64 ist alles gesagt, oder?
Da will ich mich doch nicht drum kümmern wenn 10.0.2.180 genausogut geht!
Wohlgemerkt, es geht hier nicht um diese eine Adresse, sondern um alle im Heimnetz, PC, TV, Tablet, usw.
Aber! auch die fassen wir nicht an!
Wir verhindern jetzt nur, das unser Gateway damit rumhantieren kann.
Verbieten wir dem Chinakram später den Zugang zum Internet ( via IPv4 über unser gateway ) und lassen den IPv6-Stack aktiv, wird der Chinakram unser Verbot einfach dort umgehen.
Und schlimmer noch! Die tollen IPv6-Adressen sind eindeutig und für immer gültig! Während die angenommene IPv4-Adresse 10.0.2.4 für unser Notebook millionenfach Weltweit in Millionen Heimnetzen verteilt ist.
Ok, es wird wohl eher die 192.168.0.4 sein, 192.168 ist weitaus verbreiteter, aber ich bin halt Tipfaul und habe mein Netz auf 10.0 umgestellt.
Also: öffnen wir die Datei
root@gateway:~#nano /etc/sysctl.conf
und fügen dort am Ende eine einzelne Zeile ein
net.ipv6.conf.all.disable_ipv6 = 1
speichern und schliessen die Datei
root@gateway:~#
Beim nächsten Neustart wird der IPv6 Kram verschwunden sein.
Eigentlich muss man ein Debiansystem selten wirklich neustarten, es gibt fast immer eine Möglichkeit Änderungen, auch so gravierende, im laufenden Betrieb zu übernehmen.
Wir starten jetzt trotzdem neu um uns zu vergewissern, daß das auch wirklich geklappt hat, denn nur dann können wir sinnvoll weitermachen.
root@gateway:~#reboot startet umgehend neu
root@gateway:~#shutdown -r now ebenso, etwas eleganter
root@gateway:~#shutdown -h now fährt das System runter und startet nicht wieder neu
root@gateway:~#shutdown -r 1 startet das System in 1 Minute neu, hilfreich wenn man sich erst noch ausloggen möchte, weil sich sein Fenster sonst aufhängt. Manche Terminalprogramme mögen das anscheinend nicht und brauchen ewig bis sie mit einer Meldung „broken Pipe“ wieder zurückkommen
so, reboot fertig, erneut eingeloggen
root@gateway:~#ip a
alle inet6 Einträge sind verschwunden
Prima, jetzt hübschen wir unsere Bash ein wenig auf.
root@gateway:~#nano .bashrc öffnet unsere bash-config, schau Dir das mal gut an, entferne ein paar # und füge ein paar Zeilen hinzu.
GNU nano 3.2 .bashrc # ~/.bashrc: executed by bash(1) for non-login shells.
# Note: PS1 and umask are already set in /etc/profile. You should not
# need this unless you want different defaults for root.
#PS1=‚${debian_chroot:+($debian_chroot)}\h:\w\$ ‚
PS1=‚${debian_chroot:+($debian_chroot)}\[\033[0;30m\]\h:\[\033[01;31m\] \w \$\[\033[00m\] ‚
# umask 022
# You may uncomment the following lines if you want `ls‘ to be colorized:
export LS_OPTIONS=‚–color=auto‘
eval „`dircolors`“
alias ls=‚ls $LS_OPTIONS‘
alias ll=‚ls $LS_OPTIONS -l‘
alias l=‚ls $LS_OPTIONS -lA‘
#Manchmal macht einen auch WordPress kirre! Also ACHTUNG
die ganzen ‚ um die fettgedruckten Bereiche MÜSSEN alle , am Anfang und Ende, oben sein!! Hier in meinem Bearbeitungsfenster ist alles korrekt, im Browser fast alles falsch. grrr, ich mach noch einen Screenshot, extra, weil das ist wichtig….
# Some more alias to avoid making mistakes:
# alias rm=‚rm -i‘
# alias cp=‚cp -i‘
# alias mv=‚mv -i‘
alias ..=‚cd ..‘
alias …=‚cd ..; cd ..‘
alias ….=‚cd ..; cd ..; cd ..‘
alias .-=‚cd -‚
alias ~=‚cd ~/‘
alias update=‚apt-get update && apt-get upgrade‘
speichern und schliessen, dann aus- ( control+d) und wieder einloggen
gateway: ~ #
Hier kann man ganz nach eigenem Vergnügen rumspielen. Zunächst sehen wir nur, das sich das Erscheinungsbild des Prompt verändert hat, das root@ fehlt und das aktuelle Verzeichnis ist rot.
Hier sinnvoll – es gibt nur root auf der maschine, und gut zu sehen wo man gerade ist, – auch hilfreich.
Die „Aliase“ werden immer in der gleichen Syntax angelegt
alias Name=’was es ersetzen soll‘ Hier der Screenshot. ‚ alle oben! Wichtig!
Ich suche jetzt schon im HTML Code, aber das ist mir jetzt zu blöd, vielleicht komme ich später wieder….
Weiter im Text:
Eine logische Regel gibt es natürlich zu beachten: Ich sollte kein alias „Name“ erstellen, wenn „Name“ bereits vergeben ist, oder anderweitig für andere Programme genutzt wird. Stilblüte dazu? Zu Zeiten des ifconfig hatte ich ein alias=ipa dazu gemacht und es mit dem Wechsel zu ip a völlig vergessen. Später habe ich mich mit FreeIpa angefreundet und mich ziemlich dumm gefühlt, weil ich recht lange gebraucht habe bis ich gemerkt habe, warum der Befehl ipa nicht macht was er soll….
Mit diesen Aliasen sind wir mit den ersten Schritten auch schon fast durch, wir sehen uns jetzt ein wenig um:
gateway: ~ #ls gehen wir das mal von oben an, ls steht für list und zeigt uns die Ordnerstruktur, ohne Zusatz, vom aktuellen Verzeichnis nach unten an
gateway: ~ # wir sehen nichts, heisst es gibt im Ordner ~, bzw. /root keine Verzeichnisse, keine Dateien. Probieren wir ll
insgesamt 0
gateway: ~ # bestätigt uns dies, probieren wir l
insgesamt 20
-rw——- 1 root root 628 Okt 19 14:34 .bash_history
-rw-r–r– 1 root root 810 Okt 19 14:34 .bashrc
drwxr-xr-x 3 root root 4096 Okt 18 19:13 .local
-rw-r–r– 1 root root 148 Aug 17 2015 .profile
drwx—— 2 root root 4096 Okt 19 11:49 .ssh
gateway: ~ # hui, doch was. Das alias l (kleines L) steht für ls -al und zeigt uns die ausführlichste Auflistung, alle Dateien, alle Verzeichnisse, wie viele es insgesamt sind, Rechte, Besitzer, Gruppe, Grösse, Erstellungsdatum.
alias steht übrigens auch für tipfaul.
Steht einer Datei oder einem Verzeichnis ein Punkt vor, gilt dieses als versteckt und wird bei Verwendung von ls nicht angezeigt – als nächstes; ..
gateway: / #zwei Punkte stehen ( immer und in jedem Verzeichnis ) als Symlink für das übergeordnete Verzeichnis ( ein Punkt steht entsprechend als Symlink für das aktuelle Verzeichnis, ebenfalls immer und in jedem Verzeichnis ), als alias „..“ für cd .. ( change directory ) und bringen uns ein Verzeichnis hoch . Man beachte das ~ hat sich in / verwandelt und ls
bin dev home initrd.img.old lib32 libx32 media opt root sbin sys usr vmlinuz
boot etc initrd.img lib lib64 lost+found mnt proc run srv tmp var vmlinuz.old
zeigt uns Verzeichnisse und Dateien im Verzeichnis / in vier Farben, eine (hier rot) für die Verzeichnisse, in hellblau die sogenannten symlinks ( symbolische Verknüpfung ) und schwarz für Dateien. Grün hinterlegt ist eine erweiterte Dateiberechtigung.
gateway: / # l
lrwxrwxrwx 1 root root 7 Okt 17 15:52 bin -> usr/bin
drwxr-xr-x 4 root root 1024 Okt 17 16:09 boot
drwxr-xr-x 18 root root 3320 Okt 19 14:19 dev
drwxr-xr-x 76 root root 4096 Okt 19 14:19 etc
drwxr-xr-x 2 root root 4096 Okt 19 11:14 home
lrwxrwxrwx 1 root root 30 Okt 17 16:01 initrd.img -> boot/initrd.img-4.19.0-6-amd64
lrwxrwxrwx 1 root root 30 Okt 17 15:53 initrd.img.old -> boot/initrd.img-4.19.0-5-amd64
lrwxrwxrwx 1 root root 7 Okt 17 15:52 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Okt 17 15:52 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 Okt 17 15:52 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 Okt 17 15:52 libx32 -> usr/libx32
drwx—— 2 root root 16384 Okt 17 15:52 lost+found
drwxr-xr-x 3 root root 4096 Okt 17 15:52 media
drwxr-xr-x 2 root root 4096 Okt 17 15:52 mnt
drwxr-xr-x 2 root root 4096 Okt 17 15:52 opt
dr-xr-xr-x 100 root root 0 Okt 19 14:19 proc
drwx—— 4 root root 4096 Okt 19 14:34 root
drwxr-xr-x 17 root root 560 Okt 19 14:34 run
lrwxrwxrwx 1 root root 8 Okt 17 15:52 sbin -> usr/sbin
drwxr-xr-x 2 root root 4096 Okt 17 15:52 srv
dr-xr-xr-x 13 root root 0 Okt 19 14:19 sys
drwxrwxrwt 8 root root 4096 Okt 19 14:19 tmp
drwxr-xr-x 13 root root 4096 Okt 17 15:52 usr
drwxr-xr-x 12 root root 4096 Okt 17 15:52 var
lrwxrwxrwx 1 root root 27 Okt 17 16:01 vmlinuz -> boot/vmlinuz-4.19.0-6-amd64
lrwxrwxrwx 1 root root 27 Okt 17 15:53 vmlinuz.old -> boot/vmlinuz-4.19.0-5-amd64
wir sehen wieder die ausführliche Darstellung Rechte, Besitzer, Datum, Verzeichnis, Link und wohin, und Datei. Die Rechtebezeichnungen fangen mit d für directory/Verzeichnis an oder l für Link. Das grün hinterlegte /tmp Verzeichnis hat das erweiterte Recht t am Ende, das sogenannte sticky bit. Diesen Ordner darf nur root bzw der Besitzer löschen, ganz egal was dort für die Gruppe oder andere hinterlegt ist. Macht Sinn, dem Benutzer der unser /tmp Verzeichnis löscht würde sonst schon mal was drohen….
So, wir wissen jetzt wie man Dateien öffnet und bearbeitet, wir können uns den Inhalt einer Datei mit
cat /Verzeichnisname/Dateiname anzeigen lassen, mit
mkdir Verzeichnisse anlegen.
Wir können uns Ordnerinhalte anzeigen lassen, einfach oder ausführlich mit
ls /etc
oder
l /etc/ssh
und wir können die Verzeichnisse wechseln mit
cd /etc
oder
cd /etc/ssh
Wir gelangen ins übergeordnete Verzeichnis mit .. zwei Punkten, ins überübergeordnete mit drei Punkten …
Mit ~ gelangen wir direkt in unser Homeverzeichnis und waren wir vorhin in /etc/ssh
und sind danach mit
cd /var/log
zu den logfiles gegangen, bringt uns ein
.-
direkt zu
/etc/ssh
zurück.
Einen Link zu einer Seite mit Erklärungen von Rechten und wie man sie vergibt oder ändert werden wir später vorfinden.
Das könnte man schonmal als Meilenstein stehen lassen.
Dann wollen wir unserem Server mal was zu tun geben:
next > Dienste einrichten und konfigurieren