ssh-copy-id çalışmıyor


19

CentOS 5.4'te şifresiz bir SSH girişi kurmaya çalışıyorum:

  1. İstemcide RSA ortak anahtarı oluşturdum.
  2. istemciden sunucuya ssh-copy-id.
  3. Doğrulanmış ~ / .ssh / authority_keys istemci anahtarını içerir.

İstemci hala parola ister. Ne kaçırdım?

Teşekkürler.

EDIT: tavsiye edilen ssh_config ve izinleri kontrol etti. Bu, istemcinin hata ayıklama bilgisidir:

debug2: key: /home/saguna/.ssh/identity ((nil))
debug2: key: /home/saguna/.ssh/id_rsa (0x2b31921be9a0)
debug2: key: /home/saguna/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.1.75.
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/saguna/.ssh/identity
debug3: no such identity: /home/saguna/.ssh/identity
debug1: Offering public key: /home/saguna/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/saguna/.ssh/id_dsa
debug3: no such identity: /home/saguna/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
saguna@192.168.1.75's password: 

Bunu da anladım :(
— Matt Joiner

Yanıtlar:


19

9/10 kez ~ / .ssh / authority_keys doğru modda olmadığı için.

chmod 600 ~/.ssh/authorized_keys

2
FYI, github.com/centic9/generate-and-send-ssh-key adresinde bir kerede gerekli adımları çalıştıran ve ek olarak bana her zaman başım ağrısına neden olan tüm dosya / dizin izinlerini sağlayan küçük bir komut dosyası oluşturdum ...
— centic

5
Bu birisi için işe yaramazsa, @ Gilles'in cevabına da bakmalısınız. Özellikle, ev ve~/.ssh dizinler kullanıcı dışında hiç kimse tarafından yazılamaz.
— ostrokach

Bunun eski olduğunu biliyorum, ama @ centic'e bir milyon teşekkürler. Benim izinleri doğru ama asla $ HOME ve .ssh / dizinleri kontrol için rahatsız emindi.
— jdferreira

Benim için çalıştı. Teşekkürler!
— Ivan Kovtun

12

Bir anahtarla kimlik doğrulamasına izin vermek için / etc / ssh / sshd_config öğesini kontrol edin. İçinde böyle bir şey olmalı ve satırların yorumlanmadığından emin olmalısınız:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

Not: dosyayı değiştirdikten sonra sshd'yi yeniden başlatmayı unutmayın (/etc/init.d/sshd restart)


Patkos Csaba'nın cevabına ek olarak, yerel ve uzak ~ / .ssh klasörünüzün izinlerini kontrol edin.

Benim durumumda, AuthorizedKeysFileyorumlandı ve ben de mutlak bir yol kullanmak zorunda kaldı authorized_keys.
— Andrew

'Kimlik doğrulama aracınızla bağlantı açılamadı' mesajı alıyorum. ssh-add çalışırken
— Manticore

seçilen cevap bu olmalı
— Francisco Tapia

Belki yorumları anlamıyorsunuzdur. Yorum yapılan satırlar size varsayılan değerleri gösterir. Varsayılan değeri istiyorsanız bunları açmanız gerekmez. Özelliği yalnızca varsayılan değeri geçersiz kılmak istiyorsanız kaldırmanız gerekir.
— clearlight

5

Benim sistem ile sorun kullanıcı dizini (/ home / username) yanlış izinler ayarlanmış olduğunu bulundu. Öyleydi drwxr-x-w-ve olması gerekiyordu drwxr-xr-x(sadece sahibi için yazma izniyle). Çözüm chmod kullanmaktı:

sudo chmod 0755 /home/username

1
Yah! Benim için çalıştı. ssh bana bir parola istemi veriyordu çünkü ben persmissions botched.
— clearlight

4

Burada bir uzman değilim ama böyle bir sorunla da karşılaştım, işte diğer tüm önerilere ek olarak iki sentim .

Bazen ssh-copy-idyanlış anahtarı uzak sunucuya kopyalar (birden fazla anahtarınız varsa ve / veya anahtar dosyaları için varsayılan olmayan adlar kullanıyorsanız olabilir) veya kimlik doğrulama aracısı yanlış yapılandırılmış olabilir.

Adam sayfalarından bir alıntı :

-İ seçeneği belirtilirse, ssh aracısında herhangi bir anahtar olup olmadığına bakılmaksızın kimlik dosyası (varsayılan olarak ~ / .ssh / id_rsa.pub) kullanılır. Aksi takdirde, bu: ssh-add -L herhangi bir çıktı sağlarsa, bunu kimlik dosyasına tercih olarak kullanır.

Temel olarak şunu kontrol etmek istersiniz:

  • Sistem kimlik doğrulama aracınız (genellikle ssh-agent) kullanmak istediğiniz anahtarları görür ( ssh-add -Lçıktıyı kontrol edin )
  • ssh-copy-idUzak makineye aynı anahtarı kopyalanan (sadece şifreyi kullanarak uzak sunucuya giriş ve içeriğini kontrol ~/.ssh/authorized_keys)
    • Uzak sunucuda istenen anahtarı görmüyorsanız, ssh-copy-idhangi anahtarı kopyalayacağınızı dolaylı olarak söyleyebilirsiniz :ssh-copy-id -i ~/.ssh/some_public_key

Umarım yardımcı olur.


1
Başardın! Benim ssh-copy-id sorunum kazma : DEFAULT_PUB_ID_FILE=$(ls -t ${HOME}/.ssh/id*.pub 2>/dev/null | grep -v -- '-cert.pub$' | head -n 1)hangi varsayılan alfabetik ilk anahtar olacak - benim durumumda id_boot2docker.pub(görünüşe göre boot2docker ssh şeyler için varsayılan adıdır) vardı. Etrafta bir sürü farklı ssh-copy-id uygulaması var gibi görünüyor; benimki geldi brew install ssh-copy-id, bu da opensh-portable'dan alındı. Benim adam sayfası açıkça ... Bu davranışı bahseder
— Christian Ulbrich

3

En yaygın sorun, sunucu tarafında geçersiz izinlerdir. Ev dizininin hiçbirinin kontrol edin ~/.sshve ~/.ssh/authorized_keysherkes tarafından yazılabilir ama sen (özellikle onlar grup yazılabilir olmamalıdır).

Sorun bu değilse, çalıştırın ssh -vvv serverve müşterinin konuşma görüşüne bakın. Özellikle, istemcinin anahtarı sunucuyla denediğini kontrol edin.


Teşekkür ederim!!! Neden anlamıyorum, ama ev dizini , ~/.sshve ~/.ssh/authorized_keysherkes ama sizin tarafınızdan yazılabilir olamaz.
— ostrokach

2

Yukarıdakilerin hepsine ek olarak, sshd günlük dosyasını her zaman kontrol edebilirsiniz:

/var/log/auth.log

1

Diğer düzeltmeleri denedim ama başkaları tarafından yazılabilir olmayacak şekilde ana dizini değiştirmek zorunda buldum. Başlangıç ​​dizini 777 idi. Onu 755 olarak değiştirdim ve işe yaradı.


1
hoş geldiniz @ dulcana, o şifresiz bir ssh giriş ayarlamaya çalışır, 755 için izinleri değiştirmek sorunu çözmek için nasıl yardımcı olabilir?
— Francisco Tapia

@FranciscoTapia, çünkü sshd, diğer kullanıcıların yetkili_anahtarlar dosyasını kötü amaçlı olarak oluşturamamasını sağlayarak, grup veya başkalarının dosyayı veya ebeveynlerinin herhangi birini yazabileceği ssh anahtarıyla oturum açmayı reddeder. Diğer cevaplar da bundan bahsetti.
— Ángel

0

benim durumumda / etc / ssh / sshd_config şu parametreyi içeriyordu:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys2

Ancak ssh-copy-id, yetkili_anahtarları adında bir dosya oluşturdu, bu yüzden girişi yeni ada değiştirmek zorunda kaldım. kullanımdan kaldırılan yetkili_anahtarlar2 hakkında daha fazla bilgi


0

Omer Dagan'ın daha yeni CentOS 7 için verdiği cevabı tamamlayıcı olarak şunu kullanın:

journalctl -f -u sshd

sunucudaki sshd günlüklerine bakmak için.


-1

Sorun RSAAuthentication / etc / ssh / ssh_config içinde devre dışı bırakılmış olmasıydı

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.