হোস্ট দ্বারা স্বীকৃত কী কিন্ত ক্লায়েন্ট সংযোগ বিচ্ছিন্ন

Question

কপ্টার,

ফেডোরা 23 ইনস্টলেশন করার পরে আমার এসএসএইচে সমস্যা আছে।

যখন আমি ব্যক্তিগত কী দিয়ে আমার দূরবর্তী হোস্টের সাথে সংযোগ করতে চাই না তখন আমার হোস্ট কীটি সন্ধান করে:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

তবে আপনি দেখতে পাচ্ছেন যে আমার ক্লায়েন্ট এটি নিজেই সংযোগ বিচ্ছিন্ন

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

আমি একই বেসরকারী কী ব্যবহার করে উইন্ডোতে পুট্টি দিয়ে আমার হোস্টের সাথে সংযোগ করতে পারি এবং আমি একটি আলাদা ব্যক্তিগত কী ব্যবহার করে আমার ফোনের সাথে সংযোগ করতে পারি।

যদি আপনার কোন ধারণা আছে ?

জন্য / etc / SSH / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

ধন্যবাদ

সম্পাদনা: আমি একটি পাসওয়ার্ডের সাথে সংযোগ করতে পারি

Comments

আপনি সার্ভারফল্টে এই প্রশ্নোত্তর পরীক্ষা করেছেন ? হতে পারে এটি আপনার ছায়া.কমের একটি ত্রুটি

— হেনরিক পিঞ্জেল

আপনি কি নিরীক্ষায় কোনও সেলইনাক্স অস্বীকৃতি বা এসইসিকমোএমপি বার্তা দেখতে পাচ্ছেন? ausearch -m SECCOMPবা ausearch -m AVC? সম্প্রতি কিছু পরিবর্তন হয়েছে যা কিছু সেটআপগুলিকে প্রভাবিত করতে পারে।

— জাকুজে

হেলো, আপনার সমস্ত জবাবের জন্য আপনাকে ধন্যবাদ তবে কী ঘটেছে তা আমি খুঁজে পেলাম না। আমি f22 এ ডাউনগ্রেড এবং এখন এটি কাজ করে। আপনার দিনটি সুন্দর

— প্রিভোলেও

sshd এ কোন লগ আছে?

— নিউট্রিনাস

এখানে যে মূল জিনিসটি অনুপস্থিত তা হ'ল সার্ভারের লগগুলি। ক্লায়েন্ট লগগুলি পুরো গল্পটি কখনই বলতে পারে না। আপনি যদি সম্পর্কিত সার্ভার লগগুলি যোগ করেন তবে উত্তর পাওয়ার সম্ভাবনা উল্লেখযোগ্যভাবে বেড়ে যাবে।

— জেনি ডি

Answer 1

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

খুব প্রাথমিক ধারণাটি ( এখান থেকে অনুলিপি করা ):

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

এখন আপনি পোস্ট করা ডিবাগ লগ থেকে:

• মনে হয় এটির সাথে দু'জন পৃথক ব্যবহারকারী জড়িত রয়েছে। /home/theo/.ssh/authorized_keysএবং /home/tbouge/.ssh/id_rsa। আপনি কি একজন ব্যবহারকারী হিসাবে অন্য ব্যবহারকারীর হোম ডিরেক্টরিতে লগইন করার চেষ্টা করছেন?
• ত্রুটিটির Postponed publickey for theo..অর্থ পাবলিক কী পদ্ধতির আগে অযাচিত প্রমাণীকরণ পদ্ধতি চেষ্টা করা হয়েছে। এসএসএইচ একের পর এক কনফিগারেশনে সক্ষম প্রতিটি অ্যাটিটিকেশন পদ্ধতি চেষ্টা করবে। আপনার ক্ষেত্রে আপনি GSSAPIAuthentication yesযা ব্যবহার করছেন না তা আপনি সক্ষম করেছেন। আপনি এটি করে নিরাপদে অক্ষম করতে পারেন GSSAPIAuthentication no।
• debug2: we did not send a packet, disable methodসম্ভবত এটি ব্যক্তিগত কী ফাইলটি (ফাইল অনুমতি বা নাম সমস্যা হয়) প্রসেস করতে পারে না either এসএসএইচ স্থানীয় এবং দূরবর্তী উভয় কম্পিউটারে ডিরেক্টরি এবং ফাইল অনুমতি সম্পর্কে খুব সংবেদনশীল। ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys)। সুতরাং, আপনার সঠিকভাবে সেট করা আছে তা নিশ্চিত করুন। এটি দেখুন: /unix/131886/ssh-public-key-wont-send-to-server

• তৃতীয় ত্রুটি হিসাবে:, Permission denied (public key).চেক করার জন্য কয়েকটি জিনিস রয়েছে।

  • ভুল ব্যবহারকারীর নাম
  • ভুল কী-জুটি

  • ভুল টার্গেটের হোস্ট

    • এখানে আরও বিশদ রয়েছে: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance ।

নিম্নলিখিত অংশটি কিছুটা বিভ্রান্তিকর:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

এটি আরও ভালভাবে বোঝার জন্য, এখানে ডিজিটালওশনে বর্ণিত হিসাবে ধাপে ধাপে প্রমাণীকরণ প্রক্রিয়াটি এগিয়ে চলুন :

1. ক্লায়েন্টটি কী জুটির জন্য একটি আইডি প্রেরণ শুরু করে যা এটি সার্ভারের সাথে প্রমাণীকরণ করতে চায়।
2. ক্লায়েন্ট কী আইডির জন্য লগ ইন করার চেষ্টা করছে তা সার্ভারের অ্যাকাউন্টের অনুমোদিত_কিস ফাইলটি যাচাই করে।
3. যদি ফাইলের সাথে মিলে যাওয়া আইডির সাথে কোনও পাবলিক কী পাওয়া যায় তবে সার্ভারটি একটি এলোমেলো সংখ্যা তৈরি করে এবং নম্বরটি এনক্রিপ্ট করতে সর্বজনীন কী ব্যবহার করে।
4. সার্ভার ক্লায়েন্টকে এই এনক্রিপ্ট করা বার্তা প্রেরণ করে।
5. যদি ক্লায়েন্টটির আসলে সম্পর্কিত ব্যক্তিগত কী থাকে তবে এটি মূল নম্বরটি প্রকাশ করে সেই কীটি ব্যবহার করে বার্তাটি ডিক্রিপ্ট করতে সক্ষম হবে।
6. ক্লায়েন্টটি ডিক্রিপ্ট করা নম্বরটি ভাগ করে নেওয়া সেশন কীটির সাথে সম্মিলন করে যা যোগাযোগটি এনক্রিপ্ট করতে ব্যবহৃত হয় এবং এই মানটির MD5 হ্যাশ গণনা করে।
7. ক্লায়েন্ট তারপরে এই এমডি 5 হ্যাশটি এনক্রিপ্ট করা নম্বর বার্তার উত্তর হিসাবে সার্ভারে ফিরে পাঠায়।
8. সার্ভারটি একই ভাগ করা সেশন কী এবং মূল নম্বরটি ব্যবহার করে যা ক্লায়েন্টকে তার নিজের থেকে MD5 মান গণনা করতে প্রেরণ করে। এটি তার নিজস্ব গণনার সাথে তুলনা করে যা ক্লায়েন্টটি ফেরত পাঠিয়েছিল। যদি এই দুটি মান মিলে যায় তবে এটি প্রমাণিত হয় যে ক্লায়েন্টটি ব্যক্তিগত কীটির দখলে ছিল এবং ক্লায়েন্টটি প্রমাণীকৃত।

আপনার ক্ষেত্রে যেমন আপনি দেখতে পাচ্ছেন, দূরবর্তী কম্পিউটার কেবল আপনার গ্রহণ করেছে public key, সেই কীটি দিয়ে প্যাকেটটি এনক্রিপ্ট করেছে এবং ক্লায়েন্ট কম্পিউটারে এটি আবার প্রেরণ করেছে। এখন ক্লায়েন্ট কম্পিউটারের এটির অধিকার রয়েছে তা প্রমাণ করা দরকার private key। শুধুমাত্র ডান ব্যক্তিগত_কি দিয়ে এটি পুনরুদ্ধার করা বার্তাটি ডিক্রিপ্ট করতে পারে এবং একটি উত্তর ফিরে পাঠাতে পারে। এই ক্ষেত্রে, ক্লায়েন্ট এটি করতে ব্যর্থ হচ্ছে এবং প্রমাণীকরণ প্রক্রিয়াটি সাফল্য ছাড়াই শেষ হয়।

আমি আশা করি এটি আপনাকে সমস্যাগুলি বুঝতে এবং তাদের সমাধান করতে সহায়তা করবে।

Answer 2

আপনার ssh ফাইলগুলিতে সুবিধা কি সঠিক?

.ssh ফোল্ডার -> 700

সর্বজনীন কী -> 644

ব্যক্তিগত কী -> 600

ব্যবহারকারী এবং গোষ্ঠীটিও পরীক্ষা করে দেখুন

Comments

আপনার উত্তরের জন্য ধন্যবাদ তবে আমি ইতিমধ্যে এটি পরীক্ষা করে দেখছি।

— প্রিভালেও

Answer 3

আপনি বলেন যে উইন্ডোজ মেশিনে আপনার একই কী রয়েছে; আপনি কি নিশ্চিত যে আপনার লিনাক্স মেশিনে থাকা প্রাইভেট কী ফাইলটি সঠিক? সম্ভবত ব্যক্তিগত কীটি পুটি ফর্ম্যাটে রয়েছে যা এসএস সহজে বুঝতে পারে না। যাই হোক না কেন, আমি যদি একটি ভুল বা অবৈধ প্রাইভেট কী ফাইল রাখি তবে আমি আপনার ঠিক একই ত্রুটি পেয়েছি।

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

Comments

আপনার উত্তরের জন্য আপনাকে ধন্যবাদ তবে হ্যাঁ প্রাইভেট কীটি ভাল (মজাদার ঘটনা: পুট্টিতে কীভাবে এটি ব্যবহার করতে হয় তা জানতে 1 ঘন্টা !!)।

— প্রিভালোও

সমস্যার (আপনার খুব যুক্তিযুক্ত) সমাধান অনুসারে, ব্যক্তিগত কীটি ভাল ছিল তবে ক্লায়েন্টটি এটি সক্ষম হবার কথা ভেবেও এটি ব্যবহার করতে পারেনি। আমার সন্দেহ হয় এমন কিছু আছে যা আপনাকে আপনার পাসফ্রেজের জন্য জিজ্ঞাসা করার কথা বলেছিল তবে তা করতে ব্যর্থ হয়েছে। এটি ব্যাখ্যা করবে কেন এটি আপগ্রেডের আগে কাজ করেছিল; আপগ্রেড হয় জিজ্ঞাসা-এর জন্য একটি পাসফ্রেজ পদ্ধতিটি ভুলভাবে সেট আপ করে বা এটি ইতিমধ্যে উপস্থিত থাকলে তা বিশৃঙ্খলাবদ্ধ করে তা sudo authconfig --updateallস্থির করে।

— Law29

Answer 4

আপনার সমস্যাটি বেশ সাধারণ বলে মনে হচ্ছে এবং আমি স্পষ্টও বলেছি।

 Permission denied (publickey).

এর অর্থ কি তোমার কিছু? আমার কাছে এটি আমার কাছে অনেক অর্থ।

আপনি যদি প্রয়োগকৃত মোড pls এ সেলিনাক্স রান্নিন থাকে তবে আপনি সার্ভার সাইডে পরীক্ষা করতে পারেন? যদি না বলুন সেলিনাক্স কী মোডে চলছে।

এছাড়াও, আপনি যদি আরও একটি চেষ্টা করতে পারেন এবং সেই চেষ্টাটির নিরীক্ষণ লগগুলি ক্যাপচার করতে এবং এখানে পোস্ট করতে পারেন তবে তা অবশ্যই আমাদের বলবে কেন:

  tail -f /var/log/audit/audit.log  (and try to attempt)

এটি অনুমতি সমস্যা যা স্পষ্ট তবে ফাইল অনুমতি নয় :-)

Comments

+1 এটি RHEL7.1 সেটআপগুলিতেও দেখেছেন। দয়া করে এর সাথে প্রসারিত করুন audit2allow:)

— kubanczyk

Answer 5

মনে হচ্ছে সমস্যাটি (আমার ক্ষেত্রে ...) কী এর ধরণের কারণে হয়েছিল।

আমি এখনই এটি স্থানীয় ~/.ssh/configফাইলটিতে (ফেডোরা 23 ক্লায়েন্ট মেশিন) নিম্নলিখিতটি যুক্ত করে সমাধান করেছি :

PubkeyAcceptedKeyTypes=+ssh-dss

যদিও আমি এই লাইনটি সার্ভার এবং ক্লায়েন্ট কনফিগারেশন ফাইল উভয়ই জুড়েছি, কেবল ক্লায়েন্ট পক্ষই পার্থক্য করেছে। নোট 600করুন কনফিগারেশন ফাইলটি পড়ার জন্য অনুমতিগুলি থাকা দরকার ।

Comments

এই ক্ষেত্রে না হয়. প্রশ্ন রয়েছে, কীটি আরএসএ।

— জাকুজে

@ জাকুজে হ্যাঁ, এমনটি মনে হবে, আমি খেয়ালও করি নি। ঠিক আছে, এটি অন্যান্য লোককে যেমন সহায়তা করেছে যেমন গতকাল আপগ্রেড করার পরে আমার ঠিক একই সমস্যা ছিল।

— জিরোইন

@ জিরোইন, ডিফল্টরূপে এটি rsaকী ব্যবহার করে । ফেডোরা রেফ এখানে দেখুন , এটি কাস্টমাইজ করা না হলে। কোনটি কী কনফিগার এবং ব্যবহার করতে হবে তা অবশ্যই চয়ন করতে পারেন।

— হীরা

@ জিরোইন আরও পরীক্ষায় আমি এটির প্রস্তাব দিই না; জিনোম-কিরিং-ডেমন un HOME / .ssh / id_ecdsa ফাইলগুলি গ্রহণ করে না, দুর্ভাগ্যক্রমে, যাতে এই কীগুলি আনলক করা যায় না এবং লগইনে স্বয়ংক্রিয়ভাবে সেশনের এসএস-এজেন্টে যুক্ত হয় না। যাইহোক, আমি তখন থেকে আমার সার্ভারটি এফ 23 তে আপগ্রেড করেছি এবং আরএসএ কীগুলি ব্যবহার করে এর এবং বাকি F22 ক্লায়েন্টের (উভয় দিকের) মধ্যে যেতে কোনও সমস্যা নেই। যদিও ইসিএসডিএ কীটি আমার এক ল্যাপটপের জন্য একটি প্রয়োজনীয় কাজ সরবরাহ করে যা এটির প্রয়োজন (যেখানে আরএসএ কীগুলি ব্যবহারের কোনও প্রচেষ্টা ব্যর্থ হয়), মূল সমস্যাটি অন্য কিছু বলে মনে হয়।

— এফআরডি

সহায়ক উত্তরের জন্য ধন্যবাদ। নোট করুন যে সার্ভারটি ওপেনএসএসএইচ 7.0 বা আরও উন্নত করা হয়েছে (যেমন, যদি এটি ফেডোরার 23 বা ততোধিক উন্নত হয়) তবে সার্ভারেও আপনাকে একই পরিবর্তন করতে হবে। Superuser.com/q/1016989/93541 দেখুন ।

— DW

Answer 6

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

সমস্যাটি যেমন দেখা যাচ্ছে, এসএসএইচ-তে মোটেও (আমার পক্ষে) ছিল না, তবে প্যাম কীভাবে আমার কীগুলি কনফিগার করছে। কনফিগারেশনটি পুরানো /etc/pam.dছিল (যদিও এটি ফেডোরার 22-র মাধ্যমে সঠিকভাবে কাজ করা হয়েছিল), এবং ফলস্বরূপ আমার চাবিগুলি বাছাই করার জন্য লগইন [আর] তে সঠিক জিনিস করা হচ্ছে না $HOME/.ssh/। এই আদেশটি চালাচ্ছি:

# sudo authconfig --updateall

/etc/pam.d কনফিগারেশন সঠিকভাবে পুনর্নির্মাণ করুন। পরবর্তী পুনরায় বুট করার পরে, আমি লগ ইন করার পরে, প্রথমবার যখন আমি আমার সার্ভারে স্যাশ আউট করার চেষ্টা করলাম তখন একটি ডায়ালগ বক্স আমাকে আমার এসএস কী ( $HOME/.ssh/id_rsa) এর জন্য আমার পাসফ্রেজ প্রবেশ করতে বলেছিল । আমি এটি করেছি, "লগইনটিতে স্বয়ংক্রিয়ভাবে আনলক করুন" বাক্সটি পরীক্ষা করেছিলাম এবং ভয়েলা! আমার ল্যাপটপ থেকে বেরিয়ে আসার ক্ষমতা পুনরুদ্ধার করা হয়েছিল।

পটভূমি

আমাকে যে সমস্যাটি সমাধান করার দিকে চালিত করেছিল সেগুলি যখন তখন আমি একটি বাহ্যিক উত্স থেকে একটি আরএসএ কী আমদানি করি। (একটি USB কী আমি প্রায় বহন, আমার বাড়িতে নেটওয়ার্কের জন্য আমার "দূরবর্তী প্রবেশাধিকার" কী দিয়ে। আমি PasswordAuth বন্ধ আমার বাহ্যিক ফেসিং সার্ভার বছরের আগে একটি অনুপ্রবেশের পর পরিণত।) পর ssh-add-ing যে RSA কী, এক বসে অসদৃশ $HOME/.ssh/id_rsa, এটি কোনও সমস্যা ছাড়াই রিমোট সার্ভার দ্বারা গৃহীত হয়েছিল।

তারপরে আমি যা করতে চাই তা শেষ ssh-addকরার জন্য, অতিরিক্ত কাজ করা উচিত $HOME/.ssh/id_rsa। আমি লক্ষ্য করেছি যে এটি করার পরে, একই কীটির জন্য দুটি এন্ট্রি ssh-add -lরয়েছে :

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

লক্ষ্য করুন যে দুটি এন্ট্রিগুলির মধ্যে একটি কী কী সনাক্তকারীটি প্রদর্শন করে না, কেবলমাত্র ব্যক্তিগত কী ফাইল নামটি তার সর্বজনীন স্বাক্ষরের সাথে মিলে। যদিও ব্যক্তিগত কীটি সত্যই কীরিংয়ের পরিচালক দ্বারা আনলক করা হয়নি ।

আমি বিশ্বাস করি ঠিক এটি ঘটছিল, এবং প্যাম পাসফ্রেজের সাথে আনলক করা হয়নি এমন এসএসএইচ এজেন্টের কাছে "খারাপ কীগুলি" দিচ্ছিল। সুতরাং, যখন ssh কীটি দিয়ে প্রমাণীকরণের চেষ্টা করেছিল, এটিতে কী জুটির আসলে (আনলক করা) ব্যক্তিগত অর্ধেকটি ছিল না, এবং তাই প্রমাণীকরণ ব্যর্থ হয়েছিল।

শেষ বিটটি অনুমানযোগ্য, তবে এফ 23 তে আপগ্রেড করার পরেও যদি দূরবর্তী হোস্টগুলি (যেখানে তারা ব্যবহৃত হত) দ্বারা ssh কীগুলি গ্রহণ না করে কারও সমস্যা হচ্ছে, সমাধান হিসাবে চেষ্টা /etc/pam.d/করে ডিরেক্টরিটি পুনর্নির্মাণ authconfigকরা মূল্যহীন।

Answer 7

ব্যবহারকারীর হোম ডিরেক্টরি অনুমতি পরীক্ষা করুন। এটা গুরুত্বপূর্ণ. 755 হতে হবে 700 700 বা 770 কাজ করবে না।

Answer 8

আপনার ssh_config, uncommenting এবং / অথবা যোগ / অপসারণ / হয় সংযোজন চেষ্টা Cipher, Ciphersঅথবা MACsলাইন (গুলি)।

এটি আমার কাছে উপস্থিত হয়েছে sshdযা অনুরোধে অন্তর্ভুক্ত করা হচ্ছে না এমন কোনও ধরণের নির্দিষ্ট সিফারের সন্ধান করছে যা এটি আপনার কনফিগার করে যোগ করা যেতে পারে ssh_config।

... এবং আমি তোমাদের কাছে কোন সুযোগ আছে দ্বারা না অভিমানী করছি PubkeyAuthenticationসেট no, দূরবর্তী সার্ভারে কারণ যে স্পষ্টভাবে এই বিফল হওয়ার সম্ভাবনা হবে।