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 [email protected]
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: [email protected],[email protected],[email protected],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: [email protected],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: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],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,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] 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).
ssh [email protected]als Protokoll Kerberos zu erwähnen, dass der CentOS-Server domänenintegriert sein könnte (AD, IPA, ...). Sie müssen herausfinden, welchen Benutzer Sie verwenden sollen. Fragen Sie den Administrator. Wir verwenden zum Beispiel IPA, damit Benutzer mit ihrem IPA-Domänenkonto und ihrem Schlüsselpaar eine Verbindung zu bestimmten Servern herstellen können und bei Bedarf sudo können. Kein Root-Zugriff :)Antworten:
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.
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
quelle
sudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -Rwas Tippzeit spart, aber für einen Neuling möglicherweise schwieriger zu verstehen istIch 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
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
Ich musste es mit ändern
und ich könnte mich dann ohne passwort verbinden
quelle
chmod -t...admin@SYN:~$ ls -ald . .ssh .ssh/* drwxr-xr-x 6 admin users 4096 Jan 10 15:54 . drwx------ 2 admin users 4096 Jan 10 15:54 .ssh -rwx------ 1 admin users 401 Jan 10 15:54 .ssh/authorized_keys -rw------- 1 admin users 1679 Jan 10 15:49 .ssh/id_rsa -rwxr--r-- 1 admin users 396 Jan 10 15:49 .ssh/id_rsa.pub -rwx------ 1 admin users 396 Jan 10 10:04 .ssh/known_hostsBei 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:
vi /etc/ssh/sshd_configSyslogFacility AUTH LogLevel INFOsystemctl restart sshdtail -l /var/log/messagesZum Beispiel hatte ich einige der gleichen Probleme wie oben erwähnt.
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.
quelle
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 haben0700/rwx------.ssh/*.pubDateien sollten sein644/rw-r--r--.ssh/*(andere Dateien in .ssh)0600/rw-------Wie sehen die Dinge für dich in Bezug auf die Erlaubnis aus?
quelle
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, warusermod -U usernamealles peachy.quelle
Ich hatte ein ähnliches Problem , bei dem die SSH-Verbindung den Schlüssel versucht,
~/.ssh/id_rsabevor sie unerwartet beendet wird:In meinem Fall lag es an einer alten öffentlichen Schlüsseldatei im
.sshVerzeichnis: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 .
quelle
Wir sind auf dieses Problem gestoßen. Berechtigungen und Eigentumsrechte für .ssh-Dateien waren alle korrekt. In / var / log / messages fanden wir:
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.
quelle
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
Danach funktionierte die Anmeldung mit dem rsa-Schlüssel einwandfrei.
quelle
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_keysUnd 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.quelle
Ein clientseitiges Fehlerprotokoll, das folgendermaßen endet:
kann durch eine serverseitige (Remote-) Einschränkung der Root- Anmeldung verursacht werden, wenn die sshd- Konfigurationsdatei Folgendes enthält:
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:
Es wurden hilfreiche Protokollnachrichten erstellt:
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:
Ihre Laufleistung kann variieren, obwohl dies oft hilft, kann eine andere Konfiguration dennoch nach einem in einigen sshd_config- Dateien gefundenen Kommentar stören :
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.
quelle
Der Grund in meinem Fall war eine speziell festgelegte Option
AuthorizedKeysFilein 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.quelle
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 habeund dann von meinem Desktop (versuche zu ssh zum Server)
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:
(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.quelle
In meinem Fall lag das Problem bei der falschen Shell-Ausführung.
Geänderte Datei / etc / passwd für diesen Benutzer
quelle
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>/.sshdes Verzeichnisses (ich gehe von vielen Standardeinstellungen für sshd_config aus).
Sie sollten einige
ssh_home_tunduser_home_tAttribute sehen. Wenn Sie dies nicht tun, verwenden Sie diechconfügen Befehl die fehlenden Attribute hinzu.Beispielsweise
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/
quelle
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
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
Versuchen Sie, von einem anderen Server als Ihrem aktuellen Computer @ [mylocalip] zu telneten. Sie möchten sehen, welcher Datenverkehr tatsächlich Ihren Server erreicht.
quelle