Kennt sich hier jemand mit plink aus den puTTY-Tools aus?

[TS]

Hello,

ich mühe mich ab, auf meinem Debian-Host das Tool

plink Command-Line-Tool für Kommandos per ssh

aus den puTTY-Tools mit IPv6 zu benutzen. Ich habe das gleiche Problem, wie in diesem Thread beschrieben.

Die IPv6 wird nicht akzeptiert.

Leider habe ich keine uxplink.c vorliegen, sondern nur das fertige Binary.
Wo bekomme ich die uxplink.c und wie kann ich dann eine gepatchte Version davon erzeugen (wie compilieren?).

Oder gibt es eine Alternative zu plink, die sofort funktioniert? Das wäre mir dann erstmal lieber. Ich muss noch diverse Router per ssh-6 updaten. Da könnte ich das Tool gut gebrauchen.

Glück Auf
Tom vom Berg

[ursus contionabundo]

Ich habe das gleiche Problem, wie in diesem Thread beschrieben.

Die IPv6 wird nicht akzeptiert.

An der genannten Stelle finde ich:

exactly, i tried the same i.e
"plink -v -6 -pw <pwd> <user>@fe80::206:5bff:fe7d:ef4f <cmd>"

The error messages are
------------------------------
Looking up host "fe80" (IPv6)
Unable to open connection:
Name or service not known

Ich gehe mal davon aus, dass IPv6 ordnungsgemäß funktioniert und das Deine Koste eine IPv6-Adresse hat. (zeigt ipconfig eine an?

Im obigen Beispiel scheitert plink oder schon die Windows-Shell offenbar am ":". Versuchs mal mit Quotas:

> plink -v -6 -pw "<pwd>" "<user>@fe80::206:5bff:fe7d:ef4f" "<cmd>"

Oder gibt es eine Alternative zu plink,

Jede Menge.

Ich würde auf den bitwise ssh-client oder den cyqwin-ssh-client setzen. Erste Wahl wäre aber, falls Du Windows 10 hast, das Linux-Subsystem für Windows.

Ich muss noch diverse Router per ssh-6 updaten

Ich frage mich weshalb Du Dich damit befasst, derlei überhaupt unter Windows tun zu wollen. Vielleicht wäre ja eine virtuelle Maschine eine Lösung.

[TS]

Hello,

ich habe plink für Linux im Einsatz. Mit IPv4 funktioniert das sehr gut.

Es geht um die Übergabe von Befehlen per Datei für die Remote Maschine (den Router), so als würde man sie in eine SSH-Konsole eintippen.

Man kann ja scheinbar auch ssh eine Datei reinschieben, aber das akzeptiert keine Passwortübergabe per Kommandozeile. Mit expect habe ich das noch nicht hinbekommen.

Ich habe für jeden Router den Typ, die IPv6 und das Passwort in einer Tabelle. Wäre also schön, die Biester automatisch zu bedienen mit ihren Updates bzw. Konfigurationsänderungen.

"Router" steht hier für die üblichen Kombinationsgeräte für WLAN-Access.

Glück Auf
Tom vom Berg

[ursus contionabundo]

Man kann ja scheinbar auch ssh eine Datei reinschieben, aber das akzeptiert keine Passwortübergabe per Kommandozeile.

Ja, denn das wäre sehr unsicher. Wenn Du aber Schlüsseldateien erzeugst und den privaten Key ganz sicher ablegst, kann dieser ohne Passwort erzeugt werden. Freilich müssen die "Router" dann die Möglichkeit haben, den Public-Key zu speichern und zu beachten.

[TS]

Hello,

was ist schon sicher?

Schlüsseldateien sind personenbezogen, Passworte aber gerätebezogen, also für jedes Gerät ein anderes Passwort.

Aber ich habe die uxplink.c gefunden. Wie mache ich daraus eine Binary für mein Debian-System? Reichr dafüf der GCC?

Es muss vorher die Modifikation durchgeführt werden in Zeile ???, wie in dem anderen Thread beschrieben. Ich kanns aber gar nicht mehr finden. Könnte sein, dass die Git-Version schon "repariert" ist.

Glück Auf
Tom vom Berg

[ursus contionabundo]

Aber ich habe die uxplink.c gefunden. Wie mache ich daraus eine Binary für mein Debian-System? Reicht dafür der GCC?

Wenn Du das "par tout" und gegen jeden guten Rat willst:

Erst muss Putty vorher mit dem Paketverwalter deinstalliert werden, damit Du das Problem nicht nach dem nächsten Update wieder hast. Vergiss nicht die automatisch installierten Pakete ebenfalls zu deinstallieren.

Dann https://git.tartarus.org/?p=simon/putty.git;a=summary

Den aktuellen Snaphot laden (am besten nach /usr/src/putty), entpacken und nachschauen, ob ./unix/uxplink.c gepacht werden muss (also die beschriebene Zeile überhaupt noch enthält).

Dann wie in der Datei ./README unter Linux vorgesehen vorgehen.

Freilich kann man das shared object auch einzeln kompilieren, aber das macht nur noch mehr Ärger!

Ab sofort musst Du dann putty immer wieder auf diese Weise updaten. Das will man nicht, weil es eine Menge Arbeit macht! Ich würde mir an Deiner Stelle, bevor ich mir DAS antue, mal reinziehen, wie bequem, einfach und sicher das mit ssh und den Schlüsseldateien geht!

[TS]

Hello,

Ab sofort musst Du dann putty immer wieder auf diese Weise updaten. Das will man nicht, weil es eine Menge Arbeit macht! Ich würde mir an Deiner Stelle, bevor ich mir DAS antue, mal reinziehen, wie bequem, einfach und sicher das mit ssh und den Schlüsseldateien geht!

Mit dem Verpacken in Anführungszeichen hat es leider auch nicht geklappt.

Es sind noch keine Schlüssel auf den betroffenen Geräten (ca. 180) vorhanden.
Die könnte ich dann aber hochschieben.

Ich versuche es erstmal mir der expect-Methode für ssh. Vielleicht bekomme ich das ja irgendwie hin, ein passendes Wrapper-Script dafür zu erstellen.

Glück Auf
Tom vom Berg

[ursus contionabundo]

Es sind noch keine Schlüssel auf den betroffenen Geräten (ca. 180) vorhanden. Die könnte ich dann aber hochschieben

Dabei hilft Dir "ssh-copy-id".

• Brauchbar aussehendes Beispiel für Expect

Achte darauf, dass Du womöglich entweder Deine locale-Einstellungen auf en-US setzt oder überprüfst, welche Strings ssh bei Dir "raushaut".

[TS]

Hello,

• Brauchbar aussehendes Beispiel für Expect

Achte darauf, dass Du womöglich entweder Deine locale-Einstellungen auf en-US setzt oder überprüfst, welche Strings ssh bei Dir "raushaut".

Ja das stimmt. Äußerst sinnvoll, sich da vorher ein paar Beispiele für die Ausgaben zu erzwingen, auch mit (absichtlichen) Fehleingaben.

Glück Auf
Tom vom Berg

[TS]

Hello,

welche Probleme muss ich erwarten, wenn ich ein nagelneues Binary von plink von einem 64Bit-Ubuntu auf ein älteres Debian 64Bit-System übertrage? Mal abbgesehen von der dann zerstörten Versionsverwaltung ...

Könnte das laufen?

Glück Auf
Tom vom Berg

[ursus contionabundo]

welche Probleme muss ich erwarten, wenn ich ein nagelneues Binary von plink von einem 64Bit-Ubuntu auf ein älteres Debian 64Bit-System übertrage?

Das neue kann libs in neuer Version erwarten, die dann nicht da sind. Die Nachinstallation verursacht regelmäßig Konflikte. Das wird dann ein Horror.

[TS]

Hello,

welche Probleme muss ich erwarten, wenn ich ein nagelneues Binary von plink von einem 64Bit-Ubuntu auf ein älteres Debian 64Bit-System übertrage?

Das neue kann libs in neuer Version erwarten, die dann nicht da sind. Die Nachinstallation verursacht regelmäßig Konflikte. Das wird dann ein Horror.

Ob shared Objects erwartet werden müsste ich doch eigentlich aus den Headerdateien des Quellcodes ersehen können, oder?

Aber da gibts noch 'was Interessantes, nicht von Bosch, aber von PHP ;-)

Das schaue ich mif mal näher an.

Glück Auf
Tom vom Berg

[ursus contionabundo]

Ich hoffe, Du hast das hier gelesen: ssh2.installation.

Ich bin mir nämlich "höchst unsicher", ob Webhoster php-ssh2 installieren...

Aus diesem Grund verwende ich für Zugriffe von Server zu Server lieber eine Micro-API, führe also die Shell-Befehle auf dem entfernten Host aus und liefere die Ausgaben (schon "geparst") via HTTPS als Text oder JSON zurück. Nutzerseitig sieht das so aus.

[pl]

Danke für den Begriff Micro API. Bei mir heißt das RPC ohne XML. Funktioniert aber genauso 😉

[ursus contionabundo]

Naja. Ein[m|r] RPC ("Remote Prodecure Call", "Entfernt-Ausführen-Anforderung") muss ja stets eine Vereinbarung (a.k.a. "Protokoll") zugrunde liegen, wer wem was wie übermittelt.

Und schon hat man eine "API". In dem Fall der "Micro API" halt eine sehr schlanke...

[pl]

Naja. Ein(m|r) RPC ("remote prodecure call", "Entfernt-ausführen-Anforderung") muss ja stets eine Vereinbarung (a.k.a. "Protokoll") zugrunde liegen, wer wem was wie übermittelt.

Ja natürlich, klar. Nur ist mir kein besserer Name für das Modul eingefallen was mein Kommandozeilenframework da zu laden hat.

Und schon hat man eine "API". In dem Fall der "Micro API" halt eine sehr kleine...

Serverseitig läuft das bei mir genauso übers Framework wie jeder andere HTTP Request. Und auch mein DB Management läuft darüber.

D:\>c.pl RPC -host example.com -base mybase -sql select count(*) from log
$VAR1 = [
          {
            'count(*)' => '45319'
          }
        ];

Größere Statements als -sql dateiname zum Beispiel um Dumps einzuspielen.

MfG

[ursus contionabundo]

c.pl RPC -host example.com -base mybase -sql select count(*) from log

Das ist nicht "micro" sondern "big", weil es offenbar sehr viel können soll. Ich persönlich lehne sowas ab. Grund je "bigger" ein solches Skript (und die von diesem aufgerufenen libs) sind, umso schneller(häufiger) handelt man sich Probleme ein.

Außerdem würde meine Shell den "*" in alle (nicht mit einem Punkt beginnenden) Dateisystem-Objekte im Verzeichnis auflösen... - Der Beitrag ist mit Linux "getaggt".

[pl]

c.pl RPC -host example.com -base mybase -sql select count(*) from log

Das ist nicht "micro" sondern "big",

Das sind nicht die richtigen Begriffe. Entscheidend ist, wie man so etwas aufbaut, also wie man es nicht machen sollte zeigt wordpress.

Es kommt vielmehr darauf an, ein Framework als Solches zu begreifen. Für ein serverseitiges Content Management braucht man Zugriff auf die gesamte Konfiguration und nicht nur schlechthin Zugriff auf eine Datenbank.

Und natürlich hilft OOP dabei seinen Code so zu organisieren daß man sich für Kommandozeile nur noch einen einzigen Namen für ein Kommando merken muss, also nicht 'zig Scriptnamen wie WP das praktiziert. So führt ein an dieses eine Kommando gebundenes CLI den Anwender durch ein Kommandozeilenframework was je nach Aufgabenstellung beliebige lokale Module nutzt indem es diese lose an sich bindet.

Mächtig, gewaltig ist der bessere Begriff 😉