it-swarm.com.de

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

Ich habe den public-ssh-Schlüssel zur authorized_keys-Datei hinzugefügt. ssh localhost sollte mich anmelden, ohne nach dem Passwort zu fragen. 

Ich habe das getan und versucht, ssh localhost einzugeben, aber es wird immer noch aufgefordert, das Passwort einzugeben. Gibt es eine andere Einstellung, die ich durchmachen muss, damit es funktioniert?

Ich habe die Anweisungen zum Ändern der Berechtigungen befolgt:

Unten ist das Ergebnis, wenn ich ssh -v localhost

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA Host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Dann fragt er nach dem obigen Protokoll nach der Passphase. Warum meldet es sich nicht ohne Passwort an?

378
user482594

Sie müssen die Berechtigungen der Datei authorized_keys und des Ordners bzw. der übergeordneten Ordner überprüfen, in denen sich die Datei befindet.

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

Weitere Informationen finden Sie auf dieser Seite .

Sie müssen möglicherweise auch die Berechtigungen Ihres Heimatverzeichnisses ändern/überprüfen, um den Schreibzugriff für die Gruppe und andere Personen zu entfernen.

chmod go-w ~
953
Teddy

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
137
Cole Stanfield

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

90
bortunac

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 

34
Stephan Hoyer

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.

9

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.

7
fche

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

7
Nim

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
5
wcc526

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 
4
Ulrich Behrendt

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.

3
Sean Bannister

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
3
Exsonic

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

3
user2683246

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

3
h99

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
2
Kunthar

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.

2
George

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.

1
Willem

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

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

das löst mein problem

ssh-agent bash

ssh-add

1
Julian

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.

1
Joey

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

1
GJSmith3rd

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. 

0
Edward van Kuik

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

0
alexandrul

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
0
Edd Stance

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
0
cmcginty

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.

0
Jason Cohen

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.

0
Bevor

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
0
Mark

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. 

0
pppk520