Não é possível ssh, a conexão termina imediatamente com o status de saída 254

12

A coisa mais recente que lembro é de mudar o ulimit de memlock suave e rígido para ilimitado. Agora não posso entrar na máquina.

Este é o log 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

Eu tentei o seguinte sem êxito até agora, antes de postar aqui:

  1. Tentando um login norc noprofile por ssh user@host 'bash --noprofile'

  2. Forçando um tty por ssh -t user@host

  3. Movido o bash_profile. Tentei sshing por ssh user@host.

  4. Renomear o limits.confarquivo na esperança de que não seja lido.

  5. Reiniciou o servidor ssh.

  6. Execute um comando via knifecomoknife ssh "name:server" "come_command"

  7. 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'

Não tenho certeza se esta maneira de executar comandos inline: ssh user@host "some_command"funciona, porque não consigo obter uma lista simples de diretórios. Também tentei reiniciar, ssh user@host 'reboot'mas não acho que o comando foi executado. Também reiniciei a máquina da AWS, mas sem êxito.

É uma causa perdida tentando ssh? Existe alguma maneira de eu poder ssh no servidor?

theTuxRacer
fonte
1
Se o shell de login do usuário remoto for bash, o bash sempre lerá ~ / .bashrc sobre ssh. Não há maneira de contornar isso. Você pode sftp lá e checar / alterar seu bashrc dessa maneira?
Stéphane Chazelas
Tentei o sftp usando o CyberDuck, obtive o SSH_FXP_INITcódigo de erro.
theTuxRacer
Você também pode obter resultados mais detalhados usando a -vopção ou, para mais, a -vvopção de ainda mais e depois a -vvvopção. Por exemplo ssh -vvv user@host. Isso pode lhe dar uma idéia melhor de onde as coisas estão dando errado.
213 Warwick Warwick
Tentei isso. Foi aqui que obtive o log.
theTuxRacer
Você tem algum outro acesso de arquivo (FTP / HTTP ...?) Ou shell (console?) À máquina que possa usar?
Stéphane Chazelas

Respostas:

12

Tente mudar

UsePAM yes

em

UsePAM no

in /etc/ssh/sshd_config(para CentOS)

frad sorvensen
fonte
Funciona, mas por quê?
FelikZ 07/07
1
desculpe, mas eu não lembro o motivo)
FRAD sorvensen
O SELinux está em jogo aqui? Querendo saber se o contexto de /etc/security/limits.conffoi mangueira, e pam não pode mais usá-lo.
18716 steve
Se você estiver usando uma distribuição usando systemdesta é uma solução ruim IMHO. Isso impedirá loginda abertura de uma sessão e, quando / se o usuário estiver reinicializando a máquina, alguns processos serão iniciados como o usuário não serão interrompidos conforme o esperado.
Bigon 19/12/19
No meu caso, o motivo é que o limite de arquivos abertos por usuário é maior que o nr_open. ( nr_openÉ reposto ao reiniciar a máquina): você pode verificar o nr_openpelo cat /proc/sys/fs/nr_open, e abrir arquivos de disco rígido ulimit -Hn. Se você ainda deseja que o usuário de login ssh use o Hard Open File Config, é necessário aumentar nr_open:sudo sysctl -w fs.nr_open=NUM_BIGGER_THAN_HARD
Xin Meng
4

Eu tive um problema semelhante, parecia apenas ver a seguinte mensagem estranha:

client_input_channel_req: canal 0 rtype status de saída resposta 0.

O usuário no qual eu estava tentando fazer o ssh não tinha um shell padrão .

Eu executei o seguinte:

chsh -s $(which sh) username 

E então eu fui capaz ssh.

Nota: A
execução su usernameestava retornando o código de saída 1(estava com falha) e agora apenas funciona.

GabLeRoux
fonte
1
Caramba, isso é enigmático! Este foi o meu problema também. Tentei criar um usuário do "sistema" (sem HOME e sem SHELL) para usar o SFTP e eu poderia me autenticar, mas não consegui usar o SFTP, SCP ou SSH. Isso corrigiu meu problema. Obrigado!
Dave
2

Eu encontrei isso no Mac OS X , onde a configuração no ~/.bashrctinha um problema que causou sshao trabalho, mas sftppara não trabalho. @ stéphane-chazelas parece ter a idéia certa nos comentários acima.

No sistema remoto via SSH, renomeie ~/.bashrcpara ~/.bashrc-MOVEDe tente novamente e verifique se funciona; restaure ~/.bashrce determine o problema.

No meu sistema o ~/.bashrccontinha isso:

if [ -z "$PS1" ] ; then
    exit
fi

Qual foi o provável culpado.

deslumbrado
fonte
1

Eu tive o mesmo problema hoje. A primeira coisa que notei foi que / var / log estava em 100%, corrigi isso e não resolveu o problema. Não consegui entrar no ssh nem fazer login pela GUI, mas consegui CNTRL + ALT + F2 para acessar a CLI e fazer o login dessa maneira. Digitei startx e recebi um erro que /tmp/.X0-lock existia.

Eu removi esse arquivo (tecnicamente, removi tudo de / tmp) e consegui fazer login via GUI e também via ssh.

Jerry P
fonte
Obrigado! No meu caso, foi /homepreenchido até 100%, o que eu ter detectado usando df -hno CentOS 7.
RAM237
1

Alterei a configuração de arquivos abertos no arquivo de parâmetros do kernel /etc/security/limits.conf para ilimitado e perdi a conectividade.

Depois de voltar ao normal para o usuário root, obtive a conectividade de volta.

Wrong Example:
## Example hard limit for max opened files
*        hard   nofile unlimited
root     hard   nofile  unlimited
## Example soft limit for max opened files
*        soft   nofile unlimited
root     soft   nofile unlimited

Correct Ex:
## Example hard limit for max opened files
*        hard   nofile 16000
root     hard   nofile 16000
## Example soft limit for max opened files
*        soft   nofile 16000
root     soft   nofile 16000
Santosh Garole
fonte