Bug#337954: Remote rdiff: Can't connect, test succeeds
micah a écrit (07 Nov 2005 23:13:33 +0100) :
The only way a cronjob could use your ssh-agent is if it was
launched from a shell that was created after the agent was
launched. Cron stuff generally runs as root however, so you would
have to have a ssh-agent for root and restart crond after you've ran
ssh-agent to get it to work, but this is really weird.
Using keychain, one can share ssh-agent stored identities across
sessions : keychain stores (typically in ~/.keychain/${HOST}-sh)
working values for SSH_AUTH_SOCK and SSH_AGENT_PID environment
variables, which allows any shell program sourcing this file to use
the existing ssh-agent.
Ahmad, if we add support for keychain to backupninja, would you use
it?
Ninja-friends, what do you think of adding keychain support to
backupninja? I could do this one of these days, since I'm already
using keychain actually for other tasks.
Ciao,
--
intrigeri [EMAIL PROTECTED]
| gnupg key @ http://intrigeri.boum.org/intrigeri.asc
pgpRZo6xuVHNG.pgp
Description: PGP signature
Bug#337954: Remote rdiff: Can't connect, test succeeds
Package: backupninja Version: 0.9-1 backupninja -t -n succeeds, but scheduled backups don's. They produce the message: *failed* -- /etc/backup.d/90.rdiff == fatal errors from /etc/backup.d/90.rdiff == Fatal: Can't connect to dest-host as dest-user. I noticed that the helper script uses dsa while I'm using rsa. Anyway, I can ssh without a password and backupninja -n completes the backup successfully. Note that I have a passphrase for my keys but I'm using an agent (ssh-add) so that I can ssh without any prompts or passwords. I don't want to have an empty passphrase.
Bug#337954: Remote rdiff: Can't connect, test succeeds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ahmad Khayyat wrote: Package: backupninja Version: 0.9-1 backupninja -t -n succeeds, but scheduled backups don's. They produce the message: *failed* -- /etc/backup.d/90.rdiff == fatal errors from /etc/backup.d/90.rdiff == Fatal: Can't connect to dest-host as dest-user. Does the error really say dest-host as dest-user, or was this a substitution that you did? I noticed that the helper script uses dsa while I'm using rsa. Anyway, I can ssh without a password and backupninja -n completes the backup successfully. Note that I have a passphrase for my keys but I'm using an agent (ssh-add) so that I can ssh without any prompts or passwords. I don't want to have an empty passphrase. If you have a passphrase on your key, then scheduled backups are going to somehow need to get that passphrase from you during the backups... micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDb4Wz9n4qXRzy1ioRAvy6AJ9asqO5WXJdSYRx0n1sI8pM2ct+RwCgnZ4x adTxTs97pnZPz/2t/9XtrJg= =4gzg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337954: Remote rdiff: Can't connect, test succeeds
1. That was my substituation.. consider those as variables. 2. Is there any means by which I can provide the passphrase to the scheduled backups? It seems that thay do not run in the current logged-in session, otherwise they could have used the session's ssh agent. micah wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ahmad Khayyat wrote: Package: backupninja Version: 0.9-1 backupninja -t -n succeeds, but scheduled backups don's. They produce the message: *failed* -- /etc/backup.d/90.rdiff == fatal errors from /etc/backup.d/90.rdiff == Fatal: Can't connect to dest-host as dest-user. Does the error really say dest-host as dest-user, or was this a substitution that you did? I noticed that the helper script uses dsa while I'm using rsa. Anyway, I can ssh without a password and backupninja -n completes the backup successfully. Note that I have a passphrase for my keys but I'm using an agent (ssh-add) so that I can ssh without any prompts or passwords. I don't want to have an empty passphrase. If you have a passphrase on your key, then scheduled backups are going to somehow need to get that passphrase from you during the backups... micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDb4Wz9n4qXRzy1ioRAvy6AJ9asqO5WXJdSYRx0n1sI8pM2ct+RwCgnZ4x adTxTs97pnZPz/2t/9XtrJg= =4gzg -END PGP SIGNATURE-
Bug#337954: Remote rdiff: Can't connect, test succeeds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ahmad Khayyat wrote: 1. That was my substituation.. consider those as variables. 2. Is there any means by which I can provide the passphrase to the scheduled backups? It seems that thay do not run in the current logged-in session, otherwise they could have used the session's ssh agent. I've only done it via ssh-keys and passwordless logins to unpriviledged remote users. The only way a cronjob could use your ssh-agent is if it was launched from a shell that was created after the agent was launched. Cron stuff generally runs as root however, so you would have to have a ssh-agent for root and restart crond after you've ran ssh-agent to get it to work, but this is really weird. Really, this is the point of public keys... create an unpriviledged user on the backup machine that can only execute the rdiff-backup commands via ssh authorized_keys and it should be fine. micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDb9GN9n4qXRzy1ioRAiZxAJwN8/cHzaM9ik0tD4O6BvX/WWzIhQCgkZ8D FOrGkQJhKCFnk4sSVV/cFHs= =05GX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
