[英]ssh : Permission denied (publickey,gssapi-with-mic)
i'm use centos 5.9.我正在使用 centos 5.9。 after installing gitlab by this link ssh not working.
通过此链接ssh 安装 gitlab 后无法正常工作。 before install gitlab ssh correctly working.
安装前 gitlab ssh 正常工作。 i'm using this server localy and other services such as elastix and apache,mysql installed on server.
我在本地使用此服务器和安装在服务器上的其他服务,例如 elastix 和 apache,mysql。
appeare this error:出现此错误:
OpenSSH_6.9p1 Ubuntu-2ubuntu0.1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.88.23 [192.168.88.23] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4* compat 0x00000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.88.23:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,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-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-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-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
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,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 3111/6144
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:7J6JOe94H9PedNKlx6yG/wMy6ZYC8iB74WdOVGDgY7A
debug1: Host '192.168.88.23' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug2: bits set: 3102/6144
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: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa ((nil)),
debug2: key: /root/.ssh/id_dsa ((nil)),
debug2: key: /root/.ssh/id_ecdsa ((nil)),
debug2: key: /root/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic).
I had the same issue while using vagrant.我在使用 vagrant 时遇到了同样的问题。 So from my Mac I was trying to ssh to a vagrant box (CentOS 7)
所以从我的 Mac 我试图 ssh 到一个 vagrant box (CentOS 7)
Solved it by amending the /etc/ssh/sshd_config
PasswordAuthentication yes
then re-started the service using sudo systemctl restart sshd
通过修改
/etc/ssh/sshd_config
PasswordAuthentication yes
然后使用sudo systemctl restart sshd
重新启动服务来解决它
Hope this helps.希望这可以帮助。
Setting 700 to .ssh and 600 to authorized_keys solved the issue.将 700 设置为 .ssh 并将 600 设置为 authorized_keys 解决了这个问题。
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
Setting PasswordAuthentication to yes, is not the best way to go , is not as secure as using private and public keys for authentication !将 PasswordAuthentication 设置为 yes,不是最好的方法,不如使用私钥和公钥进行身份验证安全!
First make sure that that you have the fallowing permissions set, on the server side.首先确保您在服务器端设置了闲置权限。
First check your home dir (SERVER SIDE)首先检查您的主目录(服务器端)
[vini@random ~]$ ls -ld ~
drwx------. 3 vini vini 127 Nov 23 15:29 /home/vini
if it is not like this, run如果不是这样,运行
chmod 0700 /home/your_home
Now check .ssh folder现在检查 .ssh 文件夹
[vini@random ~]$ ls -ld /home/vini/.ssh/
drwx------. 2 vini vini 29 Nov 23 15:28 /home/vini/.ssh/
if it is not looking like this, run如果看起来不是这样,请运行
chmod 0700 /home/your_home/.ssh
now make sure that authorized_keys
looks like this现在确保
authorized_keys
看起来像这样
[vini@venon ~]$ ls -ld /home/vini/.ssh/authorized_keys
-rw-------. 1 vini vini 393 Nov 23 15:28 /home/vini/.ssh/authorized_keys
or just run或者只是运行
chmod 0600 /home/your_home/.ssh/authorized_keys
After that go to /etc/ssh/sshd_config
之后转到
/etc/ssh/sshd_config
For best security set最佳安全套装
PermitRootLogin no
PubkeyAuthentication yes
keep as yes
for testing purposes保持为
yes
用于测试目的
PasswordAuthentication yes
Make sure that确保
ChallengeResponseAuthentication no
Comment those lines for GSSAPI为 GSSAPI 注释这些行
# #GSSAPIAuthentication yes
# #GSSAPICleanupCredentials no
Make sure that is set to UsePAM yes
确保设置为
UsePAM yes
UsePAM yes
now restart sshd service现在重新启动 sshd 服务
systemctl restart sshd
on the client side在客户端
cd /home/your_home/.ssh
generate new keys;生成新密钥; setting a password is optional but is a good idea
设置密码是可选的,但这是一个好主意
ssh-keygen -t rsa -b 2048
copy pub key to your server将发布密钥复制到您的服务器
ssh-copy-id -i id_rsa.pub user_name@server_ip
start ssh agent
eval $(ssh-agent)
ssh-add /home/user/.ssh/your_private_key
now your are good to go !现在你可以走了!
ssh user_name@server_ip
if everything works just fine如果一切正常
make a backup of your private key and then deny PasswordAuthentication
备份您的私钥,然后拒绝
PasswordAuthentication
PasswordAuthentication no
Restart you server重启你的服务器
now anyone trying to ssh into your server, without your keys should get现在任何人都应该在没有密钥的情况下尝试 ssh 进入您的服务器
vini@random: Permission denied (publickey).
keep script kids away from your business, and good luck让脚本儿童远离您的业务,祝您好运
As everybody else has already said you need to edit /etc/ssh/sshd_config
and change PasswordAuthentication no
to PasswordAuthentication yes
正如其他人已经说过的,您需要编辑
/etc/ssh/sshd_config
并将PasswordAuthentication no
更改为PasswordAuthentication yes
I ran into this problem setting up a Vagrant box - so therefore it makes sense to script this and do it automatically in a shell provisioner:我在设置 Vagrant 盒子时遇到了这个问题 - 因此,编写脚本并在 shell 配置器中自动执行它是有意义的:
sudo sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config;
sudo systemctl restart sshd;
According to the line debug1: Authentications that can continue: publickey,gssapi-with-mic
, ssh password authentication is disabled and apparently you are not using public key authentication.根据
debug1: Authentications that can continue: publickey,gssapi-with-mic
,ssh 密码身份验证被禁用,显然您没有使用公钥身份验证。
Login to your server using console and open /etc/ssh/sshd_config
file with an editor with root user and look for line PasswordAuthentication
then set it's value to yes and finally restart sshd service.使用控制台登录到您的服务器并使用具有 root 用户的编辑器打开
/etc/ssh/sshd_config
文件并查找行PasswordAuthentication
然后将其值设置为 yes 最后重新启动 sshd 服务。
please make sure following changes should be uncommented, which I did and got succeed in centos7请确保以下更改应取消注释,我在 centos7 中做了并取得了成功
vi /etc/ssh/sshd_config
1.PubkeyAuthentication yes
2.PasswordAuthentication yes
3.GSSAPIKeyExchange no
4.GSSAPICleanupCredentials no
systemctl restart sshd
ssh-keygen
chmod 777 /root/.ssh/id_rsa.pub
ssh-copy-id -i /root/.ssh/id_rsa.pub user@ipaddress
thank you all and good luck谢谢大家,祝你好运
I had the same problem.我有同样的问题。 In my case, macOS doesn't load my SSH keys, but I fix it with:
就我而言,macOS 不会加载我的 SSH 密钥,但我通过以下方式对其进行了修复:
ssh-add <SSH private key>
ssh-add <SSH public key>
I couldn't connect to a Droplet on DigitalOcean, but the subsequent commands work for me.我无法连接到 DigitalOcean 上的 Droplet,但后续命令对我有用。
The isssue is the username for most publickey errors on centos instances on AWS.问题是 AWS 上 centos 实例上大多数公钥错误的用户名。 For Permission denied (publickey,gssapi-keyex,gssapi-with-mic):
对于权限被拒绝(公钥、gssapi-keyex、gssapi-with-mic):
its pretty simple.它很简单。 Just change your username from centos to ec2-user and the issue is solved.
只需将您的用户名从 centos 更改为 ec2-user 即可解决问题。
Thank me later :)晚点再谢我 :)
Tried a lot of things, it did not help.尝试了很多东西,它没有帮助。
It get access in a simple way:它以一种简单的方式访问:
eval $(ssh-agent) > /dev/null
killall ssh-agent
eval `ssh-agent`
ssh-add ~/.ssh/id_rsa
Note that at the end of the ssh-add -L
output must be not a path to the key, but your email.请注意,在
ssh-add -L
输出的末尾必须不是密钥的路径,而是您的电子邮件。
In Centos 7在 Centos 7 中
Error : publickey,gssapi-keyex,gssapi-with-mic错误:公钥、gssapi-keyex、gssapi-with-mic
Ans : Root access to vi /etc/ssh/sshd_config and change the PasswordAuthentication ( no ) to yes. Ans : 对 vi /etc/ssh/sshd_config 的 Root 访问权限并将 PasswordAuthentication ( no ) 更改为 yes。
2 . 2. Restart the sshd services
重启 sshd 服务
root> systemctl restart sshd.service根> systemctl 重新启动 sshd.service
I try我试试
rm ~/.ssh/id_rsa.pub
then it work!然后它工作!
Nobody has mention this in. above answers so i am mentioning it.没有人在上面的答案中提到这一点,所以我提到它。
This error can also come if you're in the wrong folder or path of your pem file is not correct.如果您位于错误的文件夹或 pem 文件的路径不正确,也会出现此错误。 I was having similar issue and found that my pem file was not there from where i am executing the ssh command
我遇到了类似的问题,发现我的 pem 文件不在我执行 ssh 命令的位置
cd KeyPair
ssh -i Keypair.pem ec2-user@244.255.255.255
I know this is an old question, but thought I'd add my fix in the pot.我知道这是一个老问题,但我想我会把我的修复添加到锅里。
I was getting the same error trying to connect to Amazon Linux from Ubuntu.我在尝试从 Ubuntu 连接到 Amazon Linux 时遇到了同样的错误。 The solution was to simply change this:
解决方案是简单地改变这个:
ssh-add -c <key_location>.pem
to this:对此:
ssh-add "<key_location>.pem"
... pretty simple change there got me in. ......非常简单的改变让我进来了。
As a few others have mentioned, make sure you are using the right private key when you ssh into your server.正如其他一些人所提到的,确保在 ssh 进入服务器时使用正确的私钥。 I had multiple ssh private keys set up in my directory, so it was defaulting to a different key.
我在我的目录中设置了多个 ssh 私钥,因此它默认为不同的密钥。 To ssh with the correct key call it out in your CLI call
ssh centos@IP-ADDRESS -i YOUR-PATH-TO-KEY
, in my case the path was ~/.ssh/id_rsa
要使用正确的密钥进行 ssh,请在 CLI 调用
ssh centos@IP-ADDRESS -i YOUR-PATH-TO-KEY
中调用它,在我的情况下,路径是~/.ssh/id_rsa
通过在 /etc/ssh/sshd_config 中将 GSSAPIAuthentication 设置为 no 来修复
也许您应该将公钥分配给authorized_keys
,简单的方法是使用ssh-copy-id -i your-pub-key-file user@dest
。
And I think this will clearify the cause of posted problem, actualy this is bug of pssh itself (contains inside "askpass-client.py").而且我认为这将清除发布问题的原因,实际上这是 pssh 本身的错误(包含在“askpass-client.py”中)。 It is pssh's lib file.
它是 pssh 的 lib 文件。 And there is documented issue for -A case: https://code.google.com/archive/p/parallel-ssh/issues/80 There are two possible resolutions to use version of pssh containing this bug in case you forced to use passphrase for private key access:
并且有记录的问题 -A 案例: https ://code.google.com/archive/p/parallel-ssh/issues/80 如果您被迫使用包含此错误的 pssh 版本,有两种可能的解决方案用于访问私钥的密码:
Thnks for attention, hope it helps!谢谢关注,希望对你有帮助!
First a password login has to be established to remote machine首先必须为远程机器建立密码登录
you have to enable a password login by enabling the property ie) PasswordAuthentication yes in sshd_config file.Then restart the sshd service and copy the pub key to remote server (aws ec2 in my case), key will be copied without any error您必须通过启用属性来启用密码登录,即 sshd_config 文件中的PasswordAuthentication yes 。然后重新启动 sshd 服务并将 pub 密钥复制到远程服务器(在我的情况下为 aws ec2),密钥将被复制而没有任何错误
This can happen if you are missing the correct id_rsa key set up in authorized_keys for an AWS instance.如果您缺少在 authorized_keys 中为 AWS 实例设置的正确 id_rsa 密钥,则可能会发生这种情况。
Exact error I got (this article came up when I googled the error):我得到的确切错误(这篇文章是在我搜索错误时出现的):
ec2-user@XXXX: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Note: If you have many keys, you have to either specify the key on the ssh command line or else add it to you ssh-agent keys (see ssh-add -l).注意:如果您有很多密钥,则必须在 ssh 命令行上指定密钥,或者将其添加到您的 ssh-agent 密钥中(请参阅 ssh-add -l)。 Only the first 6 keys from ssh-agent may work - the default sshd MaxAuthTries config value is 6.
只有来自 ssh-agent 的前 6 个密钥可以工作 - 默认 sshd MaxAuthTries 配置值为 6。
Hope, this will help someone.希望,这会帮助某人。 Problem I encountered is, I was completely using wrong key with the IP.
我遇到的问题是,我完全使用了错误的 IP 密钥。 Make sure you are using the right key for the right IP
确保您为正确的 IP 使用正确的密钥
对我来说这是一个完全错误,有人将密钥复制粘贴到与另一个密钥相同的行中,将它们分成两行后再次起作用,因此请检查您的授权密钥文件是否有类似的错误!
I had same issue Permission denied (publickey, gssapi-keyex, gssapi-with-mic) earlier.我之前遇到了同样的问题 Permission denied (publickey, gssapi-keyex, gssapi-with-mic)。
I had to go /etc/ssh/sshd_config to add the user user into AllowUsers section, then restarted sshd service.我不得不去 /etc/ssh/sshd_config 将用户用户添加到 AllowUsers 部分,然后重新启动 sshd 服务。
Let me share with you how I did it and I am sure you will find good answer here .让我与您分享我是如何做到的,我相信您会在这里找到好的答案。
Make sure the following确保以下
Step 1. You have
Public DNS (IPv4) from aws
Eg ec2-IPV4.us-east-2.compute.amazonaws.com第 1 步。您有
Public DNS (IPv4) from aws
例如 ec2-IPV4.us-east-2.compute.amazonaws.com
Step 2. You remember where your
your_secret_key_is.pem
Eg its better to keep it far from root of the known folders like Downloads, Desktop or Documents第 2 步。您记得
your_secret_key_is.pem
的位置。例如,最好将其远离已知文件夹(如下载、桌面或文档)的根目录
Step 3 Open terminal and add the command
sudo ssh -v -i path-to-key.pem ec2-user@host
步骤 3 打开终端并添加命令
sudo ssh -v -i path-to-key.pem ec2-user@host
ec2-user is important because it for some linux server it is the username ec2-user很重要,因为它对于某些 linux 服务器来说是用户名
sudo it needs permission to execute sudo它需要执行权限
host It is Amazon Public DNS (IPv4) (copy step 1)主机是 Amazon Public DNS (IPv4)(复制步骤 1)
Permission denied (publickey)
seems like an issue generated by the ssh client rather than the ssh server in my case.在我的情况下,这似乎是 ssh 客户端而不是 ssh 服务器产生的问题。 Here's what caused my problem and how I solved.
这是导致我的问题的原因以及我如何解决的。 The problem source is I used
sudo
to generate the keys like this:问题来源是我使用
sudo
生成这样的密钥:
sudo ssh-keygen -t ed25519 -f ~/.ssh/serverA_ed25519_key
This automatically set the owner of these key files to root only, so my current user doesn't have permission to read the keys.这会自动将这些密钥文件的所有者设置为仅 root,因此我当前的用户没有读取密钥的权限。
Now solution #1 is change the file ownership to your current user.现在解决方案#1是将文件所有权更改为您当前的用户。 This's what I did.
这就是我所做的。
sudo chown CURRENT_USER ~/.ssh/serverA_ed25519_key
Solution #2 would be just run ssh client with sudo
when you try to connect to the ssh server.解决方案#2 只是在您尝试连接到 ssh 服务器时使用
sudo
运行 ssh 客户端。
Finally, a trick to find the source of problem with ssh client.最后,找到 ssh 客户端问题根源的技巧。
ssh -v -o IdentitiesOnly=yes -i ~/.ssh/serverA_ed25519_key me@serverA
This let me focus on the problem by:这让我通过以下方式专注于这个问题:
-v
flag.-v
标志显示详细信息。-o
option and -i ~/.ssh/serverA_ed25519_key
force ssh client to try with this key ONLY, not all the keys you have. -o
选项和-i ~/.ssh/serverA_ed25519_key
强制 ssh 客户端仅尝试使用此密钥,而不是您拥有的所有密钥。I also have this error info : Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
我也有这个错误信息:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Using cmd: ssh -i "~/.ssh/old.pem" user@ip
cause the error.使用 cmd:
ssh -i "~/.ssh/old.pem" user@ip
导致错误。
Problem is old.pem
has been deprecated, after changing to newest pem file, the error disappears.问题是
old.pem
已被弃用,更改为最新的 pem 文件后,错误消失。
问题很简单,如果windows(只需删除其他用户并仅保留一个或拒绝其他用户权限)对于linux / Mac只需执行chmod 400,则密钥的所有者应该是一个,因为这只会授予读取权限用户并且没有对组或公共的权限。
I run into this strange error whiles connecting from my Mac(host) to a CentOS(7.9) guest.从我的 Mac(主机)连接到 CentOS(7.9)来宾时,我遇到了这个奇怪的错误。 I had to explicitly passed the key file to the
ssh
client ssh root@ip -i private_key_file
before connection was successful.在连接成功之前,我必须将密钥文件显式传递给
ssh
客户端ssh root@ip -i private_key_file
。
Earlier on, I had enabled the following after the usual key generation with ssh-keygen
and copying with ssh-copy-id
早些时候,在使用
ssh-keygen
生成通常的密钥并使用ssh-copy-id
复制之后,我启用了以下功能
PermitRootLogin yes #Logging in with root, it was set by default
PermitRootLogin yes #root登录,默认设置
PasswordAuthentication no密码验证无
I decided against using the default name provided by ssh-keygen
though the generated file was saved at the same location as the default.我决定不使用
ssh-keygen
提供的默认名称,尽管生成的文件保存在与默认名称相同的位置。
I left the other default values untouched.我没有改变其他默认值。 Don't forget to restart sshd on the remote machine.
不要忘记在远程机器上重新启动 sshd。
I got Sucess !!我成功了!! I've copied my ssh_keys from my other machine and tryed to log to my AWS EC2, but it failed:
我从我的另一台机器上复制了我的 ssh_keys 并尝试登录到我的 AWS EC2,但它失败了:
sign_and_send_pubkey: signing failed for RSA "/home/xxxx/.ssh/my_rsa" from agent: agent refused operation ec2-user@bla-blah-blah.zzzzz.amazonaws.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). sign_and_send_pubkey:来自代理的 RSA“/home/xxxx/.ssh/my_rsa”签名失败:代理拒绝操作 ec2-user@bla-blah-blah.zzzzz.amazonaws.com:权限被拒绝(公钥、gssapi-keyex、gssapi-带麦克风)。
The solution was:解决方案是:
cd $HOME/.ssh cd $HOME/.ssh
ls -l ls -l
-rx------ 1 xxxx xxxx 1766 May 4 09:13 id_rsa -rx------ 1 xxxx xxxx 1766 年 5 月 4 日 09:13 id_rsa
-rx------ 1 xxxx xxxx 405 May 4 09:13 id_rsa.pub -rx------ 1 xxxx xxxx 405 5 月 4 日 09:13 id_rsa.pub
-rw-r--r-- 1 xxxx xxxx 444 May 6 17:18 known_hosts -rw-r--r-- 1 xxxx xxxx 444 5 月 6 日 17:18 known_hosts
Optional command: rm known_hosts可选命令:rm known_hosts
chmod 400 id * chmod 400 id *
ssh -i ./id_rsa.pub ec2-user@bla-blah-blah.zzzzz.amazonaws.com ssh -i ./id_rsa.pub ec2-user@bla-blah-blah.zzzzz.amazonaws.com
Last login: Fri May 6 19:09:48 2022 from 123.456.77.9最后登录时间:2022 年 5 月 6 日星期五 19:09:48 来自 123.456.77.9
__| __|_ )
_| ( / Amazon Linux 2 AMI
___|\___|___|
只需运行此命令即可将您的密钥添加到当前用户的本地主机。
ssh-copy-id localhost
In my case the problem was selinux.就我而言,问题是selinux。 It was just disabling it.
它只是禁用它。
vi /etc/sysconfig/selinux SELINUX= disabled vi /etc/sysconfig/selinux SELINUX=禁用
setenforce 0; setenforce 0;
sestatus;状态;
I know this reply is drowned into the abyss of answers, but I think it's still relevant to share my team's use case: the error can also be triggered because the target instance is incorrect.我知道这个回复被淹没在答案的深渊中,但我认为分享我团队的用例仍然很重要:错误也可能因为目标实例不正确而被触发。 As simple as that.
就如此容易。
GIT_SSH_COMMAND="ssh -v" git clone This will help debug the issues by printing a detailed log. GIT_SSH_COMMAND="ssh -v" git clone 这将通过打印详细日志帮助调试问题。
In my case, I was using wrong username.就我而言,我使用了错误的用户名。 Fixed that and the issue got resolved.
解决了这个问题,问题得到了解决。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.