ssh সংযোগটি শুরু করার জন্য চিরকাল লাগে, "প্রতিশ্রুতি: নেটওয়ার্ক" এ আটকে

44

Ssh ব্যবহার করে আমার একটি সার্ভারের সংযোগ শুরু হতে 20 সেকেন্ডের বেশি সময় নেয়।

এটি ল্যান বা ডাব্লিউএএন শর্তের সাথে সম্পর্কিত নয়, যেহেতু নিজের সাথে সংযোগটি একই লাগে (ssh লোকালহোস্ট)। সংযোগ অবশেষে প্রতিষ্ঠিত হওয়ার পরে, সার্ভারের সাথে ইন্টারঅ্যাক্ট করা খুব দ্রুত।

-Vvv ব্যবহার করে দেখা যায় যে "অঙ্গীকার: নেটওয়ার্ক" বলার পরে সংযোগ আটকে গেছে। এই মুহুর্তে, প্রমাণীকরণ (এখানে কী ব্যবহার করে) ইতিমধ্যে এখানে দৃশ্যমান হিসাবে সম্পন্ন হয়েছে:

...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network

(... এখানে 15 থেকে 25 সেকেন্ডের জন্য আটকে আছে ...)

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

সার্ভারটি উবুন্টু 16.04। এটি ইতিমধ্যে আমার সাথে অন্য সার্ভারের সাথে ঘটেছিল (এটি ছিল উবুন্টু 12.04), স্নায়ু সমাধানটি খুঁজে পেয়েছিল এবং সমস্যাটি কিছুক্ষণ পরে অদৃশ্য হয়ে গেল ...

sshd_config উবুন্টু প্রদত্ত ডিফল্ট।

এখন পর্যন্ত আমি চেষ্টা করেছি:

-o GSSAPIAuthentication = ssh কমান্ড ব্যবহার করে না
একটি কী এর পরিবর্তে পাসওয়ার্ড ব্যবহার করা
sshd_config এ হ্যাঁর পরিবর্তে UsePrivilegeSeparation ব্যবহার করুন

ssh

— এম-জ্যাক
সূত্র

1

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

— এরিক রেনোফ

আসলে না: ডিফল্টরূপে UseDNS sshd_config এ সংজ্ঞায়িত করা হয় নি এবং ম্যান পৃষ্ঠাটি বলে যে এই বিকল্পটি ডিফল্টরূপে "না" no

— এম-জ্যাক

3

কিছু গুগলিং পরামর্শ দেয় এটি রিবুট না করে সিস্টেমেড আপডেট করার কারণে ঘটতে পারে। এবং 12 জুলাই জেনিয়ালের জন্য একটি সিস্টেমড আপডেট ছিল । systemctl restart systemd-logindকেবলমাত্র আমার জন্য অল্প সময়ের জন্য সমস্যার সমাধান করে।

— ইভান কোজিক

বা যদি আপনি pam_systemd(sshd:session): Failed to create session: Connection timed outএকটি উত্তরে উল্লিখিত হিসাবে দেখছেন তবে এটি হতে পারে github.com/systemd/systemd/issues/2925

— ইভান কোজিক

একটি আপডেটের পরে আমি এই সমস্যাটি এখানে এসেছি এবং @ ইভানকোজিকের পরামর্শটি সমস্যাটি স্থির করেছে - যেমন সিস্টেমটেক্ট রিস্টার্ট সিস্টেমড-লগইনড - তাই এর জন্য ধন্যবাদ।

— পল এম

43

এটি সম্ভবত D-Busএবং সাথে একটি সমস্যা systemd। যদি dbusকোনও কারণে পরিষেবাটি পুনরায় চালু করা হয় তবে আপনাকে পুনরায় চালু করতে হবে systemd-logind।

Ssh ডিমন লগটি (উবুন্টুতে এটি হওয়া উচিত /var/log/auth.log) খোলার মাধ্যমে আপনি এটি পরীক্ষা করতে পারেন এবং পরীক্ষা করতে পারেন যে এটিতে এই লাইনগুলি রয়েছে:

sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out

যদি হ্যাঁ, কেবল systemd-logindপরিষেবাটি পুনরায় চালু করুন :

systemctl restart systemd-logind

সেন্টোস on এ আমার একই সমস্যা ছিল, কারণ messagebusপুনরায় চালু হয়েছিল (যা D-Busপরিষেবাগুলিকে সেন্টোজে ডাকা হয়)।

— স্ট্রাহেঞ্জা কস্টুডিক
সূত্র

আমি সিস্টেমেড-লগিন্ড পুনরায় চালু করার চেষ্টা করেছি তবে কিছুক্ষণ পরে এটি বলে যে পলিসিকিট ডিমন বাস থেকে সংযোগ বিচ্ছিন্ন হয়ে গেছে। আমরা আর কোনও নিবন্ধিত প্রমাণীকরণ এজেন্ট নই। Systemd-logind.service এর জন্য কাজ ব্যর্থ হয়েছিল কারণ একটি সময়সীমা অতিক্রম করা হয়েছিল। বিশদগুলির জন্য "systemctl স্থিতি systemd-logind.service" এবং "জার্নাল্টেল-এক্স" দেখুন।

— কুন রেন

@ কুনরেন আপনাকে সম্ভবত polkitপরিষেবাটি পুনরায় চালু করতে হবে systemctl restart polkit।

— স্ট্রাহিনজা কাস্টুডিক

16

উত্তর খুঁজে পেয়েছি:

ইউএসপিএএম sshd_config ফাইলে হ্যাঁ থেকে না থেকে পরিবর্তন করা হয়েছে

Ssh পরিষেবাটি পুনরায় আরম্ভ করার পরে সংযোগটি এখন সার্ভারের সাথে তাত্ক্ষণিক। এই সার্ভারে, পিএএম ldap এর সাথে যুক্ত, তাই সম্ভবত এটি কারণ, এমনকি যদি আমি এখানে সার্ভারে ঘোষিত কোনও ব্যবহারকারীর সাথে সংযুক্ত হয়ে থাকি, তবে কোনও এলডিএপি নেই।

ঠিক আছে, এটি সমস্যাটিকে বাইপাস করার আরও একটি উপায়, আসলেই কোনও সমাধান নয় ... আমার অন্যান্য সার্ভারগুলিও একইভাবে সেট আপ করেছে যাতে এই সমস্যাটি নেই।

আশা করি এটি কারও সহায়ক হতে পারে ...

— এম-জ্যাক
সূত্র

1

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

— এম-জ্যাক

4

এটি আসলেই ভাল ধারণা নয়।

— জাকুজে

1

কেন ?? কোন বিকল্প?

— এম-জ্যাক

8

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

— জাকুজে

এসএসএইচ অ্যাক্সেসের জন্য সক্ষম হওয়া খুব সাধারণভাবে অব্যবহৃত পিএএম মডিউলটি রেখে যাওয়া একটি সুরক্ষা গর্ত। সুরক্ষা দৃষ্টিকোণ থেকে এসএসএইচের মতো সমালোচনামূলক পরিষেবাদিতে অ্যাক্সেস সীমাবদ্ধ করা অন্য যে কোনও পরিষেবার জন্যও বরাবরই ভাল ধারণা। আপনি যখন চান পিএএম মডিউলটি এসএসএইচে সহযোগিতা করবে? উদাহরণস্বরূপ: যখন আপনি উইনবাইন্ডের মাধ্যমে সক্রিয় ডিরেক্টরিতে এটি সংহত করার প্রয়োজন হয়, যখন আপনাকে গুগল টোকেন ইত্যাদির সাথে দুটি ফ্যাক্টর লেখক প্রয়োজন হয়। অন্যান্য ক্ষেত্রে (পাসডাব্লুড এবং ছায়া ব্যবহার করার সময়) এটি বন্ধ করা পুরোপুরি নিরাপদ। প্যামের প্রতিটি ব্যবহারকারী এটি দেখতে পাবেন: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pam

— মিশাল সোকলোভস্কি

10

এটি আমার ফেডোরা 25 টি সার্ভারের দুটিতে ঘটেছিল এবং এসএসএইচ লগইন প্রচেষ্টার ব্যর্থতার কারণে হয়েছিল।

(ব্যবহার GSSAPIAuthentication=noএবং UseDNS=no, বা পুনরায় চালু করার সাধারণ পরামর্শগুলি systemd-logindকোনও পার্থক্য তৈরি করে না))

এই সার্ভারগুলিতে /etc/pam.d/postloginরয়েছে:

session     optional      pam_lastlog.so silent noupdate showfailed

ম্যান পেজটি pam_lastlogব্যাখ্যা করে যে showfailedবিকল্পটি করবে:

ব্যর্থ লগইন প্রচেষ্টা এবং বিটিএমপি থেকে শেষ ব্যর্থ প্রচেষ্টার তারিখ প্রদর্শন করুন।

এই সার্ভারগুলিতে /var/log/btmpঅনেকগুলি ব্যর্থ লগইন চেষ্টার কারণে ফাইলগুলি প্রচুর ছিল। btmpলগ ফাইল পারেন আবর্তিত হচ্ছে করা হয় নি।

logrotateভবিষ্যতে লগ ফাইলগুলি ঘোরানো হবে তা নিশ্চিত করার জন্য আমি প্যাকেজটি ইনস্টল করেছি । (ফেডোরায়, কনফিগারেশন যা জাহাজের সাহায্যে logrotateঘূর্ণন পরিচালনা করে /var/log/btmp।)

আমি প্রচুর btmpলগ ফাইলগুলি মুছে ফেলেছি ; আমি এটি করার সাথে সাথে সার্ভারের সাথে সংযোগ করা আবার তাত্ক্ষণিক হয়ে গেল।

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

এটি আমার সমস্যার সমাধান! ধন্যবাদ. চমৎকার ধরা. এসএসএইচ 5-10 সেকেন্ড সময় নিচ্ছিল এবং এখন এটি চোখের পলকের চেয়ে কম। এটি এমন একটি ভিএম-এ রয়েছে যা আমি বছরের পর বছর ধরে সর্বজনীন ইন্টারনেটের সাথে সংযুক্ত করেছি। এর ফায়ারওয়াল নিয়মগুলি সম্ভবত কিছুটা আরও ভালভাবে সুর করা যেতে পারে, এখন আমি এটির বিষয়ে ভাবছি। অন্যদের কাছে, আমি যা করেছি sudo truncate -s 0 /var/log/btmpএটিগুলি : - খনিটি আকারের 2.7G ছিল।

— কার্ল বেনেট

2

আমার ক্ষেত্রে কারণটি ক্র্যাশড আরএসপ্লোগড। আমি এটি খুঁজে পেয়েছি কারণ / var / log / syslog বা /var/log/mail.log- এ আর কোনও লগ-বার্তা নেই

সুতরাং service rsyslog restartআমাদের জন্য সমস্যা সমাধান করুন।

— randomcontrol
সূত্র

আমাদের চলমান CentOS 6.10 এর একটি সার্ভারে একই কারণ। আরএসস্লগ পুনরায় আরম্ভ করার জন্য এটি যত্ন নেওয়া হয়েছিল। কথাটি হ'ল, এটি মারা যায় নি। এটি চলছিল, তবে দৃশ্যত কার্যকর কিছু করছে না।

— উটাহ জারহেড

1

আমার জন্য এই সমস্যাটি বৃহত (শত শত এমবি) btmpফাইলের কারণে হয়। এই ফাইল লগইন প্রচেষ্টা প্রচেষ্টা। লোকেরা যখন আপনার পাসওয়ার্ডটি জোর করে চাপিয়ে দেওয়ার চেষ্টা করছে তখন এই ফাইলটি বড় হতে পারে এবং "pledge: network"পর্যায়ে বিলম্ব হতে পারে ।

লগ ফাইল সাফ করার চেষ্টা করুন

echo "" > /var/log/btmp

এবং দেখুন এটি সাহায্য করে কিনা।

— মারেক নাগি
সূত্র

3

এটি আরও অনেক ব্যাখ্যা প্রয়োজন। প্রারম্ভিকদের জন্য, আপনি কেন এটি সহায়ক বলে মনে করেন?

— সোভেন

টিপ: কেবল টাইপিং :> /var/log/btmpএকই বিটিডব্লু করে।

— মারিয়াস

1

আমার জন্য সমাধান যোগ করা হয়েছিল

UseDNS no

থেকে /etc/ssh/sshd_configএবং তারপর অবশ্যই service ssh restart(আমাদের ডেবিয়ান / জেসি সার্ভারে)। আর কিছু না...

আগে :

ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 13.440 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 20.990 total
ssh git@git.*****.de true  0.03s user 0.02s system 0% cpu 31.114 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 25.898 total

পরে :

ssh git@git.*****.de true  0.03s user 0.02s system 5% cpu 0.832 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.523 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.574 total

— tamasgal
সূত্র

না, যুক্ত UseDNS noকরা সম্পূর্ণ আলাদা সমস্যার সমাধান।

— ক্যাস্পারড

@ ক্যাস্পারড এটি কিছু বিবেচনা করে না। আমার ক্ষেত্রে আমার একই লক্ষণগুলি ছিল (সংক্ষেপে: "প্রতিশ্রুতি: নেটওয়ার্ক" বলার পরে আটকে) এবং অবশেষে এটিই সহায়তা করেছিল, তাই এটি অন্তত একটি খুব অনুরূপ সমস্যার সমাধান এবং আমি নিশ্চিত যে এটি একটি বা একটিকে সহায়তা করবে অন্য কিছু সময়ে।

— তামাসল

এখানেও একইভাবে, সংযোগ চলাকালীন দুটি হ্যাং, একের পরে sign_and_send_pubkey, আরও দীর্ঘ পরে pledge: network। শুধুমাত্র যোগ করার পদ্ধতি UseDNS noপরবর্তী সঙ্গে service ssh restartএখানে একটি পুরানো উবুন্টু 14.04.5 LTS ইনস্টলেশনের উপর সমস্যার সমাধান হয়নি।

— হাউন্ড

0

আমি আমার ডিবাগ প্রতিক্রিয়াটিতে নিম্নলিখিত লাইনটি লক্ষ্য করেছি:

Control socket connect(/var/lib/jenkins/.ssh/USER@HOST:22): Permission denied

কোন ফাইল root:rootযখন আমি থাকাকালীন মালিকানাধীন ছিল jenkins। এই ফাইলটি সরানো আমার সমস্যার সমাধান করেছে।

— Ambidex
সূত্র