O envio de variáveis env faz com que um servidor proprietário SSH / SFTP elimine a sessão [closed]

Question

É possível que um servidor que não antecipa / não suporte variáveis de ambiente de clientes termine tais sessões ao perceber o cliente enviando tais variáveis?

Eu capturei logs de nível de depuração para o cliente sftp, tudo corre bem até o final, ou seja, autenticação bem-sucedida, solicitação de subsistema sftp. Neste estágio, quando o cliente envia variáveis env, o servidor fecha a sessão.

Outro cliente sftp é executado até a conclusão da sessão, já que esse não está enviando nenhum dado env.

Estou ciente dos recursos AcceptEnv, SendENv em openssh s / w, mas esse comportamento é garantido em nome do servidor proprietário sftp / ssh (para descartar uma sessão de um cliente que tenta enviar dados env)?

debug1: channel request 0: subsystem
debug2: callback done
debug1: channel 0: open confirm rwindow 32000 rmax 35000
debug1: channel_free: channel 0: client-session, nchannels 1
debug3: channel_free: status: The following connections are open:
  #0 client-session (t4 r43 i0/0 o0/0 fd 6/7)

debug3: channel_close_fds: channel 0: r 6 w 7 e 8
debug1: fd 0 clearing O_NONBLOCK
debug2: fd 1 is not O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
Connection to xyz.com closed by remote host.

    

Answer 1

Fechar a conexão é claramente uma reação excessiva, a menos que o administrador do servidor possa configurar especificamente o que deve acontecer quando essa solicitação é feita. Eu esperaria que ele fosse tratado como qualquer outra opção do protocolo SSH2: se o servidor não permitir ou não entender as opções solicitadas pelo cliente, o servidor deve ignorar essas opções e continuar com as coisas que ele pode aceitar.

Há um precedente de tipos: quando novos algoritmos de criptografia foram adicionados ao OpenSSH, algumas implementações de firmware do SSH (no ILOM / iLO / iRMC etc. etc.) não alocaram um buffer grande o suficiente para a lista do cliente de métodos de criptografia e falha ao estabelecer uma conexão, a menos que o número de métodos de criptografia negociáveis fosse reduzido pela configuração do lado do cliente. Isso foi, sem dúvida, tratado como um bug e foi corrigido sempre que possível em versões de firmware subseqüentes.

Eu recomendaria fazer um relatório de bug para o fornecedor do servidor SSH proprietário.