scp per cronjob!?

[sebhof]

Hi,

habe einen cronjob gebastelt, der per scp von einem Rechner im lokalen Netz täglich eine Datei (Sicherungskopie) ziehen soll. Habe meine Passphrase per ssh-add hinzugefügt. Wenn ich das Script von der Konsole aufrufe, klappt das auch einwandfrei, der cronjob an sich wird auch aufgerufen, allerdings bekomme ich den Fehler:

Code: Alles auswählen

Permission denied (publickey,keyboard-interactive).

Es handelt sich dabei auch um einen User-Job...

Kann mir jemand sagen, wo mein Denkfehler liegt?
Danke und Gruß
sebhof

[Autarkis]

Ich nehme an, du musst auf dem Host, an den du dich anmelden willst, im .ssh - Verzeichnis des Users als den du dich anmeldest, deinen Pubkey deponieren.

Danach verwendest du bei scp den Batch-Mode (Parameter -B) (man scp).

Ich habe dieselbe Problemstellung mit sftp gelöst (cron - upload) und musste das dann tun.

Die anerkannte "sichere" Art, sich automatisch anzumelden, da so keine Passwörter aus deinem Skript rausgelesen werden können.

Viel Glück!

[sebhof]

Hi,

so hatte ich mir das vorgestellt - aber irgendwo hängts...

Hatte das -B bislang nicht drin - hat aber auch nix geändert... Gleicher Fehler...

Wie gesagt - wenn ich das Script normal ausführe, läuft es wunderbar. Er meldet sich ohne Probleme an und kopiert mir die Datei... Sobald es aber über die crontab angeworfen wird, bekomme ich diesen Fehler...

Merkwürdige Dinge...
Naja - mal weitersuchen...
Danke
sebhof

[Autarkis]

Achso, das hatte ich wohl nicht genau genug gelesen.

Wenn das Skript von Konsole gestartet funktioniert, also automatisch durchläuft, und der Fehler nur beim cronjob auftaucht, kann's fast nur daran liegen, dass du in der crontab zum Bashskript und in dem Skript selbst absolute Pfade verwenden musst oder was ganz raffiniertes mit Umgebungsvariablen machen musst.

[sebhof]

Hi,

auch absolute Pfade hab ich verwendet - daran liegts schon mal nicht. Ich hab den scp über cron jetzt mal verbose laufen lassen:

Code: Alles auswählen

OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7g 11 Apr 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to server [192.168.0.14] port 22.
debug1: Connection established.
debug1: identity file /home/sh/.ssh/identity type -1
debug1: identity file /home/sh/.ssh/id_rsa type -1
debug1: identity file /home/sh/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1 Debian-8.sarge.4
debug1: match: OpenSSH_3.8.1p1 Debian-8.sarge.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'server' is known and matches the RSA host key.
debug1: Found key in /home/sh/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/sh/.ssh/identity
debug1: Trying private key: /home/sh/.ssh/id_rsa
debug1: Offering public key: /home/sh/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).

Ich hab danach mal gegoogelt - das "PEM_read_PrivateKey failed" soll wohl heißen, dass er den key ohne Passphrase nicht lesen kann..!? Das ist schon alles sehr merkwürdig, da der Key ja im authentication agent abgelegt ist... Das gleiche Script direkt ausgeführt bringt an der Stelle:

Code: Alles auswählen

debug1: Offering public key: /home/sh/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending command: scp -v -f backup.zip

Da gibts anscheinend wieder irgend einen fiesen Mechanismus... Nur welchen...?

Danke und Gruß
sebhof

[QT]

Ich nehme an, dass in der Session, die durch cron gestartet wird, keine Verbindung zu Deinem ssh-agent besteht und daher auch der Zugriff auf den Key nicht moeglich ist, da ihm die Passphrase fehlt.

Eine Idee zu einer sicheren Abhilfe habe ich da nun auch nicht. Ich wuerde eventuell auf das SAFT Protokoll zurueckgreifen statt SSH und per sendfile das Thema erledigen. Wenn Verschluesselung der Daten wichtig ist, dann halt vor dem Senden jeweils verschluesseln.

Gruesse,
QT

[herrchen]

Ich nehme an, dass in der Session, die durch cron gestartet wird, keine Verbindung zu Deinem ssh-agent besteht und daher auch der Zugriff auf den Key nicht moeglich ist, da ihm die Passphrase fehlt.

das ist richtig.
dafür gibt es (mindestens) zwei lösungen:
- das programm "keychain" installieren und dann in dem cronjob die von ihm angelegte datei sourcen.
- einen benutzer verwenden, der keine passphrase auf dem key hat.

die zweite möglichkeit hat den vorteil, auch einen reboot ohne eingriff zu überstehen.

herrchen

[sebhof]

Hi,

Problem gelöst - habe mich für keychain entschieden und nu läufts - wieder was gelernt...

Danke und Gruß
sebhof