Wenn man in einem Apache Ant Build Script bei einem sshexec mehrere Befehle aneinanderreihen möchte, dann kann man nicht wie von Linux gewohnt mittels “&&” konkatinieren – Ant wirft dann einen Fehler, dass ein & nicht von einem & gefolgt werden darf. Die Lösung ist sehr banal:
<sshexec host=”${host.name}” trust=”true” username=”${user}” password=”${pw}” keyfile=”${optional.keypair}” command=”command1 && command2 & & command3″/>Für alle, die sich unnötige manuelle Schritte beim Hinzufügen eines neuen SSH Keys zum eigenen Github Account sparen wollen:
mit
curl --data "{\"title\": \"NAME\",\"key\": \"`cat ~/.ssh/id_rsa.pub`\"}" --request POST https://api.github.com/user/keys --user "USERNAME:PW"wird automatisch der Public SSH Key des aktuellen Benutzers im Github Account hinterlegt.
Unter NAME wird ein eindeutiger Name für den Schlüssel angegeben, USERNAME und PW sollten selbsterklärend sein.
Noch ein kleiner Tipp am Rand: bestehende Keys werden weder überschrieben, noch doppelt hinzugefügt.
Erinnerung an mich selbst: wenn mich ein remote git Repo das nächste mal mit so einer Fehlermeldung begrüßt
fatal: failed to write object error: unpack failed: unpack-objects abnormal exit Auto packing the repository for optimum performance. fatal: Unable to create '/[reponame].git/packed-refs.lock': Permission denied
…dann macht es Sinn zu prüfen, ob der jeweilige User auf dem Zielserver überhaupt die entsprechenden Schreibrechte für den Repository Ordner hat…
Stellt euch folgende Situation vor: ihr sitzt in einem Caffé und möchtet gern das dort vorhandene, offene Wlan nutzen. Das ist natürlich sicherheitstechnisch nicht gerade optimal, da eure Kommunikation so von jedem Script-Kiddie abgehört werden kann.
Sofern ihr einen Server irgendwo im Internet habt, auf dem ihr euch per SSH einloggen könnt, gibt es einen sehr leichten Weg, eure Verbindung abzusichern:
Im Terminal
ssh -ND 9999 benutzername@server.de
eingeben (an Stelle von 9999 könnt ihr natürlich auch einen anderen freien Port verwenden). Sofern ihr auf dem Server bereits euren public ssh Key hinterlegt habt, dann könnt ihr das Terminal nun minimieren (nicht schließen!). Wenn nicht, werdet ihr nach eurem Passwort gefragt. Eintippen, Enter drücken und nun das Fenster minimieren.
Nun habt ihr einen laufenden Socks Proxy. Richtet entweder direkt im Browser oder in den Netzwerkeinstellungen den Proxy
Server: localhost Proxy: 9999 (bzw. den von euch gewählten Port)
ein. Ab sofort surft ihr nun über einen sicheren Kanal zu eurem Server und erst dann ins Netz.
Als Erweiterung zu [Quicktip] ssh Verbindung ohne Known-Hosts Eintrag hier noch die Möglichkeit, das Loginpasswort für einen Server an den SSH Befehl zu übergeben:
Aus Sicherheitsgründen ist es nicht möglich, Passwörter an den ssh-Befehl unter Linux/Unix zu übergeben. Damit soll verhindert werden, dass Passwörter in Scripten hardcoded werden und somit nicht mehr sicher sind. Möchte man passwortlos per Script mit anderen Servern arbeiten, gibt es noch immer die Möglichkeit, die RSA Keys zu hinterlegen.
Nun gibt es aber auch einige wenige spezielle Anwendungsfälle, in denen das Passwort nicht wirklich Sicherheitsrelevant ist, man nicht die Möglichkeit hat den RSA Key zu hinterlegen und man immer mit wechselnden Rechnern zu tun hat. Für diese seltenen Fälle kann man sich mit dem “expect” Befehl behelfen. “expect” macht folgendes: man ruft ein Programm per “expect” auf und versieht das ganze mit einem Kontrollscript. Dann kann man mit einer Art regulärer Ausdrücke nach Ausgaben eines Programmes suchen und auf diese reagieren. Im Fall von ssh sucht man nach der Ausgabe “password:”. Findet expect dieses, soll es einen vorgegebenen Wert einsetzen und mittels Enter bestätigen. Wenn man nun noch ein bisschen Bash-Magie betreibt kommt dieses Script heraus.
Der Aufruf läuft dann so:
./sshlogin.exp password 192.168.1.11 who
In dieser Variante wird immer der Benutzer root verwendet, man kann das Script aber einfach noch um einen weiteren Parameter erweitern, schon ist der Benutzername auch variabel.
Und was war mein Anwendungsfall? Darüber gibt es demnächst einen Artikel… 😉
Links:
bash.cyberciti.biz
Es gibt gute Gründe, warum ssh die Fingerprints (also die virtuellen Fingerabdrücke) der Server speichert, mit denen man sich verbindet. Tut man dies nämlich erneut, so kann ssh prüfen, ob sich hinter dieser IP bzw. hinter diesem Hostnamen noch immer der gleiche Rechner befindet. Wenn nicht, gibt’s eine Warnung.
Nun gibt es aber auch Fälle, bei denen will man diesen Schutz unterbinden – vornehmlich beim Scripting. Und das macht man so:
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@server
Was passiert? Mit dem ersten Parameter wird das known-hosts-File “/dev/null”, also “nichts”, verwendet. Parameter 2 gibt an, dass die Überprüfung der Fingerprints deaktiviert werden soll. Lässt man den ersten Parameter weg, so werden trotzdem die Fingerprints in der normale known-hosts-File geschrieben.