sshd arka plan programı olduğunda SADECE genel anahtar kimlik doğrulaması başarısız oluyor


33

Bunun nasıl olduğu hakkında hiçbir fikrim yok. Dağıtım Scientific Linux 6.1'dir ve her şey ortak anahtarla kimlik doğrulaması yapmak üzere ayarlanmıştır. Ancak, sshd bir arka plan programı olarak çalıştığında (hizmet sshd başlangıcı), genel anahtarları kabul etmez. (Bu günlük kaydını elde etmek için, -ddd seçeneğini eklemek üzere sshd komut dosyasını değiştirdim)

debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1

Eğer sshd hata ayıklama modunda çalıştırılıyorsa /usr/sbin/sshd -ddd, kimlik doğrulama bir cazibe işlevi görür:

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0

Herhangi bir fikir?? Böyle bir şey gören oldu mu?

Notlar:

Dosya izinleri iki kez kontrol edildi:

# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root  786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root  393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root  448 Oct 13 12:51 known_hosts

Sshd'nin "daemon mode" da kök dosyalarına erişip erişemediği soruldu. Bu soruya en yakın cevap:

# netstat -ntap | grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      19847/sshd 
# ps -ef | grep 19847
root     19847     1  0 09:58 ?        00:00:00 /usr/sbin/sshd

Eğer sshd root olarak çalışıyorsa, kendi dosyalarına erişmenin mümkün olmadığını bilmiyorum. SELinux bunun nedeni olabilir mi?


1
Sshd init betiği ilginç bir şey yapar mı? (/Etc/init.d/sshd? Olmalıdır) komut satırında yapmıyorsunuz? 'Sshd start service' yerine 'sh -x /etc/init.d/ssh start' komutunu deneyin.
PT

Yanıtlar:


42

Evet, SELinux muhtemelen nedenidir. .sshDir muhtemelen mislabeled. Bak /var/log/audit/audit.log. Etiketlenmeli ssh_home_t. İle kontrol edin ls -laZ. restorecon -r -vv /root/.sshGerekirse koş .


1
Evet, SELinux bunun nedeni idi: tip = AVC msg = denetim (1318597097.413: 5447): avc: reddedildi {pid = 19849 için comm = "sshd" name = "onay_dosyası" dev = dm-0 ino = 262398 scontext = unconfined_u : system_r: sshd_t: s0-s0: c0.c1023 tcontext = unconfined_u: object_r: admin_home_t: s0 tclass = dosya "restorecon -r -vv /root/.ssh" çalıştırıldıktan sonra çalışır. Çok teşekkürler.
user666412

1
teşekkürler selinux komut satırı düzeltme için teşekkürler TEŞEKKÜR Ben ssh anahtar kimlik doğrulaması kullanarak redhat kurumsal 6.2 sunucusuna root olarak ssh neden olabilirdi yaş için bulmaya çalışıyorum, ancak root olmayan bir kullanıcı olarak ssh şifre girmek zorunda kalmadan. "ssh -v" olağandışı bir şey göstermedi. Dosya korumalarını /home/example/.ssh adresinde kontrol ettim ve yeniden kontrol ettim. "/ Usr / sbin / sshd -d" komutunu çalıştırıncaya kadar ve normalde çalışan bir nedenden başka bir şey olduğunu fark ettim. farklı bir google aramayı denedi ve bunu buldu. Bu yüzden, semptomlar ro gibi ssh olabilir
Paul M

1
Bunu bütün dosya sisteminde, yani restorecon -r /YMMV'de yapmak zorunda kaldım .
Irfy

1
Bunu denedim - ama hala çalışmıyor. Denetim günlüğünde type=AVC msg=audit(1434642809.455:94717): avc: denied { search } for pid=27032 comm="sshd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dirne anlama geldiğinden emin değilim
Yehosef

1
Cevap olarak name="/"- Ben restorecon -r /tavsiye @Rrfy olarak çalıştırmak zorunda kaldı .
Yehosef

3

Ben de aynı sorunu yaşadım. Benim durumumda, restorecon ve chcon işe yaramadı.

Selinux’u kapatmak istemedim. Çok fazla araştırmanın ardından nihayet, ev rehberimin başka bir yere (NFS) bağlandığı için bunu anladım. Beni içine alan bu hata raporunu buldum .

Koştum:

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

use_nfs_home_dirs öğesinin kapalı olduğunu ve ardından:

sudo setsebool -P use_nfs_home_dirs 1

açmak için.

Şimdi anahtarımı kullanarak ve bir şifre girmeden makineme ssh yapabilirim. Use_home_nfs_dirs boolean'ı değiştirmek benim için gereken şeydi.


1

Mark Wagner'in cevabını eklemek için, eğer özel bir ev dizin yolu kullanıyorsanız (yani değil /home), SELinux güvenlik bağlamını ayarladığınızdan emin olmanız gerekir. Bunu yapmak için, örneğin, kullanıcının giriş dizinleri varsa /myhome, çalıştırın:

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome

semanagesudo yum install policycoreutils-python
CentOS'taysanız

0

Bağlantıları test ederken farklı anahtarlar kullanıyorsunuz, 0x7f266e1a8840 - 0x7f85527ef230 'Ssh -v example.com'u kullanarak bir daemon olarak çalışan ve hata ayıklama modunda çalışan sshd'ye bağlanmayı deneyin ve ssh tarafından "RSA genel anahtarını sunuyor" dizesi etrafında kullanılan anahtarları arayın.


Evet, id_rsa ve id_dsa vardı. DSA anahtarı gitti ve testi tekrarlayacağım.
user666412

Belirtilen değer debug3: mm_answer_keyallowed: key 0xFFFFFFFFFF, sshd her yeni bir bağlantı aldığında değişecektir. Bunu onaylamak için, SSH'nin çalıştığı bir sunucu bulun, sshd LOGLEVEL'i hata ayıklamak3 için kranklayın, sshd'yi yeniden başlatın, çalıştırın tail -f /var/log/secure |grep mm_answer_keyallowedve ardından birkaç kez oturum açın, her bağlantı arasında birkaç saniye (veya dakika) bekleyin. Değerin her seferinde değiştiğini göreceksiniz. Ve aslında bana bir sayaç gibi görünüyor.
Stefan Lasiewski 24:13
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.