SSH Anahtarı kimlik doğrulaması başarısız

Ben üzerinde hiçbir kontrole sahip bir CentOS sunucuya ssh çalışıyorum .. yönetici sunucuya benim ortak anahtar ekledi ve hata benimle yatıyor ama ben ne olduğunu anlayamıyorum ısrar ediyor.

.Ssh içinde yapılandır:

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

Anahtar dosyalarımdaki izin:

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

Herhangi bir anlam ifade edemiyorum bağlantı günlüğü:

tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

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


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Bu genellikle birisinin izinlerde ek değişiklikler yapmadığı varsayılarak sunucu tarafında SSH yetkili anahtar izni sorunlarının çoğunu çözer .

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

Yöneticiniz .ssh / dizinini veya .ssh / yetkili_anahtarlar dosyasını kök olarak oluşturduysa (en yaygın olarak bunun nasıl gerçekleştiğini gösterir), dosyanın başka bir kullanıcının sahip olmasına (root! Bile olsa) izin verilmez.

Userify (sorumluluk reddi: kurucu ortak) bunu otomatik olarak aynı şekilde yapar .. https://github.com/userify/shim/blob/master/shim.py#L285

Aynı sorunu iki sunucuda yaşadım: Debian streç ve bir NAS üzerinde çalışan bir Linux (Synology DS715)

her iki durumda da sunucudaki giriş dizini izinlerinin yanlış olduğu ortaya çıktı

sunucudaki auth.log çok yardımcı oldu

Authentication refused: bad ownership or modes for directory /home/cyril

Linux'ta, yazma / grup biti (drwxrwxr - x) vardı, bu yüzden en azından yazma grubunu (chmod gw ~ /) kaldırmak zorunda kaldım ve sonra çalıştı

Synology'de, hangi nedenle olursa olsun, yapışkan bir parça vardı

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

İle değiştirmek zorunda kaldım

chmod -t ~/

ve sonra şifre olmadan bağlanabildim

CentOS 7 kullanırken, sshd kullanan diğer Linux işletim sistemleri için de geçerli olduğundan eminim. Kök erişimi ile kimlik doğrulamanın neden başarısız olabileceği hakkında daha fazla bilgi belirleyebilirsiniz. Bunu yapmak için:

1. Sshd için günlüğe kaydetmeyi etkinleştir: vi /etc/ssh/sshd_config
2. Günlük kaydı altında:

SyslogFacility AUTH LogLevel INFO

1. LogLevel INFO öğesini LogLevel DEBUG olarak değiştir
2. Kaydet ve çık
3. Sshd'yi yeniden başlat systemctl restart sshd
4. Mesajlar dosyasını izleyin tail -l /var/log/messages
5. Başka bir terminal kullanarak ssh ile bağlanmaya çalışın
6. Ssh ile bağlanmaya çalışın
7. Kesin neden için kimlik doğrulama günlüğünü inceleyin

Örneğin, yukarıda belirtilen sorunların bir kısmını yaşıyordum.

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

Bu adımları kullanarak sorunun yetkili_anahtarlar dosyasındaki izinler olduğunu doğrulayabildim. Kullanıcının yetkili anahtarlar dosyasında chmod'u 644 olarak ayarlayarak sorun giderildi.

.sshKlasörünüzdeki izinler doğru kopyalanmadı + yapıştırılmadı gibi görünüyor . Lütfen tekrar ekler misiniz?

Katı mod etkinleştirilirse .ssh, aşağıdaki izinlerin doğru olduğundan emin olmalıyız :

• .ssh/ izinleri olmalı 0700/rwx------
• .ssh/*.pub dosyalar olmalı 644/rw-r--r--
• .ssh/* (.ssh içindeki diğer dosyalar) 0600/rw-------

İşler sizi nasıl izin verebilir?

Birisinin bu cevabı tökezlemesi durumunda - hiçbir öneri benim senaryomda işe yaramadı. Sonunda sorun, şifre ayarlanmamış bir hesap oluşturmuş olmamdı. Parolayı kullanarak usermod -p "my password" usernameve sonra zorla hesap kilidini açtıktan sonra usermod -U usernameher şey şeftali oldu.

Benzer bir sorun yaşadım , burada ssh bağlantısı ~/.ssh/id_rsabeklenmedik bir şekilde durmadan önce anahtar deniyor :

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

Benim durumumda, bunun nedeni .sshdizinde bulunan eski bir ortak anahtar dosyasıydı :

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Hareketli / silme id_rsa.pubgelen .sshdizinde sorunu çözdü.

Anladığım kadarıyla: istemci tarafında bir ortak anahtar olduğunda, SSH 1 özel anahtarı ona karşı doğrular. Başarısız olursa, uzaktan bağlanmak için özel anahtarı kullanmaya çalışmaz.

Openssh posta listesine bir e-posta gönderdim: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Bu sorunla karşılaştık. .Ssh dosyalarındaki izinler ve sahipliklerin hepsi doğruydu. / Var / log / iletilerinde bulduk:

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

Yani, güvenlik umurumda değil geliştirici vm için çözüm selinux devre dışı bırakmaktır. / Etc / sysconfig / selinux dosyasını düzenleyin ve SELINUX'u değiştirin = devre dışı bırakıp yeniden başlatın.

Bu da birinin kurtarması ihtimaline karşı. Ubuntu 18.04 Makinemden bir anahtarı 2 CentOS 7 Sunucusuna kopyalamaya çalışıyordum. ssh-copy-idOnları transfer ederdim . Biri çalıştı, biri olmadı. Böylece tüm izinleri hata ayıklamadan geçtim ve hiçbir şey bulamadım. Sonunda dosyayı /etc/ssh/sshd_configher iki sunucuda da aldım ve satır satır ilerledim. Sonunda buldum, muhtemelen birisinin işe başlamadan çok önce değiştirdiği bir şey.

Bir okuma: AuthorizedKeysFile .ssh/authorized_keys

Ve başka bir okuma: AuthorizedKeysFile ~/.ssh/authorized_keyssunucuda olan ve anahtarlarımı kabul etmeyen. Açıkçası iki dosya arasında bakmak ve varsayılan arama desenleri ~/o sildi ve sshd yeniden başlattı önde gelen içermez bildiriyor yorum dikkat çekiyor . Sorun çözüldü.

Ayrıca bu sorunla karşılaştı. / ben / log / messages dosyasında böyle bir günlük kaydı bulunmadığından setrofixot ortamımda çalışmıyor gibi görünüyordu. SELinux'u devre dışı bırakmak benim için bir seçenek değildi, bu yüzden yaptım

restorecon -Rv ~/.ssh

Sonra rsa key ile giriş iyi çalıştı.

Benim durumumda nedeni customly dizi seçenek AuthorizedKeysFiledosyada /etc/ssh/sshd_config. Başka bir kullanıcının home dizinine ( /home/webmaster/.ssh/authorized_keys) ayarlandı , bu yüzden giriş yapmaya çalıştığım kullanıcının bu dosyaya / dizine erişimi yoktu.

Değiştirdikten ve ssh-server ( service ssh restart) yeniden başlatıldıktan sonra her şey normale döndü. Şimdi özel anahtarımla giriş yapabilirim.

Bizim durumumuzda sorunlar, güvenlik duvarımızın ve NATing kurallarımızın doğru ayarlanmamış olmasıyla ilgiliydi.

22 numaralı bağlantı noktası, anahtarlarımızın ve kullanıcımızın tanınamadığı yanlış sunucuya yönlendiriliyordu.

Birisi bu noktaya gelirse. tcpdump ve telnet arkadaşın olabilir

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

Bu iki sunucunun farklı opensh sürümleri olduğunu fark edeceksiniz. Bu, sorunu oldukça hızlı bir şekilde tespit etmeme yardımcı oldu. Ana bilgisayarlarınız aynı ssh sürümlerini kullanıyorsa, hedefe gelen trafiğin gerçekte olup olmadığını görmek için hedefte paketlenmiş bir iz yapmayı denemeniz gerekir.

Ssh aradığınız şeyi bulmak zor koymak tcpdump dışarı yapar trafik çok üretebilir.

Bu bana yardımcı oldu

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

Geçerli bilgisayarınız @ [mylocalip] değil, 3 farklı bir sunucudan telnet yapmayı deneyin. Gerçekten hangi trafiğin sunucunuza ulaştığını görmek istiyorsunuz.

Aşağıdaki gibi biten bir istemci tarafı hata günlüğü:

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
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
root@x.x.x.x's password:

sshd yapılandırma dosyası şunları içerdiğinde kök oturum açma işleminde sunucu tarafı (uzak) kısıtlamasından kaynaklanabilir :

PermitRootLogin: no

JonCav'ın günlüğe kaydetmeyi etkinleştirme önerisi böyle bir sorunun ayıklanmasında yardımcı oldu. İstemci tarafı hata ayıklama spew'i oldukça yararsız olsa da, sshd sunucusunun sshd_config dosyasına aşağıdakileri yerleştirin :

SyslogFacility AUTH
LogLevel DEBUG

sonuç olarak yararlı günlük iletileri üretildi:

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

Yalnızca kök oturum açma işleminin başarısız olması ve güvenlik ilkeniz tarafından yalnızca kök oturum açma için anahtar tabanlı kimlik doğrulamanın kullanılmasına izin verilmesi durumunda, sshd_config dosyasında yapılan bir değişiklik yardımcı olabilir:

 PermitRootLogin without-password

Kilometreniz değişebilir, ancak bu çoğu zaman yardımcı olur, ancak bazı sshd_config dosyalarında bulunan bir yoruma göre başka bir yapılandırma yine de müdahale edebilir :

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

Uzak sunucu yapılandırmasını bu şekilde hata ayıklamak için kolayca değiştiremeseniz bile, aynı kimlik dosyalarını aynı uzak sunucudaki kök olmayan bir hesaba ssh olarak kullanmak için istemci tarafı yapılandırmasını bir dereceye kadar kanıtlayabilir .

Güvenliğin neden insanları rahatsız ettiğini görebiliyorum. Sadece ssh won't use my keysorunu tekrar yaşadım . Uzak sunucuya giriş yapıp çalıştırarak çözdüm

/usr/sbin/sshd -sDp 23456

ve sonra masaüstümden (sunucuya ssh yapmaya çalışarak)

ssh -vvvv server -p 23456

Sunucuda aldım Authentication refused: bad ownership or modes for directory /

Bazı yeni sysadmin, düzelttiğim izin ve sahipliği berbat etmişti:

chmod 0755 / ; chown root:root /

( chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubİhtiyacım var ama sshd kök izinlerini kontrol etmek / bulmak benim için yeni bir tane.) Şimdi bir rootkit olup olmadığını kontrol edip yine de silin ve yeniden kurun.

Benim durumumda sorunlar yanlış kabuk exec ile oldu.

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

Söz konusu kullanıcı için / etc / passwd dosyası değiştirildi

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....

CentOS 7'de bu sorunu yaşadım. Debian tabanlı bir Linux kullanıcısıyım, bu yüzden sudan çıkmış bir balıktım. Bazı sunucularda işe yaradığını ve sadece birinde çalışmadığını fark ettim. Audit.log yararlı bir şey söylemedi ve secure.log da hiçbir şey vermedi. Tek gerçek farkın, çalışanlar ve çalışmayanlar arasındaki dosya ve dizinlerdeki bazı güvenlik bağlamı farklılıkları olduğunu buldum. İle güvenliği sağlayın

sudo ls -laZ <user-home>/.ssh

dizin (sshd_config üzerinde varsayılan bir sürü varsayıyorum).

Bazı özellikleri ssh_home_tve user_home_tözellikleri görmelisiniz . Bunu yapmazsanız chcon, eksik nitelikleri eklemek için komutu kullanın.

Örneğin

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

Benim durumumda, şüphem, kullanıcının standart olmayan bir şekilde oluşturulmuş olmasıdır. Evi bir dizindi /var/lib.

Daha fazla bilgi için: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/