"Sign_and_send_pubkey: imzalama başarısız oldu: aracı işlemi reddetti" nasıl çözülür?

SSH anahtarlarıyla yeni bir Dijital Okyanus damlacığını yapılandırma. Çalıştırdığımda ssh-copy-idşunu elde ederim:

ssh-copy-id user@012.345.67.89
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@012.345.67.89'"
and check to make sure that only the key(s) you wanted were added.

Ancak, daha sonra ssh yapmayı denediğimde, bu olur:

ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Şifreyi girdikten sonra gayet iyi oturum açtım, ancak bu elbette ilk başta SSH anahtarını oluşturma amacını ortadan kaldırıyor. Ssh-agent sunucu tarafına bir göz atmaya karar verdim ve işte elde ettiğim şey:

user@012.345.67.89:~# eval `ssh-agent -s`
Agent pid 5715
user@012.345.67.89:~# ssh-add -l
The agent has no identities.

user / .ssh / yetkili_keys, ssh-rsa anahtar girişi de içermez, ancak find -name "keynamehere"hiçbir şey döndürmez.

Çalıştırmak ssh-add SSH anahtarını ekleyen istemci makinede .

ssh-add -lGerçekten eklendiğini (tekrar istemcide) ile onaylayın .

Fedora 26'yı 28'e yükselttikten sonra aynı sorunla karşılaştım. Ve aşağıdaki günlükler eksikti

/var/log/secure
/var/log/messages

KONU:

antop@localmachine  ~  ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:

hata mesajı gerçek sorunu göstermiyor. Sorun çözen

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*

Linux Ubuntu 18'de de aynı sorunu yaşıyordum . Ubuntu 17.10 güncellemesinden sonra , her git komutu bu mesajı gösterecektir.

Bunu çözmenin yolu, id_rsave üzerinde doğru izne sahip olduğunuzdan emin olmaktır id_rsa.pub.

Kullanarak mevcut chmod numarasını kontrol edin stat --format '%a' <file>. Olması gereken 600 için id_rsa ve 644 için id_rsa.pub.

Dosyaların kullanım iznini değiştirmek için

chmod 600 id_rsa
chmod 644 id_rsa.pub

Bu, güncellemeyle ilgili sorunumu çözdü.

Bu sorunu çözmek için aşağıdaki komutu çalıştırın.

Benim için çalıştı.

chmod 600 ~/.ssh/id_rsa

Ssh-aracım olarak gpg-agent'ı kullanırken ve ssh anahtarım olarak bir gpg alt anahtarı kullanırken hata oluştu https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .

Sorunun, sway yapılandırmamda kullanılan uyku + kilit komutumun neden olduğu gpg için geçersiz bir pin giriş tty'ye sahip olmasından kaynaklandığından şüpheleniyorum

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"

ya da sadece uyku / askıya alma

Sorunu çözmek için pin giriş tty'yi sıfırlayın

gpg-connect-agent updatestartuptty /bye > /dev/null

ve sallanma uyku + kilit komutum için düzeltme:

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"

Bu hataya:

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
git@github.com: Permission denied (publickey).    
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Genel anahtarı Github hesabı> profil> ssh içinde doğrulayın veya tekrar ekleyin.

Ben şöyle çözdüm:

# chmod 400 ~/.ssh/id_rsa

# ls  ~/.ssh/id_rsa -ls  
4 -r--------. 1 reinaldo reinaldo 1679 Jul 26  2017 /home/reinaldo/.ssh/id_rsa

# git pull                                 
remote: Counting objects: 35, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0
Unpacking objects: 100% (35/35), done.

Teşekkür ederim.

SSH hatasını almanın çeşitli nedenleri olabilir:

sign_and_send_pubkey: imzalama başarısız oldu: aracı işlemi reddetti

Bazıları diğer cevaplarda vurgulanan konularla ilgili olabilir (bu konu cevaplarına bakın), bazıları gizlenebilir ve bu nedenle daha yakından inceleme gerektirebilir.

Benim durumumda aşağıdaki hata mesajını alıyorum:

sign_and_send_pubkey: imzalama başarısız oldu: aracı işlemi reddetti

user@website.domain.com: İzin reddedildi (publickey, gssapi-keyex, gssapi-with-mic)

Gerçek sorunu bulmanın tek yolu, çok sayıda hata ayıklama bilgisinin yazdırılmasına neden olan -v ayrıntılı seçeneğini :

debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1

Lütfen satırın söylediğine dikkat edin key_load_public: No such file or directory satırın bir önceki satırı değil, sonraki satırı ifade .

Öyleyse, SSH'nin gerçekten söylediği şey, adlı genel anahtar dosyasını bulamamasıdır. id_rsa.website.domain.com-cert benim durumumda sorun olarak göründüğü, çünkü genel anahtar -certdosyamın soneki içermediğidir .

Uzun lafın kısası: Benim durumumdaki düzeltme, yalnızca genel anahtar dosyasının beklendiği gibi adlandırıldığından emin olmaktı. Bağlantıda hata ayıklamadan bundan asla şüphelenemezdim.

Sonuç olarak , neyin yanlış olduğunu anlamak için SSH VERBOSE MODUNU KULLANIN (-v seçeneği), çeşitli nedenler olabilir, hiçbiri bu / başka bir iş parçacığında bulunamaz.

Bu daha çok bir Süper Kullanıcı sorusu olmalıdır.

Doğru, MacOSX SourceTree'de de aynı hatayı görüyorum, ancak bir iTerm2 terminalinin içinde işler gayet iyi çalışıyor.

Ancak sorun şu ki, çalışan iki ssh-agent s var ; (

İlki /usr/bin/ssh-agent(aka MacOSX'ler) ve ardından HomeBrew de /usr/local/bin/ssh-agentçalışıyor.

SourceTree'den bir terminali çalıştırmak, farklılıkları görmemi sağladı SSH_AUTH_SOCK, kullanarak lsofiki farklı ssh-agents buldum ve sonra anahtarları (kullanarak ssh-add) sistemin varsayılanına ssh-agent(yani /usr/bin/ssh-agent) yükleyebildim (yani ), SourceTree yeniden çalışıyordu.

Evet. İstemci makinede ssh-add'ı çalıştırın . Ardından ssh-copy-id userserver@012.345.67.89 komutunu tekrarlayın.

Benim için sorun, genel anahtarın Gitlab'a yanlış kopyalanması / yapıştırılmasıydı. Kopya fazladan bir getiri sağladı. Yapıştırdığınız şeyin tek satırlık bir anahtar olduğundan emin olun.

Ben sign_and_send_pubkey: signing failed: agent refused operationde bir hata aldım . Ama benim durumumda sorun yanlış bir pinentryyoldur.

Benim içinde mülkiyet eski pinentry yoluna işaret ediyordu. Oradaki yolu düzeltip yeniden başlatmak benim için düzeltildi.${HOME}/.gnupg/gpg-agent.confpinentry-programgpg-agent

Günlükleri takip ederek keşfettim journalctl -f. Yanlış yolu içeren aşağıdaki gibi günlük satırları burada:

Jul 02 08:37:50 my-host gpg-agent[12677]: ssh sign request failed: No pinentry <GPG Agent>
Jul 02 08:37:57 my-host gpg-agent[12677]: can't connect to the PIN entry module '/usr/local/bin/pinentry': IPC connect call failed

Çözüm aramak için çok zaman harcadığım için paylaşmam gerekiyor

Çözüm şuydu: https://unix.stackexchange.com/a/351742/215375

Bu komutu kullanıyordum:

ssh-keygen -o -t rsa -b 4096 -C "email@example.com"

gnome-keyring üretilen anahtarı desteklemiyor.

-oArgümanı kaldırmak sorunu çözdü.

Benim durumumda sorun, GNOME anahtarlığının ssh anahtarının kullanılması için geçersiz bir parola tutmasıydı. Bu sorunu gidermek için uygunsuz miktarda zaman harcadıktan sonra koştum seahorseve boş dizeyi tutan girişi buldum. İlk önce bir süre önce parolanın yanlış yazılmasından ve ardından komut satırına geri dönmek için muhtemelen istemciyi iptal etmesinden kaynaklandığını tahmin edebiliyorum. Girişin doğru parola ile güncellenmesi sorunu hemen çözdü. Bu girişi silmek ("oturum açma" anahtarlığından) ve bu ilk istemde parolayı yeniden girmek (ve uygun onay kutusunu işaretlemek) bunu da çözer. Artık ajan, "oturum açma" adlı oturum açma anahtar halkasından doğru parolayı alıyor ve artık ne parola soruyor ne de "işlemi reddediyor". Tabii ki YMMV.

Burada ne işe yaradı: müşteride

1) ssh-ekle

2) ssh-copy-id kullanıcı @ sunucu

Anahtarlar bir süre önce düz "ssh-keygen -t rsa" ile oluşturuldu çünkü önce ssh-add çalıştırmadan istemciden sunucuya (ssh-id-copy ile) ssh ortak anahtarımı kopyaladığım için hata mesajını gönderdim. hatalı bir şekilde onları bir süre önce eklediğimi varsaydığım için.

Son zamanlarda "modern" ssh sürümüne [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 Eylül 2019] yükseltme yapanlar için hızlı not - fedora 31 ile birlikte verilir, artık eski DSA SHA256 anahtarlarını kabul etmiyor gibi görünüyor (benimki 2006 tarihli!) - yeni bir rsa anahtarı oluşturdu, yetkilendirilmişe genel eklendi, istemciye özel ve her şey mükemmel çalışıyor.

önceki öneriler için teşekkürler, özellikle ssh -v çok faydalı oldu