remote debug

[mschnell]

Wenn gdb über SSH, dann bitte eine Möglichkeit vorsehen Benutzer und PW optional anzugeben.

Man kann ssh-Parameter angeben.

Ich weiß, dass man ssh mit
ssh benutzer@host
starten kann. Wie man ein Passwort angeben kann, weiß ich nicht.

-Michael

[MiR]

Wenn Du ssh durch plink (Bestandteil des ssh-Pakets putty) ersetzt dann könnte es klappen, zumindest habe ich über google das hier gefunden:

plink.exe -ssh -l USER -pw "PASSWORT" USER@1.2.3.4 BEFEHL

Unter Unix hast mit sowas wenig Glück, da hilft es entweder den ssh-Beispielcode des libssh2 Pakets anzupassen oder mit expect ein Wrapperskript zu bauen mit dem das Passwort an ssh übergeben wird und dieses dann statt ssh aufzurufen.

[mschnell]

könnte das gehen: http://sourceforge.net/projects/sshpass/

Ich glaube aber, besser ist es den Authentifizierungscode in sshgdbmiedebug.pas zu aktivieren und zu testen.

-Michael

[martin_frb]

Unter Windows geht es meines Wissens nur im mode "-gdb-set target-async 1" mit "-exec-interrupt", wenn überhaupt. Ich denke Windows empfiehlt sich für Entwicklungen mit der gnu-Toolchain sowieso nur begrenzt. Vielleicht könnte man mal schauen wie Eclipse unter Windows die Sache bewerkstelligt.
Unter Linux verwende ich ebenfalls den async mode, falls möglich, sonst "kill(<gdb_process_handle>,sigint)";

Ok, thanks.

Well then, wenn Interesse besteht. DEr patch in meinem letzten Beitrag sollte dies (SigInt) unter Linux bewirken.

Muss lediglich getestet werden.

[mschnell]

normaler gdb via SSH: Ich glaube aber, besser ist es den Authentifizierungscode in sshgdbmiedebug.pas zu aktivieren und zu testen.

Das ist momentan eigentlich meine Lieblings-Variante.

Du kannst Dich am QNAP mit

"ssh admin@ip_adresse" einloggen. Es folgt dann eine Passwort-Abfrage, die wird in sshgdbmiedebug.pas mit den auskommentierten Zeilen beantwortet.

Voraussetzung ist, das die SSL-Keys schon ausgetauscht wurden, die Rückfrage kann man auch noch abfangen, man kann aber auch zuerst einen manuellen login machen. Beim QNAP ist das vermutlich nach jedem Neustart nötig.

in sshgdbmiedebug.pas muss vermutlich noch ausprogrammiert werden, dass man das Passwort irgendwo speichern kann.

-Michael

[MiR]

Für einen schnellen Test gibt es einen einfachen Hack:

Erstmal startest Du Lazarus, aktivierst den ssh debugger und änderst die EncodeCurrentDirPath property. Jetzt LAzarus beenden.

Nun editierst Du die Lazarus Konfigurationsdatei environmentoptions.xml, unter Unix $HOME/.lazarus/environmentoptions.xml. Dort suchst Du nach SSHGDBMIDebugger und findest:

<Debugger Class="TSSHGDBMIDebugger" EventLogLineLimit="100">
<WatchesDlg ColumnNameWidth="-1" ColumnValueWidth="-1"/>
<ClassTSSHGDBMIDebugger>
<Properties EncodeCurrentDirPath="gdfeEscSpace" EncodeExeFileName="gdfeEscSpace" Password="Grinsekatz"/>
</ClassTSSHGDBMIDebugger>
</Debugger>
Unter Properties kannst Du jetzt Password="Grinsekatz" eintragen.

Jetzt musst Du die Property nur noch in der SSHGDBMIDebugger Klasse definieren (Einfach nach Remote_GDB_Exe im Sourcecode der Klasse suchen und überall wo es vorkommt noch einen neuen Eintrag mit Password machen)
und schon hast Du einen Weg auf Dein Passwort zuzugreifen.

Leider habe ich noch nicht ganz verstanden wie man Properties die im Property Editor verändert wurden zurückschreibt, ich bin entweder zu blöd oder es ist relativ kompliziert, aber das ist auf meiner Todo List.

[martin_frb]

Leider habe ich noch nicht ganz verstanden wie man Properties die im Property Editor verändert wurden zurückschreibt, ich bin entweder zu blöd oder es ist relativ kompliziert, aber das ist auf meiner Todo List.

published properties kann man editieren.

Damit der Rest klappt, muss das Feld in ASSIGN kopiert werden.

[MiR]

Hmmmm.... dachte ich eigentlich das ich es so gemacht hätte:

Code: Alles auswählen

 TGDBMIOpenOCDDebuggerProperties = class(TGDBMIDebuggerProperties)
  private
    FOpenOCDPort: String;
    FOpenOCDHost: String;
    FOpenOCDInitScript: TMemo;
    FOpenOCDBinary: String;
    FOpenOCDParams : String;
  public
    constructor Create; override;
    procedure Assign(Source: TPersistent); override;
  published
    property OpenOCDPort: String read FOpenOCDPort write FOpenOCDPort;
    property OpenOCDHost: String read FOpenOCDHost write FOpenOCDHost;
    property OpenOCDInitScript: String read FOpenOCDInitScript write FOpenOCDInitScript;
    property OpenOCDBinary : String read FOpenOCDBinary write FOpenOCDBinary;
    property OpenOCDParams : String read FOpenOCDParams write FOpenOCDParams;
  end;

und

Code: Alles auswählen

procedure TGDBMIOpenOCDDebuggerProperties.Assign(Source: TPersistent);
begin
  inherited Assign(Source);
  FOpenOCDHost := TGDBMIOpenOCDDebuggerProperties(Source).FOpenOCDHost;
  FOpenOCDPort := TGDBMIOpenOCDDebuggerProperties(Source).FOpenOCDPort;
  FOpenOCDInitScript := TGDBMIOpenOCDDebuggerProperties(Source).FOpenOCDInitScript;
  FOpenOCDBinary := TGDBMIOpenOCDDebuggerProperties(Source).FOpenOCDBinary;
  FOpenOCDParams := TGDBMIOpenOCDDebuggerProperties(Source).FOpenOCDParams;

end;

[martin_frb]

Das sieht korrekt aus.

Siehe mein Patch, Da hab ich ein Feld zugefuegt, und mehr als published/assign hab ich da auch nicht gemacht.

Die property Instanz erzeugst du in
class function CreateProperties: TDebuggerProperties; override;
?

[MiR]

Ja, genau.

class function CreateProperties: TDebuggerProperties; override; // Creates debuggerproperties

Eventuell ist das ja auch nur ein MacOS spezifisches Problem, ich werde am Wochenede mal die Windows Version übersetzen und schauen ob es da klappt.

[martin_frb]

Eventuell ist das ja auch nur ein MacOS spezifisches Problem

Ja sag das doch gleich....
http://bugs.freepascal.org/view.php?id=21653

[MiR]

Und ich dachte Ihr könnt hier im Forum Gedanken lesen

Der Workarround aus dem Bug mit dem Feldwechsel funktioniert, ein Problem weniger!
Schon wieder vielen Dank an Dich, Martin, diesmal auf Deutsch.

[mschnell]

Martin und Michael:

Gibt es beim SSH-GDB schon etwas was ich mit meinem ARM-Linux-Target, testen kann, oder woran ich basteln kann ?

Bei diesem Device (QNAP-NAS: Headles ARM/Linux) muss ich bei ssh-login merkwürdiger Weise "admin@ip_adresse" eingeben und dann kommt die Frage nach dem Passwort.

Gruß,
-Michael

[MiR]

Michael,

eine Sache verstehe ich nicht, laut diesem Artikel:

http://wiki.qnap.com/wiki/How_To_Set_Up_Authorized_Keys

scheint es möglich zu sein einen Publickey auf dem NAS zu hinterlegen, kennst du den Artikel?

Wenn der publickey auf dem NAS liegt und der private Key auf Deinem Host an der richtigen Stelle ist dann wirst Du nicht mehr nach dem Passwort gefragt.

[mschnell]

Wenn ich Andy richtig verstanden habe, ist das ein modifizierter SSH. Deswegen wollte er an den SSH-Debugger nicht ran.

Ich schaue mir den Artikel an.
Da steht u.a:

Code: Alles auswählen

5. That's it! Now you should be able to SSH login to the TS-509 from TS-209 without password, the authorized_keys has been saved in the destination host (TS-509) under /etc/config/ssh/authorized_keys

Aber trotzdem, sollten wir - wo wir gerade dabei sind - das Lazarus SSH debug Interface so erweitern, dass eine passwort-Abfrage richtig beantwortet werden kann. Das würde dann nicht nur für QNAP eine Verbesserung sein.

-Michael