Başarılı oturum açtıktan sonra Linux kapatma bağlantısı

Debian 5.2.2 ile bir sunucu üzerinde çalışıyorum. Linux ile ilgili herhangi bir idari bilgiye sahip olmadığım için, bir şeyi batırdığımı düşünüyorum. Her şeyi güncel tutmak için apt-get update ve apt-get upgrade kullandım, sonra Apache, PHP ve MySQL'i indirip yükledim. Bu araçlar iyi çalışıyor gibi görünüyor, ancak şimdi yerel konsol üzerinden EXCEPT sunucusuna giriş yapamıyorum. GUI üzerinden giriş yapmaya çalışırsam veya ssh, scp veya başka herhangi bir şeyle uzaktan giriş yapmaya çalışırsam, başarılı bir giriş yaptıktan sonra KESİNLİKLE bağlantım kesilir. Başka bir deyişle, ilk bağlantıda sorun yok, ancak doğru kullanıcı adı ve şifreyi girdiğimde (root veya herhangi bir kullanıcı için) bağlantım kesiliyor. GUI ile, ekran bir saniye siyah olur ve ardından beni hemen giriş istemine geri döndürür. Ssh ile "[server] bağlantısı kapalı" alıyorum.

Herhangi bir yardım takdir edilmektedir ve daha fazla bilgi verebilmemin bir yolu varsa, lütfen bana bildirin. Zaman ayırdığınız için teşekkür ederim.

Düzenlemeler:

- Herhangi bir kullanıcı yerel konsolda oturum açabilir

- Şu anda makineye yerel erişimim yok, bu yüzden şu an yapabileceğim tek şey ssh. Şifremi girdikten sonra ssh -vvv [server] çıktısı :

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

Bunun, kabuk yolu için yanlış ayarlar nedeniyle bir kabuğun ortaya çıkmasında bir sorun olabileceğini düşündüren birkaç benzer yazı vardır. /etc/passwd

Bunu kontrol etmek için, kullanıcı kabuk yolunuzun var olduğunu ve çalıştırılabilir olduğunu belirleyin;

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

Kabuğun var olduğunu kontrol edin:

# 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

Ayrıca, kabuk ayarlı ya değil emin olun /sbin/nologinveya /bin/falseayrıca hatta başarılı bir kimlik doğrulaması ile, giriş engel olacağını, hangi.

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

Böyle bir sorunla karşılaştığımda, hala açık / var / log / messages olan bir bağlantım oldu

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

Vi /etc/init.d/named dosyasını düzenlemek / proc'un monte edilme şeklini değiştirmesine izin verdi, böylece hata bir yeniden başlatmadan sonra olmadı.

Temelde çizgiler

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;

Olarak değiştirildi

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 adresinde bulduğum bir ipucu

Benim sorunum giriş kullanıcı adı dizini dizinde mevcut değildi /home. Bu nedenle 'testuser' adlı bir kullanıcınız varsa, /home/testuserdizinin kullanılabilir olduğundan emin olun . Bunu /var/log/messagesdosyadan öğrendim .

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 sunucunuzun sshd_configdosyasına aşağıdaki satırı ekleyin:

UsePAM no

Aşağıda sshd_configOS X'te kullanıyorum. Macport'ları kullanarak (Debian'da değil) OS X'te de aynı sorunu yaşadım çünkü (Debian makinesinde bir tane yerine) gönderiyorum.

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 kullanıyorsanız, her oluşumunu değiştirin:

pam_unix_*.so

/etc/pam.d/ içindeki tüm dosyalarda:

pam_unix.so

Bu libpam-ldap paketindeki bir hatadır (örnek pam.d dosyaları), bakınız: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825

Sistemin düzgün şekilde çözülebildiğinden emin olun, ssh bu konuda biraz özeldir.

Herhangi bir hesabın oturum açma tutarı konusunda katı limitleri olup olmadığını görmek için /etc/secuiry/limits.conf dosyasını kontrol edin ve bunları artırın;

*       hard    maxlogins   0

Bram tarafından belirtildiği gibi / var / log / mesajlara ek olarak, /var/log/auth.log dosyasını da kontrol edin ve lütfen ilgili çıktıları yapıştırın. Çok fazla bilgi çok az iyidir.

Gerçekten de bu belirtilerle daha önce @ tom-h tarafından önerilen şekilde karşılaştım ... ve çözüm çok basitti.

Çözmek, basitçe vipwve passwd dosyasını düzenlemek için, kabuğu / bin / false / / bin / bash veya tercih ettiğiniz seçeneği ayarlayı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

Lütfen bazı durumlarda hassas bir hesabı korumak için yapılabileceğini anlayın. Yerinde başka erişim kısıtlamaları olabilir. Sunucuyu korumanın önemini bilmeli ve bu tür erişime izin vermenin etkilerinin farkında olmalısınız.

LDAP ile Ubuntu 16.04 ile benzer sorunları yaşadım. "ssh -vv ..." şifre doğrulamasının başarılı olduğunu gösterdi, ancak sonra msg: "Bağlantı ... uzaktaki ana bilgisayar tarafından kapatıldı."

/Etc/ldap.conf dosyasında "bind_policy" yapılandırmasında düzeltildi.

/var/log/auth.log şunu gösterdi:

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

Sorunun /etc/ldap.conf içinde olduğunu buldu. Bind_policy'yi "soft" olarak değiştirdim, bu yüzden nss_ldap sunucu arızasında hemen geri dönüyor. Varsayılan ayar, "LDAP sunucusuna bağlantı kurulamadığında yeniden bağlanan" hard_open "dir. "Bind_policy soft" satırını yorumlamak, varsayılan ayarlara geri döndü ve sorunu çözdü. :-)

Çok fazla arama yaptıktan sonra, ayrıcalıklı olmayan bir kapta çalışan CentOS 7 durumunda nihayet bir cevap buldum.

Dışında açıklama session required pam_loginuid.so/etc/pam.d/sshd dosyasında satır ve sonra kabı tekrar başlatın.

Bu çözümü https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119 adresinde buldum

Bunların hepsi harika öneriler. Benim durumumda, acıma sebep olan bir PuTTY ortamıydı:

"SSH" yapılandırması altında sunucuya gönderilecek uzak bir komut vermiştim. Zamanın% 99'unda harika çalışan, ancak komut başarısız olduğunda, oturumu kapatır.

Komuta??? ekran -rd

Gerçekten devam etmek için bir oturum olduğunda harika çalışıyor. Yeniden başlatmanın ardından korkunç şekilde başarısız oluyor.

Çözüm:

Bunu bashrc / bash_profile dosyasına taşıyın.

Benim durumumda, bir SSH sunucusunda bir kabuk olmayan bir kullanıcı neden oldu . Çok kolay bir çözümü var, sadece -N(Açık) SSH istemcinizle anahtarı kullanın .

Gönderen adam sayfası :

-N Uzak bir komut çalıştırma. Bu sadece portları yönlendirmek için kullanışlıdır.

Buradaki bazı cevaplara katılmıyorum. Kabuğu olan bir kullanıcı /bin/false, /bin/nologinuygun bir konfigürasyondur, genellikle SSH sunucusunda herhangi bir komut girme ve yürütme imkanı olmadan, yalnızca SSH tünelleri için kullanılan kullanıcılar için kullanılır. Bu yüzden sunucuda "düzeltmeye" çalışmayın, sadece -NSSH istemcinizle anahtarı kullanın .

Bunun /etc/passwdkullanıcı için doğru kabuğu olduğundan emin olun .

Örneğin, kullanıcı ahmadeksik kabuk nedeniyle sunucuya giriş yapamadı:

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

Kabuk seti beri /bin/falsebunun kullanıcı anlamına ahmadbir kabuk yoktur, ve değiştirmek zorunda Bunu düzeltmek için /bin/falseiçin /bin/bashbash ya da her türlü diğer kabuklar için.

Web barındırma kontrol paneli, örneğin Plesk kullanıyorsanız, kullanıcının sunucuya erişebildiğinden emin olun.

LDAP sorunu olabilir. LDAP, Kerberos ve SMB ayarlarını yapılandırmak için authconfig olmadan çalıştırıldı,

--enablemkhomedir