Ubuntu 16.04 ssh: sign_and_send_pubkey: imzalama başarısız oldu: agent reddedildi işlemi

118

Ubuntu Sistemimi, sistemimden Ubuntu 15 bölümünü tamamen silerek 15.10'dan 16.04'e yükseltdim.

Ubuntu 16.04'ü yükledikten sonra ssh anahtarlarımı yeniden oluşturmayı unuttuğumda yeniden oluşturdum, ancak ssh'i kullanmaya çalıştığımda sign_and_send_pubkey: signing failed: agent refused operation aldığımda bu biraz rahatsız edici oluyor çünkü ssh sunucumdan bana izin veriyor, ama git reddediyor ssh kullanarak kodu itin.

Anahtarları sunucuya ssh-copy-id kullanarak zaten ittim.

Bağlandığım Sunucu, do-release-upgrade komutuyla yükseltilen bir Ubuntu 16.04 Sunucusudur. Herhangi bir yardım büyük takdir edilecektir.

    
sordu Gamerb 25.04.2016 18:31

12 cevap

227

ssh-agent 'nin zaten çalışıyor gibi görünüyor ancak eklenmiş herhangi bir anahtar bulamıyor. Bunu çözmek için kimlik doğrulama aracısına özel anahtar kimlikleri ekleyin:

ssh-add

Ardından sunucunuza ssh koyabilirsiniz.

Ayrıca, şu anda eklediği tüm kimliklerin parmak izlerinin listesini görebilirsiniz:

ssh-add -l
    
verilen cevap Ron 25.04.2016 18:52
25

Aynı problemim vardı (aynı semptomlar)

[email protected]:~/.ssh$ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

... ama çözüm farklıydı.

Sorun GNOME-KEYRING'in kullanımından geliyordu. Çözüme gönderme yapan gönderi buradan .

Kısaca:

  1. Ssh komutunun önüne SSH_AUTH_SOCK = 0 ekleyerek sorunu tespit edin. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh [email protected]
  2. Bağlanmayı başarıyorsa. Uygulama Başlatma Uygulamasını açın (örneğin, Masaüstünün arama işlevini kullanarak) ve gnome anahtarının kullanımını devre dışı bırakın.
  3. Yeniden Başlatma

Sayfa, farklı bir çözümle benzer sorun olması durumunda diğer ayrıntıları sağlar.

    
verilen cevap sam 10.10.2016 08:59
14

Birkaç sunucuya giriş yaparken sign_and_send_pubkey: signing failed: agent refused operation aldım, VonC'nin yanıtını okuyun İlgili hatalar hakkında daha fazla bilgi için Yığın Taşması , benim için çözüm gnome-anahtarlığı kaldırmak, ssh-agent'dan kimlikleri silmek ve yeniden başlatmaktı.

sudo apt-get autoremove gnome-keyring
ssh-add -D

Sonra tüm anahtarlarım mükemmel çalışmaya başladı.

GÜNCELLEME:

Anahtarlığı kaldırmadan geçici çözüm

Cüceler anahtarını tutmak istiyorsanız ve agent refused operation hatasında varsa, şunları kullanın:

eval 'ssh-agent -s'
ssh-add

veya SSH_AUTH_SOCK=0 ssh your-server

kullanın

Anahtarlığı kaldırmadan kalıcı çözüm

Yapabilirseniz, gnome-keyring 4096 bit RSA anahtarı ile uyumludur, bu yüzden aşağıdakilerle yeni bir anahtar oluşturun:

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

Ortak anahtarı sunucuya yükle

$ ssh-copy-id -i ~/.ssh/your-key-name.pub [email protected]

Aracıya ssh anahtarı ekleyin

ssh-add ~/.ssh/your-key-name

Bu ek bir hack olmadan çalışmalı ve cüce anahtarlık takılı kalabiliyor.

(-C [kullanıcı adı] isteğe bağlıdır, ancak Google Cloud gibi sağlayıcılar tarafından gereklidir)

    
verilen cevap Mike 26.04.2016 09:38
8

Sistemimde (ayrıca, Github'a bağlanmaya çalışan Ubuntu 16.04), ssh-add başarısızlığını yapan bir .ssh klasöründe id_ed25519 bir dosyam vardı:

$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed

~/.ssh/id_ed25519* dosyalarını kaldırdıktan sonra (artık bunlara ihtiyaç duymadı, daha önceki bir testten çıktı) her şey tekrar iyi gitti.

    
verilen cevap Daniel Alder 11.06.2016 17:56
6

Benim için özel anahtarın bir parola olduğu için oldu. % Co_de% çalıştırılmalı ve daha sonra parola sorulup doğru şekilde eklenmelidir. Ancak, şimdi bir makineye ssh'ing yaparken parolamı sormuyor.

    
verilen cevap qwertzguy 16.02.2017 02:02
6

Ubuntu 18.04 sürümüne yükselttikten sonra sign_and_send_pubkey: signing failed: agent refused operation aynı hatayı aldım. Ssh anahtarının açık olması nedeniyle izin verildiğini ortaya çıkarır. Aşağıdaki komut benim için sorunu çözdü % Co_de%

    
verilen cevap matthias 04.05.2018 17:44
6

Basit Çözüm

Ubuntu 18.04'te aynı problemi yaşadım. Bu, istemci tarafı özel anahtar izinleriyle ilgili. .

$ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation

Dosya izinleri çok açık (0644).

Aşağıdaki komut çözüldü:

chmod 600 .ssh/id_rsa
    
verilen cevap Antonio Feitosa 31.05.2018 16:56
2

ed25519 anahtarlarında aynı sorunu yaşadığım için yorum ekliyorum. Sorun gerçekten cüce anahtarlıktır. Bunu düzeltmek için şunları yaptım:

  • "başlangıç ​​uygulamaları" nda işaretlenmemiş ssh-anahtar-aracı (gnome-anahtarlık)
  • Ssh-ajan ve gnome ajanını öldürdü: (killall ssh-agent; killall gnome-keyring-daemon)
  • Daemon'u yeniden başlattı: (değerlendirme ssh-agent -s )
  • Anahtarınızı ekleyin: $ ssh-add id_ed25519 id_ed25519 için parola girin: Kimlik eklendi: id_ed25519
  • Kar !!
verilen cevap Matt 16.12.2016 16:03
2

Fedora 26’dan 28’e yükseltme yaptıktan sonra aynı sorunla karşılaştım. Ve günlük dosyaları yok

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

[email protected]  ~  ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password:

hata mesajı gerçek sorunu işaret etmiyor. Sorun

tarafından çözüldü
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
    
verilen cevap Anto P Joseph 09.06.2018 12:15
0

Ssh-add, SSH'yi sıfırlama, sunucuda .ssh / sunucu ve böyle bir şans yok gibi birkaç şey denedim. Bu yüzden bir gece boyunca uyumak zorunda kaldım. Neden? Sunucuda çalışan ssh-agent'ın önbelleğinde, şimdi uygun değerlerle o gecede yenilenen bir şeyler vardı sanırım, her neyse, şimdi bir çekicilik gibi çalışıyor. localhost, 14.04 on server).

# on local host:
$ ssh-keygen
# (yes, overwrite the default file, and let the passphrase be empty)
$ ssh-copy-id ***.***.*.**
# (insert proper server IP address)
# now test
$ ssh ***.***.*.**
# this should have erected in .ssh/ on the server:
# -rw------- 1 *** *** 2000 aug.  11 09:55 authorized_keys
# no other magic going on! :)
    
verilen cevap untill 11.08.2016 10:12
0

Bilinen ana dosyamı bıraktım ve işe yaradı. Tekrar bir şifre koymak zorunda kaldı, ama sonunda doğru şifreyi kabul etti. Yeni bir kurulumdan sonraydı.

    
verilen cevap possumkeys 01.11.2016 08:46
0

2018'in sonu ve bu böcek ya da onun varyasyonları hala Xubuntu 16.04 ve Xenial'in diğer tatlarından daha fazla. 18.04'te de var ise şaşırmayacağım! 2009'dan beri bazı formlarda ve Karmik Koala'da. Redhat, Debian ve Ubuntu’yu etkiledi. Bunun için sözümü almayın, genel hata mesajlarını görün:

İşte

Ve bu hatada, diğer 3 için de listeleri bulabilirsiniz:

Kaynaklar:

İşte

İşte

İşte

Benim durumumda, en belirgin belirti ssh anahtarlarının parolalarla kullanılamamasıydı. Arızasız olanları da etkileyebilir, çünkü arıza ssh tuşlarının tamamen yüklenmesini önler! Ve izinlerim yoktu, hepsi cüce anahtarlıktı. Anahtarlarım (evet, farklı SSH sunucuları için birkaçını reddetti!) İzinler, bununla ilgili birçok cevapta belirtildiği gibi 600'di (sahibi için rw, grup veya başka bir şey değil). Yani orada hiçbir şey değiştiremedim.

Xubuntu'da, başlangıç ​​öğelerini devre dışı bırakmanın bir yolu var. Genellikle Unity / Gnome / KDE'de de mümkündür, ancak bunları yüklemedim, bu yüzden belirli adımları alamıyorum. Diğer masaüstü bilgisayarlardan emin değilim. SSH aracısını, GPG aracısını ve buna neden olan Gnome'dan diğer öğeleri ve diğer ilgili hataları devre dışı bırakmak yerine, tüm Gnome başlangıç ​​öğelerini kapattım. Bazıları için overkill veya bir seçenek olmayabilir, ancak SSH bir sonraki yeniden başlatma için kusursuz çalışmaya geri döndü!

  1. Whisker Ana Menüsünü Aç - & gt; Ayarlar - & gt; Oturum ve Başlangıç.
  2. Gelişmiş sekmesini tıklayın, sağdaki son.
  3. İşaretlemeyi kaldırın (devre dışı bırakın) Başlangıçta Gnome Hizmetlerini başlatın.
  4. Kapat ve yeniden başlat. Çıkış yapmak da yapabilir, ancak yeniden başlatma mutlaka yapılmalıdır.

Yukarıda açıklanan GUI'nin ekran görüntüsü:

Öyleyse, düzeltmeyi yukarıda verdiğimden, birilerinin tamir edeceğini umuyorum.

Ubuntu, iyice ezmek için başarısızlıkla sonuçlandı, çünkü birkaç sürüm için sabit olduğunu iddia eden çok sayıda bilet var ve daha fazlası "gerileme" diyor, geri döndü.

Debian büyük olasılıkla punt yapmak ister (ellerini yıkamak) çünkü onlar değil, upstream Gnome.

Redhat muhtemelen sadece ödeme yapan müşteriler için geçerli. Çünkü, tarihsel olarak, Redhat, ilk bakışta cömert olan ücretli Gnome geliştiricilerinin en büyük tek işvereni. Bunun farkına varana kadar, Redhat aboneliği satmaya devam etmek için, bu gibi düzeltmeleri hiçbir zaman ücretsiz sürümlere koymayacak finansal güveni olduğu anlamına gelir.

Gnome, muhtemelen en kolay şekilde yukarı akışını ayarlayabilen kişilerdir ve sonra diğerleri kod yazmadan kendileri test edebilir ve paketleyebilirler. Ama okuduğum biletler, paketin yıllarca resmi bir bakıcı olmadan kaçtığını söylüyor! Ve şimdi gönüllü olarak yapan iki kişi (teşekkür ederim) neredeyse bir yedek tasarlamakla meşgul. Tekerleği yeniden icat etmek yerine, bir yıl sürse bile (bir on yıl oldu!) Neden bir lastiği tamir etmeyesiniz?!

    
verilen cevap Lubo Diakov 23.07.2018 16:19

Etiketlerdeki diğer soruları oku