La chose la plus récente dont je me souviens est de changer l'ulimit de memlock doux et dur en illimité. Maintenant, je ne peux plus entrer dans la machine.
Ceci est le journal ssh.
Authenticated to IP ([IP]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LC_CTYPE =
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Wed Aug 6 07:18:07 2014 from IP-SOURCE
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
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd 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
Connection to IP closed.
Transferred: sent 4256, received 2504 bytes, in 0.4 seconds
Bytes per second: sent 9616.9, received 5658.0
debug1: Exit status 254
J'ai essayé sans succès jusqu'à maintenant, avant de poster ici:
Essayer une connexion au noprofile norc par
ssh user@host 'bash --noprofile'
Forcer un tty par
ssh -t user@host
Déplacé le bash_profile. J'ai essayé de battre
ssh user@host
.Renommer le
limits.conf
fichier en espérant qu'il ne sera pas lu.Serveur ssh redémarré.
Exécutez une commande via
knife
asknife ssh "name:server" "come_command"
ssh user@host 'ulimit -l 64'
,ssh user@host 'ulimit -S -l 64'
,ssh user@host 'ulimit -H -l 64'
,ssh user@host 'exec ulimit -H -l 64'
Je ne sais pas si cette façon d'exécuter des commandes en ligne: ssh user@host "some_command"
fonctionne, car je ne peux pas obtenir une simple liste de répertoires. J'ai également essayé de redémarrer ssh user@host 'reboot'
mais je ne pense pas que la commande a été exécutée. J'ai également redémarré la machine à partir d'AWS, mais sans succès.
Est-ce une cause perdue essayant de ssh? Existe-t-il un moyen de ssh sur le serveur?
SSH_FXP_INIT
code d'erreur.-v
option, ou pour plus, l'-vv
option pour encore plus, puis l'-vvv
option. Par exemplessh -vvv user@host
. Cela peut vous donner une meilleure idée de la situation.Réponses:
Essayer de changer
sur
dans
/etc/ssh/sshd_config
(pour CentOS)la source
/etc/security/limits.conf
été arrosé et que pam ne peut plus l'utiliser.systemd
c'est une mauvaise solution à mon humble avis. Cela empêcheralogind
d'ouvrir une session et lorsque / si l'utilisateur redémarre la machine, certains processus démarrés car l'utilisateur ne sera pas arrêté comme prévu.nr_open
. (nr_open
Est remis à zéro lors du redémarrage de la machine): vous pouvez vérifier lenr_open
parcat /proc/sys/fs/nr_open
, et ouvrir des fichiers dursulimit -Hn
. Si vous voulez toujours que l'utilisateur de connexion ssh utilise la configuration Hard Open File, vous devez augmenternr_open
:sudo sysctl -w fs.nr_open=NUM_BIGGER_THAN_HARD
J'ai eu un problème similaire, il me semblait ne voir que l'étrange message suivant:
L'utilisateur dans lequel j'essayais de ssh n'avait pas de shell par défaut .
J'ai couru ce qui suit:
Et puis j'ai pu
ssh
.Remarque: L'
exécution
su username
renvoyait le code de sortie1
(échouait) et maintenant cela fonctionne.la source
Je l' ai rencontré ce sur Mac OS X où la configuration
~/.bashrc
avait un problème qui a causéssh
au travail, maissftp
à ne pas travailler. @ stéphane-chazelas semble avoir la bonne idée dans les commentaires ci-dessus.Sur le système distant via SSH, renommez-
~/.bashrc
le~/.bashrc-MOVED
et réessayez et voyez si cela fonctionne; puis restaurez~/.bashrc
et déterminez le problème.Sur mon système, le
~/.bashrc
contenu était le suivant:Quel était probablement le coupable.
la source
J'ai eu le même problème aujourd'hui. La première chose que j'ai remarquée était que / var / log était à 100%, j'ai corrigé cela et cela n'a pas résolu le problème. Je ne pouvais pas ssh ni me connecter via l'interface graphique, mais je pouvais CNTRL + ALT + F2 pour accéder à CLI et me connecter de cette façon. J'ai tapé startx et j'ai reçu une erreur indiquant que /tmp/.X0-lock existait.
J'ai supprimé ce fichier (techniquement, j'ai tout supprimé de / tmp) et j'ai pu me connecter via l'interface graphique et également via ssh.
la source
/home
rempli à 100%, ce que j'ai détecté en utilisantdf -h
CentOS 7.J'ai changé la configuration des fichiers ouverts dans le fichier de paramètres du noyau /etc/security/limits.conf en illimité et j'ai perdu la connectivité.
Après être revenu à la normale pour l'utilisateur root, j'ai récupéré la connectivité.
la source