copy-paste mit base64

Ich arbeite oft auf Systemen, die ich nur über einen virtuellen Screen erreiche (Remote Desktop etwa) und zu dem ich zwar eine gemeinsame Zwischenablage habe (copy-paste), aber keine einfache Möglichkeit, Dateien zu kopieren.

Wenn ich etwa eine Logdatei kopieren will, die in den Scrollback-Buffer des Terminalfensters auf der remote Maschine nicht komplett reinpasst, dann muss ich stückeln und bereichsweise kopieren. Das nervt tierisch.

Oder ich nutze gzip und base64:

% cp grosselogdatei.log /tmp
% cd /tmp
% gzip grosselogdatei.log
% base64 grosselogdatei.log.gz
H4sICLiyGlkAA29wZW5maWxlcy5jc3YAbZ3dlsSoCkbvz7PUmVWg+DPv/2BTnZgIuG/3oo35AoiS
VMv3n6/9o1/p/5f+77d+mv5PApPvp1li+v30llj52fXE6o99E7Mfk8DGv98fG4md1x1/1z3+toDd
33VLYn/XjXOef9eVKgkKGO [...]
B5SBkg6GOjwNjG+maEv+4PabgVJ+aBgX7iekIn32poGSDg3zQ8O4aKhDR39wL8wFSutmRx06+oP7
CalAKT/0/YJUoKRDx7jo+8XBSEGzgevFQH8YmCfH/mnWQMkfBsbFQH8YGBf3frOle7v3m9drf4FS
XAz0h4k6TMwPE/3BNTACVbg39xNSgb7nUZGiLfnDxLi495tZHbff3FS+tF7I/sni/wA6SY/SD4IA
AA==

Diesen ASCII Output kann ich locker per copy-paste in einem Rutsch kopieren und in eine Datei lokal kopieren, etwa grosselogdatei.log.gz.b64, und wieder auspacken:

% base64 -d grosselogdatei.log.gz.b64 > grosselogdatei.log.gz
% gunzip grosselogdatei.log.gz
copy-paste mit base64

sudo-matisch

Mit sudo kann man mit den Rechten eines anderen Users Befehle ausführen. Üblicherweise ist das root und wird gebraucht, um ohne root zu sein, root-Rechte zu bekommen. Andere User gehen aber so auch: sudo -u username <command>

Welche Benutzer mit sudo andere Rechte erlangen dürfen, steht in der Datei /etc/sudoers, die man nur mit dem Befehl visudo bearbeiten sollte. Je nach OS und Distribution findet man hier andere Voreinstellungen. Auf meinem Mac habe ich mir etwa einen unpriviligierten User angelegt (ist sicherer), aber mir in der sudoers-Datei trotzdem alle Rechte zugestanden (ist komfortabler).

# User privilege specification
eliyah ALL=(ALL:ALL) ALL

Aber sudo lässt sich auch für andere Dinge nutzen, etwa Scripte. Man will nicht immer ein Script, das für nur einen Befehl root-Rechte benötigt, komplett als root laufen lassen. Etwa, weil es von einem anderen Prozess, der selbst keine root Rechte besitzt, getriggert wird. Ein Beispiel sind cgi’s für den Webserver. Ein anderes sind per ssh remote ausgeführte Kommandos.

Ausserdem will man in scripten oder remote kein Passwort eintippen müssen, wenn man per sudo Befehle ausführt, will aber in seinem System nicht gleich für alle Tür und Tor öffnen.

Der Trick ist, Befehle zu definieren, die ein User ohne Passwort ausführen darf. Das geht über die Cmnd_Alias Funktion. Hier im Beispiel eine Befehlsdefinition, der es einem User erlaubt, Passworte für andere User zu setzen und einer, der erlaubt, per tcpdump Traffic mitzulesen:

# Cmnd alias specification
Cmnd_Alias PASSWD = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root
Cmnd_Alias TCPDUMP = /usr/sbin/tcpdump

Was man hier schön sehen kann ist, dass man nicht nur Programme, sondern auch Parameter bestimmen kann, die erlaubt sind. Mit dem Ausrufezeichen (!) kann man auch Dinge wieder ausschliessen, hier eben das Ändern des Passwortes für den User root.

Wenn der Befehlalias definiert ist, kann man bestimmten Usern diese Befehle erlauben, sogar ohne Eingabe des Passwortes.

# User privilege specification
eliyah ALL=(ALL:ALL) PASSWD
eliyah ALL=(ALL) NOPASSWD: TCPDUMP

Die verschiedenen ALLs erlauben, von wo aus man das darf. Wie im Detail, weiss ich nicht, interessiert mich auch nicht. Denn ich kann jetzt ein Script schreiben, das als User eliyah läuft und mit Hilfe von sudo ohne Passwortabfrage einen tcpdump machen kann.

sudo-matisch

OS X: Wer lauscht denn da?

Unter GNU Linux gibt es den Befehl netstat, mit dem man sich nicht nur anzeigen lassen kann, welche Ports gerade aktiv sind. Mit dem Parameter -pl (p für Prozess-ID und l für listen) sieht man auch, welcher Prozess gerade eine Tür geöffnet hat. Unter OS X ist das nicht ganz so einfach. Dort gibt es die BSD Variante von netstat, und die funktioniert anders. Mit folgendem Befehl sieht man, welche Ports geöffnet sind:

netstat -a | fgrep LISTEN

Bei mir erscheint da unter anderem etwa folgender Eintrag:

tcp4 0 0 192.168.2.2.54045 *.* LISTEN

Wer macht denn da Port 54045 auf und habe ich das erlaubt? Ich muss feststellen. Ja habe ich:

% lsof -nP -iTCP:54045 -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Skype 36967 eliyah 30u IPv4 0xf42576a198a9cfbb 0t0 TCP 192.168.2.2:54045 (LISTEN)

Denn ich habe Skype installiert, und das macht bekanntlich, was es will. Der Befehl lsof (List Open Files) bringt es zum Vorschein.

Ich habe bei meinem Mac auch ssh aktiviert, und wenn ich schaue, welcher Prozess diesen Dienst bereit stellt, kommt überraschendes zu Tage:

% sudo lsof -nP -iTCP:22 -sTCP:LISTEN
Password:
COMMAND PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
launchd   1 root   50u  IPv6 0xf42576a168a5fb6b      0t0  TCP *:22 (LISTEN)
launchd   1 root   51u  IPv4 0xf42576a168a676eb      0t0  TCP *:22 (LISTEN)
launchd   1 root   53u  IPv6 0xf42576a168a5fb6b      0t0  TCP *:22 (LISTEN)
launchd   1 root   54u  IPv4 0xf42576a168a676eb      0t0  TCP *:22 (LISTEN)

Das sudo ist nötig, da hier ein Port unter 1023 abgefragt wird. Der ssh-Dienst wird vom launchd selbst bereitgestellt. Das funktioniert ähnlich wie inetd oder xinetd unter Linux, nur dass launchd deutlich weitreichendere Aufgaben hat, was man schon an seiner Prozess-ID 1 erkennt.

OS X: Wer lauscht denn da?

ssh-Schlüssel generieren

Der Zugriff per ssh auf einen Server ist per Schlüssel nicht nur komfortabler, sondern auch sicherer. Das Generieren des Schlüssels ist auch sehr leicht.

Die Schlüssel landen auf Client und Server jeweils im Verzeichnis .ssh im Heimverzeichnis. Bevor man einen neuen Schlüssel generiert, sollte man nachsehen, ob es schon einen gibt, den man dadurch eventuell überschreibt.

ls -al .ssh

Wenn keine Schlüssel da sind oder das Verzeichnis gar nicht existiert, dann kann man bedenkenlos ein Schlüsselpaar erzeugen. Alte dsa-Schlüssel funktionieren zwar, aber ein sicherer rsa-Schlüssel darf es schon sein:

ssh-keygen -t rsa

Man wird nach einer Passphrase gefragt, mit der man den Schlüssel sichern kann (optional). Wer sich ganz sicher ist, dass niemand den privaten Schlüssel jemals klauen wird, der kann darauf verzichten. Dann kann man sich in Zukunft ohne Passwort einloggen oder ihn für Scripte verwenden, die ohne Benutzerinteraktion auf einem remote-Gerät Befehle ausführen sollen.

Im Verzeichnis .ssh liegen jetzt die Dateien id_rsa und id_rsa.pub. Ersterer ist der private und der zweite der öffentliche Schlüssel. Der Private muss auf dem Client in .ssh abgelegt werden. Wenn man auf dem Client das Schlüsselpaar angelegt hat, dann liegt der private Schlüssel schon an der richtigen Stelle, nämlich: .ssh/id_rsa. Der öffentliche (wesentlich kürzere) wird an die Datei .ssh/authorized_keys angehängt. Diese Datei kann viele Schlüssel gleichzeitig beinhalten. So kann man für ein und den selben Account verschiedene Schlüssel verteilen und natürlich auch wieder löschen.

Der öffentliche Schlüssel ist nicht geheim. Man kann ihn also bedenkenlos per Email an einen Serverbetreiber schicken, damit er ihn auf dem Server hinterlegt. So zeigt man ihn an, damit man ihn per Copy-Paste in eine Email packen kann.

cat .ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCTlNVxtfBK+/l/oJz3LInlxjkpAk7z3LtWJ2wq0akT6V/ckpkVFhT2aLNZfCeSp0j4SOmUN+2v+olilUmiS/6X0vVIIJJxd3ghjA0AO65VY1v/6/bcdrfyLL76wjjGnIefBYWMwGJUDdsIPhlYT8t1MaTXh+HXBkqBSBoxgIi+VUjnTP9LBoFPPatEcS6nmOqMaSelPbwksR5yFCNRTBTBQ/bEsy/Z07GSaWW0w9Uolh9cRilzWEHrgD2KvOIatS+/DTjdPxZXgCKzee3ws1OnfJ6LG72uDKkDzR5hwZjy/TQhHpdR8fMC3SJbCwOQv0qnghv1T/7hqdfzE4mWcoyF eliyah@client

Fertig! Das war es schon.

ssh-Schlüssel generieren

Lautstärke anpassen

Ich habe weiter unten ein Script für meine Webcam vorgestellt. Das Script sagt immer „take photo“ bevor es genau das tut. Mir war das zu laut. Ich will, dass das leiser ist. Dummerweise kann man dem Befehl „say“ keine Ausgabelautstärke mitgeben. Man muss also die Systemlautstärke ändern. Mein Script prüft, ob das System gemutet is, dann sagt es gar nichts. Und wenn nicht, setzt es die Lautstärke auf den niedrigst möglichen und dann wieder zurück zu dem, der vorher gewählt war. Dafür benutze ich die AppleScript engine, die man über osascript auch aus der Shell nutzen kann:

if [ $(osascript -e "output muted of (get volume settings)") == false ]; then
  VOLUME=$(osascript -e "output volume of (get volume settings)")
  osascript -e "set volume output volume 1 --100%"
  say take photo
  osascript -e "set volume output volume $VOLUME --100%"
fi

Damit kann man natürlich auch Schindluder treiben. Hat man einen ssh-Zugang auf einem fremden Mac, dann kann man aus der ferne Lautstärken verstellen und Sprachnachrichten absetzen.

osascript -e "set volume output volume 100"
say -v Zarvox Access denied
Lautstärke anpassen

NAT und Cisco

Hier will ich nicht erklären, wie man NAT auf einer Cisco konfiguriert. Aber ein paar Dinge suche ich immer wieder und daher schreibe ich sie hier auf:

  • Port forwarding mit statischer IP
ip nat inside source static tcp [int. IP] [int. Port] [ext. IP] [ext. Port] extendable
  • Port forwarding mit dynamischer IP auf Dialer1
ip nat inside source static tcp [int. IP] [int. Port] interface Dialer1 [ext. Port]
  • exposed host (alle Ports auf eine interne IP)
ip nat inside source static [int. IP] interface Dialer1

und damit Telnet von aussen auf den Router noch geht (wenn gewünscht):

ip nat inside source static tcp [int. Router-IP] 23 [ext. IP] 23 extendable
NAT und Cisco