Secure Shell on Michael’s Domain

Möglichkeiten, einen Prozess nach dem Abmelden weiterlaufen zu lassen

Sat, 26 Jun 2021 00:00:00 +0000

Es gibt viele Möglichkeiten, einen Prozess nach dem Abmelden weiterlaufen zu lassen. Jede davon hat ihre eigenen Vor- und Nachteile: nohup, disown, screen, tmux, ssh2go usw. Screen ist sicher nicht die komfortabelste und modernste Möglichkeit, aber es ist auf so ziemlich jedem Linux-Computer vorinstalliert, und genau darum benutze ich es. So funktioniert’s:

So aktivieren Sie die passwortlose Anmeldung an einem Server

Wed, 24 Jul 2019 00:00:00 +0000

Aktivieren Sie die Root-Anmeldung mit Passwort auf dem Server. Dazu müssen Sie die Datei /etc/ssh/sshd_config bearbeiten. Ändern Sie die Zeilen, die mit „PermitRootLogin“ beginnen, wie folgt: #PermitRootLogin prohibit-password PermitRootLogin yes
Starten Sie den sshd-Server neu: sudo systemctl restart sshd
Kopieren Sie auf dem Client die Dateien mit den öffentlichen Schlüsseln mit dem Befehl ssh-copy-id auf den Server: ssh-copy-id root@server
Deaktivieren Sie auf dem Server die Root-Anmeldung per Passwort und aktivieren Sie die Root-Anmeldung mit öffentlicher Schlüsselauthentifizierung:PermitRootLogin prohibit-password#PermitRootLogin yes

Sicherung von PCs und Macs

Wed, 13 Apr 2016 00:00:00 +0000

Ich selbst nutze die Backup-Software BackupPC bereits seit fast einem Jahrzehnt und habe vor etwa zwei Jahren damit begonnen, unsere Laborcomputer auf einem zentralen Backup-Server zu sichern. BackupPC unterstützt Deduplizierung, sodass auf einigen wenigen 2-TB-Festplatten viel Datenvolumen gespeichert werden kann. BackupPC unterstützt viele Protokolle (SMB, FTP, tar/rsync über SSH), aber wir nutzen meist rsync über SSH. Die Daten werden vor der Sicherung nicht verschlüsselt. Seltsamerweise wird nicht einmal die kommende Version 4 eine Verschlüsselung vor der Übertragung unterstützen. Wir speichern das Backup jedoch auf einem verschlüsselten Volume. Auf diese Weise sind die Daten zumindest geschützt, falls der Backup-Server gestohlen wird. Und während der Übertragung sind die Daten durch SSH geschützt. Das System entspricht jedoch nicht dem TNO („trust no one“), da ich (als BackupPC-Administrator) auf die Dateien zugreifen kann. Unter Linux wäre eine mögliche Methode, das Home-Verzeichnis des Benutzers mit eCryptFS (was bei der Erstellung von Benutzern unter Ubuntu eine integrierte Option ist) zu verschlüsseln und anschließend das Verzeichnis /home/.ecryptfs anstelle des Home-Verzeichnisses des Benutzers zu sichern. Die Wiederherstellung wäre jedoch ein wesentlich größeres Problem. Man könnte zwar die Verzeichnisstruktur und die Dateien der Sicherung durchsuchen, doch die Dateinamen wären bedeutungslos, da sie bei diesem Vorgang ebenfalls verschlüsselt werden.Bei der Sicherung von Mac-OS-X-Rechnern gibt es eine Besonderheit: BackupPC verbindet sich normalerweise als „root“ per SSH mit dem Client-Rechner und führt den rsync-Sicherungsbefehl aus. Um dies auf von der Universität verwalteten Mac-OS-X-Rechnern zu ermöglichen, mussten wir auf den Client-Rechnern einen dedizierten Benutzer („backuppc“) anlegen und diesem Benutzer die Ausführung von rsync mit Root-Rechten gestatten, was durch Hinzufügen dieser Zeile in die Datei /etc/sudoers erfolgt: backuppc ALL=NOPASSWD: /usr/bin/rsync. Anschließend müssen wir den SSH-/rsync-Befehl für den Mac-Client auf dem „backuppc“-Server anpassen, indem wir „root“ durch „backuppc“ ersetzen.

x11vnc als Ersatz für nxserver

Thu, 29 Nov 2012 00:00:00 +0000

Da der großartige nxclient von nomachine unter Mac OS X nicht mehr funktioniert und der neue nxplayer noch in der Beta-Phase ist (und auf meinem System überhaupt nicht läuft), brauchte ich eine andere Lösung, um von zu Hause aus eine Verbindung zu meinem Arbeits-Desktop herzustellen. Ich habe vieles ausprobiert, mich dann aber für x11vnc entschieden. Auf meinem Arbeits-Desktop läuft Ubuntu Precise Pangolin (12.04) und ich verbinde mich von einem Mac OS X 10.8 (Mountain Lion) aus. Ich musste lediglich x11vnc und openssh-server auf meinem Arbeits-Desktop installieren und eine Datei x11vnc.conf mit folgendem Inhalt unter /etc/init hinzufügen:x11vnc -forever -rfbauth /etc/x11vnc.pass -bg -o /var/log/x11vnc.log -scale 1280x800 -display :0 -auth /var/run/lightdm/root/:0Ich muss die Passwortdatei erstellen:x11vnc -storepasswd password /etc/x11vnc.passDann muss ich mich nur noch auf die eine oder andere Weise in meinen Arbeits-Desktop einloggen. Derzeit greife ich über die UNIX-Rechner der Universität darauf zu, da ein direkter SSH-Zugriff aufgrund einer Firewall nicht möglich ist. Also verbinde ich mich per SSH mit dem UNIX-Mainframe und von dort aus per SSH mit meinem Arbeitsrechner. Sobald ich angemeldet bin, richte ich einen Reverse-SSH-Tunnel zu meinem Macbook Pro zu Hause ein:ssh -R 19999:localhost:5900 IP-Adresse_des_HeimcomputersAuf meinem Macbook zu Hause musste ich zunächst die Option „Freigabe – Fernzugriff“ aktivieren. Dann nutze ich einfach die integrierte Bildschirmfreigabe des Betriebssystems „Mit Server verbinden“ und gebe „vnc://localhost:19999“ ein – und schon sehe ich den Anmeldebildschirm meines Arbeits-Desktops.Alternativ könnte ich meinen OpenVPN-Server nutzen, den ich auf meinem MacBook installiert habe, und einen OpenVPN-Client auf meinem Arbeits-Desktop verwenden, um eine Verbindung zu meinem MacBook herzustellen. Dann könnte ich mich direkt anmelden und die Umwege über die UNIX-Rechner der Universität vermeiden, um den Reverse-SSH-Tunnel einzurichten. Eine weitere, wenn auch sehr langsame Methode, um auf die GUI meines Arbeits-Desktops zuzugreifen, ist die X11-Weiterleitung über SSH. Alles, was ich dafür brauche, ist eine funktionierende SSH-Verbindung zum Server, eine in der SSH-Serverkonfigurationsdatei aktivierte X11-Weiterleitung und einen X11-Server auf dem lokalen Rechner (z. B. XQuarz unter macOS): ssh -X username@remote-server.comxclock &

Kopieren von TAR-Dateien über SSH

Fri, 26 Sep 2008 00:00:00 +0000

tar czv Quellpfad | ssh -l Benutzername 192.168.0.5 tar xz -C Zielpfad

VNC (Virtual Network Computing) über SSH

Sat, 26 May 2007 00:00:00 +0000

Ich sitze zu Hause und möchte die grafische Benutzeroberfläche meines Linux-Rechners bei der Arbeit nutzen. Mein Arbeitsrechner, auf dem der VNC-Server läuft (mcblpc2.hi.helsinki.fi), befindet sich jedoch hinter der Firewall der Universität. Die einzige Verbindung, die ich durch die Firewall herstellen kann, läuft über einen der Hauptrechner der Universität, z. B. vesuri.helsinki.fi. Um eine Verbindung über VNC herzustellen, benötige ich nur zwei Befehle: ssh -L 5901:mcblpc2.hi.helsinki.fi:5901 mjeltsch@vesuri.helsinki.fivncviewer localhost:1 Um die Verbindung zu beschleunigen, kannst du eine Komprimierung verwenden (hilft nur, wenn du eine langsame Verbindung hast, z. B. über ein Modem). Bei der Verwendung von VNC über SSH geht der VNC-Viewer fälschlicherweise davon aus, dass man eine Verbindung zum lokalen Rechner herstellt, und wählt daher eine falsche Kodierung. Der zweite Befehl sollte also eigentlich lauten: vncviewer localhost:1 -compresslevel 0 -encodings "copyrect hextile"Wenn du den vncserver auf einem Computer betreibst, der über eine eigene Firewall verfügt, muss sshd laufen und der SSH-Port (22) geöffnet sein. Anschließend richtest du einen Tunnel von diesem SSH-Server auf diesem Rechner zu einem Port auf deinem lokalen Rechner ein: ssh -L 5901:remotemachine:5901 username@remotemachine vncviewer localhost:1Wenn Sie die KDE-Desktopfreigabe unter SUSE 9.0 nutzen, geben Sie den physischen Bildschirm (:0) frei. Wenn Sie also abgemeldet sind, können Sie keine Verbindung über die Desktop-Freigabe herstellen. Sie müssen zusätzlich eine vncserver-Instanz starten: vncserver Dieser Server verwendet standardmäßig die Sitzung :1, weshalb der weitergeleitete Port 5901 und nicht 5900 (wie bei der ersten Sitzung) sein muss.

SSH-Hostschlüssel

Wed, 23 May 2007 00:00:00 +0000

Bei der Neuinstallation eines SSH-Servers sollte man die SSH-Schlüsseldateien vom alten System beibehalten. Andernfalls erhalten SSH-Clients Meldungen wie „ES IST MÖGLICH, DASS JEMAND ETWAS BÖSES VORHAT!“. Falls Sie die Dateien nicht beibehalten haben, können die Clients die Einträge natürlich aus der Host-Schlüsseldatei (normalerweise /home/user/.ssh/known_hosts) löschen. Wenn sich der Benutzer danach erneut mit dem Server verbindet, werden die neuen, geänderten Host-Schlüsseldateien zur Host-Schlüsseldatei hinzugefügt.

Ausführung des Befehls „dd“ über SSH und Umleitung der Ausgabe in eine lokale Datei

Wed, 04 Apr 2007 00:00:00 +0000

Ich wollte eine gesamte verschlüsselte Partition über das Netzwerk in eine Datei kopieren. Über SSH lassen sich zwar viele Befehle ausführen, aber gelegentlich gibt es Probleme dabei, die Ausgabe an die gewünschte Stelle umzuleiten. Beispielsweise gibt der Befehl „more“ bei Verwendung über SSH nichts an die Standardausgabe aus. Man muss „less“ verwenden, um den Dateiinhalt lokal anzuzeigen (zumindest bei einem RedHat-8-Remote-Rechner). Bei dd kann man nicht die Syntax „dd if=input of=output“ verwenden, sondern muss die Syntax „dd output“ nutzen. Der Befehl, mit dem es mir schließlich gelungen ist, lautet: ssh -l root remote-machine 'dd hda1.bin'

Weiterleitung der X11-Ausgabe eines Remote-Rechners auf einen lokalen Rechner hinter einer Firewall (ssh, X11, ForwardX11)

Wed, 04 Apr 2007 00:00:00 +0000

Wenn die X11-Weiterleitung auf Ihrem lokalen Rechner global deaktiviert ist, müssen Sie diese Einstellung durch Bearbeiten der Datei ~/.ssh/config überschreiben: Host hostname.domain.org ForwardX11 yes Anschließend verbinden Sie sich einfach per SSH mit dem Remote-Rechner hostname.domain.org: ssh -X username@hostname.domain.org Und führen Sie ein Programm aus, das auf X11 ausgibt, z. B.: xclock &

Verwendung von SSH in Skripten (sichere VNC-Verbindung mit einem Klick über krdc)

Thu, 29 Mar 2007 00:00:00 +0000

Verwendung von SSH in Skripten (sichere VNC-Verbindung mit einem Klick über krdc) Ich wollte eine VNC-Verbindung herstellen, die über SSH getunnelt wird und mit nur einem Klick funktioniert. Ich habe ein Shell-Skript mit folgendem Inhalt erstellt: !/bin/sh ssh -L 5902:192.168.0.7:5902 -f -N jeltsch@192.168.0.7 krdc localhost:2 Die SSH-Verbindung bleibt im Hintergrund offen, bis die krdc-Anwendung beendet wurde.