Möchte man sich auf einem Linux-Server per SSH Schlüssel anmelden, so kopiert man im ersten Schritt seinen Schlüssel auf den entfernten Server:
ssh-copy-id -i ~/.ssh/id_rsa.pub
Anschließend kann man sich mittels:
ssh
ohne Passworteingabe auf den Rechner einloggen. Sollte dies nicht der Fall sein, gibt es ein Problem. So kann es passieren das man trotz SSH-Schlüssel ein Passwort eingeben soll. Um die Ursache zu diagnostizieren hilft es „ssh“ im Verbose-Modus zu benutzen:
ssh -v
Im diesem Modus werden viele Debuginformationen ausgegeben, welche helfen können das Problem einzugrenzen. Das man Passwörter trotz eines SSH Schlüssels eingeben muss, liegt manchmal an falsch konfigurierten Dateirechten im „.ssh“ Ordner auf dem entfernten Rechner. Die einfachste Möglichkeit ist es hier den Ordner komplett zu entfernen, damit er vom System nochmal angelegt wird. Dazu muss der Schlüssel natürlich mittels „ssh-copy-id“ wieder auf dem Rechner angebracht werden. Alternativ ist es auch möglich die Rechte für diesen Ordner neu zu setzen:
Wenn der Verbose-Modus nicht die gewünschten Ergebnisse bringt, so sollte sich die Logdatei /var/log/auth.log“ angeschaut werden. Dort kann man dann z.B. solche Meldungen bewundern:
Sep 21 01:47:35 service sshd[34221]: Authentication refused: bad ownership or modes for directory /home/seeseekey
In diesem Fall lag es nicht nur am „.ssh“ Verzeichnis, sondern auch an dem Homeverzeichnis des Nutzers. Ein:
chmod 700 /home/seeseekey/
wirkt in einem solchen Fall wahre Wunder. Danach sollte auch die Authentifikation per SSH-Schlüssel wieder funktionieren.
Wenn man sich einem unsicheren Netz bewegt, z.B. in einem freien WLAN empfielt es sich ein VPN zu nutzen. Dafür gibt es die unterschiedlichsten VPN-Dienste, welche dies gegen einen monatlichen Obolus anbieten. Besitzt man einen eigenen Server, so kann man sich mittels OpenVPN einen solchen Dienst selber aufsetzen. Im ersten Schritt wird OpenVPN installiert:
apt-get install openvpn
Aus den Beispieldateien wird das Skript „easy-rsa2“ zum Erstellen der Zertifikate an den entsprechenden Ort kopiert:
Damit ist die Certificaty Authority (CA) erstellt. Nun geht es an die Erstellung der Schlüssel für den Server:
sudo -E ./build-key-server server
Beim Common Name, gibt man die Domain ein unter welcher der VPN Server später erreichbar sein soll (z.B. vpn.example.org). Nach der Erstellung wird man im „keys“ Verzeichnis die Dateien „server.crt“, „server.csr“ und „server.key“ finden. Für den Diffie-Hellman Schlüsselaustausch müssen entsprechende Paramater erzeugt werden:
sudo -E ./build-dh
Nun fehlen nur noch die Zertifikate für die entsprechenden Nutzer. Ein Nutzer wird dabei mittels:
sudo -E ./build-key nutzerOderClientName
erstellt. Damit sind alle benötigten Zertifikate und Schlüssel erstellt, so das nun die restliche Konfiguration des Servers vorgenommen werden kann. Als Basis wird dabei die mitgelieferte Beispieldatei genutzt:
Neben F-Zero und dessen Ablegern, wird es schwierig weitere vernünftige Science Fiction Racer zu finden. Das Spiel Quantum Rush möchte dies ändern. Es handelt sich dabei um keinen reinen Racer wie bei F-Zero, sondern die Gleiter verfügen auch über Waffensysteme ähnlich Extreme G. Ein Einspielermodus ist leider nicht vorgesehen, allerdings soll man über das Netz mit anderen Spielen um die Wette fahren können.
Quantum Rush
Entwickelt wird das ganze vom Berliner GameArt Studio und soll zuerst als Windows Version erscheinen. Da Quantum Rush mittels Unity3D entwickelt wird, sind auch Versionen für Mac, Linux, XBox, PlayStation, Android und iOS geplant. Vielleicht springt auch noch eine Version für die OUYA heraus.
Das Projekt sucht dabei noch Unterstützer auf Kickstarter welche die Entwicklung finanzieren. Ziel sind dabei $100,000 und im Moment sind noch 18 Tage Zeit um die restlichen knapp $95.000 aufzutreiben.
Die aktuelle Kubuntu-Version 13.04 hat ein Problem mit der Zeitzone. Diese ist aus irgendeinem Grund auf UTC eingestellt. Versucht man das ganze zu ändern, bekommt man eine Fehlermeldung:
Authentifizierung nicht möglich, Aktion kann nicht ausgeführt werden: 6,
Auf der Konsole kann man das Problem dabei relativ schnell beheben:
Den MTA „sendmail“ über den Paketmanager zu installieren ist eine Sache von Sekunden:
apt-get install sendmail
Interessanter wird dann wenn man versucht „sendmail“ wieder zu entfernen. Der Logik folgend sollte ein einfaches:
service sendmail stop
apt-get remove sendmail
funktionieren. Allerdings läuft der MTA auch danach noch weiter. Abhilfe schafft hier die Deinstallation eines zweiten Paketes, so das der komplette Befehl so aussehen sollte:
service sendmail stop
apt-get remove sendmail sendmail-bin
Möchte man die Konfigurationsdateien auch entfernen, so bietet sich anstatt eines „remove“ ein „purge“ an:
service sendmail stop
apt-get purge sendmail sendmail-bin
Danach hat der MTA das zeitliche gesegnet und man verfügt wieder über eine Installation ohne „sendmail“.
