Eu encontrei resposta para a minha pergunta foi respondida aqui no superusuário local. Obrigado @jagguli pela solução.
Basicamente eu tive que reduzir o tamanho da MTU da conexão ethernet e isso funcionou. Verifique este .
Desejo acessar um servidor, digamos x.x.x.x, que está em uma VPN. O gateway da VPN é y.y.y.y. Estou usando o cliente VPN openconnect para conectar-me ao gateway y.y.y.y e consigo me conectar com sucesso usando minhas credenciais de VPN.
O ping e a execução do traceroute em x.x.x.x após a conexão com a VPN também são bem-sucedidos. Estranhamente quando estou tentando se conectar ao x.x.x.x usando ssh com meu nome de usuário, o comando ssh trava e não solicita a senha. Eu usei o seguinte comando para conectar:
ssh [email protected]
Estou usando o Ubuntu 16.04 com o cliente VPN openconnect.
Por favor, me ajudem a saber onde estou perdendo alguma coisa crucial. Agradecemos antecipadamente.
Update-1
Consigo me conectar a esse servidor usando o puTTY para o ubuntu, o que significa que o servidor está aceitando conexões ssh de entrada. Mas o que ainda me bate é que o ssh na linha de comando ainda não consegue se conectar ao servidor. Eu corri netcat x.x.x.x 22 depois de conectar a VPN, a resposta foi: SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 .
Eu realmente quero conectar usando o ssh na linha de comando porque eu preciso do forwarding do X11 e eu posso fazer isso usando o flag -X em ssh.
Também não consigo usar o encaminhamento do X11 usando o puTTY no Ubuntu (é fácil no Windows graças ao Xming).
Update-2
ssh emitiu um erro dizendo que -d é uma opção desconhecida. Eu tentei -v (verbose) sinalizar com ssh. O seguinte é a saída:
OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/varshaneya/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/varshaneya/.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-4ubuntu2.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to x.x.x.x: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
e trava depois disso .....