Невозможно получить доступ к экземпляру AWS EC2 после переезда в новый офис

Моя компания переезжает в новый офис. Я регулярно получаю доступ к инстансам AWS EC2 через SSH / SFTP из офиса. Я не могу подключиться к экземпляру EC2 по ssh из нового офиса с компьютера Linux. Я МОГУ использовать ssh в ТО ЖЕ экземпляр с машины Windows (через PuTTy) в старом офисе (используя тот же ключ / имя пользователя RSA).

Я подозреваю, что проблема заключается в неправильной конфигурации нашей исходящей сети в новом офисе. Это будет проблемой моего айтишника. Однако я пытаюсь понять, действительно ли это МОЯ проблема!

Старый офис использовал Century Link. В новом офисе используется Comcast.

Вот кровавые подробности из 'ssh -vvv' из нового офиса в экземпляр EC2 (я получаю 'Permission denied (publickey, gssapi-keyex, gssapi-with-mic)' ошибка без каких-либо подробностей):

ssh -vvv -o StrictHostKeyChecking=no -i /home/mbrown/.ssh/2019_11_13_AWS_Oregon.pem  ec2-user@ec2-18-236-161-133.us-west-2.compute.amazonaws.com
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/mbrown/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p 22 ec2-18-236-161-133.us-west-2.compute.amazonaws.com
debug3: Not a RSA1 key file /home/mbrown/.ssh/2019_11_13_AWS_Oregon.pem.
debug1: permanently_drop_suid: 501
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
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
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
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
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/mbrown/.ssh/2019_11_13_AWS_Oregon.pem type -1
debug1: identity file /home/mbrown/.ssh/2019_11_13_AWS_Oregon.pem-cert type -1
debug1: Remote protocol version 2.0, remote software version PaloAltoNetworks_0.2
debug1: no match: PaloAltoNetworks_0.2
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 5 setting O_NONBLOCK
debug2: fd 4 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug3: Wrote 864 bytes for a total of 885
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96
debug2: kex_parse_kexinit: hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-sha1
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug2: mac_setup: found hmac-sha1
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug3: Wrote 24 bytes for a total of 909
debug2: dh_gen_key: priv key bits set: 171/320
debug2: bits set: 1024/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: Wrote 272 bytes for a total of 1181
debug3: check_host_in_hostfile: host ec2-18-236-161-133.us-west-2.compute.amazonaws.com filename /home/mbrown/.ssh/known_hosts
debug3: check_host_in_hostfile: host ec2-18-236-161-133.us-west-2.compute.amazonaws.com filename /home/mbrown/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host 'ec2-18-236-161-133.us-west-2.compute.amazonaws.com' is known and matches the RSA host key.
debug1: Found key in /home/mbrown/.ssh/known_hosts:2
debug2: bits set: 1006/2048
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: Wrote 16 bytes for a total of 1197
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug3: Wrote 52 bytes for a total of 1249
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/mbrown/.ssh/2019_11_13_AWS_Oregon.pem ((nil))
debug3: Wrote 68 bytes for a total of 1317
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/mbrown/.ssh/2019_11_13_AWS_Oregon.pem
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey: RSA f5:a4:12:94:bf:d1:4d:6c:94:4d:ed:a0:38:85:6c:1d:6c:7b:08:b6
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 644 bytes for a total of 1961
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Я покопался в журналах sshd-сервера на экземпляре EC2. Вот что происходит, когда я пытаюсь подключиться к ssh из нового офиса:

Nov 14 17:31:06 ip-172-31-19-149 sshd[3350]: error: key_verify: incorrect signature
Nov 14 17:31:06 ip-172-31-19-149 sshd[3350]: Connection closed by 50.220.29.106 port 62192 [preauth]

Вот результат успешного выполнения ssh с компьютера Windows в старом офисе:

Nov 14 17:33:25 ip-172-31-19-149 sshd[3407]: reverse mapping checking getaddrinfo for 50-224-166-10-static.hfc.comcastbusiness.net [50.224.166.10] failed - POSSIBLE BREAK-IN ATTEMPT!
Nov 14 17:33:26 ip-172-31-19-149 sshd[3407]: Accepted publickey for ec2-user from 50.224.166.10 port 60874 ssh2: RSA SHA256:lmkjrzq7H2aA/VBcE2CKsG8V7zPqeMUCgrKEpZ7Ndxc
Nov 14 17:33:26 ip-172-31-19-149 sshd[3407]: pam_unix(sshd:session): session opened for user ec2-user by (uid=0)

Из экземпляра EC2 я не могу пропинговать внешний IP-адрес новый офис (50.220.29.106), но Я МОГУ пропинговать внешний IP старого офиса (50.224.166.10)

Что касается некоторых очевидных (например, из устранения неполадок EC2) вопросов ...

1) Разрешения на мой локальный ключевой файл в порядке

-r--------. 1 mbrown mbrown 1670 Nov 14 11:05 2019_11_13_AWS_Oregon.pem

2) Я использую правильного пользователя ssh (ec2-user)

3) Да, имя ключа 2019_11_13_AWS_Oregon связано с экземпляром EC2

1
задан 17 November 2019 в 19:54
3 ответа

Взгляды действительно, поскольку это было внутренней проблемой. У нас есть третье лицо, обрабатывающее конфигурацию нашего брандмауэра. Мой IT думал, что наш брандмауэр был "широко открытым", но по-видимому брандмауэр был на самом деле установлен ограничить входящий трафик в Amazon. Сетевая технология добавила "исключения" для моих серверов Linux.

0
ответ дан 4 December 2019 в 02:33

Удостоверьтесь, что Ваш новый офисный IP-адрес позволяется в группе безопасности SSH.

0
ответ дан 4 December 2019 в 02:33

Похоже, это "проблема умного брандмауэра". Кажется, что трафик SSH перехватывается, распаковывается и прерывается правилом «умного брандмауэра».

В настоящее время это общепринятая политика, предотвращающая использование SSH потенциальными вредоносными программами.

За подробностями обратитесь к сетевому администратору.

1
ответ дан 5 April 2021 в 18:08

Теги

Похожие вопросы