Bu rsync + ssh cron işi neden bana 'İzin reddedildi (publickey)' hataları veriyor?

Günlük olarak uzak bir sunucuyla eşitlemek istediğim yerel bir sürücüye sık sık yedekleme yapıyorum.

Hedef sunucu yalnızca SSH anahtarı (parola yok) erişimi için yapılandırılmıştır. Bu sunucu için birincil SSH anahtarım parola korumalı olduğundan, katılımsız yedeklemeler için kullanmak üzere ikinci bir SSH anahtarı (parola korumalı değil) + kullanıcı oluşturdum - bu şekilde cron çalıştığında parolamı girmek için mevcut olmam gerekmiyor .

Cron ve rsync kullanıyorum ve tüm komutlar ayrı ayrı çalışıyor, ancak birleştirildiğinde başarısız oluyor.

Sorun giderme çalışırken elde ettiğim en uzak nokta

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/"

bu da hatayı döndürür

Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.0]

Bu sorunu nasıl giderebileceğinizle ilgili ipuçları var mı?

İşte şimdiye kadar denedim ve fikirlerim bitti:

1. Cron kesinlikle çalışıyor ps aux | grep cron

2. / Var / log / syslog dosyasında olağandışı bir şey yok Sep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

3. Yedekleme kullanıcısı olarak terminaldeki SSH uzak sunucuya ssh backups-user@XX.XX.XX.XX

4. Komutun Terminal'de çalıştırılması mükemmel çalışıyor rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

5. Yedekler kullanıcı anahtarının yolunu el ile belirtmenin bir etkisi yoktur rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

6. Çalışmayan komutun basit bir test komutuyla değiştirilmesi işe yarıyor echo "Hello world" > ~/Desktop/test.txt

7. Bilgisayarda bağırmanın / küfür etmenin hiçbir etkisi olmadı (ancak geçici olarak daha iyi hissetmemi sağladı).

Düzenleme 1:

İşte benim crontab dosyam ve çağırdığı komut dosyası.

...
# m h  dom mon dow   command
MAILTO=""
* * * * * sh /home/tom/Documents/Scripts/offsite-backup

ve

#!/bin/bash

rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/

Düzenleme 2:

Sadece netleştirmek /var/log/auth.logiçin, hedef sunucuda satır içerir Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootBu kafa karıştırıcı çünkü artık her dakika yerel olarak cron çalıştırmıyorum, ancak sunucu günlüklerinde her dakika yeni bir giriş görünüyor. Sunucudaki tüm kullanıcılar için (root dahil) Crontab dosyaları boştur ve hiçbir şey yapmazlar.

Ayrıca, 'yalnızca yedeklemeler' kullanıcısı yalnızca sunucuda ve sınırlı haklara sahip olarak oluşturuldu ve özel bir SSH anahtarı masaüstü bilgisayarıma kopyalandı. Komutları manuel olarak çalıştırdığınızda her şeyin çalıştığı için bunun yol olduğunu varsayıyorum.

Yukarıda yayınlanan crontab dosyası benim için, masaüstü bilgisayarımda 'tom' kullanıcısı. Amacım sunucuya kullanıcı 'sadece yedek' olarak oturum açması gereken komut dosyasını çağırmaktır. Sadece (içindeki komut yerine) yedek komut dosyasını çalıştırmayı denedim ve başarıyla bağlandı ve çalıştı. Masaüstümde, çalışmayan cron işini yaratan 'tom' kullanıcısı olarak çalıştırdım. İşte bu başarılı girişe karşılık gelen sunucu günlüğünden çıktı

Sep 11 08:35:31 <hostname> sshd[25071]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Sep 11 08:35:32 <hostname> sshd[25071]: Accepted publickey for backups-only from <desktop IP> port 54242 ssh2: RSA e2:e6:07:27:c1:continues...
Sep 11 08:35:32 <hostname> sshd[25071]: pam_unix(sshd:session): session opened for user backups-only by (uid=0)
Sep 11 08:35:32 <hostname> systemd-logind[638]: New session 12 of user backups-only.
Sep 11 08:36:00 <hostname> sshd[25133]: Received disconnect from <desktop IP>: 11: disconnected by user
Sep 11 08:36:00 <hostname> sshd[25071]: pam_unix(sshd:session): session closed for user backups-only

Her şey komut satırından iyi çalıştığı için, hata Permission denied (publickey)SSH bölümünün rsyncbelirtilen kullanıcı adından farklı bir kimlik dosyası kullandığı anlamına gelir .

Gönderen Jan'ın comment orijinal soru üzerine, biz kimlik dosyasını belirtebilirsiniz rsynckullanarak komuta -e 'ssh -i /path/to/identity.file' ....

Cron'da yeni bir ortamla başlamak için aşağıdaki komutu kullanmak ve dosyanın tam yolunu belirtmek sorunu çözüyor:

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/"

_{Hala bu bulguyla gerçekten ilgileniyorum. Muhtemelen cron, minimum ortam değişkenleri ile başlaması ve ssh-agent ile ilgilidir. Aynı senaryoyu birkaç gün içinde test edip geri raporlayacağım.}

Beni meşgul eden bu sorunu çözdüm ..

SSH kimliğini öngörmesine rağmen, RSYNC'ye SSH üzerinden bağlanılamıyor ... Hiçbir şey yapılmadı ... Rsync "izin verilmedi" diyor ve ssh bana "read_passphrase: açılamıyor / dev / tty: Cihaz veya adres yok bu tip"

Ama crontab'ın kendi köküyle aynı olmayan kendi ortamına sahip olduğunu açıklayan bir yazı okudum. Bunu zaten biliyordum ama SSH-AGENT'i kullanırken SSH üzerindeki etkisini anlamadım

Ancak SSH anahtar alışverişlerim PassPhrase ile yapılıyor ... bu yüzden ortam farklıysa ve SSH üzerinden RSYNC girilemeyen bir parola beklerse => SSH hata ayıklama bilgisi de hatayı gösterir:

"debug1: read_passphrase: açılamıyor / dev / tty: Böyle bir cihaz veya adres yok" => Evet evet hayır TTY = şifre yok = izin verilmiyor

Makinemde SSH aracısını çalıştırmak için "Anahtarlık" kullanıyorum, bu yüzden her uzak bağlantıyı denediğimde parolayı tekrar girmek zorunda değilim. Anahtarlık aşağıdaki bilgileri içeren bir dosya oluşturur

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent.18891; dışa aktarma SSH_AUTH_SOCK; SSH_AGENT_PID = 18893; dışa aktarma SSH_AGENT_PID;

==> SSH-AGENT komutu aynı bilgiyi döndürür.

Bu nedenle, daha önce yapıldığı ve ezberlendiği için, geçerli oturumun gelecekteki kimlik doğrularına izin veren, geçerli oturumla ilgili bu bilgiler, parolayı girmeye gerek kalmadan ...

==> Çözüm var ... crontab tarafından başlatılan komut dosyasında yeterlidir ve bu bilgileri içeren dosyayı "kaynaklamak" veya crontab komut satırında bunu yapmak ...

örnek: 14 09 * * *. /home/foo/.keychain/foo.serveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh foo@my-server.fr:. >> / var / log / check_connexion.log 2> & 1 veya SSH kullanarak bağlantı başlatan komut dosyasındaki "source /home/foo/keychain/foo.server.org-sh" komutunu kullanın.

=> Bu kaynakla endişelenmenize gerek yok. SSH_AUTH_SOCK ve SSH_AGENT_PID bilgileri Crontab ortamına yüklenir ve bu nedenle bilinir, SSH üzerinden RSYNC sorunsuz çalışır.

Beni meşgul etti ama şimdi çalışıyor :)

SSH Ajan Yönlendirme kullanan kişiler için uyarı:

Uzak bir ana bilgisayarda bir komut dosyasında hata ayıklarken bu davranışı görürseniz, bunun nedeni, -e "ssh -i /path/to/key"bayrakla bile , ssh'ın sunucudaki yerine yerel (iletilen) anahtarınızı kullanmasıdır.

Somut örnek: dev sunucusunda ssh üzerinde rsync kullanarak "veri sunucusundan" veri çeken bir komut dosyası var. Dev sunucusunda oturum açıp çalıştırdığımda her şey yolunda, ama cron'dan çalışırken izin verilmedi. SSH sürecine (bayrak -vv) biraz ayrıntı ekleyerek aşağıdakileri fark ettim:

debug2: key: /home/nighty/.ssh/id_rsa (0x562d8b974820),
debug2: key: /home/juanr/.ssh/id_rsa (0x562d8b962930), explicit
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/nighty/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 1a:19:08:9f:80:16:b1:db:55:42:9a:52:b2:49:9b:0a
debug1: Authentication succeeded (publickey).

Burada bana ne ipucu saf şans eseri, ben yerel sunucu ("nighty") dev sunucusundan ("juanr") daha farklı bir kullanıcı adı var olmasıdır.

Ama yine de benim laptop iletilen anahtarı kullanır nasıl işaretleri "açık" olarak dev sunucuda anahtarı Bildirimi giriş yapmak için. Bir Doing ssh-copy-idbu nokta giderir hiçbir şey, sadece dev gelen bir yerine iletilen anahtarını yeniden yükler nedeniyle sunucusu. Ajan yönlendirme ile ssh-copy-id kullanırsanız, -i bayrağıyla yüklemek için hangi tuşa belirtmek gerekir: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.

Host dosyalarını temizlemenin eski hilesini zaten denediniz mi? Demek istediğim:

rm ~/.ssh/known_hosts

SSH onu yeniden inşa edecek ve bayat şeylerden kurtulacaksınız denemeye değer. Elbette belirli bir IP / Host'a ait parçaları da kaldırabilirsiniz.

Daha fazla soru: Cron işiniz UID'niz altında mı çalışıyor yoksa kullanıcı cronu veya kökü olarak mı çalışıyor?

Kullanım rrsyncaşağıdaki gibi özel bir ssh anahtarı ile komut buluşmanızı:

REMOTE sunucusu

mkdir ~/bin
gunzip /usr/share/doc/rsync/scripts/rrsync.gz -c > ~/bin/rrsync
chmod +x ~/bin/rrsync

YEREL bilgisayar

ssh-keygen -f ~/.ssh/id_remote_backup -C "Automated remote backup"      #NO passphrase
scp ~/.ssh/id_remote_backup.pub devel@10.10.10.83:/home/devel/.ssh

Uzak bilgisayar

cat id_remote_backup.pub >> authorized_keys

Yeni eklenen satıra aşağıdaki ekle

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

Böylece sonuç şöyle görünür

command="$HOME/bin/rrsync -ro ~/backups/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...vp Automated remote backup

YEREL

Senin koyun crontabile aşağıdaki komut xizni:

#!/bin/sh
echo ""
echo ""
echo "CRON:" `date`
set -xv
rsync -e "ssh -i $HOME/.ssh/id_remote_backup" -avzP devel@10.10.10.83:/ /home/user/servidor 

Kaynak: http://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/

Denemek ve hata ayıklama ssh bölümüne eklemek için "ssh -v" bu şekilde bazı yararlı bilgiler ile ayrıntılı mod alabilirsiniz.

Düzenleme: Man sayfasından:

-v      Verbose mode.  Causes ssh to print debugging messages about its progress.  This is helpful in debugging connection,
             authentication, and configuration problems.  Multiple -v options increase the verbosity.  The maximum is 3.

Sanırım sshd_config dosyasını düzgün yapılandırmadınız. Bunu PermitRootLogin yesve PubkeyAuthentication yes uzaktan bakım için doğrulayın .