Kết nối Linux sau khi đăng nhập thành công

Tôi đang làm việc trên một máy chủ với Debian 5.2.2. Hoàn toàn không có kiến ​​thức quản trị với Linux, tôi nghĩ rằng tôi đã làm hỏng cái gì đó. Tôi đã sử dụng apt-get update và apt-get nâng cấp để cập nhật mọi thứ và sau đó tôi đã tải xuống và cài đặt Apache, PHP và MySQL. Những công cụ đó có vẻ hoạt động tốt, nhưng bây giờ tôi thậm chí không thể đăng nhập vào máy chủ NGOẠI TRỪ thông qua bảng điều khiển cục bộ. Nếu tôi cố gắng đăng nhập qua GUI hoặc nếu tôi cố gắng đăng nhập từ xa qua ssh, scp hoặc bất cứ điều gì khác, tôi sẽ bị ngắt kết nối NGAY LẬP TỨC khi đăng nhập thành công. Nói cách khác, nó không có vấn đề gì với kết nối ban đầu, nhưng khi tôi nhập đúng tên người dùng và mật khẩu (cho root hoặc bất kỳ người dùng nào), tôi sẽ bị ngắt kết nối. Với GUI, màn hình chuyển sang màu đen trong một giây và sau đó đưa tôi quay lại dấu nhắc đăng nhập. Với ssh, tôi nhận được "kết nối với [máy chủ] đã đóng."

Bất kỳ trợ giúp đều được đánh giá cao, và nếu có bất kỳ cách nào tôi có thể cung cấp thêm thông tin, xin vui lòng cho tôi biết. Cảm ơn bạn đã dành thời gian.

Chỉnh sửa:

- Bất kỳ người dùng nào cũng có thể đăng nhập vào bảng điều khiển cục bộ

- Hiện tại tôi không có quyền truy cập cục bộ vào máy, vì vậy tất cả những gì tôi có thể làm ngay bây giờ là ssh. Đây là đầu ra của ssh -vvv [server] sau khi tôi nhập mật khẩu của mình:

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

Có một vài bài viết tương tự cho thấy rằng đây có thể là một vấn đề với việc sinh ra một trình bao vì cài đặt không chính xác cho đường dẫn shell trong /etc/passwd

Để kiểm tra điều này, hãy xác định rằng đường dẫn vỏ người dùng của bạn tồn tại và có thể thực thi được;

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

Kiểm tra vỏ tồn tại:

# 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

cũng có, kiểm tra xem vỏ không được đặt để một trong hai /sbin/nologinhoặc /bin/false, mà cũng sẽ chặn đăng nhập, ngay cả với một xác thực thành công.

http://www.linuxforums.org/forum/ubfox-linux/173779-solve-ssh-su.html
http://www.unix.com/hp-ux/169496-solve-ssh-debug1-exit-status -254-vấn đề.html
http://www.mail-archive.com/seawolf-list@redhat.com/msg04460.html

Khi tôi gặp phải một vấn đề như vậy, tôi vẫn có một kết nối mở / var / log / message được tiết lộ:

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

Chỉnh sửa vi /etc/init.d/named được phép thay đổi cách / Proc đã được gắn kết, vì vậy lỗi không xảy ra sau khi khởi động lại.

Về cơ bản là các dòng

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;

Đã đổi thành

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

Một mẹo tôi tìm thấy tại http://www.computersalat.de/linux/strato-vserver/ssh-login-probols-nach-neustart/#comment-905

Vấn đề của tôi là đăng nhập tên người dùng thư mục không có sẵn trong /homethư mục. Vì vậy, nếu bạn có một người dùng được gọi là 'người kiểm tra', hãy đảm bảo /home/testuserthư mục có sẵn. Học được điều đó từ /var/log/messagestập tin.

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

Trong sshd_configtệp máy chủ SSH của bạn , hãy thêm dòng sau:

UsePAM no

Dưới đây là cái sshd_configtôi sử dụng trên OS X. Tôi đang đăng nó (chứ không phải trên máy Debian) vì tôi gặp vấn đề tương tự trên OS X khi sử dụng Macports (chứ không phải 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

Nếu bạn đang sử dụng LDAP, hãy thay thế mọi lần xuất hiện của:

pam_unix_*.so

trong tất cả các tệp trong /etc/pam.d/ với:

pam_unix.so

Đây là một lỗi trong gói libpam-ldap (ví dụ: tệp pam.d), xem: http://bugs.debian.org/cgi-bin/ormsreport.cgi?orms=612825

Hãy chắc chắn rằng hệ thống có thể giải quyết đúng, ssh là một chút cụ thể về điều đó.

Kiểm tra /etc/secuiry/limits.conf để xem liệu có tài khoản nào có giới hạn cứng đối với số lượng đăng nhập và tăng số đó không, ví dụ:

*       hard    maxlogins   0

Ngoài / var / log / message như được đề cập bởi Bram, cũng kiểm tra /var/log/auth.log và vui lòng dán bất kỳ đầu ra có liên quan. Quá nhiều thông tin tốt hơn là quá ít.

Tôi thực sự đã gặp chính xác các triệu chứng này theo cách được đề xuất bởi @ tom-h trước đó ... và việc giải quyết rất đơn giản.

Để giải quyết, chỉ cần vipwvà chỉnh sửa tệp passwd, điều chỉnh shell từ / bin / false thành / bin / bash hoặc tùy chọn tùy chọn của bạn.

# 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

Vui lòng hiểu rằng trong một số trường hợp, việc này có thể được thực hiện để bảo vệ tài khoản nhạy cảm. Có thể có những hạn chế truy cập khác tại chỗ. Bạn nên biết tầm quan trọng của việc bảo vệ máy chủ và nhận thức được ý nghĩa của việc cho phép loại quyền truy cập này.

Tôi gặp vấn đề tương tự với Ubuntu 16.04 với LDAP. "ssh -vv ..." cho thấy xác thực mật khẩu đã thành công, nhưng sau đó xuất hiện thông báo: "Kết nối với ... được đóng bởi máy chủ từ xa."

Đã sửa lỗi trong /etc/ldap.conf trong cấu hình của "bind_policy".

/var/log/auth.log đã hiển thị:

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

Tìm thấy rằng vấn đề là trong /etc/ldap.conf. Tôi đã thay đổi bind_policy thành "soft", vì vậy nss_ldap trả về ngay lập tức khi máy chủ bị lỗi. Mặc định là "hard_open", kết nối lại nếu mở kết nối đến máy chủ LDAP không thành công. Nhận xét dòng "bind_policy soft" đã thay đổi nó trở lại mặc định và giải quyết vấn đề. :-)

Sau rất nhiều lần tìm kiếm, cuối cùng tôi đã tìm thấy câu trả lời trong trường hợp CentOS 7 chạy trong một container không có đặc quyền.

Nhận xét session required pam_loginuid.sodòng trong tệp /etc/pam.d/sshd, sau đó khởi động lại container.

Tôi tìm thấy giải pháp này tại https://discuss.linuxcontainers.org/t/THER-user-is-unable-to-login-via-ssh/4119

Tất cả đều là những gợi ý tuyệt vời. Trong trường hợp của tôi, đó là cài đặt PuTTY gây ra nỗi đau của tôi:

Tôi đã đặt một lệnh từ xa để gửi đến máy chủ theo cấu hình "SSH". Điều này hoạt động rất tốt 99% thời gian, tuy nhiên, khi lệnh thất bại, nó chỉ đóng phiên.

Lệnh??? màn hình

Hoạt động tuyệt vời khi thực sự có một phiên để tiếp tục. Thất bại khủng khiếp sau khi khởi động lại.

Giải pháp:

di chuyển nó đến bashrc / bash_profile.

Trong trường hợp của tôi, đó là do người dùng không có vỏ trên máy chủ SSH . Nó có một sửa chữa rất dễ dàng, chỉ cần sử dụng -Nchuyển đổi với máy khách SSH (Mở) của bạn.

Từ trang người đàn ông :

-N Không thực hiện lệnh từ xa. Điều này rất hữu ích cho việc chuyển tiếp cổng.

Tôi chỉ không thể đồng ý với một số câu trả lời ở đây. Người dùng có vỏ /bin/false, /bin/nologinlà một cấu hình phù hợp, nó thường được sử dụng cho người dùng chỉ được sử dụng cho các đường hầm SSH, mà không có khả năng đăng nhập và thực hiện bất kỳ lệnh nào trên máy chủ SSH. Vì vậy, đừng cố gắng "sửa" nó trên máy chủ, chỉ cần sử dụng công -Ntắc với máy khách SSH của bạn.

Hãy chắc chắn rằng /etc/passwdcó vỏ chính xác cho người dùng.

Ví dụ: người dùng ahmadkhông thể đăng nhập vào máy chủ do thiếu shell:

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

Vì shell được đặt thành /bin/falsenó có nghĩa là người dùng ahmadkhông có shell và để khắc phục điều này, bạn phải đổi /bin/falsethành /bin/bashbash hoặc bất kỳ shell nào khác.

Nếu bạn đang sử dụng bảng điều khiển lưu trữ web, ví dụ Plesk, hãy đảm bảo người dùng có khả năng truy cập máy chủ.

Nó có thể là vấn đề LDAP. Authconfig để định cấu hình cài đặt LDAP, Kerberos và SMB đã chạy mà không có,

--enablemkhomedir