Durch Hinzufügen eines öffentlichen Schlüssels zu ~/.ssh/authorised_keys wird nicht automatisch angemeldet

SELinux kann auch dazu führen, dass Authorized_keys nicht funktionieren. Speziell für root in CentOS 6 und 7. Dies muss jedoch nicht deaktiviert werden. Wenn Sie überprüft haben, dass Ihre Berechtigungen korrekt sind, können Sie dies folgendermaßen beheben:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

die Einstellung ssh authorised_keys scheint einfach zu sein, verbirgt jedoch einige Fallen, die ich zu verstehen versuche

- SERVER -

legen Sie in / etc/ssh/sshd_configpasswordAuthentication yes fest, damit der Server die Kennwortauthentifizierung vorübergehend akzeptiert

-- KLIENT -- 

betrachten Sie cygwin als Linux-Emulation und installieren Sie und führen Sie openssh aus

1. erzeugt private und öffentliche Schlüssel (clientseitig) # ssh-keygen

durch Drücken von ENTER erhalten Sie DEFAULT 2 Dateien "id_rsa" und "id_rsa.pub" in ~/.ssh/ aber wenn Sie einen name_for_the_key angeben, werden die generierten Dateien in Ihrem pwd gespeichert. 

2. Platziere your_key.pub auf dem Zielrechner ssh-copy-id [email protected]_name

wenn Sie keinen Standardschlüssel erstellt haben, ist dies der erste Schritt, um einen Fehler zu beheben. Sie sollten dies verwenden

ssh-copy-id -i path/to/key_name.pub [email protected]_name

3. Protokollierung ssh [email protected]_name funktioniert nur für die Standardeinstellung id_rsa. Hier ist der 2. Trap, den Sie benötigen, um ssh -i path/to/key_name [email protected]

(Verwenden Sie die Option ssh -v ..., um zu sehen, was passiert.)

Wenn server immer noch nach dem Kennwort fragt, haben Sie smth angegeben. zu Passphrase eingeben:, wenn Sie Schlüssel erstellt haben (so ist es normal) 

wenn ssh nicht abhört, muss der Standardport 22 ssh -p port_nr verwenden. 

- SERVER -----

4. Ändern Sie / etc/ssh/sshd_config, um sie zu erhalten

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(unauffällig, wenn Fall)

Dies weist ssh an, die Berechtigungstasten zu akzeptieren und im Benutzerverzeichnis nach dem in der Datei .ssh/Authorized_keys geschriebenen Schlüsselnamen zu suchen

5 Berechtigungen auf dem Zielcomputer festlegen

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Deaktivieren Sie auch die Passauth 

passwordAuthentication no 

um das Gate zu allen ssh root/admin /[email protected] your_domain Versuchen zu schließen

6 stellt sicher, dass der Besitz und der Gruppeneigentum aller Nicht-Stammverzeichnisse angemessen sind.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user 

===============================================

7. betrachten das excelent http://www.fail2ban.org

8. extra ssh TUNNEL , um auf einen MySQL-Server (bind = 127.0.0.1) zuzugreifen

Vergewissern Sie sich außerdem, dass Ihr Heimatverzeichnis nicht für andere Personen schreibbar ist

chmod g-w,o-w /home/USERNAME

Antwort ist aus hier gestohlen 

die Verzweifelten stellen möglicherweise auch sicher, dass sie keine zusätzlichen Zeilenumbrüche in der Datei authorized_keys enthalten, da der Text id_rsa.pub aus einem verwirrten Terminal kopiert wird.

Das Auflisten eines öffentlichen Schlüssels in .ssh/authorised_keys ist erforderlich, reicht jedoch nicht aus, damit sshd (Server) diesen akzeptiert. Wenn Ihr privater Schlüssel passphrasengeschützt ist, müssen Sie ssh (Client) jedes Mal die Passphrase geben. Oder Sie können ssh-agent oder ein gnome-Äquivalent verwenden.

Ihre UPDATE-Ablaufverfolgung stimmt mit einem durch Passphrase geschützten privaten Schlüssel überein. Siehe ssh-agent oder ssh-keygen -p.

Beachten Sie, dass SELinux auch diesen Fehler auslösen kann, auch wenn alle Berechtigungen in Ordnung zu sein scheinen. Das Deaktivieren hat für mich den Trick geleistet (übliche Disclaimer über das Deaktivieren einfügen).

benutzer ist dein Benutzername

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

Die Sache, die den Trick für mich auslöste, war schließlich sicherzustellen, dass der Besitzer/Gruppe nicht root, sondern user waren:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

In meinem Fall musste ich meine authorized_keys-Datei in .openssh ablegen. 

Diese Position wird in /etc/ssh/sshd_config unter der Option AuthorizedKeysFile %h/.ssh/authorized_keys angegeben.

Schreibbefehl:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Nachdem Sie dies getan haben, stellen Sie sicher, dass Ihr Verzeichnis so ist:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

Noch ein Tipp, den Sie sich merken sollten. Seit v7.0 ist OpenSSH deaktiviert DSS/DSA-SSH-Schlüssel standardmäßig aufgrund ihrer Vererbungsschwäche. Wenn Sie OpenSSH v7.0 + verwenden, stellen Sie sicher, dass Ihr Schlüssel nicht ssh-dss ist.

Wenn Sie mit DSA-Schlüsseln nicht weiterkommen, können Sie die Unterstützung lokal mit .__ erneut aktivieren. Aktualisieren Sie Ihre sshd_config- und ~/.ssh/config-Dateien mit folgenden Zeilen: PubkeyAcceptedKeyTypes=+ssh-dss

Versuchen Sie "ssh-add", was für mich funktioniert hat.

Ein anderes Problem muss man beachten. Wenn Ihre generierte Datei nicht standardmäßig ist id_rsa und id_rsa.pub

Sie müssen eine .ssh/config-Datei erstellen und manuell festlegen, welche ID-Datei Sie mit der Verbindung verwenden möchten.

Beispiel ist hier:

Host remote_Host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

Stellen Sie sicher, dass der Zielbenutzer ein Kennwort festgelegt hat. Führen Sie passwd username aus, um einen zu setzen. Dies war für mich auch dann erforderlich, wenn das Passwort-SSH-Login deaktiviert war.

Stellen Sie sicher, dass Sie den gesamten öffentlichen Schlüssel in authorized_keys kopiert haben. Das ssh rsa-Präfix ist notwendig, damit der Schlüssel funktioniert.

sie müssen die Eigenschaften der Dateien überprüfen, um die erforderliche Eigenschaft zuzuweisen.

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

das löst mein problem

ssh-agent bash

ssh-add

Es scheint ein Erlaubnisproblem zu sein. Normalerweise geschieht dies, wenn die Berechtigung einer Datei/eines Verzeichnisses nicht korrekt eingerichtet ist. In den meisten Fällen sind dies ~/.ssh und ~/.ssh/*. In meinem Fall sind sie /home/xxx.

Sie können den Log-Level von sshd ändern, indem Sie /etc/ssh/sshd_config ändern (Suche LogLevel, setzen Sie ihn auf DEBUG). Überprüfen Sie dann die Ausgabe in /var/log/auth.log, um zu sehen, was genau passiert.

Ich gab Sudo chmod 700 ~/.ssh und chmod 600 ~/.ssh/authorized_keys und chmod go-w $HOME $HOME/.ssh von oben heraus und es wurde mein Problem auf einer CentOS7-Box behoben, bei der ich die Berechtigungen versaut hatte, als ich versuchte, Samba-Freigaben zum Laufen zu bringen. Vielen Dank

Schau einfach auf /var/log/auth.log auf dem Server . Das Festlegen zusätzlicher Ausführlichkeit mit -vv auf der Clientseite hilft nicht, da der Server einem möglichen Angreifer wahrscheinlich nicht zu viele Informationen bietet. 

Ich habe das Basisverzeichnis an einem nicht standardmäßigen Ort und in sshd Protokollen habe ich diese Zeile:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

selbst wenn alle Berechtigungen in Ordnung wären (siehe die anderen Antworten).

Ich habe hier eine Lösung gefunden: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

In meinem speziellen Fall:

• fügte eine neue Zeile in /etc/selinux/targeted/contexts/files/file_contexts.homedirs hinzu:

  • dies ist die ursprüngliche Zeile für reguläre Home-Verzeichnisse:

    /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

  • das ist meine neue Zeile:

    /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

• gefolgt von einem restorecon -r /data/ und einem sshd Neustart

vergewissern Sie sich in diesem Hinweis, dass Sie für sshd config -;

PermitRootLogin without-password

wie oben eingestellt, dann sshd neu starten (/etc/init.d/sshd restart)

abmelden und erneut anmelden!

ich glaube, ist standardmäßig -;

PermitRootLogin no

Suchen Sie nach /var/log/auth.log auf dem Server nach sshd auth-Fehlern.

Wenn alles andere fehlschlägt, führen Sie den sshd-Server im Debug-Modus aus:

Sudo /usr/sbin/sshd -ddd -p 2200

Verbinden Sie sich dann vom Client aus:

ssh [email protected] -p 2200

In meinem Fall habe ich am Ende den Fehlerabschnitt gefunden:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

Mit dieser Information wurde mir klar, dass mein sshd_config Logins auf Mitglieder der ssh-Gruppe beschränkt. Der folgende Befehl hat diesen Berechtigungsfehler behoben:

Sudo usermod -a -G ssh NEW_USER

Ich hatte dieses Problem und keine der anderen Antworten löste es, obwohl natürlich die anderen Antworten richtig sind.

In meinem Fall stellte sich heraus, dass das /root-Verzeichnis selbst (nicht beispielsweise /root/.ssh) die falschen Berechtigungen hatte. Ich brauchte:

chown root.root /root
chmod 700 /root

Natürlich sollten diese Berechtigungen ungeachtet dessen (vielleicht chmod 770) gleich sein. Es hat jedoch ausdrücklich verhindert, dass sshd funktioniert, obwohl /root/.ssh und /root/.ssh/authorized_keys über korrekte Berechtigungen und Besitzer verfügten.

Ich hatte dieses Problem, als ich die Gruppe des angemeldeten Benutzers einem anderen Benutzer hinzufügte. Angenommen, es gibt einen SSH-Anmeldebenutzer mit dem Namen BenutzerA und einen Nicht-SSH-Anmeldebenutzer BenutzerB. userA hat auch die Gruppe userA. Ich habe userB geändert, um auch die Gruppe userA zu haben. Dies führte zu dem beschriebenen Verhalten, so dass sich Benutzer A nicht ohne Aufforderung anmelden konnte. Nachdem ich die Gruppe BenutzerA von BenutzerB entfernt hatte, funktionierte die Anmeldung ohne Eingabeaufforderung erneut.

Mein Problem war eine modifizierte AuthorizedKeysFile, als die Automatisierung zum Auffüllen von/etc/ssh/authorised_keys noch nicht ausgeführt wurde.

$Sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

In meinem Fall liegt es daran, dass die Gruppe des Benutzers nicht in AllowGroups der Konfigurationsdatei/etc/ssh/sshd_config festgelegt ist. Nach dem Hinzufügen funktioniert alles gut.