Neden hala ortak anahtar kimlik doğrulaması ile ssh ile bir şifre istemi alıyorum?

Burada bulduğum URL’den çalışıyorum:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

Benim ssh istemcisi Ubuntu 64 bit 11.10 masaüstü ve sunucum Centos 6.2 64 bit. Yönergeleri takip ettim. Hala ssh'den bir şifre istemi alıyorum.

Bundan sonra ne yapacağımdan emin değilim.

~/.sshDizindeki ve içeriğindeki izinlerin uygun olduğundan emin olun . Ssh key auth'yu ilk kurduğumda, ~/.sshklasörü uygun şekilde ayarlamamıştım ve bana bağırdı.

• Ana dizininiz ~, ~/.sshdizininiz ve ~/.ssh/authorized_keysuzaktaki makinedeki dosya yalnızca sizin tarafınızdan yazılabilir olmalıdır: rwx------ve rwxr-xr-xiyi rwxrwx---durumdasınız, ancak grubunuzdaki tek kullanıcı olsanız bile iyi değil (sayısal modları tercih ediyorsanız: 700veya 755değil 775) . Sembolik bir link
  ise ~/.sshveya authorized_keyssembolik ise , kanonik yol (sembolik linkler genişletilmiş olarak) kontrol edilir .
• Kişisel ~/.ssh/authorized_keys(uzaktan makinede) dosyası (en az 400) okunabilir olmalıdır, ama aynı zamanda olmasını gerekir yazılabilir (600) Bunda herhangi fazla anahtar katacak eğer.
• (Yerel makinede) Özel anahtarınız dosya okunabilir ve onlara yalnızca yazılabilir gerekir: rw-------yani 600.
• Ayrıca, SELinux zorlamaya ayarlanmışsa, çalıştırmanız gerekebilir restorecon -R -v ~/.ssh(bkz. Örneğin Ubuntu bug 965663 ve Debian hata raporu # 658675 ; bu, CentOS 6'da yamalı ).

¹ _{grubunuzdaki sadece kullanıcı iseniz grup yazılabilirliğini sağlar kod yamalı bazı dağılımlar (Debian ve türevleri) hariç.}

Sunucuya kök erişiminiz varsa, bu tür sorunları çözmenin kolay yolu, sshd'yi hata ayıklama modunda çalıştırmak /usr/sbin/sshd -d -p 2222(sunucuda olduğu gibi bir şey yayınlayarak (sshd çalıştırılabilirinin tam yolu gerekli which sshdolabilir, yardımcı olabilir) ve ardından istemciyle bağlantı kurmaktır ssh -p 2222 user@host. Bu, SSH'nin arka planında durmaya ve her bağlantı hakkında hata ayıklama bilgilerini göstermeye zorlar. Gibi bir şey arayın

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

Alternatif bir bağlantı noktasının kullanılması mümkün değilse, SSH arka planını geçici olarak durdurabilir ve hata ayıklama modunda bir tane ile değiştirebilirsiniz. SSH arka planını durdurmak mevcut bağlantıları kesmez, bu yüzden uzak bir uçbirim üzerinden yapmak mümkün olur, fakat biraz risklidir - eğer hata ayıklama değişimi çalışmadığı zaman bağlantı bir şekilde koparsa, makinenin dışına kilitlenirsiniz. yeniden başlatana kadar. Gerekli komutlar:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(Linux dağıtımınıza bağlı olarak, ilk / son satır systemctl stop sshd.service/ systemctl start sshd.serviceyerine olabilir .)

Eviniz dir şifreli mi? Eğer öyleyse, ilk ssh oturumunuz için bir şifre girmeniz gerekecektir. Aynı sunucuya ikinci ssh oturumu auth anahtarı ile çalışıyor. Bu durumda, sizi authorized_keysşifrelenmemiş bir dizine taşıyabilir ve içindeki yolu değiştirebilirsiniz ~/.ssh/config.

Yaptığım şey, /etc/ssh/usernamekullanıcı adına ait ve doğru izinlere sahip bir klasör oluşturmak ve authorized_keysdosyayı buraya yerleştirmek . Ardından AuthorizedKeysFile yönergesini şurada değiştirdi /etc/ssh/config:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Bu, birden çok kullanıcının izinlerden ödün vermeden bu ssh erişimine sahip olmasını sağlar.

Anahtarları uzaktaki makineye kopyaladıktan ve içine yerleştirdikten sonra şöyle bir authorized_keysşey yapmalısınız:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Sadece aşağıdaki komutları deneyin

1. ssh-keygen

   İstemi alana kadar Enter tuşuna basın

2. ssh-copy-id -i root@ip_address

   (Bir kez ana bilgisayar sisteminin şifresini isteyecektir)

3. ssh root@ip_address

   Şimdi şifreniz olmadan giriş yapabilmeniz gerekir

Uzaktan kumandadaki giriş dizini doğru ayrıcalıklara sahip olmadığında zorluklarla karşılaştım. Benim durumumda, kullanıcı ekip içindeki bazı yerel erişimler için ev dizini 777 olarak değiştirdi . Makine artık ssh tuşlarına bağlanamadı. İzni 744 olarak değiştirdim ve tekrar çalışmaya başladı.

RedHat / CentOS 6'daki SELinux'un pubkey kimlik doğrulamasıyla ilgili bir sorunu var , muhtemelen bazı dosyalar oluşturulduğunda selinux ACL'lerini doğru şekilde ayarlamıyordur .

Kök kullanıcının SElinux ACL'lerini manuel olarak düzeltmek için:

restorecon -R -v /root/.ssh

Aynı problemle karşılaştık ve cevaptaki adımları izledik. Ama yine de bizim için işe yaramadı. Bizim sorunumuz, oturum açma işleminin bir istemciden başka birinden değil (.ssh dizininin NFS takılı olması ve her iki istemcinin de aynı anahtarları kullanması) oldu.

Bu yüzden bir adım daha ileri gitmek zorunda kaldık. Ssh komutunu ayrıntılı modda çalıştırarak çok fazla bilgi edinirsiniz.

ssh -vv user@host

Keşfettiğimiz şey, varsayılan anahtarın (id_rsa) kabul edilmediği ve bunun yerine ssh istemcisinin, istemci ana bilgisayar adıyla eşleşen bir anahtar önerdiği idi:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

Açıkçası bu başka bir müşteriden işe yaramayacak.

Bu nedenle, bizim durumumuzdaki çözüm, varsayılan rsa anahtarını user @ myclient komutunu kullanmaktı. Bir anahtar varsayılan olduğunda, müşteri adı için kontrol yoktur.

Sonra anahtardan sonra başka bir problemle karşılaştık. Anlaşılan anahtarlar yerel ssh aracısında önbelleğe alınmış ve hata ayıklama günlüğünde aşağıdaki hatayı aldık:

'Agent admitted failure to sign using the key'

Bu, anahtarları ssh aracısına yeniden yükleyerek çözüldü:

ssh-add

Sunucu sonunda SSH özledim yapılandırması olurdu. Sunucu tarafı sshd_config dosyasının düzenlenmesi gerekiyor. Bulunan /etc/ssh/sshd_config. Bu dosyada değişkenleri değiştirin

• ChallengeResponseAuthentication, PasswordAuthentication, UsePAM için 'hayır'

• PubkeyAuthentication için 'hayır' ila 'evet'

Http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/ adresine göre

Bunun AuthorizedKeysFiledoğru yeri gösterdiğinden emin olun, %ukullanıcı adı için yer tutucu olarak kullanın :

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

Sadece çizgiyi yorumlamanız gerekebilir:

YetkiliKeysFile .ssh / official_keys

Değişikliklerin gerçekleşmesi için ssh servisini yeniden yüklemeniz gerektiğini unutmayın:

service sshd reload

İki yorum: bu, orijinal dosyanın üzerine yazacaktır. Sadece oluşturulan genel anahtarı kopyalarım ve şöyle bir şey yapardım:

cat your_public_key.pub >> .ssh/authorized_keys

Bu, kullanmak istediğiniz anahtarı önceden var olan anahtar listesine ekleyecektir. Ayrıca, bazı sistemler dosyayı kullanır authorized_keys2, bu nedenle , sadece authorized_keysve arasında işaret eden sert bir bağlantı oluşturmak iyi bir fikirdir authorized_keys2.

Benim çözümüm, hesabın kilitlenmesiydi. Mesaj / var / log / secure'da bulundu: Hesap kilitli olduğu için kullanıcıya izin verilmedi Çözüm: kullanıcıya yeni bir şifre verin.

Benzer bir sorunla karşılaştım ve hata ayıklama modunu kullanarak adımları takip ettim.

/usr/sbin/sshd -d

Bu aşağıdaki sonucu gösterdi

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

Gerçekten kafa karıştırıcıydı

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

Kök dizinin her biri için izinleri olduğunu gösterdi. Bunu, başkalarının izin alamayacağı şekilde değiştirdik.

[root@sys-135 ~]# chmod 750 /root

Anahtar kimlik doğrulaması çalışmaya başladı.

/ Etc / selinux / config dosyasında SELINUX'u devre dışı bırakarak değiştirmek, şifresiz ssh işleminin başarılı bir şekilde yapılmasını sağladı.

Daha önce bunu bir şekilde yapabilirim. Şimdi her iki taraftan da parolasız ssh yapabiliyorum.

Yanlış yaptığım bir şey, ev dizini üzerindeki sunucu sistemindeki mülkiyetti. Sunucu sistemi varsayılan olarak ayarlandı: varsayılan yani ben:

chown -R root:root /root

Ve işe yaradı. Başka bir Ucuz çözüm geçici StrictModes devre dışı bırakmaktır: StirctModes no. sshd_config içinde. Bu, en azından anahtar değişimi ve bağlantı protokollerinin iyi olup olmadığını size söyleyecektir. O zaman gidip kötü izinleri avlayabilirsin.

Benim için çözüm, Wojtek Rzepala'nın karşıtıydı : Hâlâ kullandığımı authorized_keys2, kullanımdan kaldırıldığını fark etmedim . Ssh kurulumum, muhtemelen sunucu güncellendiğinde bir noktada çalışmayı durdurdu. Yeniden adlandırma .ssh/authorized_keys2olarak .ssh/authorized_keyssorun sabit.

D'oh!

Geçmişte ssh şifresiz bir kurulum yapmayı açıklayan bazı dersler verdim, ancak bazıları ne yazık ki yanlıştır.
Tekrar baştan başlayalım ve her adımı kontrol edelim:

1. İSTEMCİ'NDEN - Anahtar oluştur: ssh-keygen -t rsa
   Genel ve özel anahtar ( id_rsa.pubve id_rsa) otomatik olarak ~/.ssh/dizine kaydedilir .
   Boş bir parola kullanıyorsanız kurulum daha kolay olacaktır. Bunu yapmak istemiyorsanız, o zaman hala bu kılavuzu takip edin, ancak aşağıdaki madde işaretleme noktasını da kontrol edin.
   
   
2. İSTEMCİ'NDEN - Genel anahtarı sunucuya kopyala : ssh-copy-id user@server
   İstemci genel anahtarı sunucunun konumuna kopyalanacak ~/.ssh/authorized_keys.
   
   
3. İSTEMCİ'DEN - Sunucuya bağlan:ssh user@server
   
   

Şimdi, açıklanan 3 adımdan sonra hala çalışmıyorsa, aşağıdakileri deneyelim:

• İstemci ve sunucu makinesinde ~/sshklasör izinlerini kontrol edin .
• Giriş /etc/ssh/sshd_configiçinde sunucuya sağlamak için RSAAuthentication, PubkeyAuthenticationve UsePAMseçenekler devre dışı değildir, bunlar ile varsayılan olarak etkin olabilir yes.
• Müşteriniz anahtarını oluştururken Bir parola girdiyseniz, o zaman deneyebilirsiniz ssh-agent& ssh-addOturumunuzda şifre daha az bağlantıları elde etmek.
• Anahtar kimlik doğrulamasının neden atlanmadığını bulmak /var/log/auth.logiçin sunucudaki içerikleri kontrol edin .

PuTTY'nin Ubuntu 16.04 makinesine bağlanmasıyla da aynı sorunu yaşıyordum. PuTTY'nin pscp programı aynı anahtarla iyi çalışıyordu (ve aynı anahtar PuTTY'de başka bir ana bilgisayara bağlanmak için çalışıyordu).

@UtahJarhead'den gelen değerli yorum sayesinde, /var/log/auth.log dosyasını kontrol ettim ve aşağıdakileri buldum:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Yeni OpenSSH sürümlerinin DSA anahtarlarını varsayılan olarak kabul etmediği ortaya çıktı. Bir DSA'dan bir RSA anahtarına geçtiğimde, iyi çalıştı.

Başka bir yaklaşım: bu soru SSH sunucusunu DSA anahtarlarını kabul edecek şekilde nasıl yapılandıracağını tartışıyor: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

Bu adımlar size yardımcı olmalıdır. Bunu 64bit Ubuntu 10.04 makinelerinde düzenli olarak kullanıyorum.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

Bunu bazı komut istemleri içeren bir komut dosyasına koyabilir ve

script_name username remote_machine

Ben de ssh ile benzer bir sorun yaşadım. Benim durumumdaki sorun hadoop cloudera (centos 6'daki rpm'den) kurduğum ve home dizini ile kullanıcı hdfs'i oluşturmamdı.

/var/lib/hadoop-hdfs(standart değil /home/hdfs).

/ Etc / passwd konumunda /var/lib/hadoop-hdfsdeğiştirdim /home/hdfs, home dizinini yeni konuma taşıdım ve şimdi genel anahtar kimlik doğrulamasıyla bağlantı kurabiliyorum.

Sadece bu aynı problem vardı ve benim için çözüm belirlemekti UsePAMiçin no. Gördüğün gibi, PasswordAuthenticationayarlanmış olsa bile no, yine de alacaksın keyboard-interactiveve benim durumumda yerel ssh programım bir sebepten ötürü buna devam etmeyi sürdürdü.

Aynı durumdaki herkese yardımcı olmak için ekstra arka plan: Dropbear çalışan bir ana bilgisayardan OpenSSH çalıştıran bir kişiye bağlanıyorum. İle PasswordAuthenticationve UsePAMhem set nouzak makinede ben girerseniz, ben şu mesajı alırsınız ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

Kimlik dosyasının sağlanmasıyla -iher şey beklendiği gibi çalışır.

Burada biraz daha fazla bilgi olabilir.

İzinleri kontrol ettikten ve burada listelenen birkaç başka çözümü denedikten sonra, sunucudaki ssh dizinini kaldırdım, genel anahtarımı tekrar ayarladım.

Sunucu komutları:

# rm -rf ~/.ssh

Yerel komutlar:

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

Sunucuda:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

Öyleydi directory permission issue. Sunucuda 777 idi, öyleyse I changed it back to 700. Bu fixedbenim sorunum sunucuya ssh password less login failurekopyaladıktan sonra bile .$USER/.ssh/id_rsa.pub$USER/.ssh/authorized_keys

Yine bir başka seçenek de @ Jajarish'in cevabının bir çeşididir : stracessh daemon'a .

Önemli bir avantaja sahip, sshd'yi durdurmamız gerekmiyor, eğer bir şeyler kötüye giderse tam bir kilitlenmeye neden olabilir.

İlk olarak, ana sshd işleminin pidini bulduk. Burada bir i uygulayarak görebiliriz pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

Bildikten sonra, ödemenin 633 straceolduğunu, çocuklarını takip ederek yapabiliriz :

strace -p 633 -s 4096 -f -o sux

Sonuç, bu sshd'nin ve alt işlemlerinin yaptığı her şeyin suxyerel dizinde adı geçen dosyaya bölünmesi olacaktır .

Sonra sorunu yeniden oluşturun.

Bizim için çoğunlukla anlaşılmaz / ilgisiz olan, ancak her yerde olmayan, büyük bir çekirdek çağrı günlüğü listesi olacaktır. Benim durumumda, önemli olan şuydu:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

Bu, sshd'nin hesap kilitli olduğu için Kullanıcı cica'sına izin verilmediği mesajını kaydetmeye çalıştığı için sadece oturum açmaya çalıştı , çünkü kayıt tutma bunun için yeterli değil. Ancak zaten biliyoruz, hesap kilitli olduğundan pubkey reddedildi.

Henüz bir çözüm değil - şimdi google'a ihtiyacımız var, sshd durumunda "kilitli hesap" demek. Büyük olasılıkla önemsiz /etc/passwd, /etc/shadowsihirbazlık olacak, ancak önemli olan şey yapıldı - sorun gizemli değil, kolayca hata ayıklanabilir / aşındırıcı bir durumdur.

Benim durumumda tüm izinlerim doğru ve svv-flag ile çalışırken bile sorunun ne olduğunu çözemedim.

Böylece uzak ana bilgisayarda yeni sertifika oluşturdum

ssh-keygen -t rsa -C "your_email@example.com"

ve oluşturulan anahtarları yerel makineye kopyaladı ve uzaktaki ana makinedeki ~ / .ssh / yetkili_ anahtarlarına yeni ortak anahtar ekledi

cat id_rsa.pub >> authorized_keys

Uzaktaki ana makine bağlantısından üretilen anahtarları kullanmak artık işe yarıyor. Diğer çözümler başarısız olursa bu da denenecek başka bir şey.

Senaryom, backupbotbirincil hesabı oluşturduktan sonra, başlangıçta backupbotkullanıcıyı oluşturmak için oturum açabilen bir kullanıcı oluşturduğum bir NAS sunucum olmasıydı . Kurcalıyor sonra sudo vim /etc/ssh/sshd_config, ve oluşturma backupbotkullanıcıyı, vimen azından Ubuntu 16.04 üzerinde, oluşturabilir ve sizin dayalı ~/.vimrcgeneli, bir takas dosyası sizin vim oturumun düzenleme bıraktı /etc/ssh/sshd_config.

/etc/ssh/.sshd_config.swpVar olup olmadığını kontrol edin: var olup olmadığını kaldırır ve sshdarka plan planını yeniden başlatır:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

Bu sihirli bir şekilde sorunumu çözdü. Daha önce tüm izinlerimi ve hatta kamu ve özel anahtarların RSA parmak izlerini kontrol etmiştim. Bu garip ve muhtemelen sshd, özellikle bu sürüm ile bir hata :

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 Mart 2016