এই আরএসসিএনএস + এসএসএস ক্রোন জব কেন আমাকে 'অনুমতি অস্বীকার (পাবলিককি)' ত্রুটি দিচ্ছে?


20

আমি একটি স্থানীয় ড্রাইভে ঘন ঘন ব্যাকআপগুলি করি যা আমি প্রতিদিন একটি দূরবর্তী সার্ভারে সিঙ্ক করতে চাই।

লক্ষ্য সার্ভারটি কেবল এসএসএইচ কী (কোনও পাসওয়ার্ড নয়) অ্যাক্সেসের জন্য কনফিগার করা হয়েছে। যেহেতু সেই সার্ভারের জন্য আমার প্রাথমিক এসএসএইচ কী পাসফ্রেজ-সুরক্ষিত, তাই আমি অপ্রত্যাশিত ব্যাকআপগুলির জন্য ব্যবহার করার জন্য একটি দ্বিতীয় এসএসএইচ কী (পাসফ্রেজ সুরক্ষিত নয়) + ব্যবহারকারী তৈরি করেছি - ক্রোন চলাকালীন আমার পাসফ্রেজে প্রবেশের জন্য আমাকে উপস্থিত থাকতে হবে না ।

আমি ক্রোন এবং আরএসএনসি ব্যবহার করছি এবং সমস্ত কমান্ড পৃথকভাবে কাজ করে, তবে সংযুক্ত হয়ে ব্যর্থ হয়।

ট্রাবলশুটিং চলাকালীন আমি এখনি পেয়েছি

env -i sh -c "rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/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 / লগ / সিসলগে কোনও অস্বাভাবিক কিছুই নয় Sep 7 13:22:01 desktop CRON[6735]: (tom) CMD (sh /home/tom/Documents/Scripts/offsite-backup)

  3. ব্যাকআপ ব্যবহারকারীর কাজ করে টার্মিনালে রিমোট সার্ভারে এসএসএইচ ssh backups-user@XX.XX.XX.XX

  4. টার্মিনালে কমান্ড চালানো নিখুঁতভাবে কাজ করে rsync -lrstRO --delete --exclude 'lost+found' /Backups/auto-daily-backups/./ backups-only@XX.XX.XX.XX:/backups/desktop/
  5. ব্যাকআপগুলি-ব্যবহারকারী কীটির জন্য ম্যানুয়ালি পাথ নির্দিষ্ট করে দেওয়ার কোনও প্রভাব নেই 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. একটি সাধারণ পরীক্ষা কমান্ডের সাথে অ-কার্যকারী কমান্ডকে প্রতিস্থাপন করা কাজ করে echo "Hello world" > ~/Desktop/test.txt

  7. কম্পিউটারে শোরগোল / শপথের কোনও প্রভাব ছিল না (তবে আমাকে অস্থায়ীভাবে আরও ভাল লাগা হয়েছে)।


সম্পাদনা 1:

এখানে আমার ক্রন্টব ফাইল এবং স্ক্রিপ্টটি এটি কল করে।

...
# 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/./ backups-only@XX.XX.XX.XX:/backups/desktop/

সম্পাদনা 2:

কেবল স্পষ্ট /var/log/auth.logকরে বলতে গেলে, টার্গেট সার্ভারে লাইন রয়েছে এটি Sep 11 08:23:01 <hostname> CRON[24421]: pam_unix(cron:session): session closed for user rootবিভ্রান্তিকর কারণ আমি প্রতি মিনিটে স্থানীয়ভাবে ক্রোন চালাচ্ছি না, তবে সার্ভার লগগুলিতে প্রতি মিনিটে একটি নতুন এন্ট্রি এখনও উপস্থিত হয়। সার্ভারে সমস্ত ব্যবহারকারীর (রুট সহ) ক্রন্টব ফাইলগুলি খালি রয়েছে এবং কিছুই করছে না।

এছাড়াও, কেবলমাত্র সার্ভারে এবং সীমিত অধিকারের সাথে ব্যবহারকারীর 'ব্যাকআপ-কেবল' তৈরি করা হয়েছিল, একটি ডেডিকেটেড এসএসএইচ কীটি আমার ডেস্কটপ মেশিনে অনুলিপি করে। আমি ধরেই নিচ্ছি এটি যাওয়ার উপায় কারণ আদেশগুলি ম্যানুয়ালি চালানোর সময় সবকিছু কাজ করে।

উপরে পোস্ট করা ক্রন্টব ফাইলটি আমার জন্য, আমার ডেস্কটপ মেশিনে ব্যবহারকারী 'টম'। আমার উদ্দেশ্য হ'ল এটিতে স্ক্রিপ্টটি কল করা উচিত যা ব্যবহারকারীর 'ব্যাকআপ-কেবল' হিসাবে সার্ভারে লগ ইন করা উচিত। আমি কেবল ব্যাকআপ স্ক্রিপ্টটি চালানোর চেষ্টা করেছি (এর ভিতরে থাকা কমান্ডের চেয়ে) এবং এটি সফলভাবে সংযুক্ত ও কাজ করেছে। আমি এটি 'টম' ব্যবহারকারী হিসাবে আমার ডেস্কটপে চালিয়েছি, একই ব্যবহারকারী যিনি ক্রোন জব তৈরি করেছেন যা কাজ করবে না। এখানে সফল লগইনের সাথে সম্পর্কিত সার্ভার লগ থেকে আউটপুট

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

যদি 3. কীফাইল এবং using ব্যবহার করে কাজ করে 6.। এছাড়াও কাজ করে, তবে ... ভুল ... প্রাপ্তির শেষে এসএসডি লগফিল কী বলে?
জানুয়ারী

@ জান আমি পেয়েছিSep 7 14:45:01 <hostname> CRON[18716]: pam_unix(cron:session): session closed for user root
টম ব্রসম্যান

এটি হয় ভুল লগ লাইন অথবা ব্যবহারকারী যে এসএসএসের মাধ্যমে সংযোগ দেওয়ার চেষ্টা করছে সেটি মূল: ... বা ব্যাকআপগুলি শুরু করা মেশিন থেকে এটি?
জানুয়ারী

1
টম, কেবলমাত্র নিশ্চিত করার জন্য 2 টি প্রশ্ন আপনার প্রথম মন্তব্যে লগলাইনটিতে সিআরএন রয়েছে [...], তবে এটি দেখতে হবে Sep 7 16:06:02 <hostname> sshd[6747]...। আপনি কি 100% ইতিবাচক যে এই লগলাইনটি সার্ভার থেকে এসেছে এবং এটি সঠিক লাইন? আপনি যে ক্রন্টব পোস্ট করেছেন তা কি কেবল ব্যাকআপের ক্রন্টব ? এছাড়াও, পরিচয় ফাইলটি ম্যানুয়ালি যুক্ত করার চেষ্টা করুন:rsync .... -e 'ssh -i /home/user/.ssh/identity' ...
জানুয়ারী

1
এছাড়াও, auth.logসম্পাদনা 2 এর অধীনে আপনার পোস্ট করা লাইনটি সার্ভারে ক্রোন চলার জন্য, এবং আপনার লগইন প্রচেষ্টাগুলির সাথে কোনও সম্পর্ক নেই। আপনি চেষ্টা করতে পারেন tail -f /var/log/auth.logসার্ভারে যখন আপনি ক্রন মাধ্যমে স্ক্রিপ্ট চালানোর চেষ্টা করছেন? এছাড়াও, আমি নিশ্চিত না যে এটি কাজ করে কিনা, তবে আপনি কি আপনার প্রথম envকমান্ডটি rsync .... -e 'ssh -vvv -i /home/user/.ssh/identity ...আরও ত্রুটি ছুঁড়ে ফেলে কিনা তা দেখতে চেষ্টা করতে পারেন?
আলা আলী

উত্তর:


15

যেহেতু কমান্ড লাইন থেকে সবকিছু ঠিকঠাক কাজ করছে, ত্রুটিটির 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/./ backups-only@XX.XX.XX.XX:/backups/desktop/"

আমি এখনও এই অনুসন্ধানে সত্যই আগ্রহী। এটি সম্ভবত ক্রোন দিয়ে করতে হবে, এটি ন্যূনতম পরিবেশের ভেরিয়েবল এবং এসএস-এজেন্ট দিয়ে শুরু হয়। এটি পরীক্ষা করে দেখতে এবং প্রতিবেদন করার জন্য আমি কয়েক দিনের মধ্যে একই দৃশ্য সেট আপ করব।


1
আপনার অর্থ কি আপনি ছুটে env -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

@ প্রব্লেমেনিয়া হুপস, স্থির।
আলা আলী

আমি দেখতে পাচ্ছি যে আপনার একটি উত্তর আছে তবে আমি আগ্রহী আপনি কি 'সুডো ক্রন্টব-ই' চালাচ্ছেন এটিই মূল ক্রোন। "ব্যাকআপ" ব্যবহারকারী হিসাবে লগ ইন করার সময় আপনি যদি 'ক্রন্টব-ই' করেন তবে কি হবে?
wlraider70

আমি মনে করি আপনি যে ব্যক্তিকে প্রশ্ন জিজ্ঞাসা করেছিলেন তার জন্য আপনি এটি বোঝাতে চেয়েছিলেন। তবে তিনি তার ব্যবহারকারীর নাম ক্রোনটব ব্যবহার করেছিলেন, রুট নয়, এবং আমি মনে করি তিনি ব্যাকআপ ব্যবহারকারীর ক্রন্টব ব্যবহার করতে চান না।
আলা আলী

যখন আমি আমার ব্যবহারকারীর সাথে একই স্ক্রিপ্টটি চালাচ্ছি, এটি এক্স 11 এর মাধ্যমে এসএসএস কী লাগে, তাই কী থাকলে আমার একটি স্থানীয় অনুলিপি প্রয়োজন এবং উপরের সাথে মিলিয়ে এই ফাইলটির সঠিক মালিক এবং অধিকার রয়েছে কিনা তা নিশ্চিত করুন।
Sverre

1

আমি কেবল এই সমস্যাটি সমাধান করেছি যা আমাকে ব্যস্ত রাখে ..

এসএসএইচ-এর জন্য পরিচয় নির্ধারিত করেও এসএসএইচ-এর মাধ্যমে আরএসওয়াইএনসিতে সংযোগ স্থাপন করতে অক্ষম ... কিছুই হয় না ... রাইকিঙ্ক "অনুমতি অস্বীকৃত" বলে এবং এসএসএস আমাকে "পঠন-পাসফ্রেজ: খুলতে পারে না / দেব / টিটি: কোনও ডিভাইস বা ঠিকানা নেই এই রকম"

তবে আমি একটি পোস্ট পড়েছি যা ব্যাখ্যা করেছে যে ক্রোনটবের নিজস্ব পরিবেশ রয়েছে যা মূলের মতো নয়। আমি এটি ইতিমধ্যে জানতাম তবে এসএসএইচ-এজেন্ট ব্যবহার করার সময় এসএসএইচে এর প্রভাব কী তা আমি বুঝতে পারি নি

তবে আমার এসএসএইচ কী এক্সচেঞ্জগুলি পাসফ্রেসের সাথে করা হয় ... সুতরাং যদি পরিবেশটি আলাদা হয় এবং আমার এসএসএইচ-এর উপরের আরএসওয়াইএনসি প্রবেশ করা যায় না এমন একটি পাসফ্রেজ আশা করে => এসএসএইচ ডিবাগ তথ্যও ত্রুটিটি নির্দেশ করে:

"debug1: read_passphrase: / dev / tty খুলতে পারবেন না: এ জাতীয় কোনও ডিভাইস বা ঠিকানা নেই" => ভাল হ্যাঁ না টিটিওয়াই = কোনও পাসফ্রেজ = অনুমোদিত নয়

আমার মেশিনে আমি এসএসএইচ এজেন্ট চালু করার জন্য "কীচেইন" ব্যবহার করি যাতে প্রতিবার যখন আমি রিমোট সংযোগ চেষ্টা করি তখন আমাকে পাসফ্রেজটি আবার প্রবেশ করতে হবে না। কীচেইন একটি ফাইল তৈরি করে যার মধ্যে নিম্নলিখিত তথ্য থাকে

এসএসএইচ_এইউথ_সক = =tmp/ssh-PWg3yHAARGmP/agent.18891; এসএসএইচ_এইউথ_সককে রফতানি করুন; এসএসএইচ_এজিআইপিআইডি = 18893; এসএসএইচ_এজিআইপিআইডি রফতানি করুন;

==> এসএসএইচ-এজেন্ট কমান্ড একই তথ্য ফেরত দেয়।

সুতরাং, শেষ পর্যন্ত, এটি বর্তমান সেশনের সাথে সম্পর্কিত এই তথ্যগুলি যা পাসফ্রেজে প্রবেশের প্রয়োজন ছাড়াই বর্তমান সেশনের ভবিষ্যতের প্রমাণীকরণের অনুমতি দেয় কারণ ইতিমধ্যে পূর্বে এবং মুখস্থ হয়ে গেছে ...

==> সমাধানটি এখানে রয়েছে ... এটি ক্রোনট্যাব দ্বারা প্রবর্তিত স্ক্রিপ্টে যথেষ্ট, এবং এই তথ্য সম্বলিত ফাইলটিকে "উত্স" করতে বা কমান্ড লাইনে ডিএস ক্রোনট্যাব করার জন্য ...

উদাহরণ: 14 09 * * *। /home/foo/.keychain/foo.serur.org-sh && scp -vvv -P 22 /tmp/mon_fic/toto.sh foo@my-server.fr:। >> / var / log / check_connexion.log 2> & 1 বা স্ক্রিপ্টে "উত্স /home/foo/keychain/foo.server.org-sh" কমান্ডটি ব্যবহার করুন যা এসএসএইচ ব্যবহার করে সংযোগ শুরু করে।

=> এই সোর্সিংয়ের সাথে আর কোনও উদ্বেগের দরকার নেই। এসএসএইচ_এইউথ_সোক এবং এসএসএইচ_এজিআইপিআইডি-র তথ্য ক্রন্টাবের পরিবেশে লোড হয় এবং তাই এটি পরিচিত, এসএসএইচ-এর উপর আরএসওয়াইএনসি কোনও সমস্যা ছাড়াই কাজ করে।

এটি আমাকে ব্যস্ত রাখে তবে এখন এটি কাজ করে :)


1

যারা এসএসএইচ এজেন্ট ফরওয়ার্ডিং ব্যবহার করেন তাদের জন্য কেভেট:

রিমোট হোস্টে কোনও স্ক্রিপ্ট ডিবাগ করার সময় আপনি যদি এই আচরণটি দেখতে পান, এটি কারণ -e "ssh -i /path/to/key"পতাকাটির সাথেও 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-idthis সার্ভার। আপনি এজেন্ট ফরওয়ার্ডিং সঙ্গে SSH-অনুলিপি-আইডি ব্যবহার করেন, তাহলে কী -i পতাকা দিয়ে ইনস্টল করতে উল্লেখ করা প্রয়োজন: ssh-copy-id -i ~/.ssh/id_rsa.pub user@host


0

আপনি ইতিমধ্যে হোস্ট ফাইলগুলি পরিষ্কার করার পুরানো কৌশলটি চেষ্টা করেছেন? আমি বলতে চাচ্ছি:

rm ~/.ssh/known_hosts

Ssh এটিকে পুনর্নির্মাণ করবে এটি চেষ্টা করার মতো এবং আপনি বাসি জিনিস থেকে মুক্তি পাবেন। আপনি অবশ্যই প্রদত্ত আইপি / হোস্টের অংশগুলি অপসারণ করতে পারেন।

আরও প্রশ্ন: আপনার ক্রোন কাজটি আপনার ইউআইডি এর অধীনে চলছে বা এটি ব্যবহারকারী ক্রোন বা মূল হিসাবে চলছে?


1
কমান্ডগুলি প্রতিটি স্বতন্ত্রভাবে কাজ করে, তাই আমি কীভাবে মুছতে দেখছি না কীভাবে মুছে ফেলা ~/.ssh/known_hostsকিছু বদলে যাবে? এবং ক্রোনটি ডেস্কটপে আমার ব্যবহারকারীর 'টম' হিসাবে চালিত হয়, সেই সাথে সম্পর্কিত (পাসওয়ার্ডহীন) এসএসএইচ কী দিয়ে ব্যবহারকারীকে 'ব্যাকআপ-কেবল' হিসাবে সার্ভারে লগ ইন করার উদ্দেশ্যে, যা ব্যবহারকারী টমের মধ্যে রয়েছে ~/.ssh
টম ব্রসম্যান

3
@ রানলিভেল 0 - নিয়মিত ফাইল (ডিরেক্টরি নয়) মুছে ফেলার জন্য -rবা -fপতাকাটির দরকার নেই known_hostsএবং এটি কেবল পঠনযোগ্য নয়। rm .ssh/known-hostsএকক চরিত্রের টাইপো - দুর্ঘটনাক্রমে (বা ) এর পরে .এবং ssh/known_hostsপরে কোনও স্থান যুক্ত করলে সাধারণত ব্যবহারকারীর হোম ফোল্ডারের পুরো বিষয়বস্তু মুছে ফেলা যায়! rm -rfrm -r
এলিয়াহ কাগন

হাই এলিয়াহ, সত্যিই চমৎকার পয়েন্ট !! আমি -আরফ পতাকাটি একটি প্রতিবিম্ব ক্রিয়া হিসাবে ব্যবহার করি তবে আপনি একেবারেই ঠিক। আমার খারাপ।
রানলেভেল0

0

rrsyncনিম্নলিখিত হিসাবে একটি ডেডিকেটেড এসএস কী সহ স্ক্রিপ্টটি ব্যবহার করুন :

রিমোট সার্ভার

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

স্থানীয় কম্পিউটার

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/


0

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.

-1

আমি মনে করি আপনি sshd_config ফাইলটি সঠিকভাবে কনফিগার করেন নি। এটি PermitRootLogin yesএবং PubkeyAuthentication yes দূরবর্তী রক্ষণাবেক্ষণের জন্য যাচাই করুন ।


1
সে রুট হিসাবে লগইন করার চেষ্টা করছে না, এবং সম্ভবত তার কাছে সার্বজনীন কী প্রমাণীকরণের সেটআপ সঠিকভাবে রয়েছে কারণ তিনি টার্মিনাল থেকে সফলভাবে সফলভাবে ব্যাকআপ কমান্ড চালাতে এবং এমনকি চালাতে পারেন।
আলা আলী

1
পরামর্শের জন্য ধন্যবাদ তবে আমি অবশ্যই PermitRootLoginসক্ষম হয়েছি না এবং এটি পরিবর্তন করার কোনও পরিকল্পনা নেই। সেরা অনুশীলন হ'ল এটি অক্ষম করা, এবং কেবলমাত্র একটি সাধারণ ব্যবহারকারী হিসাবে এসএসএস করুন (তাদের প্রয়োজনে আপনার 'sudoers' এ যুক্ত করুন) এবং কখনও রুট হিসাবে নয়।
টম ব্রসম্যান
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.