Connessione di chiusura Linux dopo il login riuscito

Sto lavorando su un server con Debian 5.2.2. Non avendo quasi alcuna conoscenza amministrativa con Linux, penso di aver rovinato qualcosa. Ho usato apt-get update e apt-get upgrade per aggiornare tutto, quindi ho scaricato e installato Apache, PHP e MySQL. Questi strumenti sembrano funzionare bene, ma ora non riesco nemmeno ad accedere al server TRANNE tramite console locale. Se provo ad accedere tramite la GUI o se provo ad accedere in remoto tramite ssh, scp o qualsiasi altra cosa, mi disconnetto IMMEDIATAMENTE dopo un accesso riuscito. In altre parole, non ha problemi con la connessione iniziale, ma quando inserisco il nome utente e la password corretti (per root o qualsiasi utente), mi disconnetto. Con la GUI, lo schermo diventa nero per un secondo e quindi mi riporta al prompt di accesso. Con ssh, ottengo "la connessione a [server] chiusa."

Qualsiasi aiuto è apprezzato e, se esiste un modo per fornire ulteriori informazioni, per favore fatemi sapere. Grazie per il tuo tempo.

modifiche:

- Qualsiasi utente può accedere alla console locale

- Al momento non ho accesso locale alla macchina, quindi tutto ciò che posso fare ora è ssh. Ecco l'output di ssh -vvv [server] dopo aver inserito la mia password:

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

Ci sono un paio di post simili che suggeriscono che questo potrebbe essere un problema con la generazione di una shell a causa di impostazioni errate per il percorso della shell in /etc/passwd

Per verificare ciò, determinare che il percorso della shell dell'utente esiste ed è eseguibile;

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

Verifica che la shell esista:

# 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

verifica inoltre che la shell non sia impostata su /sbin/nologino /bin/false, il che bloccherebbe anche l'accesso, anche con un'autenticazione corretta.

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

Quando ho riscontrato un tale problema, avevo ancora una connessione aperta / var / log / messaggi rivelati:

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

La modifica di vi /etc/init.d/named ha permesso di modificare il modo in cui è stato montato / proc, quindi l'errore non è stato eseguito dopo un riavvio.

Fondamentalmente le linee

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;

Sono stati cambiati in

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

Un consiglio che ho trovato su http://www.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905

Il mio problema era che la directory del nome utente di accesso non era disponibile nella /homedirectory. Quindi se hai un utente chiamato "testuser" assicurati che la /home/testuserdirectory sia disponibile. L'ho imparato dal /var/log/messagesfile.

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

Nel sshd_configfile del tuo server SSH , aggiungi la seguente riga:

UsePAM no

Di seguito lo sshd_configuso su OS X. Lo sto pubblicando (piuttosto che su un computer Debian) perché ho riscontrato lo stesso problema su OS X usando Macports (e non 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

Se si utilizza LDAP, sostituire ogni occorrenza di:

pam_unix_*.so

in tutti i file in /etc/pam.d/ con:

pam_unix.so

Questo è un bug nel pacchetto libpam-ldap (esempio file pam.d), vedere: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825

Assicurati che il sistema possa risolversi correttamente, ssh è un po 'particolare.

Controlla /etc/secuiry/limits.conf per vedere se alcuni account hanno limiti fissi sulla quantità di accessi e aumentali, ad esempio:

*       hard    maxlogins   0

Oltre a / var / log / messages come menzionato da Bram, controlla anche /var/log/auth.log e incolla qualsiasi output rilevante. Troppe informazioni sono meglio di troppo poche.

In effetti ho riscontrato esattamente questi sintomi nel modo suggerito da @ tom-h in precedenza ... e la risoluzione è stata molto semplice.

Per risolvere, semplicemente vipwe modifica il file passwd, regola la shell da / bin / false a / bin / bash o l'opzione delle tue preferenze.

# 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

Ti preghiamo di comprendere che in alcuni casi ciò potrebbe essere fatto per proteggere un account sensibile. Potrebbero esserci altre restrizioni di accesso in atto. È necessario conoscere l'importanza della protezione del server ed essere consapevoli delle implicazioni di consentire questo tipo di accesso ad esso.

Ho avuto problemi simili con Ubuntu 16.04 con LDAP. "ssh -vv ..." ha mostrato che l'autenticazione della password è riuscita, ma poi è arrivato il messaggio: "Connessione a ... chiusa dall'host remoto."

Risolto in /etc/ldap.conf nella configurazione di "bind_policy".

/var/log/auth.log ha mostrato:

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

Trovato che il problema era in /etc/ldap.conf. Ho modificato bind_policy in "soft", quindi nss_ldap ritorna immediatamente in caso di errore del server. L'impostazione predefinita è "hard_open", che si riconnette se l'apertura della connessione al server LDAP non è riuscita. Commentando la riga "bind_policy soft" è stato ripristinato il valore predefinito e risolto il problema. :-)

Dopo molte ricerche, ho finalmente trovato una risposta nel caso di CentOS 7 in esecuzione in un contenitore senza privilegi.

Annotare la session required pam_loginuid.soriga nel file /etc/pam.d/sshd, quindi riavviare il contenitore.

Ho trovato questa soluzione su https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119

Tutti questi sono ottimi suggerimenti. Nel mio caso, è stata un'impostazione GENTILE che ha causato il mio dolore:

Avevo messo un comando remoto da inviare al server nella configurazione "SSH". Che funziona benissimo il 99% delle volte, tuttavia, quando il comando fallisce, chiude semplicemente la sessione.

Il comando??? schermo -rd

Funziona alla grande quando c'è effettivamente una sessione da riprendere. Errore orribile dopo un riavvio.

La soluzione:

spostalo su bashrc / bash_profile.

Nel mio caso, è stato causato da un utente senza shell su un server SSH . Ha una soluzione molto semplice, basta usare lo -Nswitch con il tuo client (Open) SSH.

Dalla pagina man :

-N Non eseguire un comando remoto. Questo è utile solo per il port forwarding.

Non posso proprio essere d'accordo con alcune delle risposte qui. Un utente con il guscio /bin/false, /bin/nologinè una configurazione adeguata, di solito utilizzato per gli utenti utilizzati solo per tunnel SSH, senza la possibilità di accesso ed eseguire i comandi su un server SSH. Quindi non provare a "ripararlo" sul server, basta usare lo -Nswitch con il tuo client SSH.

Assicurarsi che /etc/passwdabbia la shell corretta per l'utente.

Ad esempio, l'utente ahmadnon è riuscito ad accedere al server a causa della shell mancante:

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

Dal momento che il set di shell per /bin/falseesso significa che l'utente ahmadnon dispone di una conchiglia, e per risolvere questo si deve cambiare /bin/falsea /bin/bashper bash o qualsiasi altre shell.

Se stai utilizzando un pannello di controllo di web hosting, ad esempio Plesk, assicurati che l'utente abbia la possibilità di accedere al server.

Potrebbe essere un problema LDAP. Il authconfig per configurare le impostazioni LDAP, Kerberos e SMB è stato eseguito senza,

--enablemkhomedir