Die SSH-Schlüsselauthentifizierung schlägt fehl

Ich versuche, in einen CentOS-Server zu sshen, über den ich keine Kontrolle habe. Der Administrator hat meinen öffentlichen Schlüssel zum Server hinzugefügt und besteht darauf, dass der Fehler bei mir liegt, aber ich kann nicht herausfinden, was falsch ist.

Konfiguration in .ssh:

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

Erlaubnis für meine Schlüsseldateien:

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

Verbindungsprotokoll, aus dem ich keinen Sinn machen kann:

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

Dies behebt normalerweise die meisten Probleme mit SSH-autorisierten Schlüsseln auf der Serverseite , vorausgesetzt, jemand hat keine zusätzlichen Änderungen an den Berechtigungen vorgenommen.

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

Wenn Ihr Administrator die Datei .ssh / directory oder .ssh / authorized_keys als root erstellt hat (was am häufigsten der Fall ist), darf die Datei keinem anderen Benutzer gehören (auch wenn root!).

Userify (Haftungsausschluss: Mitbegründer) macht das automatisch genauso. Https://github.com/userify/shim/blob/master/shim.py#L285

Ich hatte genau das gleiche Problem auf zwei Servern: einem Linux, auf dem Debian ausgeführt wird, und einem NAS (Synology DS715).

Es stellte sich heraus, dass in beiden Fällen die Berechtigungen für das Basisverzeichnis auf dem Server falsch waren

Das auth.log auf dem Server war sehr hilfreich

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

Unter Linux war das Write / Group-Bit aktiviert (drwxrwxr-x), sodass ich mindestens die Write-On-Gruppe (chmod gw ~ /) entfernen musste und es funktionierte

auf der Synology gab es aus irgendeinem Grund ein klebriges Stück

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

Ich musste es mit ändern

chmod -t ~/

und ich könnte mich dann ohne passwort verbinden

Bei Verwendung von CentOS 7 und ich bin zuversichtlich, dass dies auch für andere Linux-Betriebssysteme gilt, die sshd verwenden. Mit dem Root-Zugriff können Sie genauer feststellen, warum die Authentifizierung möglicherweise fehlschlägt. Um dies zu tun:

1. Aktivieren Sie die Protokollierung für sshd: vi /etc/ssh/sshd_config
2. Unter Protokollierungskommentar:

SyslogFacility AUTH LogLevel INFO

1. Ändern Sie in dem LogLevel DEBUG LogLevel INFO
2. Speichern und schließen
3. Starten Sie sshd neu systemctl restart sshd
4. Sehen Sie sich die Nachrichtendatei an tail -l /var/log/messages
5. Versuchen Sie mit einem anderen Terminal, eine Verbindung mit ssh herzustellen
6. Versuch mit ssh zu verbinden
7. Überprüfen Sie das Authentifizierungsprotokoll auf die genaue Ursache

Zum Beispiel hatte ich einige der gleichen Probleme wie oben erwähnt.

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

Mit diesen Schritten konnte ich bestätigen, dass das Problem Berechtigungen für die authorized_keys-Datei waren. Durch Setzen von chmod auf 644 in der Datei mit den autorisierten Schlüsseln meines Benutzers wurde das Problem behoben.

Es sieht so aus, als ob die Berechtigungen für Ihren .sshOrdner nicht richtig kopiert und eingefügt wurden. Könnten Sie es bitte noch einmal hinzufügen?

Wenn der strenge Modus aktiviert ist, müssen wir sicherstellen, dass .sshdie folgenden Berechtigungen korrekt sind:

• .ssh/ sollte Dauerwellen haben 0700/rwx------
• .ssh/*.pub Dateien sollten sein 644/rw-r--r--
• .ssh/* (andere Dateien in .ssh) 0600/rw-------

Wie sehen die Dinge für dich in Bezug auf die Erlaubnis aus?

Nur für den Fall, dass jemand auf diese Antwort stößt - keine der Empfehlungen hat in meinem Szenario funktioniert. Am Ende war das Problem, dass ich ein Konto ohne Passwort eingerichtet hatte. Nachdem ich das Passwort mit festgelegt usermod -p "my password" usernameund dann das Konto gewaltsam entsperrt hatte, war usermod -U usernamealles peachy.

Ich hatte ein ähnliches Problem , bei dem die SSH-Verbindung den Schlüssel versucht, ~/.ssh/id_rsabevor sie unerwartet beendet wird:

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

In meinem Fall lag es an einer alten öffentlichen Schlüsseldatei im .sshVerzeichnis:

[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

Das Verschieben / Löschen von id_rsa.pubaus dem .sshVerzeichnis hat das Problem gelöst.

Soweit ich weiß: Wenn auf der Clientseite ein öffentlicher Schlüssel vorhanden ist, validiert SSH 1st den privaten Schlüssel dagegen. Wenn dies fehlschlägt, wird nicht versucht, eine Remoteverbindung über den privaten Schlüssel herzustellen.

Ich habe eine E-Mail an die Mailingliste von openssh gesendet: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Wir sind auf dieses Problem gestoßen. Berechtigungen und Eigentumsrechte für .ssh-Dateien waren alle korrekt. In / var / log / messages fanden wir:

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

Die Lösung für Entwickler vm, bei der die Sicherheit keine Rolle spielt, ist die Deaktivierung von Selinux. Bearbeite / etc / sysconfig / selinux und ändere SELINUX = disabled und starte neu.

Auch dieses Problem aufgetreten. Die Fehlerbehebung schien in meiner Umgebung nicht zu funktionieren, daher gab es in / var / log / messages keinen solchen Protokolldatensatz. SELinux zu deaktivieren war für mich keine Option, also habe ich es getan

restorecon -Rv ~/.ssh

Danach funktionierte die Anmeldung mit dem rsa-Schlüssel einwandfrei.

Nur für den Fall, dass dies auch jemanden rettet. Ich habe versucht, einen Schlüssel von meinem Ubuntu 18.04-Computer auf 2 CentOS 7-Server zu kopieren. Früher habe ich sie ssh-copy-idübertragen. Einer hat gearbeitet, einer nicht. Also habe ich das Debuggen aller Berechtigungen durchlaufen und nichts gefunden. Schließlich habe ich die Datei /etc/ssh/sshd_configauf beiden Servern abgerufen und bin Zeile für Zeile durch sie gegangen. Endlich habe ich es gefunden, wahrscheinlich etwas, das jemand geändert hat, lange bevor ich zur Arbeit kam.

Man las: AuthorizedKeysFile .ssh/authorized_keys

Und noch eine Lektüre:, AuthorizedKeysFile ~/.ssh/authorized_keysdie sich auf dem Server befand, der meine Schlüssel nicht akzeptierte. Wenn Sie zwischen den beiden Dateien suchen und den Kommentar beachten, in dem die Standard-Suchmuster angegeben sind, ist der führende nicht enthalten. ~/Ich habe ihn entfernt und sshd neu gestartet. Problem gelöst.

Ein clientseitiges Fehlerprotokoll, das folgendermaßen endet:

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:

kann durch eine serverseitige (Remote-) Einschränkung der Root- Anmeldung verursacht werden, wenn die sshd- Konfigurationsdatei Folgendes enthält:

PermitRootLogin: no

Der Vorschlag von JonCav, die Protokollierung zu aktivieren, war hilfreich beim Debuggen eines solchen Problems. Während clientseitige Debug speien bemerkenswert wenig hilfreich war, wird die folgende Platzierung in dem sshd - Server sshd_config - Datei:

SyslogFacility AUTH
LogLevel DEBUG

Es wurden hilfreiche Protokollnachrichten erstellt:

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

Wenn nur die Root- Anmeldung fehlschlägt und die Verwendung einer schlüsselbasierten Authentifizierung für die Root-Anmeldung gemäß Ihrer Sicherheitsrichtlinie zulässig ist, kann eine Änderung der Datei sshd_config hilfreich sein:

 PermitRootLogin without-password

Ihre Laufleistung kann variieren, obwohl dies oft hilft, kann eine andere Konfiguration dennoch nach einem in einigen sshd_config- Dateien gefundenen Kommentar stören :

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

Auch wenn Sie die Remoteserverkonfiguration nicht einfach so ändern können, dass sie auf diese Weise debuggt, können Sie die clientseitige Konfiguration in gewissem Umfang überprüfen , indem Sie dieselben Identitätsdateien für ssh für ein Nicht-Root-Konto auf demselben Remoteserver verwenden.

Der Grund in meinem Fall war eine speziell festgelegte Option AuthorizedKeysFile in der Datei/etc/ssh/sshd_config . Es wurde auf home dir ( /home/webmaster/.ssh/authorized_keys) eines anderen Benutzers festgelegt , sodass der Benutzer, den ich anmelden wollte, keinen Zugriff auf diese Datei / dieses Verzeichnis hatte.

Nach dem Wechsel und dem Neustart von ssh-server ( service ssh restart) hat sich alles normalisiert. Ich kann mich jetzt mit meinem privaten Schlüssel anmelden.

Ich kann sehen, warum Sicherheit Menschen stören kann. Ich hatte gerade wieder das ssh won't use my keyProblem. Ich habe das Problem gelöst, indem ich mich beim Remote-Server angemeldet und ausgeführt habe

/usr/sbin/sshd -sDp 23456

und dann von meinem Desktop (versuche zu ssh zum Server)

ssh -vvvv server -p 23456

Auf dem Server habe ich Authentication refused: bad ownership or modes for directory /

Ein neuer Systemadministrator hatte die Erlaubnis und den Besitz, mit denen ich das Problem behoben hatte, durcheinander gebracht:

chmod 0755 / ; chown root:root /

(Ich bin es gewohnt, dass ich chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubsshd brauche, um die Root-Berechtigungen zu überprüfen / zu finden.) Jetzt werde ich nach einem Rootkit suchen und es trotzdem löschen und neu installieren.

In meinem Fall lag das Problem bei der falschen Shell-Ausführung.

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

Geänderte Datei / etc / passwd für diesen Benutzer

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

Ich hatte dieses Problem unter CentOS 7. Ich bin ein regelmäßiger Debian-basierter Linux-Benutzer, also war ich ein Fisch aus dem Wasser. Mir ist aufgefallen, dass es bei einigen Servern funktioniert hat und bei nur einem nicht. Das audit.log sagte nichts Nützliches und das secure.log gab auch nichts. Ich stellte fest, dass der einzige wirkliche Unterschied einige Unterschiede im Sicherheitskontext von Dateien und Verzeichnissen zwischen denen, die funktionierten, und denen, die nicht funktionierten, waren. Holen Sie sich die Sicherheit mit

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

des Verzeichnisses (ich gehe von vielen Standardeinstellungen für sshd_config aus).

Sie sollten einige ssh_home_tund user_home_tAttribute sehen. Wenn Sie dies nicht tun, verwenden Sie diechcon fügen Befehl die fehlenden Attribute hinzu.

Beispielsweise

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"

In meinem Fall habe ich den Verdacht, dass der Benutzer auf nicht standardmäßige Weise erstellt wurde. Sein Zuhause war ein Verzeichnis in/var/lib .

Weitere Informationen unter: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

In unserem Fall hing das Problem damit zusammen, dass unsere Firewall- und NAT-Regeln nicht richtig eingerichtet waren.

Port 22 wurde an den falschen Server weitergeleitet, auf dem unsere Schlüssel und Benutzer nicht erkannt wurden.

Wenn jemand an diesen Punkt kommt. tcpdump und telnet können dein Freund sein

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

Sie werden feststellen, dass diese beiden Server unterschiedliche OpenSh-Versionen haben. Dies hat mir geholfen, das Problem ziemlich schnell zu erkennen. Wenn Ihre Hosts die gleichen ssh-Versionen verwenden, müssen Sie versuchen, eine gepackte Ablaufverfolgung für das Ziel durchzuführen, um festzustellen, ob tatsächlich Verkehr am Ziel ankommt.

Ssh kann eine Menge Verkehr erzeugen, der es schwierig macht, das zu finden, wonach Sie suchen.

Das hat mir geholfen

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

Versuchen Sie, von einem anderen Server als Ihrem aktuellen Computer @ [mylocalip] zu telneten. Sie möchten sehen, welcher Datenverkehr tatsächlich Ihren Server erreicht.