यह rsync + ssh cron जॉब मुझे 'अनुमति अस्वीकृत (publickey)' त्रुटियां क्यों दे रहा है?

Question

मैं एक स्थानीय ड्राइव पर लगातार बैकअप बनाता हूं जिसे मैं एक दूरस्थ सर्वर पर दैनिक सिंक करना चाहता हूं।

लक्ष्य सर्वर केवल SSH कुंजी (कोई पासवर्ड नहीं) एक्सेस के लिए कॉन्फ़िगर किया गया है। चूँकि उस सर्वर के लिए मेरी प्राथमिक SSH कुंजी पासफ़्रेज़-रक्षित है, इसलिए मैंने एक दूसरी SSH कुंजी (पासफ़्रेज़ रक्षित नहीं) + उपयोगकर्ता बनाया है जिसका उपयोग अनअटेंडेड बैकअप के लिए किया जाता है - इस तरह से मुझे अपना पासफ़्रेज़ दर्ज करने के लिए उपस्थित होने की आवश्यकता नहीं है जब क्रोन चलता है ।

मैं क्रोन और rsync का उपयोग कर रहा हूं, और सभी कमांड व्यक्तिगत रूप से काम करते हैं, लेकिन संयुक्त होने पर विफल होते हैं।

समस्या निवारण के दौरान मुझे जो फुर्सत मिली है, वह चल रही है

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [e-mail]:/backups/desktop/"

जो त्रुटि देता है

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]

कैसे आगे का निवारण करने के लिए कोई सुझाव?

---

यहाँ मैंने जो अभी तक कोशिश की है और मैं विचारों से बाहर हूँ:

1. क्रोन निश्चित रूप से चल रहा है ps aux | grep cron

2. कुछ भी असामान्य नहीं है / var / log / syslog Sep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

3. टर्मिनल में SSH रिमोट सर्वर के रूप में बैकअप उपयोगकर्ता काम करता है ssh [e-mail]

4. टर्मिनल में कमांड चलाना पूरी तरह से काम करता है rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [e-mail]:/backups/desktop/

5. मैन्युअल रूप से बैकअप-उपयोगकर्ता कुंजी के लिए पथ निर्दिष्ट करने का कोई प्रभाव नहीं है rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /home/tom/.ssh/backups-only' /Backups/auto-daily-backups/./ [e-mail]:/backups/desktop/

6. नॉन-फंक्शनिंग कमांड को साधारण टेस्ट कमांड के साथ बदलना echo "Hello world" > ~/Desktop/test.txt

7. कंप्यूटर पर चिल्लाना / शपथ ग्रहण का कोई प्रभाव नहीं पड़ा (लेकिन मुझे अस्थायी रूप से बेहतर महसूस हुआ)।

---

1 संपादित करें:

यहाँ मेरी crontab फ़ाइल और इसे कॉल की गई स्क्रिप्ट है।

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

तथा

#!/bin/bash

rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ [e-mail]:/backups/desktop/

---

2 संपादित करें:

बस स्पष्ट करने के लिए, /var/log/auth.logलक्ष्य सर्वर पर लाइन शामिल है Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootयह भ्रामक है क्योंकि मैं अब हर मिनट स्थानीय रूप से क्रोन नहीं चला रहा हूं, लेकिन सर्वर लॉग में एक नई प्रविष्टि अभी भी हर मिनट दिखाई देती है। सर्वर पर सभी उपयोगकर्ताओं (रूट सहित) के लिए Crontab फाइलें खाली हैं और कुछ भी नहीं करते हैं।

इसके अलावा, उपयोगकर्ता 'बैकअप-ओनली' केवल सर्वर पर और सीमित अधिकारों के साथ, समर्पित डेस्कटॉप SSH कुंजी के साथ मेरी डेस्कटॉप मशीन पर बनाया गया था। मैं मान रहा हूं कि यह रास्ता है क्योंकि कमांड को मैन्युअल रूप से चलाने पर सब कुछ काम करता है।

ऊपर पोस्ट की गई कॉन्टैब फाइल मेरे लिए है, मेरे डेस्कटॉप मशीन पर उपयोगकर्ता 'टॉम'। मेरा इरादा यह है कि यह उस स्क्रिप्ट को कॉल करे जो सर्वर पर उपयोगकर्ता 'बैकअप-ओनली' के रूप में लॉग इन करे। मैंने बस बैकअप स्क्रिप्ट चलाने की कोशिश की (बजाय इसके अंदर कमांड के) और यह सफलतापूर्वक जुड़ा और काम किया। मैंने इसे अपने डेस्कटॉप पर उपयोगकर्ता 'टॉम' के रूप में चलाया, उसी उपयोगकर्ता ने जो क्रॉन जॉब बनाया था जो काम नहीं करेगा। यहाँ उस सफल लॉगिन के साथ इसी सर्वर लॉग से आउटपुट है

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

Comments

अगर 3. keyfile का उपयोग करके काम करता है और 6. तब भी काम करता है, तो ... इर ... प्राप्त अंत पर sshd logfile क्या कहता है?

— Jan

@ जान मुझे मिलीSep 7 14:45:01 <hostname> CRON[18716]: pam_unix(cron:session): session closed for user root

— टॉम ब्रॉसमैन

यह या तो गलत लॉग लाइन है या ssh के माध्यम से कनेक्ट करने का प्रयास करने वाला उपयोगकर्ता रूट है ... या क्या वह मशीन से है जो बैकअप आरंभ करता है?

— Jan

टॉम, 2 सवाल बस यह सुनिश्चित करने के लिए कि आपकी पहली टिप्पणी में लॉगलाइन में CRON [...] है, लेकिन यह दिखना चाहिए Sep 7 16:06:02 <hostname> sshd[6747]...। क्या आप 100% सकारात्मक हैं कि यह लॉगलाइन सर्वर से है और यह सही लाइन है? आपके द्वारा पोस्ट किया गया क्रेस्टब केवल बैकअप का क्रॉस्टैब है ? इसके अलावा, पहचान फ़ाइल को मैन्युअल रूप से जोड़ने का प्रयास करें:rsync .... -e 'ssh -i /home/user/.ssh/identity' ...

— Jan

इसके अलावा, auth.logआपके द्वारा Edit 2 के तहत पोस्ट की गई लाइन सर्वर पर चलने वाले क्रोन के लिए है, और आपके लॉगिन प्रयासों से कोई लेना-देना नहीं होना चाहिए। क्या आप tail -f /var/log/auth.logक्रोन के माध्यम से स्क्रिप्ट को चलाने की कोशिश करते समय सर्वर पर कोशिश कर सकते हैं ? इसके अलावा, मुझे यकीन नहीं है कि यह काम करेगा, लेकिन क्या आप अपनी पहली envकमांड को rsync .... -e 'ssh -vvv -i /home/user/.ssh/identity ...यह देखने के लिए आज़मा सकते हैं कि क्या यह अधिक त्रुटि करता है?

— अला अली

Answer 1

चूंकि सब कुछ कमांड लाइन से ठीक काम कर रहा है, इसलिए त्रुटि का Permission denied (publickey)मतलब है कि एसएसएच का हिस्सा rsyncनिर्दिष्ट उपयोगकर्ता नाम की तुलना में एक अलग पहचान फ़ाइल का उपयोग कर रहा है।

मूल प्रश्न पर जनवरी की टिप्पणी से , हम rsyncकमांड फाइल का उपयोग करके कमांड में पहचान निर्दिष्ट कर सकते हैं -e 'ssh -i /path/to/identity.file' ...।

क्रॉन में एक ताज़ा वातावरण के साथ शुरू करने के लिए नीचे दिए गए आदेश का उपयोग करना और फ़ाइल का पूरा पथ निर्दिष्ट करना समस्या को हल करता है:

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

_{मुझे अभी भी इस खोज में दिलचस्पी है। यह संभवतः क्रोन के साथ करना है, तथ्य यह है कि यह न्यूनतम पर्यावरण चर, और एसएसएच-एजेंट के साथ शुरू होता है। मैं इसे देखने और वापस रिपोर्ट करने के लिए एक-दो दिनों में एक ही परिदृश्य स्थापित करूंगा।}

Comments

क्या आपका मतलब है कि आप दौड़ेenv -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' -e 'ssh -i /path/to/identity.file' /Backups/auto-daily-backups/./ [e-mail]:/backups/desktop/"

— qazwsx

@Problemania व्हॉट्स, फिक्स्ड।

— अलाअ अली

मैं देखता हूं कि आपके पास एक उत्तर है, लेकिन मैं उत्सुक हूं कि क्या आप 'sudo crontab -e' यानी रूट क्रोन चला रहे हैं। यदि आप "बैकअप" उपयोगकर्ता के रूप में लॉग इन करते हैं तो क्या होता है।

— wlraider70

मुझे लगता है कि आपका मतलब उस व्यक्ति से था जिसने सवाल पूछा था। लेकिन वह अपने उपयोगकर्ता नाम के क्रॉस्टैब का उपयोग कर रहा था, रूट नहीं, और मुझे लगता है कि वह बैकअप उपयोगकर्ता के कॉन्टैब का उपयोग नहीं करना चाहता था।

— आला अली

जब मैं अपने उपयोगकर्ता के साथ एक समान स्क्रिप्ट चलाता हूं, तो यह X11 के माध्यम से ssh कुंजी लेता है, इसलिए मुझे कुंजी की आवश्यकता होने पर स्थानीय प्रतिलिपि की आवश्यकता होती है, और सुनिश्चित करें कि इस फ़ाइल में सही स्वामी और अधिकार हैं, जो कि ऊपर के साथ मिलकर मेरे लिए अच्छी तरह से काम करता है।

— सेवरे

Answer 2

मैंने बस इस समस्या को हल किया है जिसने मुझे व्यस्त रखा है ।।

SSH के लिए RSYNC में कनेक्ट करने में असमर्थ, SSH के लिए पहचान निर्धारित होने के बावजूद ... कुछ भी नहीं किया गया ... Rsync कहता है "अनुमति अस्वीकृत" और ssh मुझे बताता है "read_passphrase: नहीं खोल सकता / dev / tty: कोई डिवाइस या का पता नहीं इस तरह"

लेकिन मैंने एक पोस्ट पढ़ी जिसमें समझाया गया कि क्रॉस्टैब का अपना वातावरण है जो जड़ जैसा नहीं है। मैं पहले से ही जानता था कि एसएसएच-एजेंट का उपयोग करते समय मुझे एसएसएच पर पड़ने वाले प्रभाव की समझ नहीं थी

लेकिन मेरी SSH कुंजी का आदान-प्रदान PassPhrase के साथ किया जाता है ... इसलिए यदि वातावरण अलग है और SSH पर मेरा RSYNC एक पासफ़्रेज़ की अपेक्षा करता है जो दर्ज नहीं किया जा सकता है => SSH डीबग जानकारी भी त्रुटि का संकेत देती है:

"debug1: read_passphrase: नहीं खोल सकता / dev / tty: ऐसा कोई उपकरण या पता नहीं है" => खैर हाँ नहीं TTY = कोई पासफ़्रेज़ = अनुमति नहीं है

मेरी मशीन पर मैं SSH एजेंट को लॉन्च करने के लिए "किचेन" का उपयोग करता हूं, इसलिए जब भी मैं रिमोट कनेक्शन की कोशिश करता हूं, तो मुझे पासफ़्रेज़ को दोबारा प्रस्तुत नहीं करना पड़ता। कीचेन एक फ़ाइल बनाता है जिसमें निम्नलिखित जानकारी होती है

SSH_AUTH_SOCK = /tmp/ssh-PWg3yHAARGmP/agent_8891; SSH_AUTH_SOCK निर्यात करें; SSH_AGENT_PID = 18893; SSH_AGENT_PID निर्यात करें;

==> SSH-AGENT कमांड एक ही जानकारी देता है।

तो, अंत में, यह वर्तमान सत्र से संबंधित यह जानकारी है जो भविष्य के वर्तमान सत्र की प्रमाणिकता की अनुमति देता है, बिना पासफ़्रेज़ में प्रवेश करने की आवश्यकता के बिना क्योंकि पहले से ही किया गया था और याद ...

==> समाधान वहाँ है ... यह crontab द्वारा शुरू की गई स्क्रिप्ट में पर्याप्त है, और इस जानकारी से युक्त फ़ाइल को "स्रोत" या कमांड लाइन पर इसे करने के लिए crontab ...

उदाहरण: 14 09 * * *। /home/foo/.keychain/foo.erveur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh [e-mail]:। >> / var / log / check_connexion.log 2> और 1 या SSH का उपयोग करके कनेक्शन शुरू करने वाली स्क्रिप्ट में कमांड "source /home/foo/keychain/foo.server.org-sh" का उपयोग करें।

=> इस सोर्सिंग के साथ, कोई और चिंता नहीं। SSH_AUTH_SOCK और SSH_AGENT_PID की जानकारी Crontab के वातावरण में भरी हुई है और इसलिए ज्ञात है, SSH पर RSYNC बिना किसी समस्या के काम करता है।

इसने मुझे व्यस्त रखा है लेकिन अब, यह काम करता है :)

Answer 3

SSH एजेंट अग्रेषण का उपयोग करने वालों के लिए चेतावनी:

यदि आप किसी दूरस्थ होस्ट पर स्क्रिप्ट को डीबग करते समय इस व्यवहार को देखते हैं, तो यह इसलिए है क्योंकि -e "ssh -i /path/to/key"ध्वज के साथ भी , ssh सर्वर पर एक के बजाय आपके स्थानीय (अग्रेषित) कुंजी का उपयोग करेगा।

ठोस उदाहरण: मेरे पास देव सर्वर पर एक स्क्रिप्ट है जो ss पर rsync का उपयोग करके "डेटा सर्वर" से डेटा में खींचती है। जब मैं देव सर्वर में लॉग इन करता हूं और इसे चलाता हूं, तो सब ठीक है, लेकिन क्रोन से चलने पर मुझे अनुमति से वंचित कर दिया जाता है। SSH प्रक्रिया (ध्वज -vv) में कुछ वर्बोसिटी जोड़कर मैंने निम्नलिखित पर ध्यान दिया:

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

मुझे यहाँ से जो मिला वह यह है कि शुद्ध संयोग से, मुझे स्थानीय सर्वर ("जुआन") की तुलना में स्थानीय होस्ट ("रात") पर एक अलग उपयोगकर्ता नाम होना चाहिए।

ध्यान दें कि यह कैसे देव सर्वर पर "स्पष्ट" के रूप में कुंजी को चिह्नित करता है, लेकिन फिर भी मेरे लैपटॉप से ​​लॉग इन करने के लिए अग्रेषित कुंजी का उपयोग करता है। ssh-copy-idइस बिंदु पर करना कुछ भी नहीं हल करता है, क्योंकि यह बस देव से एक के बजाय अग्रेषित कुंजी को पुनर्स्थापित करता है। सर्वर। यदि आप एजेंट अग्रेषण के साथ ssh-copy-id का उपयोग करते हैं, तो आपको -i ध्वज के साथ कौन सी कुंजी स्थापित करनी है: यह निर्दिष्ट करना होगा ssh-copy-id -i ~/.ssh/id_rsa.pub user@host।

Answer 4

क्या आपने पहले से ही मेजबानों की फ़ाइलों को साफ करने की पुरानी चाल की कोशिश की है? मेरा मतलब:

rm ~/.ssh/known_hosts

यह कोशिश कर रहा लायक है क्योंकि ssh इसे फिर से बनाएगा और आपको बासी सामान से छुटकारा मिलेगा। आप निश्चित रूप से किसी दिए गए आईपी / होस्ट से संबंधित भागों को भी हटा सकते हैं।

अधिक प्रश्न: क्या आपका क्रोन जॉब आपके UID के तहत चल रहा है या यह उपयोगकर्ता क्रोन या रूट के रूप में चल रहा है?

Comments

कमांड प्रत्येक काम को व्यक्तिगत रूप से करते हैं, इसलिए मैं यह नहीं देखता कि हटाने से ~/.ssh/known_hostsकुछ भी कैसे बदल जाएगा? और क्रोन डेस्कटॉप पर मेरे उपयोगकर्ता 'टॉम' के रूप में चलता है, सर्वर में लॉग इन करने के इरादे से उपयोगकर्ता 'बैकअप-ओनली' के रूप में उस संबंधित (पासवर्ड रहित) एसएसएच कुंजी के साथ, जो उपयोगकर्ता टॉम में है ~/.ssh।

— टॉम ब्रॉसमैन

@ runlevel0 न तो -rहै और न ही -fध्वज को नष्ट करने की जरूरत है known_hosts-यह एक नियमित रूप से फ़ाइल (नहीं एक निर्देशिका) है, और यह केवल पढ़ने के लिए नहीं है। rm .ssh/known-hostsयह काफी हद तक सुरक्षित होगा, यह देखते हुए कि एक एकल चरित्र टाइपो - गलती से .और ssh/known_hostsउसके बाद rm -rf(या rm -r) के बीच की जगह को जोड़ना आमतौर पर उपयोगकर्ता के होम फ़ोल्डर की संपूर्ण सामग्री को हटा देगा!

— एलिया कागन

हाय एलिया, उत्कृष्ट बिंदु वास्तव में !! मैं -Rf ध्वज का उपयोग एक प्रतिवर्त क्रिया के रूप में करता हूं, लेकिन आप बिल्कुल सही हैं। मैं बुरा।

— रनलेवेल0

Answer 5

का प्रयोग करें rrsyncइस प्रकार एक समर्पित ssh कुंजी के साथ स्क्रिप्ट एक साथ:

रीमोट सर्वर

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

LOCAL कंप्यूटर

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

रिमोट कंप्यूटर

cat id_remote_backup.pub >> authorized_keys

निम्नलिखित नई गयी पंक्ति के लिए आगे बढ़ें

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

ताकि परिणाम दिखे

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

स्थानीय

अनुमति के crontabसाथ अपनी निम्न स्क्रिप्ट में रखें x:

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

स्रोत: http://www.guyrutenberg.com/2014/01/14/restricting-ssh-access-to-rsync/

Answer 6

Ssh भाग "ssh -v" को जोड़ने और डिबग करने के लिए इस तरह आप कुछ उपयोगी जानकारी के साथ वर्बोज़ मोड प्राप्त कर सकते हैं।

संपादित करें: आदमी पृष्ठ से:

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

Answer 7

मुझे लगता है कि आपने sshd_config फ़ाइल को ठीक से कॉन्फ़िगर नहीं किया है। सत्यापित करें कि PermitRootLogin yesऔर PubkeyAuthentication yes दूरस्थ रखरखाव के लिए।

Comments

वह रूट के रूप में लॉगिन करने की कोशिश नहीं कर रहा है, और उसके पास शायद सार्वजनिक कुंजी प्रमाणीकरण सेटअप सही है क्योंकि वह टर्मिनल से बैकअप कमांड को सफलतापूर्वक चला सकता है और चला भी सकता है।

— अला अली

सलाह के लिए धन्यवाद, लेकिन मैं निश्चित रूप से PermitRootLoginसक्षम नहीं है और इसे बदलने की कोई योजना नहीं है। सबसे अच्छा अभ्यास इसे अक्षम करना है, और केवल एक सामान्य उपयोगकर्ता के रूप में ssh करें (यदि आवश्यक हो तो उन्हें अपने 'sudoers में जोड़ें) और कभी भी रूट के रूप में नहीं।

— टॉम ब्रॉसमैन