我的 Synology NAS 运行 SSH 服务器，监听默认端口 22，并使用公钥/私钥和密码设置无密码身份验证：
来自 sshd_config：
PasswordAuthentication no
AllowTcpForwarding yes
Port 22
这里一切正常，问题是我想监听 22 之外的另一个端口，所以我将以下行添加到 sshd_config 并重新启动服务器：
Port 5984
当我使用端口 5984 和在收到登录提示之前生成的相同私钥 (ppk) 从客户端连接时，但一旦输入密码，客户端就会关闭。但是，如果我使用端口 22 进行连接，则一切正常。
有什么想法为什么会发生这种情况吗？添加第二个侦听端口后是否需要生成另一个私钥文件，或者它只是我缺少的 sshd_config 中的设置？
编辑： 我的 NAS 上运行了防火墙，并添加了允许的端口 5984。这是 iptables -vL 的输出：
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
35992 8607K DOS_PROTECT all -- eth0 any anywhere anywhere
6 336 ACCEPT tcp -- any any anywhere anywhere tcp dpt:5984
0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:5984
15 828 ACCEPT tcp -- eth0 any anywhere anywhere tcp dpt:ssh
以下是尝试使用端口 5984 连接到我的 NAS ssh 客户端后的 Putty 日志：
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.03.14 11:16:34 =~=~=~=~=~=~=~=~=~=~=~=
login as: root
Authenticating with public key "rsa-key-20131004"
Passphrase for key "rsa-key-20131004":
Permission denied, please try again.
编辑2： sshd_config 文件：
Port 22
Port 5984
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
AllowTcpForwarding yes
UsePrivilegeSeparation sandbox # Default for new installations.
UseDNS no
ChrootDirectory none
AllowTcpForwarding yes
到端口 5984 的详细 SSH 连接输出：
DiskStation> ssh -vvv -i id_rsa2 -p 5984 root@localhost
OpenSSH_6.6, OpenSSL 1.0.1k-fips 8 Jan 2015
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 5984.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Incorrect RSA1 identifier
debug3: Could not load "id_rsa2" as a RSA1 public key
debug1: identity file id_rsa2 type -1
debug1: identity file id_rsa2-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6p2-hpn14v4
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6p2-hpn14v4
debug1: match: OpenSSH_6.6p2-hpn14v4 pat OpenSSH* compat 0x04000000
debug2: fd 4 setting O_NONBLOCK
debug3: put_host_port: [localhost]:5984
debug3: load_hostkeys: loading entries for host "[localhost]:5984" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-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: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
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: setup [email protected]
debug1: REQUESTED ENC.NAME is 'aes128-cbc'
debug1: kex: server->client aes128-cbc [email protected] none
debug2: mac_setup: setup [email protected]
debug1: REQUESTED ENC.NAME is 'aes128-cbc'
debug1: kex: client->server aes128-cbc [email protected] none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 19:e9:39:02:b9:32:c5:a5:f8:2d:c1:fc:fc:30:c0:b0
debug3: put_host_port: [127.0.0.1]:5984
debug3: put_host_port: [localhost]:5984
debug3: load_hostkeys: loading entries for host "[localhost]:5984" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: checking without port identifier
debug3: load_hostkeys: loading entries for host "localhost" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'localhost' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
debug1: found matching key w/out port
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: id_rsa2 ((nil)), explicit
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: id_rsa2
debug1: key_parse_private2: missing begin marker
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key 'id_rsa2':
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey: RSA 21:25:09:ac:79:97:31:ac:37:d4:99:61:9f:1d:09:f8
debug2: we sent a publickey packet, wait for reply
debug1: Authentication succeeded (publickey).
Authenticated to localhost ([127.0.0.1]:5984).
debug1: Final hpn_buffer_size = 2097152
debug1: HPN Disabled: 0, HPN Buffer Size: 2097152
debug1: channel 0: new [client-session]
debug1: Enabled Dynamic Window Scaling
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug2: callback start
debug2: fd 4 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: tcpwinsz: 87380 for connection: 4
debug2: tcpwinsz: 87380 for connection: 4
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 87380
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug2: tcpwinsz: 87380 for connection: 4
debug2: tcpwinsz: 87380 for connection: 4
Permission denied, please try again.
debug2: tcpwinsz: 87380 for connection: 4
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: tcpwinsz: 87380 for connection: 4
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: tcpwinsz: 87380 for connection: 4
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)
Connection to localhost closed.
Transferred: sent 3268, received 1456 bytes, in 0.0 seconds
Bytes per second: sent 109919.7, received 48972.8
debug1: Exit status 1
工作连接（端口 22）和失败连接（端口 5984）之间的区别：
谢谢
答案1
首先，我通常创建一个第二sshd 进程有自己的配置文件。 （sshd -f /etc/ssh/sshd-2222.conf例如）或通过覆盖命令行上的配置 ( sshd -p 2222 -o PasswordAuthentication=no,AllowRoot=no)。这样它们共享相同的密钥等，但您可以覆盖任何参数。
知道为什么会发生这种情况吗？
我有一些想法：
selinux 已启用并阻止您使用该端口登录。这不太可能，因为如果问题出在 selinux 上，问题就不会那么严重。运行
selinuxenabled && echo "SELinux enabled" && getenforce并查看是否启用和强制执行，grep sshd /var/log/audit/audit.log以识别失败。禁用看看它是否消失。PAM 正在阻碍。同样，这似乎不太可能，因为 PAM 并不关心您与 SSH 结合使用的端口。
/etc/hosts.allow或者/etc/hosts.deny。您可以在此处以任意数量的组合关联端口-服务-用户。如果这些文件是空的，我们就得去别处寻找。ssh 是否在密钥中添加了一些神秘的端口号？这是可能的。您的日志表明它正在发生并且没有发生。例如，参见：
debug1：身份验证成功（公钥）。已通过本地主机身份验证 ([127.0.0.1]:5984)。
来自 CentOS7 的变更日志：
* Fri Oct 26 2012 Petr Lautrbach <[email protected]> 6.1p1-2 - add SELinux comment to /etc/ssh/sshd_config about SELinux command to modify port (#861400)
好吧，也许这是selinux。