Mengapa pekerjaan cs rsync + ssh cron ini memberi saya kesalahan 'Izin ditolak (publickey)'?


20

Saya sering membuat cadangan ke drive lokal yang ingin saya sinkronkan setiap hari ke server jarak jauh.

Server target dikonfigurasikan hanya untuk akses kunci SSH (tanpa kata sandi). Karena kunci SSH utama saya untuk server itu dilindungi frasa sandi, saya telah membuat kunci SSH kedua (tidak dilindungi frasa sandi) + pengguna yang akan digunakan untuk cadangan tanpa pengawasan - dengan cara ini saya tidak harus hadir untuk memasukkan frasa sandi saya ketika cron berjalan .

Saya menggunakan cron dan rsync, dan semua perintah bekerja secara individual, tetapi gagal saat digabungkan.

Terjauh yang saya miliki saat pemecahan masalah sedang berjalan

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

yang mengembalikan kesalahan

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]

Adakah tips tentang cara memecahkan masalah ini lebih lanjut?


Inilah yang saya coba sejauh ini dan saya kehabisan ide:

  1. Cron jelas berjalan ps aux | grep cron
  2. Tidak ada yang aneh di / var / log / syslog Sep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

  3. SSH di Terminal ke server jauh saat pengguna cadangan bekerja ssh backups-user@XX.XX.XX.XX

  4. Menjalankan perintah di Terminal berfungsi dengan baik rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/
  5. Menentukan jalur secara manual ke cadangan-pengguna tidak berpengaruh 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. Mengganti perintah yang tidak berfungsi dengan perintah tes sederhana berfungsi echo "Hello world" > ~/Desktop/test.txt

  7. Berteriak / bersumpah pada komputer tidak berpengaruh (tapi membuatku merasa lebih baik sementara).


Edit 1:

Ini file crontab saya dan script yang dipanggilnya.

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

dan

#!/bin/bash

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

Edit 2:

Hanya untuk memperjelas, /var/log/auth.logpada server target berisi baris Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootIni membingungkan karena saya tidak lagi menjalankan cron setiap menit secara lokal, tetapi entri baru masih muncul setiap menit di log server. File crontab untuk semua pengguna (termasuk root) di server kosong & tidak melakukan apa-apa.

Juga, 'cadangan-saja' pengguna dibuat hanya di server dan dengan hak terbatas, dengan kunci SSH khusus yang disalin ke mesin desktop saya. Saya berasumsi ini adalah cara untuk pergi karena semuanya bekerja ketika menjalankan perintah secara manual.

File crontab yang diposting di atas adalah untuk saya, pengguna 'tom' di mesin desktop saya. Maksud saya adalah meminta skrip panggilan yang harus masuk ke server sebagai 'cadangan saja' pengguna. Saya baru saja mencoba menjalankan skrip cadangan (alih-alih perintah di dalamnya) dan berhasil tersambung & berfungsi. Saya menjalankannya di desktop saya sebagai pengguna 'tom', pengguna yang sama yang menciptakan pekerjaan cron yang tidak akan berfungsi. Inilah output dari log server yang sesuai dengan login yang berhasil

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

Jika 3. berfungsi menggunakan keyfile dan 6. juga berfungsi, maka ... err ... apa yang dikatakan sshd logfile pada sisi penerima?
Jan

@Jan saya dapatkanSep 7 14:45:01 <hostname> CRON[18716]: pam_unix(cron:session): session closed for user root
Tom Brossman

Entah itu jalur log yang salah atau pengguna yang mencoba terhubung melalui ssh adalah root ... Atau apakah itu dari mesin yang memulai pencadangan?
Jan

1
Tom, 2 pertanyaan hanya untuk memastikan Dalam komentar pertama Anda logline memiliki CRON [...], tetapi seharusnya terlihat seperti Sep 7 16:06:02 <hostname> sshd[6747].... Apakah Anda 100% positif bahwa logline ini dari server dan itu adalah baris yang benar? Crontab yang Anda poskan adalah crontab khusus cadangan ? Juga, cobalah untuk menambahkan file identitas secara manual:rsync .... -e 'ssh -i /home/user/.ssh/identity' ...
Jan

1
Juga, baris yang auth.logAnda posting di bawah Edit 2 adalah untuk cron berjalan di server, dan seharusnya tidak ada hubungannya dengan upaya login Anda. Bisakah Anda mencoba tail -f /var/log/auth.logdi server saat Anda mencoba menjalankan skrip melalui cron? Juga, saya tidak yakin apakah ini akan berhasil, tetapi dapatkah Anda mencoba envperintah pertama dengan Anda rsync .... -e 'ssh -vvv -i /home/user/.ssh/identity ...untuk melihat apakah ia mengeluarkan lebih banyak kesalahan?
Alaa Ali

Jawaban:


15

Karena semuanya bekerja dengan baik dari baris perintah, kesalahan Permission denied (publickey)berarti bagian SSH rsyncmenggunakan file identitas yang berbeda dari nama pengguna yang ditentukan.

Dari komentar Jan pada pertanyaan awal, kita dapat menentukan file identitas dalam rsyncperintah menggunakan -e 'ssh -i /path/to/identity.file' ....

Menggunakan perintah di bawah ini untuk memulai dengan lingkungan baru di cron dan menentukan path lengkap ke file tampaknya memecahkan masalah:

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/"

Saya masih sangat tertarik dengan temuan ini. Mungkin ada hubungannya dengan cron, fakta bahwa ia dimulai dengan variabel lingkungan minimal, dan ssh-agent. Saya akan menyiapkan skenario yang sama dalam beberapa hari untuk mengujinya dan melaporkan kembali.


1
Maksud Anda berlarienv -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /path/to/identity.file' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/"
qazwsx

@ Problemania whops, diperbaiki.
Alaa Ali

Saya melihat bahwa Anda memiliki jawaban, tetapi saya ingin tahu apakah Anda menjalankan 'sudo crontab -e' yang merupakan root cron. Apa yang terjadi jika Anda 'crontab -e' saat masuk sebagai pengguna "cadangan".
wlraider70

Saya pikir Anda memaksudkan ini untuk orang yang mengajukan pertanyaan. Tapi dia menggunakan crontab nama penggunanya, bukan root, dan saya pikir dia tidak ingin menggunakan crontab pengguna cadangan.
Alaa Ali

ketika saya menjalankan skrip yang sama dengan pengguna saya, dibutuhkan kunci ssh via X11, jadi saya memerlukan salinan lokal jika kunci, dan pastikan file ini memiliki pemilik dan hak yang benar, dikombinasikan dengan di atas bekerja dengan baik untuk saya.
Sverre

1

Saya baru saja menyelesaikan masalah ini yang membuat saya sibuk ..

Tidak dapat terhubung di RSYNC melalui SSH, meskipun telah menetapkan identitas untuk SSH ... Tidak ada yang dilakukan ... Rsync mengatakan "izin ditolak" dan ssh memberi tahu saya "read_passphrase: tidak dapat membuka / dev / tty: Tidak ada perangkat atau alamat tipe ini"

Tetapi saya membaca posting yang menjelaskan bahwa crontab memiliki lingkungannya sendiri yang tidak sama dengan root. Saya sudah tahu itu tetapi saya tidak mengerti dampaknya pada SSH saat menggunakan AGEN SSH

Tetapi pertukaran kunci SSH saya dilakukan dengan PassPhrase ... jadi jika lingkungannya berbeda dan RSYNC saya atas SSH mengharapkan frasa sandi yang tidak dapat dimasukkan => Info debug SSH juga menunjukkan kesalahan:

"debug1: read_passphrase: tidak bisa membuka / dev / tty: Tidak ada perangkat atau alamat seperti itu" => Yah ya tidak TTY = tidak ada frasa sandi = tidak diizinkan

Di mesin saya, saya menggunakan "Keychain" untuk memiliki agen SSH diluncurkan jadi saya tidak perlu memasukkan kembali kata sandi setiap kali saya mencoba koneksi jarak jauh. Keychain menghasilkan file yang berisi informasi berikut

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent.18891; ekspor SSH_AUTH_SOCK; SSH_AGENT_PID = 18893; ekspor SSH_AGENT_PID;

==> Perintah SSH-AGENT mengembalikan info yang sama.

Jadi, pada akhirnya, informasi ini terkait dengan sesi saat ini yang memungkinkan otentikasi masa depan dari sesi saat ini, tanpa perlu memasukkan frasa sandi karena sudah dilakukan sebelumnya dan dihafal ...

==> Solusinya ada ... cukup di skrip yang diluncurkan oleh crontab, dan untuk "sumber" file yang berisi informasi ini atau melakukannya di baris perintah ds crontab ...

contoh: 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 atau gunakan perintah "source /home/foo/keychain/foo.server.org-sh" dalam skrip yang memulai koneksi menggunakan SSH.

=> Dengan sumber ini, tidak ada lagi kekhawatiran. Informasi SSH_AUTH_SOCK dan SSH_AGENT_PID dimuat di lingkungan Crontab dan oleh karena itu diketahui, RSYNC melalui SSH berfungsi tanpa masalah.

Itu membuat saya sibuk tetapi sekarang, ia bekerja :)


1

Peringatan bagi mereka yang menggunakan SSH Agent Forwarding:

Jika Anda melihat perilaku ini ketika men-debug skrip pada host jarak jauh, itu karena bahkan dengan -e "ssh -i /path/to/key"flag, ssh akan menggunakan kunci lokal Anda (diteruskan) daripada yang ada di server.

Contoh konkret: Saya memiliki skrip pada server dev yang menarik data dari "server data" menggunakan rsync over ssh. Ketika saya masuk ke server dev dan menjalankannya, semuanya baik-baik saja, tetapi ketika menjalankan dari cron, saya mendapatkan izin yang ditolak. Menambahkan beberapa verbositas ke proses SSH (flag -vv) saya perhatikan hal berikut:

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).

Apa petunjuk saya di sini adalah bahwa kebetulan, saya kebetulan memiliki nama pengguna yang berbeda pada host lokal ("nighty") daripada pada server dev ("juanr").

Perhatikan bagaimana ini menandai kunci pada dev server sebagai "eksplisit", tetapi masih menggunakan kunci diteruskan dari laptop saya untuk login. Melakukan ssh-copy-idpada saat ini tidak menyelesaikan apa-apa, karena itu hanya menginstal ulang kunci yang diteruskan daripada yang dari dev server. Jika Anda menggunakan ssh-copy-id dengan agen forwarding, Anda perlu menentukan kunci yang untuk menginstal dengan bendera -i: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host.


0

Sudahkah Anda mencoba trik lama membersihkan file host? Maksudku:

rm ~/.ssh/known_hosts

Layak dicoba karena ssh akan membangunnya kembali dan Anda akan menyingkirkan barang-barang basi. Anda tentu saja dapat juga menghapus bagian-bagian milik IP / Host yang diberikan.

Pertanyaan lain: Apakah pekerjaan cron Anda berjalan di bawah UID Anda atau apakah berjalan sebagai pengguna cron atau root?


1
Perintah masing-masing bekerja secara individual, jadi saya tidak melihat bagaimana menghapus ~/.ssh/known_hostsakan mengubah apa pun? Dan cron berjalan sebagai 'tom' pengguna saya di desktop, dengan tujuan masuk ke server sebagai 'cadangan-saja' pengguna dengan kunci SSH (tanpa kata sandi) yang sesuai, yang ada di tom pengguna ~/.ssh.
Tom Brossman

3
@ runlevel0 Baik -rmaupun -fbendera diperlukan untuk menghapus known_hosts--Itu adalah file biasa (bukan sebuah direktori), dan tidak dibaca. rm .ssh/known-hostsakan jauh lebih aman, mengingat bahwa kesalahan ketik satu karakter - tanpa sengaja menambahkan ruang antara .dan ssh/known_hostssetelah rm -rf(atau rm -r) biasanya akan menghapus seluruh isi folder rumah pengguna!
Eliah Kagan

Hai Eliah, poin yang sangat bagus !! Saya menggunakan flag -rf sebagai tindakan refleks, tetapi Anda benar sekali. Saya buruk.
runlevel0

0

Gunakan rrsyncskrip bersama dengan kunci ssh khusus sebagai berikut:

Server REMOTE

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

Komputer LOKAL

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

Komputer remot

cat id_remote_backup.pub >> authorized_keys

Ikuti baris yang baru ditambahkan berikut ini

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

Sehingga hasilnya terlihat seperti

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

LOKAL

Masukkan crontabskrip berikut dengan xizin:

#!/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 

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


0

Untuk mencoba dan men-debug tambahkan ke bagian ssh "ssh -v" dengan cara ini Anda bisa mendapatkan mode verbose dengan beberapa informasi bermanfaat.

Edit: Dari halaman manual:

-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.

-1

Saya pikir Anda belum mengkonfigurasi file sshd_config dengan benar. Pastikan itu PermitRootLogin yesdan PubkeyAuthentication yes untuk pemeliharaan jarak jauh.


1
Dia tidak mencoba masuk sebagai root, dan dia mungkin memiliki pengaturan otentikasi kunci publik dengan benar karena dia dapat ssh dan bahkan menjalankan perintah cadangan dari terminal dengan sukses.
Alaa Ali

1
Terima kasih atas sarannya tetapi saya jelas tidak PermitRootLoginmengaktifkan dan tidak punya rencana untuk mengubahnya. Praktik terbaik adalah menonaktifkannya, dan ssh hanya sebagai pengguna biasa (tambahkan mereka ke 'sudoers' Anda jika perlu) dan jangan pernah sebagai root.
Tom Brossman
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.