การเชื่อมต่อปิด Linux หลังจากล็อกอินสำเร็จ

ฉันกำลังทำงานบนเซิร์ฟเวอร์ที่มี Debian 5.2.2 แทบจะไม่มีความรู้ด้านการบริหารกับ Linux ฉันคิดว่าฉันทำอะไรบางอย่างผิดพลาด ฉันใช้อัปเดต apt-get และ apt-get อัปเดตเพื่อรับข้อมูลล่าสุดแล้วฉันดาวน์โหลดและติดตั้ง Apache, PHP และ MySQL เครื่องมือเหล่านั้นดูเหมือนจะทำงานได้ดี แต่ตอนนี้ฉันไม่สามารถแม้แต่เข้าสู่เซิร์ฟเวอร์ยกเว้นผ่านคอนโซลท้องถิ่น ถ้าฉันพยายามเข้าสู่ระบบผ่านทาง GUI หรือถ้าฉันพยายามเข้าสู่ระบบจากระยะไกลผ่าน ssh, scp หรืออะไรก็ตามฉันจะถูกตัดการเชื่อมต่อทันทีเมื่อเข้าสู่ระบบที่ประสบความสำเร็จ กล่าวอีกอย่างหนึ่งก็คือมันไม่มีปัญหากับการเชื่อมต่อเริ่มต้น แต่เมื่อฉันใส่ชื่อผู้ใช้และรหัสผ่านที่ถูกต้อง (สำหรับผู้ใช้ root หรือผู้ใช้คนอื่น) ฉันจะถูกตัดการเชื่อมต่อ ด้วย GUI หน้าจอจะมืดไปหนึ่งวินาทีจากนั้นทำให้ฉันกลับไปที่พรอมต์การลงชื่อเข้าใช้ทันที ด้วย ssh ฉันได้รับ "การเชื่อมต่อกับ [เซิร์ฟเวอร์] ปิด"

ความช่วยเหลือใด ๆ ที่ได้รับการชื่นชมและหากมีวิธีใดที่ฉันสามารถให้ข้อมูลเพิ่มเติมโปรดแจ้งให้เราทราบ ขอขอบคุณสำหรับเวลาของคุณ.

การแก้ไข:

- ผู้ใช้ใด ๆ สามารถเข้าสู่ระบบในคอนโซลท้องถิ่น

- ในขณะนี้ฉันไม่สามารถเข้าถึงเครื่องได้ดังนั้นตอนนี้สิ่งที่ฉันทำได้คือ 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

มีโพสต์ที่คล้ายกันสองสามข้อแนะนำว่านี่อาจเป็นปัญหากับการวางไข่เชลล์เนื่องจากการตั้งค่าที่ไม่ถูกต้องสำหรับเส้นทางของเชลล์ใน /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

เมื่อฉันพบปัญหาดังกล่าวฉันยังคงมีการเชื่อมต่อหนึ่งเปิด / var / log / ข้อความที่เปิดเผย:

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

การแก้ไข vi /etc/init.d/named ได้รับอนุญาตให้เปลี่ยนวิธีการติดตั้ง / proc ดังนั้นข้อผิดพลาดไม่ได้หลังจากรีบูต

โดยทั่วไปคือเส้น

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.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905

ปัญหาของฉันคือไดเรกทอรีชื่อผู้ใช้เข้าสู่ระบบไม่สามารถใช้ได้ใน/homeไดเรกทอรี ดังนั้นหากคุณมีผู้ใช้ชื่อ 'testuser' ตรวจสอบให้แน่ใจว่า/home/testuserไดเรกทอรีพร้อมใช้งาน เรียนรู้ว่าจาก/var/log/messagesไฟล์

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

ในsshd_configไฟล์เซิร์ฟเวอร์ SSH ของคุณเพิ่มบรรทัดต่อไปนี้:

UsePAM no

ด้านล่างคือsshd_configฉันใช้บน OS X ฉันกำลังโพสต์ไว้ (แทนที่จะเป็นหนึ่งในเครื่อง Debian) เพราะฉันประสบปัญหาเดียวกันใน OS X โดยใช้ Macports (ไม่ใช่ Debian)

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

หากคุณใช้ LDAP แทนที่ทุกสิ่งที่เกิดขึ้น:

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 / ข้อความตามที่ Bram กล่าวถึงให้ตรวจสอบ /var/log/auth.log และโปรดวางผลลัพธ์ที่เกี่ยวข้อง ข้อมูลมากเกินไปดีกว่าน้อยเกินไป

ฉันได้พบกับอาการเหล่านี้ตามแฟชั่นที่ @ tom-h เร็ว ๆ นี้ ... และความละเอียดนั้นตรงไปตรงมามาก

หากต้องการแก้ไขเพียงแค่vipwแก้ไขไฟล์ passwd ให้ปรับเชลล์จาก / bin / false เป็น / bin / bash หรือตัวเลือกที่คุณต้องการ

# 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

โปรดเข้าใจว่าในบางกรณีอาจมีการดำเนินการเพื่อปกป้องบัญชีที่มีความละเอียดอ่อน อาจมีข้อ จำกัด การเข้าถึงอื่น ๆ คุณควรทราบถึงความสำคัญของการปกป้องเซิร์ฟเวอร์และตระหนักถึงความหมายของการอนุญาตการเข้าถึงประเภทนี้

ฉันมีปัญหาที่คล้ายกันกับ Ubuntu 16.04 กับ LDAP "ssh -vv ... " แสดงการตรวจสอบรหัสผ่านสำเร็จ แต่แล้วข้อความ msg: "การเชื่อมต่อกับ ... ปิดโดยโฮสต์ระยะไกล"

แก้ไขใน /etc/ldap.conf ในการกำหนดค่าของ "bind_policy"

/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 soft" เปลี่ยนกลับเป็นค่าเริ่มต้นและแก้ไขปัญหา :-)

หลังจากการค้นหาจำนวนมากในที่สุดฉันก็พบคำตอบในกรณีของ CentOS 7 ที่ทำงานอยู่ในคอนเทนเนอร์ที่ไม่มีสิทธิพิเศษ

ใส่session required pam_loginuid.soเครื่องหมายคอมเม้นต์ในไฟล์ /etc/pam.d/sshd จากนั้นรีสตาร์ทคอนเทนเนอร์

ฉันพบวิธีแก้ไขปัญหานี้ที่https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119

ทั้งหมดนี้เป็นคำแนะนำที่ดี ในกรณีของฉันมันเป็นการตั้งค่า PuTTY ที่ทำให้ฉันเจ็บปวด:

ฉันใส่คำสั่งระยะไกลเพื่อส่งไปยังเซิร์ฟเวอร์ภายใต้การกำหนดค่า "SSH" ซึ่งใช้งานได้ดี 99% ของเวลาอย่างไรก็ตามเมื่อคำสั่งล้มเหลวมันเพิ่งปิดเซสชัน

คำสั่ง ??? หน้าจอ

ใช้งานได้ดีเมื่อมีเซสชันเพื่อดำเนินการต่อจริง ล้มเหลวอย่างน่ากลัวหลังจากรีสตาร์ท

การแก้ไขปัญหา:

ย้ายไปที่ bashrc / bash_profile

ในกรณีของฉันมันก็เกิดจากผู้ใช้โดยไม่ต้องเปลือกบนเซิร์ฟเวอร์ SSH มันมีการแก้ไขที่ง่ายมากเพียงแค่ใช้-Nสวิตช์กับไคลเอนต์ (Open) SSH ของคุณ

จากหน้าคน :

-N อย่าดำเนินการคำสั่งระยะไกล สิ่งนี้มีประโยชน์สำหรับการส่งต่อพอร์ต

ฉันไม่เห็นด้วยกับคำตอบบางข้อที่นี่ ผู้ใช้ที่มีเปลือก/bin/false, /bin/nologinคือการกำหนดค่าที่เหมาะสมก็มักจะใช้สำหรับผู้ใช้ที่ใช้เฉพาะสำหรับอุโมงค์ SSH โดยไม่ต้องไปได้ที่จะเข้าสู่ระบบและดำเนินการคำสั่งใด ๆ บนเซิร์ฟเวอร์ SSH ดังนั้นอย่าพยายาม "แก้ไข" บนเซิร์ฟเวอร์เพียงใช้-Nสวิตช์กับไคลเอ็นต์ SSH ของคุณ

ตรวจสอบให้แน่ใจว่า/etc/passwdมีเชลล์ที่ถูกต้องสำหรับผู้ใช้

ตัวอย่างเช่นผู้ใช้ahmadไม่สามารถเข้าสู่เซิร์ฟเวอร์เนื่องจากเชลล์ขาดหายไป:

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

เนื่องจากเชลล์ตั้งค่า/bin/falseไว้หมายความว่าผู้ใช้ahmadไม่มีเชลล์และเพื่อแก้ไขปัญหานี้คุณต้องเปลี่ยน/bin/falseเป็น/bin/bashทุบตีหรือเชลล์อื่น ๆ

หากคุณใช้แผงควบคุมการโฮสต์เว็บเช่น Plesk ตรวจสอบให้แน่ใจว่าผู้ใช้มีความสามารถในการเข้าถึงเซิร์ฟเวอร์

อาจเป็นปัญหาของ LDAP การตรวจสอบอัตโนมัติเพื่อกำหนดค่าการตั้งค่า LDAP, Kerberos และ SMB นั้นทำได้โดยไม่มี

--enablemkhomedir