Warum erhalte ich bei ssh mit öffentlicher Schlüsselauthentifizierung immer noch eine Passwortabfrage?

470

Ich arbeite über die URL, die ich hier gefunden habe:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

Mein SSH-Client ist Ubuntu 64 Bit 11.10 Desktop und mein Server ist Centos 6.2 64 Bit. Ich habe die Anweisungen befolgt. Ich erhalte immer noch eine Passwortabfrage für ssh.

Ich bin mir nicht sicher, was ich als nächstes tun soll.

Thom
quelle
5
Ausgabe des Befehls, den Sie mit dem Flag -v an ssh übergeben? sollte ähnlich sein pastebin.com/xxe57kxg
Rob
14
Stellen Sie außerdem sicher, dass Ihr .ssh-Ordnerchmod 700
Rob
8
Wenn Sie Root-Zugriff auf den Server haben, /var/log/auth.logwerden Sie darüber informiert, warum die Anmeldung fehlschlägt.
UtahJarhead
5
@UtahJarhead: Auf dem CentOS-Server befindet es sich wahrscheinlich in /var/log/secure.
Dennis Williamson
3
Interessanterweise war das chmod 0700die Antwort, aber als ich es ssh -vauf der Client-Seite tat, zeigte es keinen Fehler an, der damit zusammenhängt, warum der Schlüssel nicht akzeptiert wurde. Es wurde nur gesagt, dass es als nächstes versucht wurde, ein Passwort zu verwenden, obwohl mein Client einen öffentlichen Schlüssel gesendet hatte. Wie erwarten sie, dass wir Probleme ohne Fehlerinformationen vom Server diagnostizieren?
void.pointer

Antworten:

557

Stellen Sie sicher, dass die Berechtigungen für das ~/.sshVerzeichnis und dessen Inhalt korrekt sind. Als ich meine SSH-Schlüsselauthentifizierung zum ersten Mal eingerichtet habe, war der ~/.sshOrdner nicht richtig eingerichtet, und er hat mich angeschrien.

  • Ihr Home-Verzeichnis ~, Ihr ~/.sshVerzeichnis und die ~/.ssh/authorized_keysDatei auf dem Remotecomputer dürfen nur von Ihnen geschrieben werden: rwx------und rwxr-xr-xsind in Ordnung, aber rwxrwx---nicht gut¹, auch wenn Sie der einzige Benutzer in Ihrer Gruppe sind (wenn Sie numerische Modi bevorzugen: 700oder 755nicht 775). .
    Wenn ~/.sshoder authorized_keyseine symbolische Verknüpfung ist, wird der kanonische Pfad (mit erweiterten symbolischen Verknüpfungen) überprüft .
  • Ihre ~/.ssh/authorized_keysDatei (auf dem Remotecomputer) muss lesbar sein (mindestens 400), aber Sie müssen auch beschreibbar sein (600), wenn Sie weitere Schlüssel hinzufügen möchten.
  • Ihre private Schlüsseldatei (auf der lokalen Maschine) muss lesbar sein und beschreibbar nur von Ihnen: rw-------, dh 600.
  • Wenn SELinux auf Erzwingen eingestellt ist, müssen Sie möglicherweise ausführen restorecon -R -v ~/.ssh(siehe zB Ubuntu-Fehler 965663 und Debian-Fehlerbericht # 658675 ; dies ist in CentOS 6 gepatcht ).

¹ Mit Ausnahme einiger Distributionen (Debian und Derivate), die den Code gepatcht haben, um die Beschreibbarkeit von Gruppen zu ermöglichen, wenn Sie der einzige Benutzer in Ihrer Gruppe sind.

rauben
quelle
29
Vielen Dank für den Hinweis auf restorecon. Ich habe mir über genau dieses Thema schon eine Weile den Kopf gekratzt.
Richard Barrell
19
Seltsamerweise hatte ich Probleme mit einem Konto, das ein Freund in seinem VPS eingerichtet hatte, um die Pubkey-Authentifizierung zu aktivieren. Ich dachte, dass alle Berechtigungen korrekt waren, aber es ist wichtig, sich daran zu erinnern, dass dies sein /home/USERmuss 700oder755
Rob
2
Denken Sie auch daran, die Eigentümer- und Gruppeneinstellungen zu überprüfen. Ich habe RSYNC verwendet, um eine authorized_keys-Datei zu kopieren, und habe nicht bemerkt, dass der Eigentümer / die Gruppe auf 1000 anstelle von root gesetzt wurde!
nak
11
Fügen Sie Ihrem Befehl ssh -v hinzu, um zu sehen, was mit diesem Schlüssel geschieht. ssh -v user@host.
Tedder42
14
chmod -R 700 ~/.ssharbeitete für mich, um die Einschränkungen dieser Antwort zu erfüllen (RHEL 7)
Scottyseus
147

Wenn Sie Root-Zugriff auf den Server haben, können Sie solche Probleme auf einfache Weise lösen, indem Sie sshd im Debug-Modus ausführen, indem Sie etwas wie /usr/sbin/sshd -d -p 2222auf dem Server ausgeben (vollständiger Pfad zur ausführbaren Datei von sshd erforderlich, which sshdkann helfen) und dann eine Verbindung vom Client mit herstellen ssh -p 2222 user@host. Dadurch wird der SSH-Dämon gezwungen, im Vordergrund zu bleiben und Debuginformationen zu jeder Verbindung anzuzeigen. Suchen Sie nach etwas wie

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

Wenn es nicht möglich ist, einen alternativen Port zu verwenden, können Sie den SSH-Daemon vorübergehend anhalten und ihn im Debug-Modus durch einen anderen ersetzen. Durch das Stoppen des SSH-Daemons werden vorhandene Verbindungen nicht beendet. Dies kann über ein Remote-Terminal erfolgen, ist jedoch etwas riskant. Wenn die Verbindung zu einem Zeitpunkt unterbrochen wird, an dem der Debug-Ersatz nicht ausgeführt wird, ist der Computer gesperrt bis Sie es neu starten können. Die erforderlichen Befehle:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(Abhängig von Ihrer Linux-Distribution kann die erste / letzte Zeile stattdessen systemctl stop sshd.service/ sein systemctl start sshd.service.)

Tgr
quelle
5
Ich habe es gerade ausprobiert ... und es funktioniert gut, wenn ich renne sshd -d, aber es schlägt fehl, wenn ich tatsächlich renne service sshd start. Ich bin mir sicher, dass es einfach ist, aber ich bin kein Linux-Guru. Irgendwelche Gedanken?
N Rohler
3
Als Referenz wird in diesem Beitrag die SELinux-Lösung erläutert, mit der mein Problem behoben wurde.
N Rohler
2
Ich hatte auch Probleme damit, die Authentifizierung mit öffentlichen Schlüsseln zum Laufen zu bringen, und ich war mir ziemlich sicher, dass die Verzeichnisberechtigungen nicht das Problem waren. Nachdem ich SSH im Debug-Modus ausgeführt hatte, stellte ich schnell fest, dass ich falsch lag und die Berechtigungen die Probleme waren.
ub3rst4r
3
Toller Rat, mein Benutzerordner hatte die falschen Berechtigungen.
gdfbarbosa
2
Danke. Aus allen Gründen durfte sich mein Benutzer nicht anmelden, da die von ansible (/ bin / zsh) bei der Benutzererstellung angegebene Shell nicht vorhanden war. Das hätte ich nie gedacht.
Chishaku
53

Ist Ihr Heimverzeichnis verschlüsselt? In diesem Fall müssen Sie für Ihre erste SSH-Sitzung ein Kennwort angeben. Die zweite SSH-Sitzung auf demselben Server arbeitet mit dem Authentifizierungsschlüssel. In diesem Fall können Sie Ihr authorized_keysVerzeichnis in ein unverschlüsseltes Verzeichnis verschieben und den Pfad in ändern ~/.ssh/config.

Am Ende habe ich einen /etc/ssh/usernameOrdner mit dem Benutzernamen und den richtigen Berechtigungen erstellt und die authorized_keysDatei dort abgelegt. Dann änderte die AuthorizedKeysFile-Direktive in /etc/ssh/config:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Dies ermöglicht es mehreren Benutzern, diesen SSH-Zugriff zu erhalten, ohne die Berechtigungen zu beeinträchtigen.

cee
quelle
3
Diese Antwort ist herausragend und hat mir geholfen - für alle, die sich fragen, ob dies das Problem ist - in Ihrer Datei auth.log wird möglicherweise "pam_ecryptfs: Passphrase file wrapped" angezeigt. irgendwie reichte das nicht aus, um mich zu erinnern, dass der Homedir verschlüsselt war. Außerdem werden Sie bei der ersten Anmeldung möglicherweise nach einem Kennwort gefragt, bei den nachfolgenden Sitzungen nicht (da es entschlüsselt wird, während die anderen Sitzungen geöffnet sind).
Pazifist
Heiliger Mist, ich habe viel zu lange nach Wayyyy gesucht, um das Problem zu lösen.
h3.
33

Nachdem Sie die Schlüssel auf den Remote-Computer kopiert und in den Computer eingefügt haben, müssen authorized_keysSie Folgendes tun:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa
Gusior
quelle
1
Eigentlich nein, tust du nicht. ssh verwendet automatisch ~ / .ssh / id_rsa (oder id_dsa), ohne dass ein Schlüsselagent verwendet werden muss.
Patrick
7
Dies kann immer noch ein hilfreicher Rat sein, wenn in ~ / .ssh / config ein Schlüssel mit einem anderen Namen angegeben werden soll (z. B. auf host * .mydomain.org ... IdentityFile ~ / .ssh / some_limited_use.pub - ssh-add ~ / .ssh / some_limited_use.pub).
89c3b1b8-b1ae-11e6-b842-48d705
Dies hat mein Problem mit der Passwortabfrage nach dem Hinzufügen eines Schlüssels gelöst. Wie 89c3b1b8-b1ae-11e6-b842-48d705 hervorhob, war der Grund für die manuelle Ausführung dieser Befehle ein nicht standardmäßiger Name einer Schlüsseldatei.
Михаил Лисаков
Wie oben in den Kommentaren erwähnt, wird der ssh-Agent nicht standardmäßig mit einem anderen Schlüssel als dem Standardschlüssel versehen. ssh-add -L
James,
30

Probieren Sie einfach die folgenden Befehle aus

  1. ssh-keygen

    Drücken Sie die Eingabetaste, bis Sie dazu aufgefordert werden

  2. ssh-copy-id -i root@ip_address

    (Es wird einmalig nach dem Passwort des Hostsystems gefragt)

  3. ssh root@ip_address

    Jetzt sollten Sie sich ohne Passwort anmelden können

Ravindra
quelle
1
Auf welchem ​​Server?
Amalgovinus
@Amalgovinus Natürlich führen Sie dies auf dem Client aus, nicht auf dem Computer, zu dem Sie eine Verbindung herstellen - Sie möchten keine Kopie Ihres privaten Schlüssels auf dem Server! :)
nevelis
4
Bitte beachten Sie, dass das Zulassen von Remote-Root-Anmeldungen im Allgemeinen keine empfohlene Sicherheitsmaßnahme ist.
Arielf
27

Ich stand vor Herausforderungen, wenn das Basisverzeichnis auf der Fernbedienung nicht über die richtigen Berechtigungen verfügt. In meinem Fall hat der Benutzer das Home-Verzeichnis für einen lokalen Zugriff im Team auf 777 geändert . Das Gerät konnte keine Verbindung mehr mit SSH-Schlüsseln herstellen. Ich habe die Erlaubnis auf 744 geändert und es hat wieder funktioniert.

Sahil
quelle
7
Wir hatten auch dieses Problem - 755 in den Heimverzeichnissen haben es behoben
davidfrancis
Ich hatte die Berechtigungen auf 777 gesetzt und es wurde ignoriert, danke !!!
Ka_lin
Hier gilt das gleiche. Vielen Dank. Ich kratzte mich eine Weile am Kopf, und es passierte WTF.
Marcin
Ja, siehe die Antwort hier für weitere Details. Unix.stackexchange.com/questions/205842/…
Tim
Dies ist möglicherweise die Antwort für Personen, die die Schlüsselerstellung korrekt durchgeführt haben und dennoch zur Eingabe eines Kennworts aufgefordert werden.
Fergie
14

SELinux unter RedHat / CentOS 6 hat ein Problem mit der Pubkey-Authentifizierung , wahrscheinlich, wenn einige der Dateien erstellt werden. Selinux setzt seine ACLs nicht richtig.

So korrigieren Sie die SElinux-ACLs für den Root-Benutzer manuell:

restorecon -R -v /root/.ssh
David Mackintosh
quelle
Verwenden des OpenSSH-Clients unter Windows Ich konnte ohne ssh root@mymachineProbleme auf ein CentOS6 zugreifen mymachine, habe jedoch einen Benutzer mit niedrigeren Berechtigungen, den ich lieber verwenden würde, der ssh regularUser@mymachinemich jedoch weiterhin zur Eingabe eines Kennworts auffordert. Gedanken?
Groostav
13

Wir sind auf dasselbe Problem gestoßen und haben die Schritte in der Antwort befolgt. Bei uns hat es aber trotzdem nicht geklappt. Unser Problem war, dass die Anmeldung von einem Client aus funktionierte, von einem anderen jedoch nicht (das .ssh-Verzeichnis war NFS-gemountet und beide Clients verwendeten dieselben Schlüssel).

Also mussten wir noch einen Schritt weiter gehen. Wenn Sie den Befehl ssh im ausführlichen Modus ausführen, erhalten Sie viele Informationen.

ssh -vv user@host

Wir stellten fest, dass der Standardschlüssel (id_rsa) nicht akzeptiert wurde und stattdessen der SSH-Client einen Schlüssel anbot, der mit dem Hostnamen des Clients übereinstimmt:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

Offensichtlich wird dies von keinem anderen Client funktionieren.

In unserem Fall bestand die Lösung darin, den Standard-RSA-Schlüssel auf den zu ändern, der user @ myclient enthielt. Wenn ein Schlüssel die Standardeinstellung ist, wird nicht nach dem Clientnamen gesucht.

Dann stießen wir nach dem Wechsel auf ein anderes Problem. Anscheinend werden die Schlüssel im lokalen ssh-Agenten zwischengespeichert und es wird der folgende Fehler im Debug-Protokoll angezeigt:

'Agent admitted failure to sign using the key'

Dies wurde gelöst, indem die Schlüssel zum ssh-Agenten neu geladen wurden:

ssh-add
Joachim Nilsson
quelle
9

Es wäre eine SSH-Fehlkonfiguration am Serverende. Die serverseitige Datei sshd_config muss bearbeitet werden. Befindet sich in /etc/ssh/sshd_config. Ändern Sie in dieser Datei die Variablen

  • "Ja" bis "Nein" für ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

  • 'no' bis 'yes' für PubkeyAuthentication

Basierend auf http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

nisch
quelle
1
Wie in Kommentaren zu Frage überprüfen Sie die / var / log / secure oder /var/log/auth.log. In meinem Fall wird "Benutzer xxx von xxx nicht zulässig, da nicht in AllowUsers aufgeführt" "input_userauth_request: ungültiger Benutzer xxx [preauth]" (und "Zeile 35 erneut ausführen: Veraltete Option ServerKeyBits" in / var / log / messages angezeigt, obwohl ich nicht weiß, was das ist). Um das Problem zu beheben vi /etc/ssh/sshd_config, fügen Sie Benutzer xxx zur Liste der service sshd restartzulässigen Benutzer hinzu. *** ACHTUNG: Wenn Sie den sshd-Dienst mit einer fehlerhaften sshd_config neu starten, werden Sie möglicherweise blockiert !? ***. Das hat funktioniert.
Gaoithe
6

Stellen Sie sicher, dass diese AuthorizedKeysFileauf die richtige Stelle zeigen, und verwenden Sie sie %uals Platzhalter für den Benutzernamen:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

Es kann sein, dass Sie nur die Zeile auskommentieren müssen:

AuthorizedKeysFile .ssh / authorized_keys

Beachten Sie, dass Sie den ssh-Dienst neu laden müssen, damit die Änderungen wirksam werden:

service sshd reload
Dziamid
quelle
4

Zwei Kommentare: Dadurch wird die Originaldatei überschrieben. Ich kopiere einfach den generierten öffentlichen Schlüssel und mache etwas wie:

cat your_public_key.pub >> .ssh/authorized_keys

Dadurch wird der Schlüssel, den Sie verwenden möchten, an die bereits vorhandene Liste der Schlüssel angehängt. Einige Systeme verwenden die Datei auch authorized_keys2, daher ist es eine gute Idee, eine feste Verknüpfung zwischen authorized_keysund zu erstellen authorized_keys2, nur für den Fall.

Wojtek Rzepala
quelle
Ja, das ist mir auch beim Überschreiben aufgefallen, aber ich hatte keine, also war es egal. Ich habe einen Symlink zu authorized_keys2 erstellt, aber das hat nicht geholfen.
Thom
Überprüfen Sie auch die Datei- / Verzeichnisberechtigungen. Sie werden auf der von Ihnen bereitgestellten Website beschrieben.
Wojtek Rzepala
3
Ihr ~ / .ssh-Verzeichnis muss 700 sein. Ihre private Schlüsseldatei muss 600 sein. Ihre öffentliche Schlüsseldatei muss 644 sein. Ihre auth-Datei (auf der Fernbedienung) muss 644 sein
Rob
@Rob das war das Problem. Wenn Sie das als Antwort posten würden, würde ich es akzeptieren.
Thom
4

Meine Lösung war, dass das Konto gesperrt war. Nachricht in / var / log / secure gefunden: Benutzer nicht erlaubt, da Konto gesperrt. Lösung: Geben Sie dem Benutzer ein neues Passwort.

user46932
quelle
Ich habe das Problem behoben, indem ich das Kennwortfeld /etc/shadowfür diesen Benutzer von !in geändert habe *. Danach ist die Passwort-Authentifizierung immer noch nicht möglich, der Benutzer ist jedoch nicht mehr gesperrt.
user3132194
4

Ich bin auf ein ähnliches Problem gestoßen und habe die Schritte im Debug-Modus ausgeführt.

/usr/sbin/sshd -d

Dies zeigte das folgende Ergebnis

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

Es war wirklich verwirrend

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

Es zeigte, dass das Stammverzeichnis Berechtigungen für alle hatte. Wir haben es geändert, damit andere keine Berechtigungen haben.

[root@sys-135 ~]# chmod 750 /root

Die Schlüsselauthentifizierung funktioniert nun.

Jagadisch
quelle
Ich habe das gleiche Problem. Gestern gab ich rsync -av ./root/ root@THE_HOST:/rootan, einige Dateien aus meinem lokalen Arbeitsverzeichnis hochzuladen. Dann tritt dieses Problem auf (tatsächlich bemerkte ich es zuerst nicht. Nachdem Cron-Jobs auf anderen Hosts am nächsten Morgen fehlschlugen, begann ich, den Grund zu suchen.) . Der rsync -av ./root/ root@THE_HOST:/rootBefehl hat den Eigentümer und die Berechtigung des /rootVerzeichnisses des Remote-Hosts geändert . Die Erlaubnis wurde behoben, das Problem wurde behoben.
LiuYan 刘 研
Failed publickey for root from 135.250.24.32 port 54553 ssh2Ich erhalte dieselbe Meldung und dasselbe Problem, wenn ich vergessen habe, den Pubkey einem Host hinzuzufügen authorized_keys. Wenn ich diesen Kommentar wie in meinem Fall
hinzufüge, merke
3

In der Datei / etc / selinux / config wurde SELINUX so geändert, dass es nicht mehr möglich ist, passwortloses SSH zu erzwingen.

Früher bin ich in der Lage, es auf eine Weise zu tun. Jetzt kann ich von beiden Seiten aus passwortloses ssh ausführen.

Chinna
quelle
3

Eine Sache, die ich falsch hatte, war der Besitz in meinem Home-Verzeichnis auf dem Serversystem. Das Serversystem wurde auf default: default gesetzt, damit ich:

chown -R root:root /root

Und es hat funktioniert. Eine andere günstige Problemumgehung besteht darin, StrictModes zu deaktivieren: StirctModes-Nr. in sshd_config. Dies zeigt Ihnen zumindest, ob die Schlüsselaustausch- und Verbindungsprotokolle gut sind. Dann können Sie die schlechten Berechtigungen jagen.

Wille
quelle
Ich auch. Schauen Sie sich die Nachrichten in / var / log / secure an. Ich sah eine Meldung: "Authentifizierung abgelehnt: falscher Besitz oder Modi für Verzeichnis" ($ HOME). Stellen Sie sicher, dass für Group oder Other kein Schreibzugriff auf $ HOME besteht. Ich hätte das nie gefunden, wenn ich keinen nicht autorisierten Root-Zugriff auf den Server
gehabt hätte
2

Für mich war die Lösung gegenüber der von Wojtek Rzepala : Ich habe nicht bemerkt, dass ich immer noch benutze authorized_keys2, was veraltet ist . Mein SSH-Setup funktionierte irgendwann nicht mehr, vermutlich als der Server aktualisiert wurde. Umbenennung .ssh/authorized_keys2als.ssh/authorized_keys das Problem behoben.

D'oh!

Michael Scheper
quelle
Dies ist auch eine Konfigurationsoption in / etc / ssh / sshd_config, obwohl ich denke, ich würde es umbenennen, wie Sie es getan haben.
Rick Smith
2

In der Vergangenheit bin ich auf einige Tutorials gestoßen, die beschreiben, wie man ein passwortloses ssh-Setup erreicht, aber einige sind leider falsch.
Fangen wir noch einmal von vorne an und überprüfen Sie jeden Schritt:

  1. FROM CLIENT - Schlüssel generieren: ssh-keygen -t rsa
    Öffentlicher und privater Schlüssel ( id_rsa.pubund id_rsa) werden automatisch im ~/.ssh/Verzeichnis gespeichert .
    Die Einrichtung wird einfacher, wenn Sie eine leere Passphrase verwenden. Wenn Sie dazu nicht bereit sind, befolgen Sie trotzdem diese Anleitung, aber überprüfen Sie auch den nachstehenden Aufzählungspunkt.

  2. FROM CLIENT - Kopieren des öffentlichen Schlüssels auf den Server : Der ssh-copy-id user@server
    öffentliche Schlüssel des Clients wird auf den Serverstandort kopiert ~/.ssh/authorized_keys.

  3. FROM CLIENT - Verbindung zum Server herstellen:ssh user@server

Wenn es nach den drei beschriebenen Schritten immer noch nicht funktioniert, versuchen wir Folgendes:

  • Überprüfen Sie die ~/sshOrdnerberechtigungen auf dem Client- und Server- Computer.
  • Überprüfen Sie /etc/ssh/sshd_configin dem Server , um sicherzustellen RSAAuthentication, PubkeyAuthenticationund UsePAMOptionen nicht deaktiviert werden, können sie standardmäßig mit aktiviert werden yes.
  • Wenn Sie ein Passwort eingegeben , während der Client - Schlüssel zu erzeugen, dann können Sie versuchen , ssh-agentund ssh-addkennwort weniger Verbindungen in Ihrer Sitzung zu erreichen.
  • Überprüfen Sie den Inhalt /var/log/auth.logauf dem Server das Problem zu finden , warum Key - Authentifizierung überhaupt übersprungen.
Marc
quelle
Vielen Dank für die Auflistung der Schritte! Ich ging zu "ssh-copy-id user @ server" und stellte fest, dass ich ursprünglich über den falschen öffentlichen Schlüssel kopiert hatte.
Mattavatar
2

Ich hatte genau das gleiche Problem mit PuTTY, das an eine Ubuntu 16.04 Maschine anschließt. Es war rätselhaft, weil das pscp-Programm von PuTTY mit demselben Schlüssel einwandfrei funktionierte (und mit demselben Schlüssel in PuTTY eine Verbindung zu einem anderen Host hergestellt wurde).

Dank des wertvollen Kommentars von @UtahJarhead habe ich meine Datei /var/log/auth.log überprüft und Folgendes festgestellt:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Es stellt sich heraus, dass neuere Versionen von OpenSSH standardmäßig keine DSA-Schlüssel akzeptieren. Nachdem ich von einem DSA zu einem RSA-Schlüssel gewechselt hatte, funktionierte es einwandfrei.

Ein anderer Ansatz: In dieser Frage wird erläutert, wie der SSH-Server für die Annahme von DSA-Schlüsseln konfiguriert wird: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

Tschad
quelle
1

Diese Schritte sollten Ihnen helfen. Ich benutze dies regelmäßig unter vielen 64-Bit-Ubuntu 10.04-Maschinen.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

Sie können dies mit einigen Eingabeaufforderungen in ein Skript einfügen und es als aufrufen

script_name username remote_machine
Sriharsha
quelle
Es existiert bereits ssh-copy-idwas die letzten beiden Schritte automatisch macht.
Jofel
2
@jofel bedenke, dass es in vielen Systemen keine ssh-copy-id gibt. @ Sriharsha, nachdem mkdirSie dort chmod 700 .sshauch hinzufügen sollten und übrigens nicht so ausführlich sein müssen ~/.ssh, ist gerade .sshgenug, da die Befehle sowieso im
Ausgangsverzeichnis
1

Ich hatte ein ähnliches Problem mit ssh. In meinem Fall bestand das Problem darin, dass ich hadoop cloudera (von rpm auf centos 6) installiert und den Benutzer hdfs mit dem Basisverzeichnis erstellt habe

/var/lib/hadoop-hdfs (nicht standard /home/hdfs ).

Ich habe in / etc / passwd /var/lib/hadoop-hdfszu gewechselt /home/hdfs, das Home-Verzeichnis an einen neuen Speicherort verschoben und kann jetzt eine Verbindung mit der Authentifizierung mit öffentlichem Schlüssel herstellen.

Andrzej Jozwik
quelle
1

Ich habe das gleiche Problem hatte, und für mich war die Lösung gesetzt UsePAMzu no. Sehen Sie, auch wenn auf PasswordAuthenticationgesetzt no, werden Sie immer noch bekommen keyboard-interactive, und in meinem Fall hat mein lokales ssh-Programm aus irgendeinem Grund diese Voreinstellung beibehalten.

Zusätzlicher Hintergrund für alle, die in der gleichen Situation sind: Ich verbinde mich von einem Host mit Dropbear zu einem mit OpenSSH. Mit PasswordAuthenticationund UsePAMbeide setzen noauf dem entfernten Rechner, werde ich die folgende Meldung erhalten , wenn ich eingeben ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

Wenn Sie die Identitätsdatei bereitstellen -i, funktioniert alles wie erwartet.

Möglicherweise gibt es hier etwas mehr Informationen.

Marty
quelle
1

Nachdem ich die Berechtigungen überprüft und verschiedene andere hier aufgelistete Lösungen ausprobiert hatte, entfernte ich schließlich das ssh-Verzeichnis auf dem Server und richtete meinen öffentlichen Schlüssel erneut ein.

Serverbefehle:

# rm -rf ~/.ssh

Lokale Befehle:

# ssh-copy-id [email protected]        # where <user> is your username and <192.168.1.1> is the server IP
Steven C. Howell
quelle
1

Auf dem Server:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

Es war directory permission issue. Es war 777 am Server, also I changed it back to 700. Dies ist fixedmein Problem, ssh password less login failureauch nach dem Kopieren $USER/.ssh/id_rsa.pubauf den Server $USER/.ssh/authorized_keys.

fastrizwaan
quelle
0

Eine weitere Option ist eine Variante von @Jagadishs Antwort : an straceden ssh-Daemon.

Es hat den entscheidenden Vorteil, dass wir sshd nicht stoppen müssen, was zu einer vollständigen Sperrung führen kann, wenn etwas schief geht.

Zuerst finden wir die PID des Hauptprozesses sshd. Hier können wir es sehen, indem wir a ausführen pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

Nachdem wir wissen, dass die pid 633 ist, können wir stracesie nach ihren Kindern:

strace -p 633 -s 4096 -f -o sux

Das Ergebnis wird sein, dass alles, was dieser sshd und seine untergeordneten Prozesse getan haben, in die suxim lokalen Verzeichnis angegebene Datei verschoben wird .

Dann reproduzieren Sie das Problem.

Es wird eine riesige Liste von Kernel-Anrufprotokollen geben, die für uns größtenteils unverständlich / irrelevant sind, aber nicht überall. In meinem Fall war das Wichtigste:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

Es war beabsichtigt, dass das sshd versuchte, die Nachricht zu protokollieren. Benutzer cica nicht erlaubt, da das Konto gesperrt ist - es konnte nur nicht, weil die Protokollierung nicht ausführlich genug ist. Aber wir wissen bereits, dass der Pubkey abgelehnt wurde, weil das Konto gesperrt war.

Es ist noch keine Lösung - jetzt müssen wir googeln, was im Fall von sshd ein "gesperrtes Konto" bedeutet. Es wird höchstwahrscheinlich einige trivial /etc/passwd, /etc/shadowZauberei, aber das Wichtigste ist , getan - das Problem ist nicht ein mysteriöser ist, sondern ein leicht debug / googlable ein.

Peterh
quelle
0

In meinem Fall hatte ich alle Rechte und selbst wenn ich ssh mit -vvv flag laufen ließ, konnte ich nicht herausfinden, was das Problem war.

Also habe ich ein neues Zertifikat auf dem Remote-Host generiert

ssh-keygen -t rsa -C "[email protected]"

und kopierte generierte Schlüssel auf den lokalen Computer und fügte einen neuen öffentlichen Schlüssel zu ~ / .ssh / authorized_keys auf dem Remote-Host hinzu

cat id_rsa.pub >> authorized_keys

Die Verwendung der generierten Schlüssel von der Remote-Host-Computer-Verbindung funktioniert jetzt. Wenn andere Lösungen versagen, ist dies eine andere Sache, die Sie versuchen sollten.

kovinet
quelle
0

Mein Szenario war, dass ich einen NAS-Server besitze, auf dem ich backupbotnach der Erstellung meines primären Kontos einen Benutzer erstellt habe, der sich anmelden konnte, um den backupbotBenutzer zunächst zu erstellen . Nachdem Sie mit sudo vim /etc/ssh/sshd_configdem backupbotBenutzer herumgespielt und ihn erstellt haben , vimkönnen Sie zumindest unter Ubuntu 16.04 und basierend auf Ihrer ~/.vimrcKonfiguration eine Auslagerungsdatei erstellen, die von der Bearbeitung Ihrer vim-Sitzung von übrig geblieben ist /etc/ssh/sshd_config.

Überprüfen Sie, ob: /etc/ssh/.sshd_config.swpvorhanden ist und ob es entfernt wird, und starten Sie den sshdDämon neu:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

Dies löste mein Problem auf magische Weise. Ich hatte zuvor alle meine Berechtigungen und sogar die RSA-Fingerabdrücke der öffentlichen und privaten Schlüssel überprüft. Das ist seltsam und wahrscheinlich ein Fehler in sshddieser Version:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1. März 2016

Rivanov
quelle