A porta está aberta, mas não posso ssh para ela

2

Meu PC da empresa está por trás do firewall, quero me conectar ao meu servidor remoto. A porta está aberta no entanto não consigo me conectar a ela, alguém sabe a causa raiz?

Do PC da minha empresa, conecte-se ao meu servidor remoto:

# telnet my-server 2221
Trying x.x.x.x...
Connected to my-server.
Escape character is '^]'.
^C^C^C
# nc -vzw5 my-server 2221
Connection to my-server 2221 port [tcp/rockwell-csp1] succeeded!
# ssh -vvv my-server -p 2221
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /root/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to my-server [x.x.x.x] port 2221.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
^C

O processo ficará preso para sempre.

No entanto, ao mesmo tempo, verifico o status do meu servidor remoto, posso ver claramente que a conexão foi estabelecida:

# netstat -at
tcp        0    402 myserver:ssh             x.x.x.x:11307     ESTABLISHED

Depois de um tempo, o status da conexão será alterado para FIN_WAIT1 e, em seguida, fechado:

 # netstat -at
    tcp        0    402 myserver:ssh             x.x.x.x:11307     FIN_WAIT1

Tcpdump no lado do servidor enquanto o cliente inicia um pedido de conexão:

# tcpdump -i ppp0 port 2221 -vv
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
12:09:01.408239 IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    server_ip.2221 > client_ip.20999: Flags [S.], cksum 0x21e6 (correct), seq 2805531925, ack 581774329, win 14400, options [mss 1452,sackOK,TS val 9959078 ecr 74287789,nop,wscale 4], length 0
12:09:01.424747 IP (tos 0x0, ttl 50, id 41302, offset 0, flags [DF], proto TCP (6), length 52)
    client_ip.20999 > server_ip.2221: Flags [.], cksum 0x8711 (correct), seq 1, ack 1, win 457, options [nop,nop,TS val 74287802 ecr 9959078], length 0
12:09:01.448272 IP (tos 0x10, ttl 64, id 62398, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5dba (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959082 ecr 74287802], length 402
12:09:01.674641 IP (tos 0x10, ttl 64, id 62399, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5da3 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959105 ecr 74287802], length 402
12:09:01.904523 IP (tos 0x10, ttl 64, id 62400, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5d8c (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959128 ecr 74287802], length 402
12:09:02.364225 IP (tos 0x10, ttl 64, id 62401, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5d5e (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959174 ecr 74287802], length 402
12:09:03.283694 IP (tos 0x10, ttl 64, id 62402, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5d02 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959266 ecr 74287802], length 402
12:09:05.122593 IP (tos 0x10, ttl 64, id 62403, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5c4a (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959450 ecr 74287802], length 402
12:09:08.810407 IP (tos 0x10, ttl 64, id 62404, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5ad9 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9959819 ecr 74287802], length 402
12:09:15.006311 IP (tos 0x10, ttl 64, id 17769, offset 0, flags [DF], proto TCP (6), length 52)
    server_ip.2221 > client_ip.4708: Flags [F.], cksum 0x0499 (correct), seq 1497941342, ack 2936162453, win 900, options [nop,nop,TS val 9960438 ecr 74001029], length 0
12:09:16.176090 IP (tos 0x10, ttl 64, id 62405, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x57f8 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9960556 ecr 74287802], length 402
12:09:30.927316 IP (tos 0x10, ttl 64, id 62406, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x5234 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9962032 ecr 74287802], length 402
12:10:00.429743 IP (tos 0x10, ttl 64, id 62407, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x46ac (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9964984 ecr 74287802], length 402
12:10:59.354673 IP (tos 0x10, ttl 64, id 62408, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x2fa4 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9970880 ecr 74287802], length 402
12:12:57.364324 IP (tos 0x10, ttl 64, id 62409, offset 0, flags [DF], proto TCP (6), length 454)
    server_ip.2221 > client_ip.20999: Flags [P.], cksum 0x0184 (correct), seq 1:403, ack 1, win 900, options [nop,nop,TS val 9982688 ecr 74287802], length 402
12:14:01.653934 IP (tos 0x10, ttl 64, id 62410, offset 0, flags [DF], proto TCP (6), length 52)
    server_ip.2221 > client_ip.20999: Flags [F.], cksum 0x0e69 (correct), seq 403, ack 1, win 900, options [nop,nop,TS val 9989120 ecr 74287802], length 0
    
por NeilWang 15.07.2015 / 06:08

3 respostas

5
debug1: Connection established.
[...]
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
^C

Quando um cliente se conecta a um servidor SSH, a primeira troca de dados é que o servidor e o cliente enviam suas sequências de versões entre si. O cliente OpenSSH normalmente registra isso imediatamente após a lista de arquivos de identidade, por exemplo, do meu sistema:

[...]
debug1: identity file /home/devuser/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2

Seu cliente nunca registrou o recebimento da string da versão SSH do servidor. Uma de três coisas provavelmente está acontecendo:

  1. Um firewall ou algo semelhante está bloqueando ou descartando pacotes de dados TCP do servidor para o cliente.
  2. O cliente está se conectando a um servidor SSH, mas não está funcionando corretamente.
  3. O cliente está se conectando a algo diferente de um servidor ssh.

Você precisará solucionar isso no servidor. O servidor OpenSSH registra através do syslog. Você deve começar verificando os logs do syslog para ver se alguma coisa sshd registrou sobre a tentativa de conexão.

    
por 15.07.2015 / 19:31
1

Verifique as permissões no seu arquivo ~/.ssh/authorized_keys . Eles devem ser 0600.

Verifique as permissões no diretório inicial (~) e não apenas no ~/.ssh diretório.

Como alternativa, você pode criar um novo conjunto de chaves e tentar:

  • ssh-keygen -t rsa
  • Enter file in which to save the key (/home/demo/.ssh/id_rsa): Pressione Enter
  • Enter passphrase (empty for no passphrase): Pressione Enter

Será algo parecido com isto:

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/demo/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/demo/.ssh/id_rsa.
Your public key has been saved in /home/demo/.ssh/id_rsa.pub.
The key fingerprint is:
4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 demo@a
The key's randomart image is:
+--[ RSA 2048]----+
|          .oo.   |
|         .  o.E  |
|        + .  o   |
|     . = = .     |
|      = S = .    |
|     o + = +     |
|      . o + o .  |
|           . o   |
|                 |
+-----------------+

As chaves id_rsa serão algo assim:

-----BEGIN RSA PRIVATE KEY-----
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-----END RSA PRIVATE KEY-----

Verifique a integridade disso e tente novamente.

    
por 15.07.2015 / 07:48
0

Talvez haja algo errado com sua chave? Você pode tentar fazer login com um nome de usuário e senha apenas para garantir que não seja a chave. Isso não funcionará se o sshd estiver configurado para aceitar apenas as chaves. Aqui está um exemplo

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no -p 2221 username@my-server
    
por 15.07.2015 / 07:30

Tags