Cronjob öffnet und schließt dann SOFORT den SSH-Tunnel

Cronjob öffnet und schließt dann SOFORT den SSH-Tunnel

Ich versuche, ein Skript zu schreiben, das einen SSH-Tunnel zu einem öffentlich zugänglichen Server öffnet. Ich habe alles richtig geschrieben und es funktioniert, aber die Verbindung scheint nicht zu meinem Server zu gelangen. In den Protokollen steht so etwas wie:

Jun 8 21:00:01 <hostname> CRON[xxxx]: session opened for user <user> by (uid=0)
Jun 8 21:00:01 <hostname> CRON[xxxx]: session closed for user <user>

Immer und immer wieder, mit 0-1 Sekunden dazwischen. Ich möchte, dass diese Verbindung offen bleibt.... Wie kann ich sie offen halten?

Mein Code für den Cron sieht folgendermaßen aus (Ja, ich weiß, dass er jede Minute läuft):

* * * * * /bin/bash /home/<user>/ssh

Mein Code für den Check-In lautet:

sshpass -p <password> ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null <user>@<url> -p <port> -R222<random_number>:localhost:22

Also, noch einmal: Wie kann ich diese Verbindung offen halten? Ich habe in einem anderen Skript einen Mechanismus, um sie zu einem geeigneten Zeitpunkt zu beenden, aber wenn ich den obigen Befehl nicht manuell über die Befehlszeile ausführe, beendet cron sie sofort.

Antwort1

Ihr Crontab-Skript enthält mehrere Fehler.

  1. Der Grund für die Verbindungsabbrüche ist die Tatsache, dass das Skript nicht nur eine Ausführungsberechtigung benötigt, sondern auch das gesetzte Suid-Bit (sudo chmod 4755 /pah/zu/Skript)WennSie führen das Shell-Skript als Root aus.

  2. crontab-Umgebungen unterscheiden sich stark von denen der Benutzer. Daher ist es immer erforderlich,vollständige Pfadezu Befehlen:

    /usr/bin/sshpass -p <password> /usr/bin/ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null <user>@<url> -p <port> -R222<random_number>:localhost:22
    
  3. Sie sollten die Flaggen hinzufügen-t -tzumsshBefehl (ja, zweimal), da dies den Fehler unterdrückt, dass kein TTY zugewiesen werden kann.

  4. Während ich mir der vorherigen Fehler sicher bin, gibt es einen, derkönnteProbleme verursachen, ich bin mir nicht sicher und habe keine Zeit, es auszuprobieren: Sie haben zwei-PFlags in Ihrem Befehl, und ich bin nicht sicher, ob sie von der Shell richtig interpretiert werden. An Ihrer Stelle würde ich diesshBefehl mit allen Optionen in einfachen oder doppelten Anführungszeichen, nur um es auszuprobieren.

Der vorherige Einwand und die Verwendung eines offenen Passworts könnten vermieden werden, wenn Sie kryptografische Schlüssel verwenden würden. In diesem Fall könnten Sie zu Ihrem.ssh/konfigurationDatei die folgenden Zeilen:

   Host ShortName
             HostName The.Full.HostName.com
             User yourname
             Port your-non-standard-port
             IdentityFile /path/to/crypto/keyù
             IdentitiesOnly yes

und dann würde der Einzeiler

  /usr/bin/ssh -t -t -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R222<random_number>:localhost:22 ServerName

verwandte Informationen