O cliente SSH nativo não pode mais se conectar, mas os clientes scp e PyCharm SSH funcionam ok?

Question

Problema realmente estranho que estou encontrando hoje, e não me lembro de mudar nada. Meu cliente SSH trava ao tentar se conectar a um cliente (veja o snippit de saída abaixo). No entanto, o scp funciona bem para o mesmo endereço, o PyCharm funciona bem (ele tem seu próprio cliente SSH), e outras pessoas na minha rede podem entrar no SSH. Eu não posso conectar o SSH em nenhum outro cliente.

user@user:~$ ssh [email protected] -v
OpenSSH_7.2p2 Ubuntu-4, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 2: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.

Usando o Ubuntu 16.04.2, openssh-client, sem firewall ou qualquer outra coisa assim.

* adicionando saídas de depuração do scp

user@user:~$ scp -v [email protected]:FILE .
Executing: program /usr/bin/ssh host 192.168.1.1, user user, command scp -v -f FILE
OpenSSH_7.2p2 Ubuntu-4, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
debug1: Connection established.
debug1: SELinux support disabled
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.1:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:zxclXzh+D5j1+BwcOUly8AChlfh9Hqdoh651rShR7Bo
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
ECDSA key fingerprint is SHA256:zxclXzh+D5j1+BwcOUly8AChlfh9Hqdoh651rShR7Bo.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.1' (ECDSA) to the list of known hosts.
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Next authentication method: password
[email protected]'s password: 
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.1 ([192.168.1.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = en_CA.UTF-8
debug1: Sending command: scp -v -f FILE
Sending file modes: C0664 329835 FILE
Sink: C0664 329835 FILE
FILE                                                                        100%  322KB 322.1KB/s   00:00    
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 1988, received 332744 bytes, in 0.2 seconds
Bytes per second: sent 10317.9, received 1726971.4
debug1: Exit status 0

    

Answer 1

Eu verifico meu /home/user/.ssh/config .

O cliente SSH o lê, enquanto o SCP não o faz.

Além disso, seu log de depuração diz:

debug1: /home/user/.ssh/config linha 2: Aplicando opções para *

... então é algo (pelo menos duas linhas) na sua configuração de usuário.

Não tenho conhecimento de quaisquer brincadeiras ¹ que possam ser executadas através desse arquivo que possam impedir a conexão e o façam com os sintomas observados, mas nunca se sabe ...

(1) e. definindo IdentityFile para /dev/zero , colocando valores interessantes em SendEnv, tocando com caracteres 'invisíveis' UTF-8 ...