簡體   English   中英

ssh:權限被拒絕(公鑰,gssapi-with-mic)

[英]ssh : Permission denied (publickey,gssapi-with-mic)

我正在使用 centos 5.9。 通過此鏈接ssh 安裝 gitlab 后無法正常工作。 安裝前 gitlab ssh 正常工作。 我在本地使用此服務器和安裝在服務器上的其他服務,例如 elastix 和 apache,mysql。

出現此錯誤:

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).

我在使用 vagrant 時遇到了同樣的問題。 所以從我的 Mac 我試圖 ssh 到一個 vagrant box (CentOS 7)

通過修改/etc/ssh/sshd_config PasswordAuthentication yes然后使用sudo systemctl restart sshd重新啟動服務來解決它

希望這可以幫助。

將 700 設置為 .ssh 並將 600 設置為 authorized_keys 解決了這個問題。

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

將 PasswordAuthentication 設置為 yes,不是最好的方法,不如使用私鑰和公鑰進行身份驗證安全!

首先確保您在服務器端設置了閑置權限。

首先檢查您的主目錄(服務器端)

[vini@random ~]$ ls -ld ~

drwx------. 3 vini vini 127 Nov 23 15:29 /home/vini

如果不是這樣,運行

chmod 0700 /home/your_home

現在檢查 .ssh 文件夾

[vini@random ~]$ ls -ld  /home/vini/.ssh/

drwx------. 2 vini vini 29 Nov 23 15:28 /home/vini/.ssh/

如果看起來不是這樣,請運行

chmod 0700 /home/your_home/.ssh

現在確保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

或者只是運行

chmod 0600 /home/your_home/.ssh/authorized_keys

之后轉到/etc/ssh/sshd_config

最佳安全套裝

PermitRootLogin no

PubkeyAuthentication yes

保持為yes用於測試目的

PasswordAuthentication yes

確保

ChallengeResponseAuthentication no

為 GSSAPI 注釋這些行

# #GSSAPIAuthentication yes
# #GSSAPICleanupCredentials no

確保設置為UsePAM yes

UsePAM yes

現在重新啟動 sshd 服務

systemctl restart sshd 

在客戶端

cd /home/your_home/.ssh

生成新密鑰; 設置密碼是可選的,但這是一個好主意

ssh-keygen -t rsa -b 2048  

將發布密鑰復制到您的服務器

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

現在你可以走了!

ssh user_name@server_ip

如果一切正常

備份您的私鑰,然后拒絕PasswordAuthentication

PasswordAuthentication no 

重啟你的服務器

現在任何人都應該在沒有密鑰的情況下嘗試 ssh 進入您的服務器

vini@random: Permission denied (publickey).

讓腳本兒童遠離您的業務,祝您好運

正如其他人已經說過的,您需要編輯/etc/ssh/sshd_config並將PasswordAuthentication no更改為PasswordAuthentication yes

我在設置 Vagrant 盒子時遇到了這個問題 - 因此,編寫腳本並在 shell 配置器中自動執行它是有意義的:

sudo sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config;

sudo systemctl restart sshd;

根據debug1: Authentications that can continue: publickey,gssapi-with-mic ,ssh 密碼身份驗證被禁用,顯然您沒有使用公鑰身份驗證。

使用控制台登錄到您的服務器並使用具有 root 用戶的編輯器打開/etc/ssh/sshd_config文件並查找行PasswordAuthentication然后將其值設置為 yes 最后重新啟動 sshd 服務。

請確保以下更改應取消注釋,我在 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

謝謝大家,祝你好運

我有同樣的問題。 就我而言,macOS 不會加載我的 SSH 密鑰,但我通過以下方式對其進行了修復:

ssh-add <SSH private key>
ssh-add <SSH public key>

我無法連接到 DigitalOcean 上的 Droplet,但后續命令對我有用。

你可以去這里的論壇。

問題是 AWS 上 centos 實例上大多數公鑰錯誤的用戶名。 對於權限被拒絕(公鑰、gssapi-keyex、gssapi-with-mic):

它很簡單。 只需將您的用戶名從 centos 更改為 ec2-user 即可解決問題。

晚點再謝我 :)

嘗試了很多東西,它沒有幫助。

它以一種簡單的方式訪問:

eval $(ssh-agent) > /dev/null
killall ssh-agent
eval `ssh-agent`
ssh-add ~/.ssh/id_rsa

請注意,在ssh-add -L輸出的末尾必須不是密鑰的路徑,而是您的電子郵件。

在 Centos 7 中

錯誤:公鑰、gssapi-keyex、gssapi-with-mic

Ans : 對 vi /etc/ssh/sshd_config 的 Root 訪問權限並將 PasswordAuthentication ( no ) 更改為 yes。

2. 重啟 sshd 服務

根> systemctl 重新啟動 sshd.service

  1. 通過 putty 無密鑰登錄到本地 id。

我試試

rm ~/.ssh/id_rsa.pub

然后它工作!

沒有人在上面的答案中提到這一點,所以我提到它。

如果您位於錯誤的文件夾或 pem 文件的路徑不正確,也會出現此錯誤。 我遇到了類似的問題,發現我的 pem 文件不在我執行 ssh 命令的位置

cd KeyPair
ssh -i Keypair.pem ec2-user@244.255.255.255

我知道這是一個老問題,但我想我會把我的修復添加到鍋里。

我在嘗試從 Ubuntu 連接到 Amazon Linux 時遇到了同樣的錯誤。 解決方案是簡單地改變這個:

ssh-add -c <key_location>.pem

對此:

ssh-add "<key_location>.pem"

......非常簡單的改變讓我進來了。

正如其他一些人所提到的,確保在 ssh 進入服務器時使用正確的私鑰。 我在我的目錄中設置了多個 ssh 私鑰,因此它默認為不同的密鑰。 要使用正確的密鑰進行 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

而且我認為這將清除發布問題的原因,實際上這是 pssh 本身的錯誤(包含在“askpass-client.py”中)。 它是 pssh 的 lib 文件。 並且有記錄的問題 -A 案例: https ://code.google.com/archive/p/parallel-ssh/issues/80 如果您被迫使用包含此錯誤的 pssh 版本,有兩種可能的解決方案用於訪問私鑰的密碼:

  1. 按照我的帖子之前列出的鏈接中的說明更正您的“askpass-client.py”。
  2. 使用你最喜歡的傳球門將。

謝謝關注,希望對你有幫助!

首先必須為遠程機器建立密碼登錄

  • 首先進行密碼登錄

您必須通過啟用屬性來啟用密碼登錄,即 sshd_config 文件中的PasswordAuthentication yes 。然后重新啟動 sshd 服務並將 pub 密鑰復制到遠程服務器(在我的情況下為 aws ec2),密鑰將被復制而沒有任何錯誤

  • 當且僅當首先進行密碼登錄時,沒有密碼登錄才有效
  • 將 pub 密鑰內容復制到授權密鑰 cat xxx.pub >> ~/.ssh/authorized_keys

如果您缺少在 authorized_keys 中為 AWS 實例設置的正確 id_rsa 密鑰,則可能會發生這種情況。

我得到的確切錯誤(這篇文章是在我搜索錯誤時出現的):

ec2-user@XXXX: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

注意:如果您有很多密鑰,則必須在 ssh 命令行上指定密鑰,或者將其添加到您的 ssh-agent 密鑰中(請參閱 ssh-add -l)。 只有來自 ssh-agent 的前 6 個密鑰可以工作 - 默認 sshd MaxAuthTries 配置值為 6。

希望,這會幫助某人。 我遇到的問題是,我完全使用了錯誤的 IP 密鑰。 確保您為正確的 IP 使用正確的密鑰

對我來說這是一個完全錯誤,有人將密鑰復制粘貼到與另一個密鑰相同的行中,將它們分成兩行后再次起作用,因此請檢查您的授權密鑰文件是否有類似的錯誤!

我之前遇到了同樣的問題 Permission denied (publickey, gssapi-keyex, gssapi-with-mic)。

我不得不去 /etc/ssh/sshd_config 將用戶用戶添加到 AllowUsers 部分,然后重新啟動 sshd 服務。

讓我與您分享我是如何做到的,我相信您會在這里找到好的答案。

確保以下

第 1 步。您有Public DNS (IPv4) from aws例如 ec2-IPV4.us-east-2.compute.amazonaws.com

第 2 步。您記得your_secret_key_is.pem的位置。例如,最好將其遠離已知文件夾(如下載、桌面或文檔)的根目錄

步驟 3 打開終端並添加命令sudo ssh -v -i path-to-key.pem ec2-user@host

ec2-user很重要,因為它對於某些 linux 服務器來說是用戶名

sudo它需要執行權限

主機是 Amazon Public DNS (IPv4)(復制步驟 1)

在此處查找更多信息

Permission denied (publickey)

在我的情況下,這似乎是 ssh 客戶端而不是 ssh 服務器產生的問題。 這是導致我的問題的原因以及我如何解決的。 問題來源是我使用sudo生成這樣的密鑰:

sudo ssh-keygen -t ed25519 -f ~/.ssh/serverA_ed25519_key

這會自動將這些密鑰文件的所有者設置為僅 root,因此我當前的用戶沒有讀取密鑰的權限。

現在解決方案#1是將文件所有權更改為您當前的用戶。 這就是我所做的。

sudo chown CURRENT_USER ~/.ssh/serverA_ed25519_key

解決方案#2 只是在您嘗試連接到 ssh 服務器時使用sudo運行 ssh 客戶端。

最后,找到 ssh 客戶端問題根源的技巧。

ssh -v -o IdentitiesOnly=yes -i ~/.ssh/serverA_ed25519_key me@serverA

這讓我通過以下方式專注於這個問題:

  • 通過-v標志顯示詳細信息。
  • -o選項和-i ~/.ssh/serverA_ed25519_key強制 ssh 客戶端僅嘗試使用此密鑰,而不是您擁有的所有密鑰。

我也有這個錯誤信息: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

使用 cmd: ssh -i "~/.ssh/old.pem" user@ip導致錯誤。

問題是old.pem已被棄用,更改為最新的 pem 文件后,錯誤消失。

問題很簡單,如果windows(只需刪除其他用戶並僅保留一個或拒絕其他用戶權限)對於linux / Mac只需執行chmod 400,則密鑰的所有者應該是一個,因為這只會授予讀取權限用戶並且沒有對組或公共的權限。

從我的 Mac(主機)連接到 CentOS(7.9)來賓時,我遇到了這個奇怪的錯誤。 在連接成功之前,我必須將密鑰文件顯式傳遞給ssh客戶端ssh root@ip -i private_key_file

早些時候,在使用ssh-keygen生成通常的密鑰並使用ssh-copy-id復制之后,我啟用了以下功能

PermitRootLogin yes #root登錄,默認設置
密碼驗證無

我決定不使用ssh-keygen提供的默認名稱,盡管生成的文件保存在與默認名稱相同的位置。

我沒有改變其他默認值。 不要忘記在遠程機器上重新啟動 sshd。

我成功了!! 我從我的另一台機器上復制了我的 ssh_keys 並嘗試登錄到我的 AWS EC2,但它失敗了:

sign_and_send_pubkey:來自代理的 RSA“/home/xxxx/.ssh/my_rsa”簽名失敗:代理拒絕操作 ec2-user@bla-blah-blah.zzzzz.amazonaws.com:權限被拒絕(公鑰、gssapi-keyex、gssapi-帶麥克風)。

解決方案是:

cd $HOME/.ssh

ls -l

-rx------ 1 xxxx xxxx 1766 年 5 月 4 日 09:13 id_rsa

-rx------ 1 xxxx xxxx 405 5 月 4 日 09:13 id_rsa.pub

-rw-r--r-- 1 xxxx xxxx 444 5 月 6 日 17:18 known_hosts

可選命令:rm known_hosts

chmod 400 id *

ssh -i ./id_rsa.pub ec2-user@bla-blah-blah.zzzzz.amazonaws.com

最后登錄時間:2022 年 5 月 6 日星期五 19:09:48 來自 123.456.77.9

   __|  __|_  )
   _|  (     /   Amazon Linux 2 AMI
  ___|\___|___|

只需運行此命令即可將您的密鑰添加到當前用戶的本地主機。

 ssh-copy-id localhost

就我而言,問題是selinux。 它只是禁用它。

vi /etc/sysconfig/selinux SELINUX=禁用

setenforce 0;

狀態;

我知道這個回復被淹沒在答案的深淵中,但我認為分享我團隊的用例仍然很重要:錯誤也可能因為目標實例不正確而被觸發。 就如此容易。

GIT_SSH_COMMAND="ssh -v" git clone 這將通過打印詳細日志幫助調試問題。

就我而言,我使用了錯誤的用戶名。 解決了這個問題,問題得到了解決。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM