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

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.

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

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

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.

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

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

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.

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

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

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/

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

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.

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.

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.

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.

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.

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!

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.

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

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

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.

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.

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

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.

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.

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.

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