ssh: হোস্টের 'হোস্টনেম' এর সত্যতা প্রতিষ্ঠিত হতে পারে না

153

আমি যখন কোনও মেশিনে ছুঁড়ে ফেলি, কিছু সময় আমি এই ত্রুটির সতর্কতা পাই এবং এটি "হ্যাঁ" বা "না" বলার অনুরোধ জানায়। স্ক্রিপ্টগুলি থেকে চালিত হয়ে কিছু সমস্যা দেখা দেয় যা স্বয়ংক্রিয়ভাবে অন্যান্য মেশিনে চলে যায়।

সতর্কীকরণ বার্তা:

The authenticity of host '<host>' can't be established.
ECDSA key fingerprint is    SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts.

স্বয়ংক্রিয়ভাবে "হ্যাঁ" বলার বা এটিকে উপেক্ষা করার কোনও উপায় আছে কি?

ssh ssh-keys rsa-key-fingerprint

— সেনথিল এ কুমার
সূত্র

27

আমি এর বিরুদ্ধে পরামর্শ দেব আপনি কেন এই ত্রুটিগুলি পাচ্ছেন তা নিয়ে আপনাকে কাজ করা দরকার, অন্যথায় আপনি মধ্য আক্রমণে নিজেকে একজন ব্যক্তির সামনে উন্মুক্ত করছেন, যা এই ত্রুটিগুলি আপনাকে রক্ষা করার চেষ্টা করছে।

— পিটার বাগনাল

3

এই ssh কী ব্যবহার করে সার্ভারে পরিবর্তনের কারণে এটি হতে পারে বা আপনার এবং সার্ভারের মধ্যে বসে কেউ আপনার পাঠানো / গ্রহণের সমস্ত কিছু শোনার কারণে হতে পারে।

— derekdreery

এই ত্রুটির কারণ কী হতে পারে?

— আইআইইউ

আমি পিটারের সাথে একমত নই। একটি বড় সংস্থায় অন্য কাউকে এরকম সমস্যা সমাধানের চেষ্টা করার সময় যখন আপনি কেবল নিজের কাজ শেষ করার চেষ্টা করছেন অবাস্তব।

— শ্রীধর সারনোবাত

অনেকগুলি বৃহত সংস্থা @ শ্রীধারারনোব্যাট যে পরামর্শ দিচ্ছে তার ঠিক বিপরীত। আপনি আছে নিশ্চিত সঠিক ব্যক্তির সমস্যার ঐ প্রকারের সমাধান করার জন্য এবং তাদের চারপাশে কাজ করার চেষ্টা মাত্র খারাপ করে তোলে।

— জেমস মুর

135

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

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

সম্পাদনা

@ ইয়ানডান নোট হিসাবে, এটি করার জন্য সুরক্ষা ঝুঁকি রয়েছে। আপনি যে সংস্থার সাথে সংযোগ করছেন তা যদি কোনও আক্রমণকারী দ্বারা ছদ্মবেশী হয়ে থাকে তবে তারা গন্তব্য সার্ভারের চ্যালেঞ্জটি আপনার কাছে ফিরিয়ে আনতে পারে, আপনাকে এই ভেবে বোকা বানাবে যে আপনি যখন রিমোট রিসোর্সে সংযুক্ত হচ্ছেন তখন তারা সেই সংস্থার সাথে সংযোগ করছেন are আপনার শংসাপত্র। আপনার সতর্কতার সাথে বিবেচনা করা উচিত যে হোস্টকিচেকিং এড়াতে আপনার সংযোগ ব্যবস্থাটি পরিবর্তন করার আগে এটি গ্রহণ করা উপযুক্ত ঝুঁকিপূর্ণ কিনা।

রেফারেন্স ।

— Cori
সূত্র

40

আমি মনে করি এটির নিরাপত্তা সম্পর্কিত প্রভাব সম্পর্কে সতর্কতা ছাড়াই এটির প্রস্তাব দেওয়া বেআইনী। superuser.com/a/421084/121091 একটি ভাল উত্তর আইএমও।

— ইয়ান ডান

5

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

— Cori

6

আমি বিশ্বাস করতে পারি না যে এত লোক এই উত্তরটিকে উচ্চারণ করেছে এবং এটিও যে প্রশ্নকর্তা গ্রহণ করেছেন। এই পদ্ধতিটি সুরক্ষা চেকগুলি বাইপাস করে এবং এটিকে দূরবর্তী হোস্টের সাথে সংযুক্ত করে। Check / .ssh / ফোল্ডারে জ্ঞাত_হোস্ট ফাইলের লেখার অনুমতি আছে কিনা তা পরীক্ষা করুন। যদি তা না হয় তবে এই উত্তরটি stackoverflow.com/a/35045005/2809294

— ARK

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

— user1683793

75

পুরানো প্রশ্ন যা আরও ভাল উত্তরের দাবি রাখে।

আপনি অক্ষম না করে ইন্টারেক্টিভ প্রম্পটটি প্রতিরোধ করতে পারেন StrictHostKeyChecking(যা অনিরাপদ)।

আপনার স্ক্রিপ্টে নিম্নলিখিত যুক্তি যুক্ত করুন:

if [ -z "$(ssh-keygen -F $IP)" ]; then
  ssh-keyscan -H $IP >> ~/.ssh/known_hosts
fi

সার্ভারের সর্বজনীন কী রয়েছে কিনা তা এটি পরীক্ষা করে known_hosts। যদি তা না হয় তবে এটি সার্ভার থেকে সর্বজনীন কী অনুরোধ করে এবং এতে যুক্ত করে known_hosts।

এইভাবে আপনি কেবল একবারই ম্যান-ইন-দ্য-মিডল আক্রমণটির মুখোমুখি হয়েছিলেন, যা এটিকে প্রশমিত করতে পারে:

স্ক্রিপ্টটি কোনও সুরক্ষিত চ্যানেলের মাধ্যমে প্রথমবারের সাথে সংযুক্ত হওয়ার বিষয়টি নিশ্চিত করে
ম্যানুয়ালি আঙুলের ছাপগুলি পরীক্ষা করতে লগ বা ज्ञात_হোস্টগুলি পরিদর্শন করা হচ্ছে (কেবল একবারেই করা হবে)

— গ্রজেগোর্স লুসজিও
সূত্র

4

অথবা আপনার অবকাঠামোগত কনফিগারেশন সেটআপের অংশ হিসাবে সমস্ত মেশিনের জন্য ज्ञात_হোস্টগুলি ফাইল পরিচালনা করুন।

— থিলো

1

নোট করুন যে ssh-keycan প্রক্সিকমন্ডের সাথে কাজ করে না: marc.info/?l=openssh-unix-dev&m=108446567718763&w=2

— রিচলভ

1

এটি প্রত্যাশার মতো কাজ করবে না। `ssh-keygen -F $IP`হওয়া উচিত "`ssh-keygen -F $IP`"(উদ্ধৃতিগুলিতে), অন্য ক্ষেত্রে এটি স্ট্রিং হিসাবে ব্যাখ্যা করা হবে না

— অ্যাভোমাটন

অথবা একটি oneliner SSH-kegen ফেরত মান ব্যবহার:ssh-keygen -F $IP >/dev/null || ssh-keyscan -H $IP >> ~/.ssh/known_hosts

— Gohu

38

অক্ষম করতে (বা অক্ষম করা নিয়ন্ত্রণ করুন), এর শুরুতে নিম্নলিখিত লাইনগুলি যুক্ত করুন /etc/ssh/ssh_config...

Host 192.168.0.*
   StrictHostKeyChecking=no
   UserKnownHostsFile=/dev/null

বিকল্প:

হোস্ট সাবনেটটি *সমস্ত আইপিগুলিতে সীমাহীন অ্যাক্সেসের অনুমতি দিতে পারে ।
/etc/ssh/ssh_configগ্লোবাল কনফিগারেশন বা ~/.ssh/configব্যবহারকারী-নির্দিষ্ট কনফিগারেশনের জন্য সম্পাদনা করুন ।

Http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html দেখুন

Superuser.com এ অনুরূপ প্রশ্ন - https://superuser.com/a/628801/55163 দেখুন

— জিম ফ্রেড
সূত্র

19

~/.ssh/known_hostsলিখিতযোগ্য তা নিশ্চিত করুন । এটা আমার জন্য এটি স্থির।

— রিচার্ড
সূত্র

4

সবাইকে পরিচিত_হোস্টগুলিতে লিখতে দেওয়া কি নিরাপদ?

— ওরফে রেম

2

@akaRem অবশ্যই না। সাধারণত আপনি চান যে এটি কেবল সেই .sshফোল্ডারের মালিক হিসাবে ব্যবহারকারীর কাছেই লেখার যোগ্য ।

— 2rs2ts

অনুমতিগুলি 0400সর্বোত্তম (দয়া করে আমাকে কাউকে সংশোধন করুন) তবে আমার ক্ষেত্রে বিষয়টি কেবল এই ছিল যে .sshআমার ব্যবহারকারীর জন্য ফোল্ডারটির মালিকানা পরিবর্তন হয়েছিল - আমার নিজের 0400 অনুমতি বাতিল করে দিয়েছে। sudoআমার কাছে মালিকানা ফিরিয়ে দেওয়া আমার সমস্যা সমাধান করেছে।

— চার্নি কায়ে

এটি আমার জন্য সমস্যাটি স্থির করেছে।

— শিবাজি

14

এটির সর্বোত্তম উপায় হ'ল 'স্ট্রিক্টহস্টকি চেকিং' ছাড়াও 'ব্যাচমড' ব্যবহার করা। এইভাবে, আপনার স্ক্রিপ্টটি একটি নতুন হোস্টনাম গ্রহণ করবে এবং এটি পরিচিত_হোস্ট ফাইলটিতে লিখবে, তবে হ্যাঁ / কোনও হস্তক্ষেপের প্রয়োজন হবে না।

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime"

— কোরি রিংডাহল
সূত্র

10

আপনার কনফিগারেশন ফাইলটি সাধারণত '~ / .ssh / config' এ অবস্থিত হন এবং ফাইলের সূচনাতে নীচের লাইনগুলি যুক্ত করুন

Host *
    User                   your_login_user
    StrictHostKeyChecking  no
    IdentityFile          ~/my_path/id_rsa.pub

ব্যবহারকারীরা সেট করুন your_login_userযে এই সেটিংসটি আপনার_লগিন_উজার
স্ট্রিটহোস্টকি- তে অন্তর্ভুক্ত যাচাই করা সেট করা প্রম্পটটি এড়ানো হবে না
আইডেন্টিটি ফাইলটি আরএসএ কী'র পথে

এটি আমার এবং আমার স্ক্রিপ্টগুলির জন্য কাজ করে, আপনার জন্য শুভকামনা।

— কার্লোস এমজিটি
সূত্র

ধন্যবাদ সত্যই এটি দিনটি বাঁচিয়েছিল। তবে শেষ লাইনটি IdentityFileকী? এটি এটি ছাড়াও কাজ করছে বলে মনে হচ্ছে ..

— সুপারসান

7

সুরক্ষা বৈশিষ্ট্যগুলির কারণে এই সতর্কতা জারি করা হয়েছে, এই বৈশিষ্ট্যটি অক্ষম করবেন না।

এটি কেবল একবার প্রদর্শিত হয়েছে।

এটি এখনও দ্বিতীয় সংযোগের পরে দেখা দিলে সমস্যাটি সম্ভবত known_hostsফাইলটিতে লিখিত ক্ষেত্রে । এই ক্ষেত্রে আপনি নিম্নলিখিত বার্তাটি পাবেন:

Failed to add the host to the list of known hosts

আপনি আপনার ব্যবহারকারীর দ্বারা লেখার যোগ্য ফাইলের অনুমতিগুলি পরিবর্তন করে মালিককে পরিবর্তন করে এটি ঠিক করতে পারেন।

sudo chown -v $USER ~/.ssh/known_hosts

— Sfisioza
সূত্র

5

কোরির উত্তরের রেফারেন্স সহ, আমি এটিকে সংশোধন করেছি এবং নীচের কমান্ডটি ব্যবহার করছি, যা কাজ করছে। ছাড়া exit, অবশিষ্ট কমান্ডটি আসলে রিমোট মেশিনে লগইন করছিল যা আমি স্ক্রিপ্টে চাইনি

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit"

— চিন্তামণি মাঞ্জারে
সূত্র

5

এটি করুন -> chmod +w ~/.ssh/known_hosts। এটি ফাইলটিতে লেখার অনুমতি যুক্ত করে ~/.ssh/known_hosts। এর পরে known_hostsআপনি যখন পরের বার সংযোগ করবেন তখন দূরবর্তী হোস্টটি ফাইলটিতে যুক্ত হবে।

— ARK
সূত্র

4

আদর্শভাবে, আপনার একটি স্ব-পরিচালিত শংসাপত্র কর্তৃপক্ষ তৈরি করা উচিত। একটি মূল জুড়ি উত্পাদন দিয়ে শুরু করুন: ssh-keygen -f cert_signer

তারপরে প্রতিটি সার্ভারের সর্বজনীন হোস্ট কীতে স্বাক্ষর করুন: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

এটি একটি স্বাক্ষরিত সর্বজনীন হোস্ট কী উত্পন্ন করে: /etc/ssh/ssh_host_rsa_key-cert.pub

ইন /etc/ssh/sshd_config, HostCertificateএই ফাইলটি নির্দেশ করুন: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Sshd পরিষেবাটি পুনরায় চালু করুন: service sshd restart

তারপরে এসএসএইচ ক্লায়েন্টের সাথে নিম্নলিখিতগুলিতে যুক্ত করুন ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

উপরেরটি রয়েছে:

@cert-authority
ডোমেইন *.example.com
সর্বজনীন কী এর সম্পূর্ণ বিষয়বস্তু cert_signer.pub

cert_signerসর্বজনীন কী কোন সার্ভার যার প্রকাশ্য হোস্ট কী দ্বারা স্বাক্ষরিত হয় বিশ্বাস করবে না cert_signerব্যক্তিগত কী।

যদিও এটির জন্য ক্লায়েন্টের পক্ষে এক-সময়ের কনফিগারেশন প্রয়োজন, আপনি একাধিক সার্ভারগুলিতে বিশ্বাস রাখতে পারেন, এমনগুলি সহ যা এখনও সরবরাহ করা হয়নি (যতক্ষণ আপনি প্রতিটি সার্ভারে স্বাক্ষর করেন, ততক্ষণ)।

আরও তথ্যের জন্য এই উইকি পৃষ্ঠাটি দেখুন ।

— রবার্ট চেন
সূত্র

2

সাধারণত আপনি যখন প্রায়শই কীগুলি সংশোধন করেন তখন এই সমস্যাটি দেখা দেয়। সার্ভারের ভিত্তিতে আপনি সার্ভারে তৈরি এবং আটকানো নতুন কী আপডেট করতে কিছুটা সময় নিতে পারে। সুতরাং কীটি উত্পন্ন করার পরে এবং সার্ভারে আটকানোর পরে, 3 থেকে 4 ঘন্টা অপেক্ষা করুন এবং তারপরে চেষ্টা করুন। সমস্যাটি সমাধান করা উচিত। এটা আমার সাথে ঘটেছিল।

— এম কে ..
সূত্র

2

এগুলি আপনার / etc / ssh / ssh_config এ যুক্ত করুন

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

— কেভিন এনগুইন
সূত্র

এখানে আরও বিস্তারিত শেলহ্যাকস.ডিজিয়েবল

— -এসএইচ-

0

এটি পূর্বনির্ধারার সমস্যা হোস্ট সার্ভারে এটি চালান

chmod -R 700 ~/.ssh

— রবার্ট এ
সূত্র

আপনি কি লোকেদের অনুমোদিত_কিগুলি এবং পাবলিক কীগুলির অনুমতিগুলি 644 থেকে 700 এ পরিবর্তন করতে বলছেন? এবং প্রাইভেট কী 600 থেকে 700?

— নুরেটিন

0

আমারও একই ত্রুটি ছিল এবং আমি এদিকে দৃষ্টি আকর্ষণ করতে চেয়েছিলাম - যেমনটি আমার সাথে ঘটেছিল - আপনার হয়তো ভুল সুযোগও থাকতে পারে।
আপনি .sshনিয়মিত বা rootব্যবহারকারী হিসাবে আপনার ডিরেক্টরিটি সেট আপ করেছেন এবং আপনাকে সঠিক ব্যবহারকারী হতে হবে। যখন এই ত্রুটিটি উপস্থিত হয়েছিল, আমি ছিলাম rootতবে আমি .sshনিয়মিত ব্যবহারকারী হিসাবে কনফিগার করেছি । প্রস্থানটি rootএটি স্থির করেছে।

— Lavair
সূত্র

-3

আমি নীচে লিখিত ত্রুটিটি দেয় এমন সমস্যাটি সমাধান করি:
ত্রুটি:
হোস্ট 'XXX.XXX.XXX' এর সত্যতা প্রতিষ্ঠিত করা যায় না।
আরএসএ কী আঙুলের ছাপ 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89

সমাধান:
1. যে কোনও ওপেনএসএইচ সরঞ্জাম ইনস্টল করুন।
কমান্ড এসএসএস রান করুন
3.. এটি আপনাকে এই হোস্টের মতো করতে চাইবে। হ্যাঁ গ্রহণ করুন।
৪) এই হোস্টটি পরিচিত হোস্ট তালিকায় যুক্ত করবে।
৫. এখন আপনি এই হোস্টের সাথে সংযোগ করতে সক্ষম হন।

এই সমাধানটি এখন কাজ করছে ......

— রাকেশ কুমার গার্গ
সূত্র

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

— মাস্টারএএম

যদি এটি তার পক্ষে কাজ করে তবে এটি অন্যের পক্ষে কাজ করে। আসলে দরকারী এমন কোনও কিছুকে

— আটকানোর

"ssh" চালানো কাজ করছে না। এটি বিকল্পগুলির ব্যবহারের জন্য প্রদর্শিত হচ্ছে: ssh [..] [..] [..] [ব্যবহারকারী @] হোস্টনাম [কমান্ড]

— পি সতীশ প্যাট্রো