fork von ssh
-
Hallo,
ich versuche einen Tunnel mit ssh mit Private/Public-Key und weiteren Parametern mit fork und execlp zu starten.
Der direkte Aufruf des Kommandos in der Konsole klappt und die Verbindung wird ohne Passwortabfrage ausgeführt.
Mache ich das ganze jedoch über mein Programm kommt immer die Passwortabfrage.
Sehe ich mir den Aufruf des Child-Prozesses über
ps -aX | less
an, scheint die Befehlszeile zu stimmen.
std::string para[15]; para[0] = "ssh"; para[1] = "ssh"; para[2] = "-oUserKnownHostsFile=/dev/null"; para[3] = "-oStrictHostKeyChecking=no"; para[4] = "-l user"; para[5] = "-p22"; para[6] = "-fNC"; para[7] = "-R5000:localhost:81"; para[8] = "192.168.100.200"; pid_t pid; switch (pid = fork ()) { case -1: perror("fork()"); return EXIT_FAILURE; case 0: execlp (para[0].c_str(), para[1].c_str(), para[2].c_str(), para[3].c_str(), para[4].c_str(), para[5].c_str(), para[6].c_str(), para[7].c_str(), para[8].c_str(), NULL); printf("never"); break; default: if (waitpid (pid, NULL, 0) != pid) { perror ("waitpid()"); return EXIT_FAILURE; } } return EXIT_SUCCESS;
Hab auch schon versucht, die Datei "id_rsa" ins gleiche Verzeichnis zu kopieren und den Parameter "-i id_rsa" testweise zu benutzen, jedoch komm ich nicht weiter.
-
Mach noch das -v Parameter an, damit du sehen kannst, woran es scheitert. Der
execlp
Aufruf sieht nämlich OK aus.Eventuell wäre es besser ansatt zu forke und einen ssh client aufzurufen, gleich libssh zu verwenden.
-
Hallo.
Hab das mit dem -v Parameter getestet.
Direkter Aufruf:
debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 192.168.100.200 [192.168.100.200] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/user/.ssh/id_rsa-cert type -1 debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: identity file /home/user/.ssh/id_dsa-cert type -1 debug1: identity file /home/user/.ssh/id_ecdsa type -1 debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-8 debug1: match: OpenSSH_6.6.1p1 Ubuntu-8 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 00:c8:72:00:ea:fe:bf:96:b9:f1:de:ff:e5:2c:f0:44 Warning: Permanently added '192.168.100.200' (ECDSA) to the list of known hosts. debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/user/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: read PEM private key done: type RSA debug1: Enabling compression at level 6. debug1: Authentication succeeded (publickey). Authenticated to 192.168.0.101 ([192.168.0.101]:22). debug1: Remote connections from LOCALHOST:5000 forwarded to local address localhost:81 debug1: Requesting no-more-sessions@openssh.com debug1: forking to background debug1: Entering interactive session. debug1: remote forward failure for: listen 5000, connect localhost:81 debug1: remote port forward success for: listen 5000, connect localhost:81 debug1: All remote forwarding requests processed
Mit dem Fork:
debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 192.168.100.200 [192.168.100.200] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/user/.ssh/id_rsa-cert type -1 debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: identity file /home/user/.ssh/id_dsa-cert type -1 debug1: identity file /home/user/.ssh/id_ecdsa type -1 debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-8 debug1: match: OpenSSH_6.6.1p1 Ubuntu-8 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 00:c8:72:00:ea:fe:bf:96:b9:f1:de:ff:e5:2c:f0:44 Warning: Permanently added '192.168.100.200' (ECDSA) to the list of known hosts. debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/user/.ssh/id_rsa debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/user/.ssh/id_dsa debug1: Trying private key: /home/user/.ssh/id_ecdsa debug1: Next authentication method: password
Dann kommt die Passwortabfrage
-
Was spuckt ssh denn aus, wenn du die
BatchMode
-Option verwendest? Ist/home/user/.ssh/id_rsa
für deinen Prozess lesbar? Was steht denn im sshd-Log bzw. auth-Log des Servers?
-
Hallo nman,
dein Hinweis hat mich weiter gebracht.
In der auth.log kam die Meldung "invalid user[zwei Leerzeichen]user".
Der etwas größere Abstand zwischen user und user brachte mich dazu, das eventuell das Leerzeichen ein Problem ist.Hab jetzt die Zeile
para[4] = "-l user";
in
para[4] = "-luser";
geändert. Jetzt hat es mal auf meinem Testrechner geklappt.
Hab jetzt zwar auch noch die Option für den Batchmode drin, muss mal sehn, ob der nötig ist.
Vielen Dank
-
Ah ja, klar. Hätten wir vorher auch schon sehen können. "-l" und "user" sind ja zwei Parameter, nicht nur einer, dh. die musst du auch entsprechend and execlp weiterreichen.
Wobei ich persönlich einfach die "user@hostname"-Syntax verwenden würde, dann sparst du dir zwei Parameter.
Die Batchmode-Option brauchst du nicht unbedingt, aber du möchtest vmtl. lieber, dass der Aufruf fehlschlägt, wenn der Key nicht funktioniert und nicht dass es einen Fallback auf Passwort-Auth gibt. Dafür ist Batchmode praktisch.