सफल लॉगिन के बाद लिनक्स समापन कनेक्शन


23

मैं डेबियन 5.2.2 के साथ एक सर्वर पर काम कर रहा हूं। बमुश्किल लिनक्स के साथ कोई प्रशासनिक ज्ञान होने पर, मुझे लगता है कि मैंने कुछ गड़बड़ कर दी है। मैंने एप-गेट अपडेट और एप-गेट अपग्रेड का उपयोग किया, ताकि सब कुछ अप टू डेट हो सके और फिर मैंने अपाचे, पीएचपी और मायएसक्यूएल को डाउनलोड और इंस्टॉल किया। वे उपकरण ठीक काम करने लगते हैं, लेकिन अब मैं स्थानीय कंसोल के माध्यम से सर्वर EXCEPT में भी प्रवेश नहीं कर सकता। अगर मैं GUI के माध्यम से लॉगिन करने का प्रयास करता हूं या यदि मैं ssh, scp, या किसी अन्य चीज के माध्यम से दूरस्थ रूप से लॉगिन करने का प्रयास करता हूं, तो मुझे सफल लॉगिन पर डिस्कनेक्ट किए गए IMMEDIATELY मिलते हैं। दूसरे शब्दों में, इसे प्रारंभिक कनेक्शन के साथ कोई समस्या नहीं है, लेकिन जब मैं सही उपयोगकर्ता नाम और पासवर्ड (रूट या किसी उपयोगकर्ता के लिए) डालता हूं, तो मैं डिस्कनेक्ट हो जाता हूं। GUI के साथ, स्क्रीन एक सेकंड के लिए काली हो जाती है और फिर मुझे लॉगिन प्रांप्ट पर वापस डाल देती है। Ssh के साथ, मुझे "[सर्वर] कनेक्शन बंद है।"

किसी भी मदद की सराहना की है, और अगर वहाँ किसी भी तरह से मैं और अधिक जानकारी दे सकता है, कृपया मुझे बताएं। आपके समय के लिए शुक्रिया।

संपादन:

- कोई भी उपयोगकर्ता स्थानीय कंसोल पर लॉगिन कर सकता है

- इस समय मेरे पास मशीन तक स्थानीय पहुंच नहीं है, इसलिए मैं अभी जो कर सकता हूं वह सब है। मेरे पासवर्ड दर्ज करने के बाद यहाँ ssh -vvv [सर्वर] का आउटपुट है :

Linux xxxxxxx.com 2.6.26.8+20091222+1056-debhawk-5.2.2-custom #1 SMP PREEMPT Tue Dec 22 10:58:57 EST 2009 i686

Last login: Mon Apr 30 14:48:07 2012 from xxxxxxx.com
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)

debug3: channel 0: close_fds r -1 w -1 e 6
Connection to xxx.x.xx.xx closed.
debug1: Transferred: stdin 0, stdout 0, stderr 35 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3845.3
debug1: Exit status 254

5
लिनक्स एक कर्नेल है, ऑपरेटिंग सिस्टम नहीं है। कोई कर्नेल संस्करण 5.2.2 नहीं है, इसलिए आप किस वितरण का उपयोग कर रहे हैं?
स्वेन

2
कंसोल पर लॉग ऑन करें /var/log/messagesऔर /car/log/secureजब आप दूरस्थ रूप से लॉग ऑन करने का प्रयास करते हैं तो लॉग और चेक करें । लॉग ऑन करने का प्रयास करें ssh -vvv <servername>ताकि आप देख सकें कि क्या गलत हो रहा है। dmesgआउटपुट उपयोगी हो सकता है लेकिन आपको केवल प्रासंगिक भागों को ट्रिम और पोस्ट करने की आवश्यकता होगी। क्या आप किसी भी उपयोगकर्ता खाते के साथ स्थानीय कंसोल या केवल रूट पर लॉग इन कर सकते हैं? क्या SSH डेमॉन चल रहा है ( ps auxwww|grep ssh)?
ब्रैम

जवाबों:


24

ऐसे ही कुछ पदों के बारे में सुझाव दे रहे हैं कि शेल पथ के लिए गलत सेटिंग्स के कारण शेल खोलना समस्या हो सकती है /etc/passwd

यह जाँचने के लिए, निर्धारित करें कि आपका उपयोगकर्ता शेल पथ मौजूद है और निष्पादन योग्य है;

# cat /etc/passwd | grep tomh
tomh:x:1000:1000:Tom H:/home/tomh:/bin/bash <-- check this exists

चेक शेल मौजूद है:

# file /bin/bash
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped

यह भी देखें कि शेल /sbin/nologinया तो सेट नहीं है या /bin/false, जो एक सफल प्रमाणीकरण के साथ लॉगिन को भी ब्लॉक करेगा।

http://www.linuxforums.org/forum/ubuntu-linux/173779-solved-ssh-issue.html
http://www.unix.com/hp-ux/169496-solved-ssh-debug1-exit-status -254-problem.html
http://www.mail-archive.com/seawolf-list@redhat.com/msg04460.html


यह वास्तव में मेरा मुद्दा था, एक ताजा सागविन इंस्टॉल के साथ, इंस्टॉल द्वारा बनाए गए उपयोगकर्ता के पास एक उपयोगकर्ता / बिन / गलत का रास्ता होगा। इसे बदलने के लिए / बिन / बैश मुद्दा तय किया। धन्यवाद!
मिच केंट

1
मेरे अनुभव में उपयोगकर्ता बनाने पर शेल निर्दिष्ट करना बुद्धिमान है। डिफॉल्ट सेटिंग डिस्टर्ब से डिस्टर्ब होती है।
मेटलग्विन

4

जब मुझे इस तरह की समस्या का सामना करना पड़ा, तब भी मेरे पास एक कनेक्शन खुला था / var / log / संदेश सामने आए:

pam_loginuid(sshd:session): Cannot open /proc/self/loginuid: Read-only file system

Vi /etc/init.d/ame का संपादन करने के तरीके / खरीद को बदलने की अनुमति दी गई थी, इसलिए त्रुटि रिबूट के बाद नहीं हुई।

मूल रूप से लाइनों

if [ ! -e "${CHROOT_PREFIX}/proc/meminfo" ]; then
mkdir -p “${CHROOT_PREFIX}/proc”
        mount -tproc -oro,nosuid,nodev,noexec proc ${CHROOT_PREFIX}/proc 2>/dev/null
fi;

में बदल गए थे

if [ ! -e "${CHROOT_PREFIX}/proc/meminfo" ]; then
mkdir -p “${CHROOT_PREFIX}/proc”
        mount –bind -o ro /proc “${CHROOT_PREFIX}/proc” 2>/dev/null
fi;

एक टिप जो मुझे http://www.compointsalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905 पर मिली


एसएफ में आपका स्वागत है। आप 4 स्थानों के साथ कोड को इंडेंट करके (या इसके चारों ओर बैकटिक्स का उपयोग करके) अपने उत्तर की शैली में सुधार कर सकते हैं।
.फिंक

सेंटोस 7 के बजाय सिस्टेम का उपयोग करने वाले CentOS 7 पर समकक्ष क्या होगा?
स्टीव जोर्गेनसन

4

मेरी समस्या लॉगिन उपयोगकर्ता नाम निर्देशिका में उपलब्ध नहीं थी /home। इसलिए यदि आपके पास 'testuser' नामक उपयोगकर्ता है, तो सुनिश्चित करें कि /home/testuserनिर्देशिका उपलब्ध है। /var/log/messagesफ़ाइल से सीखा है ।


/var/log/messages/auth.logपॉइंटर्स के लिए निश्चित रूप से जांचें । इसके अलावा एक फ़ाइल मुद्दा था
निक

3
debug3: channel 0: close_fds r -1 w -1 e 6
Connection to xxx.x.xx.xx closed.
debug1: Transferred: stdin 0, stdout 0, stderr 35 bytes in 0.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 3845.3
debug1: Exit status 254

अपने SSH सर्वर की sshd_configफ़ाइल में, निम्न पंक्ति जोड़ें:

UsePAM no

नीचे sshd_configमैं ओएस एक्स पर उपयोग कर रहा हूं। मैं इसे (एक डेबियन मशीन पर एक के बजाय) पोस्ट कर रहा हूं क्योंकि मैंने मैकपोर्ट (और डेबियन नहीं) का उपयोग करके ओएस एक्स पर एक ही समस्या का अनुभव किया।

AddressFamily any
ListenAddress 0.0.0.0
Port 1522

# The default requires explicit activation of protocol 1
Protocol 2

# HostKeys for protocol version 2
HostKey /opt/local/etc/ssh/ssh_host_ed25519_key
HostKey /opt/local/etc/ssh/ssh_host_ecdsa_key
HostKey /opt/local/etc/ssh/ssh_host_rsa_key
HostKey /opt/local/etc/ssh/ssh_host_dsa_key

# Ciphers and keying
#RekeyLimit default none

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# User Authentication

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
UsePAM no

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile  .ssh/authorized_keys

# Use sandbox on OS X
UsePrivilegeSeparation sandbox

# All user's environment
PermitUserEnvironment yes

# no default banner path
#Banner none

# override default of no subsystems
Subsystem   sftp    /opt/local/libexec/sftp-server

1
UsePAM = हां मेरी सेंटो 7 / i686 LXD छवि में समस्या है। एक बार 'नहीं' के लिए सेट, ssh लॉगिन फिर से काम करते हैं। हालाँकि, sshd_config में एक नोट है: "चेतावनी: 'UsePAM no' Red Hat Enterprise Linux में समर्थित नहीं है और इससे कई समस्याएं हो सकती हैं।" अगर किसी को पता है कि वास्तव में इसका क्या मतलब है, कृपया, कुछ प्रकाश डालें।
ILIV

जब मैंने UsePAM = नहीं को बदलने की कोशिश की, तो मुझे एक पासवर्ड दर्ज करने के लिए कहा गया, भले ही मुझे RSA कुंजी के साथ प्रमाणित करना चाहिए।
स्टीव जोर्गेनसन

2

यदि आप एलडीएपी का उपयोग कर रहे हैं, तो हर घटना की जगह:

pam_unix_*.so

/etc/pam.d/ में सभी फ़ाइलों में:

pam_unix.so

यह libpam-ldap पैकेज (उदाहरण pam.d फ़ाइलें) में एक बग है, देखें: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825

सुनिश्चित करें कि सिस्टम ठीक से हल कर सकता है, ssh उस बारे में थोड़ा विशेष है।

यह देखने के लिए /etc/secuiry/limits.conf चेक करें कि क्या किसी भी खाते में लॉग इन की मात्रा पर कठोर सीमाएँ हैं और उन्हें बढ़ाएँ, अर्थात:

*       hard    maxlogins   0

ब्रैम द्वारा बताए गए / var / log / संदेश के अलावा, /var/log/auth.log भी जांचें और कृपया कोई प्रासंगिक आउटपुट पेस्ट करें। बहुत अधिक जानकारी बहुत कम से बेहतर है।


1

मैं वास्तव में @ टॉम-एच द्वारा पहले बताए गए फैशन में इन लक्षणों का सामना कर चुका हूं ... और संकल्प बहुत सीधा था।

हल करने के लिए, बस vipwपासवार्ड फ़ाइल को संपादित करें, शेल को / बिन / झूठे से / बिन / बाश या अपनी पसंद के विकल्प में समायोजित करें।

# cat /etc/passwd | grep adamjohn
adamjohn:x:1000:1000:Adam John:/home/adamjohn:/bin/false <-- check this exists
# vi /etc/passwd
adamjohn:x:1000:1000:Adam John:/home/adamjohn:/bin/bash <-- change this item

कृपया समझें कि कुछ मामलों में संवेदनशील खाते की सुरक्षा के लिए ऐसा किया जा सकता है। जगह में अन्य पहुंच प्रतिबंध हो सकते हैं। आपको सर्वर की सुरक्षा के महत्व को जानना चाहिए और इस प्रकार की पहुंच की अनुमति देने के निहितार्थों से अवगत होना चाहिए।


1

मैं Ubuntu 16.04 LDAP के साथ इसी तरह के मुद्दे थे। "ssh -vv ..." ने पासवर्ड प्रमाणीकरण को सफल दिखाया, लेकिन फिर संदेश आया: "कनेक्शन ... दूरस्थ होस्ट द्वारा बंद किया गया।"

"Bind_policy" के कॉन्फ़िगरेशन में /etc/ldap.conf में फिक्स्ड।

/var/log/auth.log दिखाया:

sshd[19884]: Accepted password for xxxx from xx.xx.xx.xx port 48426 ssh2
sshd[19884]: pam_unix(sshd:session): session opened for user xxxx by (uid=0)
systemd-logind[577]: New session 22 of user xxxx.
systemd: pam_unix(systemd-user:session): session opened for user xxxx by (uid=0)
sshd[19884]: nss_ldap: could not search LDAP server - Server is unavailable
sshd[19884]: fatal: login_get_lastlog: Cannot find account for uid 1502 
sshd[19884]: pam_unix(sshd:session):   session closed for user xxxx

पाया कि समस्या /etc/ldap.conf में थी। मैंने bind_policy को "soft" में बदल दिया है, इसलिए nss_ldap सर्वर विफलता पर तुरंत वापस आ जाता है। डिफ़ॉल्ट "hard_open" है, जो LDAP सर्वर से कनेक्शन खोलने में विफल होने पर फिर से जुड़ जाता है। "Bind_policy सॉफ्ट" लाइन से टिप्पणी करने से इसे डिफ़ॉल्ट रूप से बदल दिया गया, और समस्या हल हो गई। :-)


1

बहुत खोज के बाद, आखिरकार मुझे एक अप्रकाशित कंटेनर में चल रहे CentOS 7 के मामले में एक जवाब मिला।

session required pam_loginuid.so/Etc/pam.d/sshd फ़ाइल में पंक्ति बाहर टिप्पणी करें , और फिर कंटेनर को पुनरारंभ करें।

मुझे यह समाधान https://discuss.linuxcontainers.org/t/ अनियमित-user-is-unable-to-login-via-ssh / 4119 पर मिला।


0

ये सभी महान सुझाव हैं। मेरे मामले में, यह एक PuTTY सेटिंग थी जो मेरे दर्द का कारण बनी:

मैंने "SSH" कॉन्फ़िगरेशन के तहत सर्वर को भेजने के लिए एक रिमोट कमांड रखा था। जो कि 99% समय में महान काम करता है, हालांकि, जब कमांड विफल हो जाता है, तो यह सत्र को बंद कर देता है।

आदेश??? स्क्रीन-आर डी

जब वास्तव में फिर से शुरू करने के लिए एक सत्र होता है तो बहुत अच्छा काम करता है। पुनरारंभ के बाद बुरी तरह से विफल हो जाता है।

समाधान:

bashrc / bash_profile पर जाएं।


0

मेरे मामले में, यह SSH सर्वर पर बिना शेल के उपयोगकर्ता के कारण हुआ । इसका एक बहुत आसान निर्धारण है, बस -Nअपने (ओपन) SSH क्लाइंट के साथ स्विच का उपयोग करें ।

से आदमी पेज :

-N दूरस्थ कमांड निष्पादित न करें। यह सिर्फ अग्रेषित बंदरगाहों के लिए उपयोगी है।

मैं यहाँ कुछ उत्तरों से सहमत नहीं हूँ। शेल वाला एक उपयोगकर्ता /bin/false, /bin/nologinएक उचित कॉन्फ़िगरेशन है, यह आमतौर पर एसएसएच सुरंगों के लिए उपयोग किए जाने वाले उपयोगकर्ताओं के लिए उपयोग किया जाता है, एसएसएच सर्वर पर किसी भी कमांड को लॉगिन और निष्पादित करने की संभावना के बिना। इसलिए इसे सर्वर पर "ठीक" करने की कोशिश न करें, बस -Nअपने एसएसएच क्लाइंट के साथ स्विच का उपयोग करें ।


0

सुनिश्चित करें कि /etc/passwdउपयोगकर्ता के लिए सही शेल है।

उदाहरण के लिए, उपयोगकर्ता ahmadगुम शेल के कारण सर्वर में प्रवेश नहीं कर सकता:

ahmad:x:10000:1003::/home/ahmad:/bin/false

चूंकि इसके लिए सेट किया गया शेल का /bin/falseअर्थ है कि उपयोगकर्ता के ahmadपास शेल नहीं है, और इसे ठीक /bin/falseकरने के /bin/bashलिए आपको बैश या अन्य किसी भी शेल के लिए बदलना होगा ।

यदि आप वेब होस्टिंग कंट्रोल पैनल जैसे Plesk का उपयोग कर रहे हैं, तो सुनिश्चित करें कि उपयोगकर्ता के पास सर्वर तक पहुंचने की क्षमता है।


-1

यह LDAP मुद्दा हो सकता है। LDAP, Kerberos और SMB सेटिंग्स को कॉन्फ़िगर करने के लिए ऑक्टोकोनफिग को बिना चलाया गया था,

--enablemkhomedir


हैलो, अन्य सवालों के जवाब देने की कोशिश करें: ओपी डेबियन 5 के बारे में बात करता है, उत्पादन के लिए पूरी तरह से पुराना है
bgtvfr
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.