SSH 7.4 pausa prolongada em “penhor: rede”

Question

Eu tenho uma máquina recentemente atualizada para o Fedora 25, rodando o openSSH 7.4. Desde então, o login via ssh leva de 25 a 30 segundos em uma LAN, onde normalmente não leva mais que 1 segundo.

Executando o cliente com -vvv , usando autenticação de chave pública, a pausa ocorre aqui.

debug1: Authentication succeeded (publickey).
Authenticated to crystalline.kodiak ([192.168.0.22]:127).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network

Isso parece idêntico ao de saída para outras máquinas (Fedora 23, openSSH 7.2) na mesma rede, que não tem nenhum problema.

Assistindo ao topo no lado do servidor durante o login, systemd explode brevemente - alguns segundos - no início da pausa, algo que não é perceptível nas outras máquinas. Depois disso, o sistema está completamente ocioso. Da mesma forma, não há atividade incomum no lado do cliente.

Uma vez logado, tudo está bem.

Eu assisti a troca do cliente com o Wireshark e durante a pausa não há troca de pacotes. O cliente e o servidor estão na Ethernet por meio de um roteador, portanto, também posso assistir ao endereço do servidor para qualquer tráfego. Não há nada acontecendo.

Aqui está o sshd_config :

Port 127
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
IgnoreRhosts yes
SyslogFacility AUTHPRIV
LogLevel INFO
TCPKeepAlive yes
ClientAliveInterval 120
ClientAliveCountMax 15
PermitRootLogin yes
StrictModes yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM yes
X11Forwarding no
UsePrivilegeSeparation sandbox
AcceptEnv LANG LC_*
Subsystem   sftp    /usr/libexec/openssh/sftp-server  

De acordo com a sugestão de Sato Katsura nos comentários, tentei com UseDNS no ; isso não fez diferença alguma.

    

Answer 1

Acontece que este é um bom exemplo.

A máquina é um Raspberry Pi, rodando o kernel Pi do estoque, mas com uma userland genérica do Fedora 25 armhf. Ele também foi configurado sem cabeça e nunca usado de outra forma, mas quando conectado a um monitor e teclado, havia um problema óbvio com systemd-logind.service . Eu rastreei até esta questão , que foi introduzida no ano passado, quando partes centrais do systemd tornou-se dependente de seccomp , que por qualquer motivo não está incluído no kernel Pi de estoque, mas possivelmente através de uma configuração incorreta que o torna parece que é.

A solução foi bastante simples; opções de arquivo de serviço que requerem seccomp precisam ser removidas. Há um punhado deles em /usr/lib/systemd/system , incluindo systemd-logind.service .

Também provavelmente deixaria a rede desativada em um sistema de estoque, mas eu uso o meu próprio serviço para isso e isso não foi afetado (ou seja, a chance de alguém ter esse problema ser magro).

De qualquer forma, comentei as seguintes linhas em todas elas:

MemoryDenyWriteExecute=yes
SystemCallFilter=...

Rebooted, não há mais problemas.