Самое последнее, что я помню, это изменение мягкого и жесткого ulimit memlock на неограниченное количество. Теперь я не могу ssh в машину.
Это журнал 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
Я пробовал следующее безуспешно до сих пор, прежде чем размещать здесь:
Попытка входа в Norc Noprofile
ssh user@host 'bash --noprofile'
Принуждать к
ssh -t user@host
Перемещен bash_profile. Пробовал сшинг мимо
ssh user@host
.Переименование
limits.conf
файла в надежде, что он не будет прочитан.Перезапустил ssh сервер.
Запустите команду через
knife
какknife 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'
Я не уверен, что этот способ запуска команд inline: ssh user@host "some_command"
работает, потому что я не могу получить простой список каталогов. Я также попытался перезагрузиться, ssh user@host 'reboot'
но не думаю, что команда была выполнена. Я перезапустил машину из AWS также, но безуспешно.
Это безнадежное дело, пытаясь SSH? Есть ли способ я могу SSH в сервер?
SSH_FXP_INIT
код ошибки.-v
опцию или, более того,-vv
опцию еще больше, чем-vvv
опция. Напримерssh -vvv user@host
. Это может дать вам лучшее представление о том, где что-то идет не так.Ответы:
Попробуй поменять
на
в
/etc/ssh/sshd_config
(для CentOS)источник
/etc/security/limits.conf
попал ли контекст контекста , и Пэм больше не может его использовать.systemd
это плохое решение, ИМХО. Это не позволитlogind
открыть сеанс, и когда / если пользователь перезагружает компьютер, некоторые процессы запускаются, так как пользователь не будет остановлен, как ожидалось.nr_open
. (nr_open
Сбрасывается при перезагрузке машины): вы можете проверить сnr_open
помощьюcat /proc/sys/fs/nr_open
и жестких открытых файловulimit -Hn
. Если вы все еще хотите, чтобы пользователь ssh для входа в систему использовал конфигурацию Hard Open File, вам нужно увеличитьnr_open
:sudo sysctl -w fs.nr_open=NUM_BIGGER_THAN_HARD
У меня была похожая проблема, я, кажется, видел только следующее странное сообщение:
У пользователя, с которым я пытался войти, не было оболочки по умолчанию .
Я запустил следующее:
И тогда я смог
ssh
.Примечание:
Запуск
su username
возвращал код1
завершения (не удавался), и теперь он просто работает.источник
Я столкнулся с этим на Mac OS X , где конфигурация
~/.bashrc
имела проблемы , который вызвалssh
к работе, ноsftp
в не работы. @ stéphane-chazelas, кажется, имеет правильную идею в комментариях выше.В удаленной системе через SSH переименуйте
~/.bashrc
ее~/.bashrc-MOVED
и попробуйте снова и посмотрите, работает ли она; затем восстановить~/.bashrc
и определите проблему.В моей системе
~/.bashrc
содержится следующее:Который был вероятным виновником.
источник
У меня была такая же проблема сегодня. Первое, что я заметил, было / var / log на 100%, я исправил это, и это не решило проблему. Я не мог войти в ssh и не мог войти через GUI, но я мог CNTRL + ALT + F2, чтобы добраться до CLI и войти таким образом. Я набрал startx и получил ошибку, что /tmp/.X0-lock существует.
Я удалил этот файл (технически я удалил все из / tmp) и смог войти через GUI, а также через ssh.
источник
/home
заполнен до 100%, который я обнаружил, используяdf -h
CentOS 7.Я изменил конфигурацию Open files в файле параметров ядра /etc/security/limits.conf на unlimited и потерял связь.
После возврата его к обычному для пользователя root я вернул соединение.
источник