Ssh anahtarının id_rsa olarak adlandırılması gerekiyor mu?


130

Anahtarlı kimlik doğrulamalı yapı sunucuları oluştururken bu soruna birkaç kez rastladım.

Bunu başkasının yaşadığını merak ediyordum. Şu anki kullanıcım için farklı makinelere bağlanabilecek birkaç anahtarım var. Diyelim ki makine1 ve makine2. Genel anahtarımı ilgili yetkili_ dosyalarına yapıştırdım. İlki, ilk anahtar id_rsa ve ikinci anahtar bender adını verdim.

Bender'a bağlanmaya çalıştığımda verbose ssh bağlantım ile aşağıdaki çıktıları alıyorum

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/bozo/.ssh/.ssh/identity
debug1: Trying private key: /home/bozo/.ssh/.ssh/id_rsa
debug1: Trying private key: /home/bozo/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

Yukarıda görebileceğiniz gibi, yalnızca id_rsa anahtarını sunar. Bu doğru mu? Öyleyse neden? Daha fazla anahtar sunmasını nasıl sağlayabilirim? Kesin olarak gördüğüm bir sorun olduğunu biliyorum, çünkü evde çok fazla sorun yaşamadan çok anahtarım var.

Ayrıca, pub ve özel anahtarların istemci ve sunucu ile nasıl etkileşimde bulunduğuna dair genel bir bakış için de teşekkür ederim. İyi bir fikrim olduğunu düşündüm, ama görünüşe göre bir şeyleri özlüyorum.

Lütfen ve teşekkür ederim.

Yanıtlar:


156

Varsayılan olarak, ssh id_dsave id_rsadosyaları arar . Anahtarların böyle adlandırılması gerekmez, aynı şekilde adlandırabilir mykeyveya hatta farklı bir dizine yerleştirebilirsiniz. Ancak, bunlardan birini yaparsanız, ssh komutundaki anahtara açıkça başvurmanız gerekir:

ssh user@server -i /path/to/mykey

Bir komut kabul etmiyorsa -i, örneğin sshfs, IdentityFileseçeneği kullanın:

sshfs -o IdentityFile=/path/to/mykey user@host:/path/on/remote /mountpoint

Nasıl çalışır

Bir anahtar oluştururken iki dosya alırsınız: id_rsa(özel anahtar) ve id_rsa.pub(genel anahtar). Adlarından da anlaşılacağı gibi, özel anahtar gizli tutulmalıdır ve ortak anahtar halka açıklanabilir.

Genel anahtar kimlik doğrulaması, genel ve özel anahtarla çalışır. Hem istemci hem de sunucu kendi anahtarlarına sahiptir. openssh-serverSunucuyu kurarken ortak ve özel anahtarlar otomatik olarak oluşturulur. Müşteri için bunu kendi başınıza yapmanız gerekir.

Siz (istemci) bir sunucuya bağlandığınızda, genel anahtarlar değiş tokuş edilir. Sunuculardan birini, sunucu ise size ait. Sunucu genel anahtarını ilk aldığınızda, sizden kabul etmeniz istenir. Bu genel anahtar bir süre içinde değişirse, olası bir MITM (ortadaki adam) saldırısı gerçekleştiği için, istemci ile sunucu arasındaki trafiği ele geçiren uyarılırsınız.

Sunucu, bağlanmanıza izin verilip verilmediğini (içinde tanımlanmış /etc/ssh/sshd_config) ve ortak anahtarınızın ~/.ssh/authorized_keysdosyada olup olmadığını kontrol eder . Genel anahtarın reddedilmesinin olası nedenleri:

  • /etc/ssh/sshd_config:
    • AllowUsersveya AllowGroupsbelirtilmişse ancak sunucu kullanıcı grupları veya kullanıcılar listesinde yer almıyorsa (varsayılan giriş yapmalarını kullanıcılara veya gruplara ilişkin kısıtlama olmadığı yerleştirerek, tanımlanmamış).
    • DenyUsersveya DenyGroupsbelirtildiyseniz, kullanıcılar veya gruplar listesindesiniz.
    • Kök olarak giriş yapmaya çalışıyorsunuz, ancak (varsayılan ) PermitRootLoginolarak ayarlanmışsınız .Noyes
    • PubkeyAuthenticationNo(varsayılan yes) olarak ayarlanmış .
    • AuthorizedKeysFilefarklı bir konuma ayarlanmış ve ortak anahtarlar bu dosyaya eklenmemiş (varsayılan .ssh/authorized_keys, ana dizine göre)
  • ~/.ssh/authorized_keys: ortak anahtarınız bu dosyaya eklenmemiş (bu dosyanın kök kullanıcı olarak okunduğunu unutmayın)

Birden çok tuş kullanma

Birden fazla anahtar kullanmak nadir değildir. Çalıştırmak yerine, ssh user@host -i /path/to/identity_filebir yapılandırma dosyası kullanabilirsiniz ~/.ssh/config.

Genel ayarlar, IdentityFile (anahtarlar) ve bağlantı noktasıdır. Bir sonraki konfigürasyon "id_dsa" ve "bender" ı yalnızca aşağıdakilerle bağlantı kurarken kontrol edecektir ssh youruser@yourhost:

Host yourhost
   IdentityFile ~/.ssh/id_dsa
   IdentityFile ~/.ssh/bender

Atlarsanız Host yourhost, ayarlar tüm SSH bağlantılarına uygulanır. Diğer seçenekler de, böyle bu konak maç için belirtilebilir User youruser, Port 2222vb Bu steno ile bağlantı olanağı sağlayacak ssh yourhostyerine ssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/bender.


1
anahtarı neden belirtmem gerekiyor? Mesele şu ki, makineye daha kolay bağlanabiliyorum.
myusuf3

2
@StevenRoose from ssh_config(5): Dosya adı, kullanıcının giriş dizinine veya aşağıdaki çıkış karakterlerinden birine başvurmak için tilde sözdizimini kullanabilir: '% d' (yerel kullanıcının giriş dizini), '% u' (yerel kullanıcı adı), '% l '(yerel ana bilgisayar adı),'% h '(uzak ana bilgisayar adı) veya'% r '(uzak kullanıcı adı). Joker karakterleri belirtmek mümkün değildir, ancak bu sanırım yeterince uygun olmalı. Bir sunucunun gönderdiğiniz her bir anahtarı araştırması gerektiğine dikkat edin, bu nedenle daha az anahtar belirlemek daha iyidir. Ana bilgisayar çalışmasında joker karakterler, tekrar kılavuz sayfasına bakın ssh_config(5).
Lekensteyn

2
@ therobyouknow Her makine için benzersiz bir anahtar çifti oluşturmak zorunda değilsiniz. Genellikle birkaç anahtarınız olur ve anahtarlardan birinin genel anahtarını .ssh/authorized_keysuzaktaki makinelerdeki dosyaya ekleyin . Standart .ssh/id_rsadosya adını (veya id_dsa, id_ecdsa veya son id_ed25519) kullanırsanız, ssh bunu otomatik olarak deneyecek ve IdentityFileconfig (veya için -i path/to/id_fileparametresini ssh) belirtmeniz gerekmez .
Lekensteyn

4
Gerekli detayın ötesine geçen cevapları seviyorum ve konsepti açıklamak için zaman ayırıyorum. Harika iş! +1
user2490003

1
@landed SSH sunucusunun sunucusudur (bir IP adresi veya DNS adı olabilir). Bu bölümü açıklığa kavuşturmaya çalıştım, umarım yardımcı olur.
Lekensteyn

40

Favori yöntemim özel anahtarın otomatik olarak seçilmesine izin veriyor

IdentityFile ~/.ssh/%l_%r@%h_id_rsa

SSH,% l yerel makine ismiyle,% r uzak kullanıcı adıyla ve% h uzak ana makine ile değiştirir, bu nedenle makinemden foo denilen kullanıcı olarak bara bağlanmak istersem, çalıştırırım:

ssh bar

Ve ssh otomatik olarak kullanırdı:

~/.ssh/foo_user@bar_id_rsa

Yerel ana bilgisayar da saklandığından, bu NFS üzerinden paylaşılan ev dizinlerine (makine başına farklı anahtar!) Veya anahtarın hangi makinede olması gerektiğini tanımlamaya olanak tanır ...


1

StevenRoose'un pek çok anahtar belirtmesinin daha uzun sürdüğü yorumuna bakıldığında, çok fazla anahtarla oynuyordum, kişisel çözümümü önermek istiyorum.

O anda kullanmak istediğim anahtara bir sembolik bağlantı oluşturuyorum ve bu sadece üzerinde çalıştığım projeye bağlı olarak çok az değiştiğinden, bundan mutlu oluyorum.

Burada sanal kutu altında çalışan makineler için anahtarlarıma bağlandım:

$ cd .ssh/
$ ln -s adam_vbox-id_rsa.pub id_rsa.pub
$ ln -s adam_vbox-id_rsa id_rsa

$ ls -l
total 12
-rw------- 1 adam adam 1675 2013-10-04 02:04 adam_vbox-id_rsa
-rw-r--r-- 1 adam adam  396 2013-10-04 02:04 adam_vbox-id_rsa.pub
lrwxrwxrwx 1 adam adam   16 2013-10-04 02:17 id_rsa -> adam_vbox-id_rsa
lrwxrwxrwx 1 adam adam   20 2013-10-04 02:17 id_rsa.pub -> adam_vbox-id_rsa.pub
-rw-r--r-- 1 adam adam 3094 2013-10-04 02:09 known_hosts

Biri, ln komutunu tekrar elle yazmak zorunda kalmadan başka bir gruba geçmek için gerçekten hızlı bir komut dosyası ekleyebilir .

Yine, bu sadece iki anahtar için bir çözüm değildir, ancak daha büyük bir sayı için uygulanabilir olabilir.


1
Çalıştığım her sunucu için bash_profile tarafından bir takma ad ekliyorum. Yani bob adında bir sunucu için sadece bu var ... alias bob = "ssh bob.example.com -l pete -i / path / to / key" - sonra sadece bob yazın - ve ben varım!
Peter Bagnall

2
"İşleri önceden bildiğiniz şekilde yapma" bazen daha kolay olsa da, .ssh / configs anahtarlarını ve ana bilgisayarlarını ayarlarsanız daha kolay yaklaşımlar vardır. Bu yorum hem yorum posterine hem de yorumcuna yöneliktir @ Peter-Bagnall
Scott Prive
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.