গিট বলেছেন "সতর্কতা: স্থায়ীভাবে পরিচিত হোস্টগুলির তালিকায় যুক্ত করা হয়েছে"

Question

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

সতর্কতা: স্থায়ীভাবে পরিচিত হোস্টগুলির তালিকায় '...' (আরএসএ) যুক্ত হয়েছে।

আমি কীভাবে এই বিরক্তিকর বার্তাটি প্রদর্শন করা থেকে আটকাতে পারি? এটি কেবল একটি বিরক্তি — সবকিছু সঠিকভাবে কাজ করে।

Comments

আপনি কি সত্যই প্রতিবার বোঝাতে চান ? এটি কি আপনাকে ফর্মের একটি প্রম্পট দিচ্ছে The authenticity of host '...' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)?, বা আপনি তা চাপা দিয়েছেন? যদি তা হয় তবে প্রতিবারেই কি একই আঙুলের ছাপ রয়েছে? যদি তা না হয় তবে তা সত্যিই ভীতিজনক । কম ভীতিজনক বিকল্পটি হ'ল কোনওভাবে এটি হোস্ট ফাইলে লিখতে আসলে পরিচালনা করছে না, তাই এটি প্রতিবার চেষ্টা করে। একবার দেখুন ~/.ssh/known_hosts?

— ক্যাসাবেল

হ্যাঁ. <i> প্রতি </ i> সময়। তবে, "আপনি কি নিশ্চিত ..." বার্তাটি দেখতে পাচ্ছি না - সম্ভবত আমি এটি চাপা দিয়েছি।

— ডোনাল্ড টেলর

হোস্টটি কি তালিকাভুক্ত ~/.ssh/known_hosts? (এটি 5000 বার তালিকাভুক্ত?) কি ~/.ssh/configকোনও কিছুর উপস্থিতি রয়েছে / রয়েছে (বিশেষত একটি মান StrictHostKeyChecking)?

— ক্যাসাবেল

হোস্টটি সেই ফাইলে একবার তালিকাভুক্ত হয় এবং এটিই কেবল প্রবেশ।

— ডোনাল্ড টেইলর

আমি অনুমান করছি যে আপনার known_hostsফাইলের সামগ্রীগুলি খারাপ are এটি এক ভয়ঙ্কর দীর্ঘ লাইনে হোস্ট কী হওয়া উচিত। যদি আপনার কেবল সেখানে হোস্টের নাম থাকে (উদাহরণস্বরূপ) এটি কাজ করবে না। আমি আপনাকে প্রস্তাব দিচ্ছি যে আপনি এই ফাইলটি সরান (যদি সত্যই এটিতে এই একক হোস্টের জন্য তথ্য রয়েছে) এবং আপনি পরবর্তী বার সংযোগ করার সময় এসএসএইচকে এটি তৈরি করার অনুমতি দিন। এটি পরে নীরব হওয়া উচিত।

— ট্রিপলি

Answer 1

সমাধান: একটি ~/.ssh/configফাইল তৈরি করুন এবং লাইনটি সন্নিবেশ করুন:

UserKnownHostsFile ~/.ssh/known_hosts

পরের বার আপনি গিথুব অ্যাক্সেস করার পরে আপনি বার্তাটি দেখতে পাবেন, কিন্তু এর পরে আপনি আর দেখতে পাবেন না কারণ হোস্টটি known_hostsফাইলে যুক্ত হয়েছে । এটি কেবল লগ বার্তাটি গোপন করার চেয়ে সমস্যাটি স্থির করে।

এই সমস্যাটি আমাকে বেশ কিছুদিন ধরে তল্লাশি করছিল। সমস্যা দেখা দেয় কারণ উইন্ডোজের জন্য সংকলিত ওপেনএসএইচ ক্লায়েন্টটি ज्ञात_হোস্ট ফাইলটি চেক করে না~/.ssh/known_hosts

ssh -vvvvvvvvvvvvvvvvv [e-mail]

debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.

Comments

হ্যাঁ, আমি সতর্কবাণী বা ত্রুটিগুলি দমনকে কোনও সমস্যার উপযুক্ত সমাধান হিসাবে বিবেচনা করি না। ;)

— যেরেমিয়া গৌডি

সম্প্রতি, আমি আমার উবুন্টু মেশিনে একই সমস্যার মুখোমুখি হয়েছি। ~/.ssh/id_rsaসার্ভারের সাথে সংযোগ স্থাপনের জন্য আমি আলাদা (আমার ডিফল্ট থেকে ) কী ব্যবহার করার পরে এটি এভাবে আচরণ শুরু করে started @ জেরেমিয়া গৌডি যেমন উল্লেখ করেছেন, আমার আছে debug3: load_hostkeys: loading entries for host "172.16.3.101" from file "/dev/null"। /dev/nullআমি কী পরিবর্তন করার পরে এসএসএইচ কেন পরিচিত_হোস্ট হিসাবে ব্যবহার শুরু করে ?

— এম-রিচ

দুর্দান্ত কাজ! অবশেষে বোকা সতর্কতা বন্ধ হয়ে গেল। উইন্ডোজে বিটিডব্লিউ, ~ইন ~/.ssh/configহ'ল ব্যবহারকারীর হোম ফোল্ডার। এটিকে সহজেই খোলার জন্য, উইন-আর টিপুন , এন্টারটি cmd লিখুন । কমান্ড প্রম্পটটি ইতিমধ্যে আপনার হোম ফোল্ডারে খোলা উচিত। উইন্ডোজ এক্সপ্লোরার-এ ফোল্ডারটি খুলতে এন্টার লিখুন এবং তারপরে এন্টার টাইপ cd .ssh করুন । তারপরে আপনি নোটপ্যাডে কনফিগার ফাইলটি তৈরি করতে পারবেন ( সংরক্ষণের সময়। Txt এক্সটেনশন নয়)। (প্রো ব্যবহারকারীরা কমান্ড প্রম্পটে নিজেই একটি নতুন ফাইলে প্রতিধ্বনি করতে পারবেন )। দুবার (যেমন ) রিমোট জড়িত একটি গিট কমান্ড চালান , এবং আপনার কাজ শেষ। start . ;)git fetch

— ADTC

আপনার কাছে কেন ssh এর জন্য 20 ভি আছে?

— বুবাকাযৌবা

@ বুবকাজৌবা যত বেশি ভি এর লগ পাবেন তত লম্বা লম্বা হয়ে যায়, তার জন্য ডকগুলি পরীক্ষা করে দেখুন। তিনটি যথেষ্ট হবে, বিশটি একটি ওভারকিল: ডি

— পেটর মেনেক

Answer 2

আপনার ssh কনফিগারেশন ফাইলটিতে নিম্নলিখিত লাইনটি যুক্ত করুন (OME HOME / .ssh / config):

LogLevel=quiet

কমান্ড লাইন থেকে ssh চালানো হলে কমান্ড স্ট্রিংয়ে নিম্নলিখিত বিকল্পটি যুক্ত করুন:

-o LogLevel=quiet

উদাহরণস্বরূপ, নিম্নলিখিত নিবন্ধগুলি mach.example.org এ ইনস্টল করা gcc সংস্করণটি মুদ্রণ করে (এবং কোনও সতর্কতা নেই):

ssh -o UserKnownHostsFile=/dev/null \
    -o StrictHostKeyChecking=no \
    -o LogLevel=quiet \
    -i identity_file \
    machine.example.org \
    gcc -dumpversion

Comments

"কনফিগারেশন" ফাইলটিতে "লগলিভেল = শান্ত" যুক্ত করার কাজ হয়েছে। ধন্যবাদ.

— ডোনাল্ড টেলর

সুরক্ষা বজায় রাখতে, "হোস্ট" বিভাগের মধ্যে "লগইভেল = শান্ত" রাখা ভাল হবে be

— জো

LogLevel=quietএটি একটি খারাপ ধারণা, তিনি সমস্ত ত্রুটিগুলি প্রদর্শিত হতে চান, তিনি কেবল এই নির্দিষ্ট অসুস্থ ত্রুটিটি এড়াতে চান want সম্ভবত তিনি ফাইলটি /dev/nullহিসাবে ব্যবহার করার জন্য এসএসিকে প্রতারণা করেছিলেন কারণ known_hostsসম্ভবত তিনি known_hostsফিঙ্গারপ্রিন্ট চেকিং বন্ধ করতে চেয়েছিলেন , কিন্তু পারেননি, কারণ এসএসএস ওভারলর্ডরা তাকে অনুমতি দেয়নি।

— এলাজার লাইবোভিচ

সংযোগটি loglevel=errorবন্ধ হয়ে গেলে @ বুকজর এখনও "সার্ভারের সাথে সংযোগ স্থাপন করে" প্রদর্শন করেন যা স্ক্রিপ্টিংয়ের জন্য সত্যই বিরক্তিকর।

— গাস

সমস্যাটিকে প্রকৃতপক্ষে সমাধান না করায় আমি এটিকে হ্রাস করেছি। এটি কেবল এটি লুকায়।

— আলাবৌদি

Answer 3

সেট LogLevelথেকে ERROR(না QUIET) এ ~/.ssh/configফাইল এই ত্রুটিগুলি দেখা এড়াতে হবে:

Host *
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null
   LogLevel ERROR

Comments

এটি আমার ক্ষেত্রে সবচেয়ে ভাল কাজ করেছে - অথবা আপনি কমান্ড লাইনে "-oLogLevel = ERROR" নির্দিষ্ট করতে পারেন

— ব্র্যাড

Answer 4

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

Comments

তবে আমি এটির সাথে প্রতিদিন 10-15 বার সংযোগ করি এবং এখনও আমি এই সতর্কতা পাই receive

— ডোনাল্ড টেলর

@JackB। তাকান ~/.ssh/known_hostsএবং যদি আপনার হোস্ট সেখানে দেখতে।

— বোরিলিড

কী কোনও কারণে চাবি পরিবর্তন হচ্ছে? Ssh দ্বারা আউটপুট হওয়া ফিঙ্গারপ্রিন্ট বনাম ফাইলে ফিঙ্গারপ্রিন্ট পরীক্ষা করুন। এছাড়াও, আপনার .ssh ডিরেক্টরিটির মোডটি 0700 এ সেট করা আছে?

— জেসন ক্যারিরো

@ জেসন কারেরিও, আমি একটি বড় ছেলে, আমি জানি যে আমার রকের ভিতরে কেউ এমআইটিএম আক্রমণকে টেনে তুলবে না, সুরক্ষা একটি ট্রেডঅফ, এবং আমি চাই নতুন কম্পিউটারগুলি সিএ পরিচালনা করার প্রয়োজন নেই, প্রেসারযুক্ত কী সহ বাক্সটি বাইরে বেরিয়ে কাজ করা উচিত বা ssh-keyscan।

— এলাজার লেইবোভিচ

Answer 5

সতর্কতা বার্তাগুলি দমন sshকরতে আপনি নিম্নলিখিত লাইনগুলি যুক্ত করতে পারেন ~/.ssh/config:

Host *
LogLevel error

এটি সতর্কতা অক্ষম করবে তবে ত্রুটি বার্তাগুলি নয়। যদি আপনি আরও সূক্ষ্ম নিয়ন্ত্রণ চান তবে আপনি অন্যান্য সেটিংসের মতো প্রতি হোস্ট ভিত্তিতে ~/.ssh/configকনফিগার LogLevelকরতে পারেন।

Answer 6

এর মূল অর্থ হ'ল হোস্টের চাবির জন্য পরিবর্তন রয়েছে ~/.ssh/known_hostsএবং এটি স্বয়ংক্রিয়ভাবে এটি আপডেট হবে না। সুতরাং প্রতিবার আপনি এই সতর্কতা বার্তাটি পান।

পুনরায় তৈরি ভার্চুয়াল মেশিনে সংযোগের জন্য এটি প্রায়শই ঘটে যা একই আইপি ঠিকানার সাথে কীটি পরিবর্তন করে

সমাধান

আপনার যদি কেবল একটি প্রবেশ থাকে, তবে আপনি এটি মুছতে পারেন ~/.ssh/known_hosts ফাইলটি এবং প্রথম সংযোগের পরে, কীটি উপস্থিত থাকবে এবং এর পরে কোনও সতর্কতা বার্তা নেই।

আপনার যদি একাধিক এন্ট্রি থাকে তবে অপসারণ করতে আপনি নীচের কমান্ডটি ব্যবহার করতে পারেন

$ ssh-keygen -R <hostname>

এটি আমার জন্য দারুণ কাজ করছে

Answer 7

আপনি যদি গিটহাব থেকে কোনও সংগ্রহশালা ব্যবহার করছেন , সম্পূর্ণরূপে এই সমস্যাটিকে পাশ কাটাতে, পরিবর্তে ইউআরএল এর এইচটিটিপিএস সংস্করণ ব্যবহার করে বিবেচনা করুন :

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

Comments

দ্রষ্টব্য: আপনি যদি ব্যক্তিগত কী প্রমাণীকরণ ব্যবহার করেন তবে আপনি HTTP (এস) ব্যবহার করতে পারবেন না।

— কিওয়ার্টজগুয়ে

Answer 8

আমার একই প্রশ্ন রয়েছে এবং আমি খুঁজে পেলাম .sshআমার মধ্যে কোনও ফাইল নেই ~। সুতরাং আমি কেবল পথের .sshঅধীনে ডিরেক্টরি তৈরি করেছি ~এবং সমস্যাটি সমাধান হয়েছে।

Answer 9

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

https://help.github.com/articles/checking-for-existing-ssh-keys/ https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it- টু--SSH-এজেন্ট /

Answer 10

Ssh কী যুক্ত করুন

ssh-keygen -t rsa -b 4096 -C "[e-mail]"

eval "$(ssh-agent -s)"

ssh-add ~/.ssh/bitbucket_rsa

ক্রেট কনফিগার ফাইল

crate ~/.ssh/config

লাইন নীচে যুক্ত করুন।

UserKnownHostsFile ~/.ssh/known_hosts

তারপরে পাব কী যুক্ত করুন এবং আপনার সংগ্রহস্থলটি ক্লোন করুন ... হয়ে গেল .....

Answer 11

লিনাক্স / সেন্ট ওএস ভিএম-তে আমি একই ত্রুটির মুখোমুখি হয়েছিলাম এবং এটি কারণ আইপি পুনরায় চালু হওয়ার পরে পরিবর্তন হয়েছিল। এই সমস্যাটি সরাতে, আমি নেটওয়ার্কে একটি স্ট্যাটিক আইপি সংজ্ঞায়িত করেছি এবং / ইত্যাদি / হোস্ট ফাইলটিতে এন্ট্রি যুক্ত করেছি। স্ট্যাটিক আইপির জন্য কিছুটা উচ্চতর পরিসরের মান উল্লেখ করুন। উদাহরণস্বরূপ যদি আপনার বর্তমান আইপি (ipconfig / ifconfig) 192.168.0.102 হয়, পরের বার পুনরায় চালু করার পরে এটি 192.168.0.103 হয়ে যেতে পারে। সুতরাং আইপিভি 4 সেটিংসে আপনার স্থির আইপিটি 192.168.0.181 হিসাবে সংজ্ঞায়িত করুন যা কৌশলটি করা উচিত।

Comments

কীওয়ার্ডগুলি হাইলাইট করার চেষ্টা করুন এবং ফর্ম্যাটটি দিয়ে পরিষ্কার করুন এটি অন্যের কাছে আপনার উত্তর পৌঁছাতে সহায়তা করবে

— Agilanbu

Answer 12

আমার ক্ষেত্রে, এটি কারণ সার্ভার সেট আপ করা প্রশাসকরা এই বিকল্পগুলিতে সেট করে ~/.ssh/config

StrictHostKeyChecking no
UserKnownHostsFile /dev/null

যা বেশিরভাগ ক্ষেত্রে ব্যবহার না করে ভাল কাজ করেছে ~/.ssh/known_hosts ফাইলটি । কিন্তু এন্টারপ্রাইজ গিটল্যাব রেপোর জন্য, প্রতিবার এটি "সতর্কতা: স্থায়ীভাবে ... যুক্ত হোস্টের তালিকায় যুক্ত হয়েছে" gave

আমার সমাধানটি ছিল UserKnownHostsFile /dev/nullলাইনটি মন্তব্য করা , যা তৈরির অনুমতি দিয়েছে~/.ssh/known_hosts । তারপরে এটি আর কোনও সতর্কতা দেয় নি।

আপনার একটিতে পুরানো / অবৈধ এন্ট্রি থাকতে পারে known_hosts।

# find entry in ~/.ssh/known_hosts
ssh-keygen -F <hostname>

# delete entry in ~/.ssh/known_hosts
ssh-keygen -R <hostname>

Answer 13

অবিরত ডাউনভোটের কারণে আমি আমার সমাধানটি নিচে নিচ্ছি।
এটি আসলে এসএসএইচ ক্লায়েন্টের উত্স কোডটি হ্যাক না করেই সেরা সমাধান ছিল।
যদি কেউ আগ্রহী হন তবে সম্পাদনার ইতিহাস পরীক্ষা করুন।