Fermeture de la connexion Linux après une connexion réussie

Je travaille sur un serveur avec Debian 5.2.2. Ayant à peine des connaissances administratives avec Linux, je pense que j'ai foiré quelque chose. J'ai utilisé la mise à jour apt-get et la mise à niveau apt-get pour tout mettre à jour, puis j'ai téléchargé et installé Apache, PHP et MySQL. Ces outils semblent bien fonctionner, mais maintenant je ne peux même plus me connecter au serveur SAUF via la console locale. Si j'essaie de me connecter via l'interface graphique ou si j'essaie de me connecter à distance via ssh, scp ou toute autre chose, je me déconnecte IMMÉDIATEMENT après une connexion réussie. En d'autres termes, cela n'a aucun problème avec la connexion initiale, mais lorsque je mets le nom d'utilisateur et le mot de passe corrects (pour root ou tout utilisateur), je me déconnecte. Avec l'interface graphique, l'écran devient noir pendant une seconde, puis me ramène directement à l'invite de connexion. Avec ssh, je reçois "connexion au [serveur] fermée".

Toute aide est appréciée, et s'il y a un moyen de donner plus d'informations, veuillez me le faire savoir. Merci pour votre temps.

Modifications:

- Tout utilisateur peut se connecter sur la console locale

- Pour le moment, je n'ai pas d'accès local à la machine, donc tout ce que je peux faire maintenant est ssh. Voici la sortie de ssh -vvv [serveur] après avoir entré mon mot de passe:

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

Il y a quelques articles similaires suggérant que cela pourrait être un problème avec la génération d'un shell en raison de paramètres incorrects pour le chemin du shell dans /etc/passwd

Pour vérifier cela, déterminez que votre chemin de shell utilisateur existe et est exécutable;

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

Vérifier que le shell existe:

# 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

vérifiez également que le shell n'est pas défini sur /sbin/nologinou /bin/false, ce qui bloquerait également la connexion, même avec une authentification réussie.

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/[email protected]/msg04460.html

Lorsque j'ai rencontré un tel problème, j'avais toujours une connexion ouverte / var / log / messages révélée:

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

La modification de vi /etc/init.d/named a permis de changer la façon dont / proc a été monté, donc l'erreur ne s'est pas produite après un redémarrage.

Fondamentalement, les lignes

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;

Ont été remplacés par

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 conseil que j'ai trouvé sur http://www.computersalat.de/linux/strato-vserver/ssh-login-problem-nach-neustart/#comment-905

Mon problème était que le répertoire du nom d'utilisateur de connexion n'était pas disponible dans le /homerépertoire. Donc, si vous avez un utilisateur appelé «testuser», assurez-vous que le /home/testuserrépertoire est disponible. J'ai appris cela du /var/log/messagesfichier.

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

Dans le sshd_configfichier de votre serveur SSH , ajoutez la ligne suivante:

UsePAM no

Ci-dessous, sshd_configj'utilise sur OS X. Je le poste (plutôt que sur une machine Debian) parce que j'ai rencontré le même problème sur OS X en utilisant Macports (et 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

Si vous utilisez LDAP, remplacez chaque occurrence de:

pam_unix_*.so

dans tous les fichiers de /etc/pam.d/ avec:

pam_unix.so

Il s'agit d'un bogue dans le package libpam-ldap (exemples de fichiers pam.d), voir: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612825

Assurez-vous que le système peut résoudre correctement, ssh est un peu particulier à ce sujet.

Vérifiez /etc/secuiry/limits.conf pour voir si des comptes ont des limites strictes sur le nombre de connexions et augmentez-les, c'est-à-dire:

*       hard    maxlogins   0

En plus de / var / log / messages comme mentionné par Bram, vérifiez également /var/log/auth.log et collez toute sortie pertinente. Trop d'informations valent mieux que trop peu.

J'ai en effet rencontré exactement ces symptômes de la manière suggérée par @ tom-h plus tôt ... et la résolution était très simple.

Pour résoudre, simplement vipwet éditez le fichier passwd, ajustez le shell de / bin / false à / bin / bash ou l'option de votre préférence.

# 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

Veuillez comprendre que dans certains cas, cela peut être fait afin de protéger un compte sensible. Il peut y avoir d'autres restrictions d'accès en place. Vous devez connaître l'importance de protéger le serveur et être conscient des implications de l'autorisation de ce type d'accès.

J'ai eu des problèmes similaires avec Ubuntu 16.04 avec LDAP. "ssh -vv ..." a montré que l'authentification par mot de passe a réussi, mais est venu le message suivant: "Connexion à ... fermée par l'hôte distant."

Corrigé dans /etc/ldap.conf dans la configuration de "bind_policy".

/var/log/auth.log a montré:

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

Trouvé que le problème se trouvait dans /etc/ldap.conf. J'ai changé le bind_policy en "soft", donc nss_ldap revient immédiatement en cas de panne du serveur. La valeur par défaut est "hard_open", qui se reconnecte si l'ouverture de la connexion au serveur LDAP a échoué. En commentant la ligne "bind_policy soft", elle est revenue à la valeur par défaut et a résolu le problème. :-)

Après beaucoup de recherches, j'ai finalement trouvé une réponse dans le cas de CentOS 7 fonctionnant dans un conteneur non privilégié.

Mettez en commentaire la session required pam_loginuid.soligne dans le fichier /etc/pam.d/sshd, puis redémarrez le conteneur.

J'ai trouvé cette solution sur https://discuss.linuxcontainers.org/t/regular-user-is-unable-to-login-via-ssh/4119

Ce sont toutes d'excellentes suggestions. Dans mon cas, c'était un paramètre PuTTY qui causait ma douleur:

J'avais mis une commande à distance à envoyer au serveur sous la configuration "SSH". Ce qui fonctionne très bien 99% du temps, cependant, lorsque la commande échoue, elle ferme simplement la session.

La commande??? écran -rd

Fonctionne très bien quand il y a effectivement une session à reprendre. Échoue horriblement après un redémarrage.

La solution:

déplacez-le vers bashrc / bash_profile.

Dans mon cas, cela a été causé par un utilisateur sans shell sur un serveur SSH . Il a une solution très simple, utilisez simplement le -Ncommutateur avec votre client SSH (ouvert).

Depuis la page de manuel :

-N N'exécute pas de commande à distance. Ceci est utile uniquement pour le transfert de ports.

Je ne peux tout simplement pas être d'accord avec certaines des réponses ici. Un utilisateur avec le shell /bin/false, /bin/nologinest une configuration correcte, il est généralement utilisé pour les utilisateurs utilisés uniquement pour les tunnels SSH, sans possibilité de se connecter et d'exécuter des commandes sur un serveur SSH. N'essayez donc pas de le "réparer" sur le serveur, utilisez simplement le -Ncommutateur avec votre client SSH.

Assurez-vous qu'il /etc/passwda le bon shell pour l'utilisateur.

Par exemple, l'utilisateur ahmadn'a pas pu se connecter au serveur en raison d'un shell manquant:

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

Étant donné que le jeu de shell /bin/falsecela signifie que l'utilisateur ahmadne dispose pas d' une coquille, et de corriger cela , vous devez changer /bin/falsepour /bin/bashpour bash ou tout autre obus.

Si vous utilisez un panneau de contrôle d'hébergement Web, par exemple Plesk, assurez-vous que l'utilisateur a la possibilité d'accéder au serveur.

Il peut s'agir d'un problème LDAP. L'authconfig pour configurer les paramètres LDAP, Kerberos et SMB a été exécuté sans,

--enablemkhomedir