Probleme mit dem SSH Zugang per Schlüssel

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:

chmod 700 /home/seeseekey/.ssh/
chmod 600 /home/seeseekey/.ssh/authorized_keys

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.

Seltsame Zeichen unter PuTTY

Wenn man PuTTY nutzt, wird man sich sicherlich das ein oder andere Mal über die seltsame Zeichen gewundert haben. Ein schönes Beispiel dafür ist der Midnight Commander, der anstatt mit der gewohnten Linienoptik mit ganz anderen Zeichnen arbeitet. Das Problem ist hier allerdings nicht beim Server zu finden. Stattdessen muss bei PuTTY gesucht werden.

Die PuTTY Optionen

Die PuTTY Optionen

Um das Problem zu beheben, sollte man in den Einstellungen unter „Window“ -> „Translation“ das „Remote character set“ auf UTF-8 stellen. Danach gehören die fehlerhaften Zeichen der Vergangenheit an.

SSH Schlüssel aus known_hosts entfernen

Manchmal ändert sich die RSA Schlüssel für einen entfernten Server welchen man per SSH erreichen möchte. Dann bekommt man vom System eine schöne Meldung:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.

The fingerprint for the RSA key sent by the remote host is
3b:a3:48:fc:55:70:70:f8:43:33:50:73:d9:b8:1d:9e.

Please contact your system administrator.

Add correct host key in /Users/seeseekey/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/seeseekey/.ssh/known_hosts:17
RSA host key for 8.8.8.8 has changed and you have requested strict checking.
Host key verification failed.

Das Problem besteht darin, das ein alter Fingerprint in der „known_hosts“-Datei vorhanden ist. Die brachiale Methode wäre es die Datei zu löschen. Damit wäre die Verbindung mit dem Server wieder möglich. Natürlich löscht man so auch alle anderen verifizierten Server (bzw. deren Fingerprints). Sauberer ist es den veralteten Key mittels „ssh-keygen“ zu entfernen:

ssh-keygen -R 8.8.8.8

Anschließend wird man beim nächsten Verbindungsversuch wieder gefragt ob man die Verbindung akzeptieren möchte. Ist dies der Fall kann sich mit dem Server verbunden werden.

Git bei all-inkl einrichten

Nachdem ich versuchte Git per WebDAV in Verbindung mit ownCloud einzurichten, fiel mir ein, das die größeren Paketen (ab Premium) bei all-inkl.com auch einen SSH Zugang beinhalten. Mit diesem ist es relativ einfach das Webhosting Paket als Server für Git Repositories zu benutzen. Sollte auf dem lokalen Rechner noch kein SSH-Schlüssel erzeugt worden sein, so kann dies mittels:

ssh-keygen -t rsa -C ""

nachgeholt werden. Nun kann der Schlüssel an den all-inkl Server übertragen werden:

ssh-copy-id -i ~/.ssh/id_rsa.pub

Anschließend ist es möglich sich mit dem all-inkl SSH Server ohne Authentifikation über ein Passwort anzumelden:

ssh

Dort legen wir in dem Ordner in welchem unserer Git Repository landen soll ein leeres Repository an:

git init --bare

Als nächsten Schritt trägt man einen Remote an ein lokales Git Repository an:

git remote add origin ssh:///www/htdocs/nutzername/repos/Example.git

Danach kann das lokale Repository mit dem Befehl:

git push origin master

auf den entfernten Server kopiert werden. Benötigt man es auf einem anderen Rechner so kann das ganze mittels:

git clone ssh:///www/htdocs/nutzername/repos/Example.git

bewerkstelligt werden.

Linux Nutzer ohne Shell anlegen

Manchmal benötigt man unter Linux einen Nutzer, möchte aber das dieser keine Shell zugewiesen bekommt und sich somit nicht anmelden kann. Dies kann unter anderem mit dem Befehl „adduser“ bewerkstelligt werden:

adduser seeseekey --no-create-home --shell /bin/false

Damit legt man einen Nutzer an, welcher sich nicht anmelden kann, aber durchaus für die Authentifizierung über das Nutzersystem z.B. bei bestimmten Netzwerkdiensten taugt. Daneben wird auch gleich verhindert, dass der Nutzer einen „home“-Ordner bekommt.