Uwierzytelnianie za pomocą klucza SSH kończy się niepowodzeniem

Próbuję ssh na serwerze CentOS, nad którym nie mam kontroli. Administrator dodał mój klucz publiczny do serwera i nalega, że ​​wina leży po mojej stronie, ale nie mogę zrozumieć, co jest nie tak.

Konfiguracja w .ssh:

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

Zezwolenie na moje pliki kluczy:

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

Dziennik połączeń, którego nie rozumiem:

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).

Zwykle rozwiązuje to większość problemów związanych z uprawnieniami klucza SSH po stronie serwera , zakładając, że ktoś nie wprowadził dodatkowych zmian w uprawnieniach.

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

Jeśli administrator utworzył plik .ssh / lub .ssh / Author_keys jako root (co najczęściej jest realizowane w ten sposób), to posiadanie pliku przez innego użytkownika (nawet jeśli root!) Jest niedozwolone.

Userify (zastrzeżenie: współzałożyciel) automatycznie robi to dokładnie w ten sam sposób. Https://github.com/userify/shim/blob/master/shim.py#L285

Miałem dokładnie ten sam problem na dwóch serwerach: Linuksie z uruchomionym Debianem stretch i na NAS (Synology DS715)

okazało się, że w obu przypadkach uprawnienia do katalogu domowego na serwerze były nieprawidłowe

auth.log na serwerze był bardzo pomocny

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

w Linuksie miał bit zapisu / grupy na (drwxrwxr - x), więc musiałem usunąć przynajmniej zapis na grupie (chmod gw ~ /), a potem zadziałało

na Synology, z jakiegokolwiek powodu, było trochę kleju

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

Musiałem to zmienić

chmod -t ~/

i mógłbym wtedy połączyć się bez hasła

Korzystając z CentOS 7, jestem przekonany, że dotyczy to także innych systemów operacyjnych Linux korzystających z sshd. Dzięki prawom dostępu root możesz dowiedzieć się więcej o tym, dlaczego uwierzytelnianie może nie powieść się. Aby to zrobić:

1. Włącz rejestrowanie dla sshd: vi /etc/ssh/sshd_config
2. W trakcie logowania komentowanie:

SyslogFacility AUTH LogLevel INFO

1. Zmień INFO na LogLevel na DEBUGĘ LogLevel
2. Zapisz i wyjdź
3. Uruchom ponownie sshd systemctl restart sshd
4. Obejrzyj plik wiadomości tail -l /var/log/messages
5. Używając innego terminala, spróbuj połączyć się z ssh
6. Próba połączenia z ssh
7. Przejrzyj dziennik uwierzytelnienia w celu znalezienia dokładnej przyczyny

Na przykład miałem takie same problemy jak wspomniano powyżej.

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

Wykonując te czynności udało mi się potwierdzić, że problem dotyczy uprawnień do pliku uprawniony do kluczy. Ustawiając chmod na 644 w pliku autoryzowanych kluczy mojego użytkownika, problem został naprawiony.

Wygląda na to, że uprawnienia do Twojego .sshfolderu nie zostały poprawnie skopiowane i wklejone. Czy możesz dodać go ponownie?

Jeśli włączony jest tryb ścisły, musimy upewnić się, że .sshma odpowiednie uprawnienia:

• .ssh/ powinien mieć perms 0700/rwx------
• .ssh/*.pub pliki powinny być 644/rw-r--r--
• .ssh/* (inne pliki w .ssh) 0600/rw-------

Jak wyglądają twoje sprawy pod względem uprawnień?

Na wypadek, gdyby ktoś natknął się na tę odpowiedź - żadne z zaleceń nie zadziałało w moim scenariuszu. Ostatecznie problem polegał na tym, że utworzyłem konto bez ustawionego hasła. Kiedyś ustawiłem hasło za pomocą, usermod -p "my password" usernamea następnie siłą odblokowałem konto, usermod -U usernamewszystko było brzoskwiniowe.

Miałem podobny problem , w którym połączenie ssh próbuje klucz ~/.ssh/id_rsaprzed nieoczekiwanym zatrzymaniem:

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

W moim przypadku było to spowodowane starym plikiem klucza publicznego leżącym w .sshkatalogu:

[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

Przeniesienie / usunięcie id_rsa.pubz .sshkatalogu rozwiązało problem.

Z tego, co rozumiem: kiedy klucz publiczny jest obecny po stronie klienta, SSH 1st sprawdza klucz prywatny względem niego. Jeśli się nie powiedzie, nie będzie próbował użyć klucza prywatnego do zdalnego połączenia.

Wysłałem wiadomość e-mail na listę mailingową openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Napotkaliśmy ten problem. Uprawnienia i prawa własności do plików .ssh były prawidłowe. W / var / log / messages znaleźliśmy:

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

SO, rozwiązaniem dla programistów vm, w którym nie dbamy o bezpieczeństwo, jest wyłączenie selinux. Edytuj / etc / sysconfig / selinux i zmień SELINUX = wyłączony i uruchom ponownie.

Na wszelki wypadek to też kogoś ratuje. Próbowałem skopiować klucz z mojej maszyny Ubuntu 18.04 na 2 serwery CentOS 7. Kiedyś ssh-copy-idje przenosiłem. Jeden działał, drugi nie. Przeszedłem więc debugowanie wszystkich uprawnień i nic nie znalazłem. W końcu podciągnąłem plik /etc/ssh/sshd_configna obu serwerach i przeszedłem przez nie linia po linii. W końcu znalazłem, prawdopodobnie coś, co ktoś zmodyfikował na długo przed tym, jak dostałem pracę.

Jeden odczyt: AuthorizedKeysFile .ssh/authorized_keys

I kolejny odczyt: AuthorizedKeysFile ~/.ssh/authorized_keysktóry był na serwerze, który nie akceptował moich kluczy. Oczywiście patrząc między dwoma plikami i zauważając komentarz, który stwierdza, że ​​domyślne wzorce wyszukiwania nie obejmują wiodącego ~/, usunąłem go i ponownie uruchomiłem sshd. Problem rozwiązany.

Napotkałem również ten problem. Wydaje się, że setroubleshoot nie działa w moim środowisku, więc nie ma takiego zapisu w / var / log / messages. Wyłączenie SELinux nie było dla mnie opcją, więc zrobiłem to

restorecon -Rv ~/.ssh

Po tym logowanie za pomocą klucza rsa działało poprawnie.

Powodem w moim przypadku była niestandardowo ustawiona opcja AuthorizedKeysFilew pliku /etc/ssh/sshd_config. Został ustawiony na /home/webmaster/.ssh/authorized_keyskatalog domowy dir ( ) innego użytkownika , więc użytkownik, którego próbowałem się zalogować, nie miał dostępu do tego pliku / katalogu.

Po zmianie i ponownym uruchomieniu ssh-server ( service ssh restart) wszystko wróciło do normy. Mogę teraz zalogować się przy użyciu mojego klucza prywatnego.

W naszym przypadku problemy związane były z tym, że nasza zapora i reguły NATing nie zostały poprawnie skonfigurowane.

port 22, był kierowany do niepoprawnego serwera, na którym nasze klucze i użytkownik nie byli rozpoznawani.

Jeśli ktoś dojdzie do tego punktu. tcpdump i telnet mogą być twoimi przyjaciółmi

[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
^]

Zauważysz, że te dwa serwery mają różne wersje openssh. To pomogło mi dość szybko wykryć problem. Jeśli twoje hosty używają tych samych wersji ssh, będziesz musiał wykonać spakowane śledzenie w miejscu docelowym, aby sprawdzić, czy ruch faktycznie dociera do miejsca docelowego.

Ssh może generować duży ruch, co sprawia, że ​​tcpdump trudno znaleźć to, czego szukasz.

To mi pomogło

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

Spróbuj telnet z 3 innego serwera niż twój obecny komputer @ [mylocalip]. Chcesz zobaczyć, jaki ruch faktycznie dociera do twojego serwera.

Dziennik błędów po stronie klienta kończy się tak:

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:

może być spowodowane ograniczeniem logowania użytkownika root po stronie serwera, gdy plik konfiguracyjny sshd zawiera:

PermitRootLogin: no

Sugestia JonCav, aby włączyć rejestrowanie, była pomocna w debugowaniu takiego problemu. Podczas gdy spew debugowania po stronie klienta był wyjątkowo nieprzydatny, umieszczenie następujących elementów w pliku sshd_config serwera sshd :

SyslogFacility AUTH
LogLevel DEBUG

skończyło się na tworzeniu pomocnych komunikatów w dzienniku:

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 ...

W przypadku, gdy tylko logowanie do katalogu głównego kończy się niepowodzeniem i pod warunkiem, że stosowanie tylko uwierzytelniania opartego na kluczach do logowania do konta root jest dozwolone przez zasady bezpieczeństwa, zmiana pliku sshd_config może pomóc:

 PermitRootLogin without-password

Twój przebieg może się różnić, choć często to pomaga, niektóre inne konfiguracje mogą nadal zakłócać zgodnie z komentarzem znalezionym w niektórych plikach sshd_config :

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

Nawet jeśli nie można łatwo zmienić konfiguracji zdalnego serwera w celu debugowania w ten sposób, można do pewnego stopnia sprawdzić konfigurację po stronie klienta, używając tych samych plików tożsamości do ssh do konta użytkownika innego niż root na tym samym serwerze zdalnym.

Rozumiem, dlaczego ochrona może niepokoić ludzi. Właśnie miałem ssh won't use my keyproblem ponownie. Rozwiązałem to, logując się do zdalnego serwera i uruchamiając

/usr/sbin/sshd -sDp 23456

a następnie z mojego pulpitu (próbuję ssh na serwer)

ssh -vvvv server -p 23456

Na serwerze mam Authentication refused: bad ownership or modes for directory /

Niektórzy nowi administratorzy pomieszali uprawnienia i prawa własności, które naprawiłem za pomocą:

chmod 0755 / ; chown root:root /

(Jestem przyzwyczajony do potrzeby, chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubale sprawdzanie sshd / znajdowanie uprawnień roota jest dla mnie nowe). Teraz zamierzam sprawdzić rootkita, a następnie wyczyścić i zainstalować ponownie.

W moim przypadku problem dotyczył nieprawidłowego wykonania powłoki.

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

Zmieniono plik / etc / passwd dla tego użytkownika

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

Miałem ten problem na CentOS 7. Jestem zwykłym użytkownikiem Linuksa opartym na Debianie, więc byłem rybą z wody. Zauważyłem, że na niektórych serwerach działało, a na jednym nie. Audyt.log nie powiedział nic przydatnego, a bezpieczny.log też nic nie dał. Odkryłem, że jedyną prawdziwą różnicą były różnice w kontekście bezpieczeństwa plików i katalogów między tymi, które działały, a tymi, które nie działały. Uzyskaj bezpieczeństwo dzięki

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

katalogu (zakładam wiele domyślnych ustawień sshd_config).

Powinieneś zobaczyć niektóre ssh_home_ti user_home_tatrybuty. Jeśli nie, użyj chconpolecenia, aby dodać brakujące atrybuty.

Na przykład

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"

W moim przypadku podejrzewam, że użytkownik został utworzony w niestandardowy sposób. Jego domem był katalog /var/lib.

Więcej informacji: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/