Ubuntu 15 diskimi sistemimden tamamen silerek 15.10'dan 16.04'e yükselttim.

Ubuntu 16.04'ü kurduktan sonra, ssh anahtarlarım onları yedeklemeyi unuttum diye yeniden yarattım, ancak ssh kullanmaya çalıştığımda sign_and_send_pubkey: signing failed: agent refused operationssh sunucuma girmeme izin verdiği için biraz can sıkıcı oluyor ama git ssh kodunu itmeyi reddediyor.

Ben zaten kullanarak anahtarlarını sunucuya ittim ssh-copy-id.

Bağlandığım Sunucu, do-release-upgradekomut aracılığıyla yükseltilmiş bir Ubuntu 16.04 Sunucusudur . Herhangi bir yardım çok takdir edilecektir.

Bir ssh-agentzaten çalışıyor gibi görünüyor ama ekli bir anahtar bulamıyor. Bunu çözmek için, kimlik doğrulama aracısına özel anahtar kimliklerini şöyle ekleyin:

ssh-add

Sonra sshsunucunuza ekleyebilirsiniz .

Ek olarak, şu anda eklenen tüm kimliklerin parmak izlerinin listesini görebilirsiniz:

ssh-add -l

Basit bir çözüm

Aynı problemi 18.04 Ubuntu'da da yaşadım. Hepsi müşteri tarafı özel anahtar izinleriyle ilgili .

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

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

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

chmod 600 ~/.ssh/id_rsa

Aynı problemi yaşadım (aynı semptomlar)

sam@xxxxx:~/.ssh$ ssh centos@123.123.123.123
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 kullanımından kaynaklanıyordu. Çözüme atıfta bulunan posta burada okunabilir .

Kısacası:

1. Ssh komutunun önüne SSH_AUTH_SOCK = 0 ekleyerek sorunu tespit edin. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123
2. Bağlanmayı başarması durumunda. Uygulama Başlangıç ​​Uygulamasını açın (örneğin, Desktop’ın arama işlevini kullanarak) ve gnome anahtarlık kullanımını devre dışı bırakın.
3. Yeniden Başlatma

Sayfa, farklı çözümlerle ilgili benzer bir sorun olması durumunda diğer detayları sunar.

Ben başlamıştı sign_and_send_pubkey: signing failed: agent refused operationbirkaç sunucularına giriş yaparken, okumak Yığın taşması VonC cevabını benim için çözüm ssh-agent ve yeniden başlatın kimlikleri silme gnome-anahtarlık kaldırmak oldu, ilgili hatalar hakkında daha fazla bilgi için bkz.

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

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

GÜNCELLEME:

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

GNOME anahtarlığını korumak istiyorsanız ve agent refused operationhatayı alıyorsanız, şunları kullanın:

eval `ssh-agent -s`
ssh-add

ya da kullan SSH_AUTH_SOCK=0 ssh your-server

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

Yapabiliyorsanız, gnome-keyring 4096 bit RSA anahtarıyla uyumludur, bu nedenle aşağıdakilerle yeni bir anahtar oluşturun:

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

Sunucuya ortak anahtar yükle

$ ssh-copy-id -i ~/.ssh/your-key-name.pub root@12.34.56.78

Aracıya ssh anahtarı ekle

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

Bu herhangi bir ek hack olmadan çalışmalıdır ve gnome-anahtarlık takılı kalabilir.

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

Ubuntu 18.04'e yükselttikten sonra aynı hatayı aldım sign_and_send_pubkey: signing failed: agent refused operation. Ssh anahtarının izinlerinin çok açık olmasından kaynaklandığı anlaşılıyor. Aşağıdaki komut benim için sorunu çözdü chmod 600 .ssh/id_rsa

Sistemimde (ayrıca Ubuntu 16.04, github'a bağlanmaya çalışıyor), .ssh klasörümde hata yapan id_ed25519 bir dosyam vardı ssh-add:

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

Dosyaları çıkardıktan sonra ~/.ssh/id_ed25519*(artık gerek yoktu, daha önceki bir testten geliyordu) her şey yeniden yolunda gitti.

Başıma geldi çünkü özel anahtarımın bir parolası vardı. Çalıştırmak zorunda kaldı ssh-addve sonra şifreyi istedi ve doğru olarak ekledi. Ancak, şimdi bir makineye ssh yaparken parolamı sormuyor.

Yeni bir Ubuntu16.04 kurulumum var ve benzer problemler yaşadım. Açık anahtarımı github'a kopyaladıktan sonra ( github.com adresindeki talimatlara göre ) ve aşağıdaki kontrolü yaptıktan sonra ( github.com sitesinde önerilen ):

ssh -T git@github.com

Aşağıdakiler tarafından karşılandı:

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

Bir şeyi çıkarmadan veya başlangıç ​​yapılandırmamı değiştirmeden hızlıca düzeltmek için terminale aşağıdakini yazdım:

killall gnome-keyring-daemon

Sonra klon çalıştı. Daha sonra yazarak tekrar durdurulan servise başladım:

gnome-keyring-daemon

Daha sonra daha kalıcı bir şekilde bir şeyleri değiştirmek için, ben tavsiyesine uyarak buraya

Fedora 26'yı 28'e yükselttikten sonra da aynı sorunla karşılaştım. Ve günlük dosyası yok

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

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 çözüldü

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

Yorum ekleyerek ed25519 tuşları ile aynı sorunu yaşadım. Mesele cidden anahtar kelimelerdir. Bunu düzeltmek için aşağıdakileri yaptım:

• "Başlangıç ​​uygulamaları" ndaki denetlenmeyen ssh-key-agent (gnome-keyring)
• Ssh ajanı ve gnome ajanı öldürüldü: (killall ssh-ajanı; killall gnome-anahtarlık-arka plan programı)
• Cini yeniden başlattı: (eval ssh-agent -s)
• Anahtarınızı ekleyin: $ ssh-add id_ed25519 id_ed25519 için parola girin: Kimlik eklendi: id_ed25519
• Kar !!

2018'in sonları ve bu böcek veya varyasyonları, hala Xubuntu 16.04'ü ve Xenial'in diğer lezzetlerinden daha fazla veba. 18.04'te de var olsaydı şaşırmam! 2009'dan bu yana bazı şekillerde olmuştur ve Karmic Koala. Redhat, Debian ve Ubuntu'yu etkiledi. Buna söz vermeyin, genel avcıları görün:

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

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

Referanslar:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=576700

Benim durumumda, en belirgin belirti, ssh tuşlarını parola cümleleriyle kullanamamaktı. Arıza ssh tuşlarının yüklenmesini engellediğinden, bunlar da olmayanları etkileyebilir! Ve hiçbir izin problemim yoktu, hepsi cüce anahtarlıktı. Anahtarlarım (evet, farklı SSH sunucuları için birkaçını reddetti!) İzinler, bu konuda birçok cevapta belirtildiği gibi, 600'dü (mal sahibi için, grup ya da diğer hiçbir şey). Yani hiçbir şey orada değiştiremezdim.

Xubuntu'da başlangıç ​​öğelerini devre dışı bırakmanın bir yolu var. Genellikle Unity / Gnome / KDE'de de mümkündür, ancak yüklü olanlara sahip değilim, bu yüzden belirli adımlar atamazsınız. Diğer masaüstlerinden emin değil. SSH ajanı, GPG ajanı ve Gnome'dan buna neden olan diğer öğeleri ve ilgili diğer hataları devre dışı bırakmak yerine, tüm Gnome başlangıç ​​öğelerini kapattım. Bazıları için fazla seçenek olabilir veya olmayabilir, ancak SSH bir sonraki yeniden başlatmada kusursuz çalışmaya geri döndü!

1. Whisker Ana Menüsünü açın -> Ayarlar -> Oturum ve Başlangıç.
2. Sağdaki en son Gelişmiş sekmesini tıklayın.
3. Seçimi kaldır (kapat) Başlangıçta Gnome Hizmetleri'ni başlat.
4. Kapatın ve yeniden başlatın. Oturumu kapatmak da yapabilir, ancak yeniden başlatmanın kesin yapılması gerekir.

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

Yani, yukarıda düzeltmemi verdiğim için, birinin düzelteceğini umuyorum.

Ubuntu, bunu kesin olarak engelleyemedi, çünkü sabit olduğunu iddia eden birçok sürüm için çok sayıda bilet var ve "regresyon" diyen daha fazlası geri döndü.

Debian büyük olasılıkla kumar oynamak istiyor (ellerini yıkamak için), çünkü onlar değil, yukarı akış Gnome.

Redhat muhtemelen sadece ödeme yapan müşteriler için bir düzeltme yapmıştır. Çünkü, tarihsel olarak, Redhat, ilk bakışta cömert olan ücretli Gnome geliştiricilerinin en büyük işvereniydi. Bunun farkına varıncaya kadar, Redhat abonelikleri satmaya devam etmek için asla bu gibi düzeltmeleri ücretsiz sürümlere sokmamak için finansal bir teşvikleri olduğu anlamına gelir.

Gnome muhtemelen onu en kolay yukarı doğru düzeltebilecek olanlardır ve daha sonra diğerleri kod satırı yazmadan test edebilir ve paketleyebilir. Ama okuduğum biletler paketin resmi bir bakıcı olmadan yıllarca tükendiğini söylüyor! Ve şimdi gönüllü olarak bunu yapan iki kişi (teşekkür ederim) bir yedek tasarım yapmakla neredeyse meşguller. Neden tekerleği yeniden icat etmek yerine bir yıl sürse (on yıl oldu!) Bile lastiği tamir etmiyorsunuz ?!

ssh-add

benim için çalışıyor. Ama emin ol

SSH-madde

çalışıyor.

Benim durumumda bu konuya GNOME Keyring neden oldu. GNOME-Keyring'in SSH yeteneklerini tamamen kaldırmadan (bir çok şeyi kıran) devre dışı bırakmak için aşağıdaki talimatları izleyin :

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

ve oturumu yeniden başlatın. Artık gnome-keyring müdahalesi olmadan ssh-agent'ı çalıştırabilirsiniz.

Bazılarını ssh-add, SSH'yi (sunucudaki .ssh / silme, vb. Silme, ama şanssızlık gibi) sıfırlama denedim. Bu yüzden sadece bir gece uyumak zorunda kaldım. Sanırım sunucuda çalışan ssh-agent önbellekte bir şey vardı, o gecenin ilerleyen saatlerinde şimdi uygun değerlerle yenilendi. Her neyse, şimdi bir cazibeye benziyor. Sunucuda 14.04).

# 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! :)

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

Ssh komutunun yardımı olmadan önce SSH_AUTH_SOCK = 0 eklenirse, gnome anahtarlık hatası olur. Sağlanan çözümler ve sorunlar dışında, sorun parola ile ilişkili olabilir. Anahtar için parolanız varsa, gnome anahtarlığı ilk kez giriş yaptığınızda ve hatalı bir şekilde boş girerseniz veya beklenmedik bir şekilde pencereyi kapattıysanız, gnome bunu boş parola olarak kabul eder ve sonsuza dek hatırlar. Hiçbir şey tekrar parola sorulmasına yardımcı olmaz. Açık ssh anahtarlık uygulamasını çözmek ve Parolalar kategorisinin altındaki Giriş bölümüne gidin. Sorunlu tuşa karşılık gelen kaydı bulun ve Özellikler'e girin ve doğru parolayı girin.

Bunun henüz bir cevabı olmayan bir başka nedeni daha var: Anahtar dosya için PEM formatı, ssh-keygenUbuntu'nun gnome-keyring-daemonyeni RFC4716 formatını destekleyene taşınmadan önceki için varsayılan olması durdu .

Yeni bir anahtar oluşturursanız veya anahtarınızdan bir parola ekler / kaldırırsanız, bozulabilir. Anahtar, ssh-keygen -m PEMçalıştırmanız gereken başka bir işlemden önce kullanıyor . Örneğin ssh-keygen -m PEM -p, eski parolayı yeni parola olarak kullanarak ve girerek eski parolaya geri dönüştürebilirsiniz (parola yok).