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 suis déconnecté. 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". J'ai essayé WinSCP et j'obtiens "La connexion a été fermée de manière inattendue. Le serveur a envoyé l'état de sortie de la commande 254."
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 utilisateur Shell existe et qu'il est exécutable;
# cat /etc/passwd | grep tomh
tomh:x:1000:1000:Tom H:/home/tomh:/bin/bash <-- check this exists
Check 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/nologin ou /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 /home répertoire. Donc, si vous avez un utilisateur appelé "testuser", assurez-vous que le /home/testuser le répertoire est disponible. J'ai appris que du /var/log/messages fichier.
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 fichier sshd_config De votre serveur SSH, ajoutez la ligne suivante:
UsePAM no
Ci-dessous se trouve le sshd_config Que j'utilise sur OS X. Je le poste (plutôt qu'un 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 paquet 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, à savoir:
* hard maxlogins 0
En plus de/var/log/messages comme mentionné par Bram, vérifiez également /var/log/auth.log et collez toute sortie appropriée. 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 vipw et éditez le fichier passwd, ajustez 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.
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é.
Commentez le session required pam_loginuid.so ligne 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
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. :-)
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.
Je viens de rencontrer ce problème (spécifiquement pour sftp mais pas ssh, où je pouvais me connecter sans problème) et aucune des solutions ici ne fonctionnait pour moi. Dans mon cas, cela était dû au fait qu'il y avait trop de clés ssh (IdentityFile) dans ~/.ssh/. Il semble que lorsque vous n'avez pas d'entrée d'hôte dans ~/.ssh/config Pour l'hôte auquel vous essayez de vous connecter avec la bonne clé, il envoie simplement toutes vos clés une par une. J'avais plus de 6 clés, et bien sûr, la valeur par défaut MaxAuthTries est 6 (au moins dans Ubuntu).
La solution était de modifier le /etc/ssh/sshd_config Du serveur et d'augmenter MaxAuthTries. J'ai mis le mien à 10.
#MaxAuthTries 6
MaxAuthTries 10
(Ou bien sûr, ajoutez simplement une entrée Hôte avec la bonne clé - dans ce cas particulier, j'essaie de me connecter sans utiliser de clé).
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 -N basculez avec votre client SSH (ouvert).
Depuis la page de manuel :
- N N'exécutez 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 Shell /bin/false, /bin/nologin est 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 -N basculez avec votre client SSH.
Sois sûr que /etc/passwd a le Shell correct pour l'utilisateur.
Par exemple, l'utilisateur ahmad n'a pas pu se connecter au serveur en raison de Shell manquant:
ahmad:x:10000:1003::/home/ahmad:/bin/false
Étant donné que le shell défini sur /bin/false cela signifie que l'utilisateur ahmad n'a pas de Shell, et pour résoudre ce problème, vous devez changer /bin/false à /bin/bash pour bash ou tout autre shell.
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.