我的公司正在搬迁到新办公室。我经常从办公室通过 SSH/SFTP 访问 AWS EC2 实例。我无法从 Linux 计算机通过 SSH 连接到新办公室的 EC2 实例。我可以从旧办公室的 Windows 计算机（通过 PuTTy）通过 SSH 连接到同一个实例（使用相同的 RSA 密钥/用户名）。
我怀疑问题出在新办公室的出站网络配置错误。那应该是我的 IT 人员的问题。不过，我试图弄明白这是否真的是我的问题！
旧办公室使用 Century Link。新办公室使用 Comcast。
以下是从新办公室到 EC2 实例的“ssh -vvv”的详细信息（我收到“权限被拒绝（publickey、gssapi-keyex、gssapi-with-mic）”错误，没有任何详细信息）：
ssh -vvv -o StrictHostKeyChecking=no -i /home/mbrown/.ssh/2019_11_13_AWS_Oregon.pem [email protected]
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: [email protected],[email protected],[email protected],[email protected],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,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,[email protected]
debug2: kex_parse_kexinit: hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96
debug2: kex_parse_kexinit: hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[email protected],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).
我深入研究了 EC2 实例上的 sshd 服务器日志。以下是我尝试从新办公室 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]
以下是从旧办公室的 Windows 机器成功进行 ssh 的输出：
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 实例，我无法 ping 新办公室的外部 IP（50.220.29.106），但我可以 ping 旧办公室的外部 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
这似乎是“智能防火墙问题”。SSH 流量似乎被“智能防火墙”规则拦截、解包和终止。
如今，这是防止潜在恶意程序（恶意软件）使用 SSH 的常见策略。
因此请向您的网络管理员询问详细信息。
答案2
看起来确实如此，因为这是一个内部问题。我们的防火墙由第三方处理配置。我的 IT 部门认为我们的防火墙“完全开放”，但显然防火墙实际上设置为限制来自亚马逊的入站流量。网络技术人员为我的 Linux 服务器添加了“例外”。
答案3
确保您的新办公室 IP 地址在安全组中允许 SSH。