主页 / server / 问题 / 1163011
Accepted
Darrell Brogdon
Asked: 2024-07-25 02:13:59 +0800 CST

为什么我在 Azure Ubuntu 上收到“权限被拒绝（公钥）”？

  • 772

我在 Azure 上设置了一台 Ubuntu 24.04 服务器。设置实例时它生成的密钥有效。然后我创建了一个新用户 (dbrogdon) 并生成了一个具有相同密钥类型 (Ed25519) 的新密钥。然后我将公钥复制到 ~dbrogdon/.ssh/authorized_keys 并将权限更改为以下内容：

drwx------ 2 dbrogdon dbrogdon 4.0K Jul 24 17:21 .
drwxr-x--- 3 dbrogdon dbrogdon 4.0K Jul 24 17:22 ..
-rw------- 1 dbrogdon dbrogdon  104 Jul 24 17:20 authorized_keys

在我的 Mac 上，我拥有具有以下权限的私钥：

-rw-------  1 dbrogdon  staff   419B Jul 24 10:51 dbrogdon-key.pem

当我尝试从我的 Mac ssh 到服务器时，我得到以下信息：

debug1: Host 'xxxxxxx' is known and matches the ED25519 host key.
debug1: Found key in /Users/dbrogdon/.ssh/known_hosts:53
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: Sending SSH2_MSG_EXT_INFO
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256>
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug1: kex_ext_info_check_ver: [email protected]=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],rsa-sha2-512,rsa-sha2-256>
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

这是该会话的 auth.log：

2024-07-24T18:09:51.877109+00:00 xxxxxxx sshd[3349]: Connection from 71.205.127.54 port 52988 on 10.1.0.4 port 22 rdomain ""
2024-07-24T18:09:51.877153+00:00 xxxxxxx sshd[3349]: debug1: Local version string SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.4
2024-07-24T18:09:51.877191+00:00 xxxxxxx sshd[3349]: debug1: Remote protocol version 2.0, remote software version OpenSSH_9.6
2024-07-24T18:09:51.877240+00:00 xxxxxxx sshd[3349]: debug1: compat_banner: match: OpenSSH_9.6 pat OpenSSH* compat 0x04000000
2024-07-24T18:09:51.877917+00:00 xxxxxxx sshd[3349]: debug1: permanently_set_uid: 105/65534 [preauth]
2024-07-24T18:09:51.877973+00:00 xxxxxxx sshd[3349]: debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
2024-07-24T18:09:51.878017+00:00 xxxxxxx sshd[3349]: debug1: SSH2_MSG_KEXINIT sent [preauth]
2024-07-24T18:09:51.947718+00:00 xxxxxxx sshd[3349]: debug1: SSH2_MSG_KEXINIT received [preauth]
2024-07-24T18:09:51.947838+00:00 xxxxxxx sshd[3349]: debug1: kex: algorithm: [email protected] [preauth]
2024-07-24T18:09:51.947929+00:00 xxxxxxx sshd[3349]: debug1: kex: host key algorithm: ssh-ed25519 [preauth]
2024-07-24T18:09:51.947984+00:00 xxxxxxx sshd[3349]: debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none [preauth]
2024-07-24T18:09:51.948032+00:00 xxxxxxx sshd[3349]: debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none [preauth]
2024-07-24T18:09:51.948082+00:00 xxxxxxx sshd[3349]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
2024-07-24T18:09:52.033019+00:00 xxxxxxx sshd[3349]: debug1: SSH2_MSG_KEX_ECDH_INIT received [preauth]
2024-07-24T18:09:52.044766+00:00 xxxxxxx sshd[3349]: debug1: ssh_packet_send2_wrapped: resetting send seqnr 3 [preauth]
2024-07-24T18:09:52.044927+00:00 xxxxxxx sshd[3349]: debug1: rekey out after 134217728 blocks [preauth]
2024-07-24T18:09:52.044976+00:00 xxxxxxx sshd[3349]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
2024-07-24T18:09:52.045012+00:00 xxxxxxx sshd[3349]: debug1: Sending SSH2_MSG_EXT_INFO [preauth]
2024-07-24T18:09:52.045047+00:00 xxxxxxx sshd[3349]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
2024-07-24T18:09:52.145161+00:00 xxxxxxx sshd[3349]: debug1: ssh_packet_read_poll2: resetting read seqnr 3 [preauth]
2024-07-24T18:09:52.145271+00:00 xxxxxxx sshd[3349]: debug1: SSH2_MSG_NEWKEYS received [preauth]
2024-07-24T18:09:52.145321+00:00 xxxxxxx sshd[3349]: debug1: rekey in after 134217728 blocks [preauth]
2024-07-24T18:09:52.145366+00:00 xxxxxxx sshd[3349]: debug1: KEX done [preauth]
2024-07-24T18:09:52.145417+00:00 xxxxxxx sshd[3349]: debug1: SSH2_MSG_EXT_INFO received [preauth]
2024-07-24T18:09:52.145475+00:00 xxxxxxx sshd[3349]: debug1: kex_ext_info_check_ver: [email protected]=<0> [preauth]
2024-07-24T18:09:52.325543+00:00 xxxxxxx sshd[3349]: debug1: userauth-request for user dbrogdon service ssh-connection method none [preauth]
2024-07-24T18:09:52.325656+00:00 xxxxxxx sshd[3349]: debug1: attempt 0 failures 0 [preauth]
2024-07-24T18:09:52.326541+00:00 xxxxxxx sshd[3349]: debug1: PAM: initializing for "dbrogdon"
2024-07-24T18:09:52.328243+00:00 xxxxxxx sshd[3349]: debug1: PAM: setting PAM_RHOST to "71.205.127.54"
2024-07-24T18:09:52.328320+00:00 xxxxxxx sshd[3349]: debug1: PAM: setting PAM_TTY to "ssh"
2024-07-24T18:09:52.328369+00:00 xxxxxxx sshd[3349]: debug1: kex_server_update_ext_info: Sending SSH2_MSG_EXT_INFO [preauth]
2024-07-24T18:09:52.397374+00:00 xxxxxxx sshd[3349]: Connection closed by authenticating user dbrogdon 71.205.127.54 port 52988 [preauth]
2024-07-24T18:09:52.397473+00:00 xxxxxxx sshd[3349]: debug1: do_cleanup [preauth]
2024-07-24T18:09:52.397793+00:00 xxxxxxx sshd[3349]: debug1: monitor_read_log: child log fd closed
2024-07-24T18:09:52.397848+00:00 xxxxxxx sshd[3349]: debug1: do_cleanup
2024-07-24T18:09:52.397924+00:00 xxxxxxx sshd[3349]: debug1: PAM: cleanup
2024-07-24T18:09:52.398518+00:00 xxxxxxx sshd[3349]: debug1: Killing privsep child 3350
2024-07-24T18:09:52.398567+00:00 xxxxxxx sshd[3349]: debug1: audit_event: unhandled event 12

这是我用来连接的命令：

ssh -v -o PubkeyAuthentication=no -i ./dbrogdon-key.pem [email protected]

设置此用户时我是否遗漏了什么？我以前在其他系统上从未遇到过此问题，因此我想知道这是否是 Azure 特有的问题。

ssh

1 个回答

  1. Best Answer

    您没有指定用于连接的命令行选项，但根据日志，似乎您没有指定用于连接的密钥。

    例如，如果您的密钥在目录中~/.ssh，则命令应如下所示：

    ssh -i ~/.ssh/dbrogdon-key.pem [email protected]

    您还可以使用 ssh 代理来加载密钥并将其用作替代方案，但您没有指定将密钥加载到代理中。如果您只有几个密钥，代理会很方便，但由于 sshd 服务器通常不接受超过 5 次身份验证尝试，因此这在规模化时很快就会变得站不住脚，您需要像上面一样手动指定密钥。

    根据您问题中更新的命令，您明确指定PubKeyAuthentication=no，这将禁用您正在使用的公钥认证。PubKeyAuthentication=yes是公钥认证工作所必需的，并且是默认设置，因此通常不需要指定。

    • 3

相关问题