it-swarm.com.de

ssh "Berechtigungen sind zu offen" Fehler

Ich hatte ein Problem mit meinem Mac, bei dem ich keine Art von Datei mehr auf der Festplatte speichern konnte.

Wenn ich jetzt ein Repository festschreiben möchte, erhalte ich folgende Fehlermeldung von ssh:

Permissions 0777 for '/Users/username/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

Welche Berechtigungsstufen sollte ich der id_rsa-Datei geben?

1508
Yannick Schall

Schlüssel müssen nur von Ihnen lesbar sein:

chmod 400 ~/.ssh/id_rsa

600 scheint auch in Ordnung zu sein (in den meisten Fällen sogar besser, da Sie zum Ändern keine Dateiberechtigungen ändern müssen).

Der relevante Teil der Manpage (man ssh)

 ~/.ssh/id_rsa
         Contains the private key for authentication.  These files contain sensitive 
         data and should be readable by the user but not
         accessible by others (read/write/execute).  ssh will simply ignore a private 
         key file if it is              
         accessible by others.  It is possible to specify a
         passphrase when generating the key which will be used to encrypt the sensitive 
         part of this file using 3DES.

 ~/.ssh/identity.pub
 ~/.ssh/id_dsa.pub
 ~/.ssh/id_ecdsa.pub
 ~/.ssh/id_rsa.pub
         Contains the public key for authentication.  These files are not sensitive and 
         can (but need not) be readable by anyone.
2616
quickshiftin

Wenn Sie Cygwin in Windows 8.1 verwenden, muss ein Befehl ausgeführt werden:

chgrp-Benutzer ~/.ssh/id_rsa

Dann kann die hier veröffentlichte Lösung angewendet werden, 400 oder 600 ist in Ordnung.

chmod 600 ~/.ssh/id_rsa

Ref: http://vineetgupta.com/blog/cygwin-permissions-bug-on-windows-8

82
tanza9

Die localeunabhängige Lösung, die unter Windows 8.1 funktioniert, lautet:

chgrp 545 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa

Die GID 545 ist eine spezielle ID , die sich immer auf die Gruppe "Benutzer" bezieht, auch wenn das Gebietsschema ein anderes Word für Benutzer verwendet.

31
thehouse

0600 ist, was meine ist (und es funktioniert)

28
Devin Ceartas

AFAIK die Werte sind:

700 für das versteckte Verzeichnis ".ssh", in dem sich die Schlüsseldatei befindet

600 für die Schlüsseldatei "id_rsa"

21
ajaaskel

Es gibt eine Ausnahme von der Berechtigungsanforderung "0x00" für einen Schlüssel. Wenn sich der Schlüssel im Besitz von root befindet und der Gruppe eine Gruppe mit Benutzern gehört, kann er "0440" sein und jeder Benutzer in dieser Gruppe kann den Schlüssel verwenden.

Ich glaube, das funktioniert mit allen Berechtigungen im Set "0xx0", aber ich habe nicht jede Kombination mit jeder Version getestet. Ich habe 0660 mit 5.3p1-84 auf CentOS 6 ausprobiert, und die Gruppe ist nicht die primäre Gruppe des Benutzers, sondern eine sekundäre Gruppe, und es funktioniert gut.

Dies wird normalerweise nicht für den persönlichen Schlüssel einer Person durchgeführt, sondern für einen Schlüssel, der für die Automatisierung verwendet wird, wenn die Anwendung nicht mit dem Schlüssel in Berührung kommen soll.

Ähnliche Regeln gelten für die .ssh-Verzeichniseinschränkungen.

13
syberghost

400-Berechtigung vorlegen, Befehl unter ausführen 

chmod 400 /Users/username/.ssh/id_rsa

 enter image description here

9
Sujit Dhamale

was für mich gearbeitet hat

chgrp Benutzer ORDNER

chmod 600 ORDNER

4
Jerome Ansia

Ich habe das gleiche Problem nach der Migration von einem anderen Mac. Und es blockierte, Github durch meinen Schlüssel zu verbinden.

Ich habe die Erlaubnis wie folgt zurückgesetzt und es funktioniert jetzt gut.

chmod 700 ~/.ssh     # (drwx------)
cd ~/.ssh            
chmod 644 *.pub      # (-rw-r--r--)
chmod 600 id_rsa     # (-rw-------)
3
Jeff Gu Kang

Unter Windows 10 reichten mir Cygwins chmod und chgrp nicht. Ich musste mit der rechten Maustaste auf die Datei klicken -> Eigenschaften -> Sicherheit (Registerkarte) und alle Benutzer und Gruppen mit Ausnahme meines aktiven Benutzers entfernen.

3
Jared Beach

Interessante Nachricht hier . Betriebssysteme sind intelligent genug, um Remoteverbindungen abzulehnen, wenn Ihr privater Schlüssel zu offen ist. Es versteht das Risiko, bei dem Berechtigungen für id_rsa weit offen stehen (lesen, kann von jedem bearbeitet werden).

{Vielleicht hat man zuerst das Schloss geändert und dann mit den bereits vorhandenen Schlüsseln geöffnet. }

cd ~/.ssh
chmod 400 id_rsa

PS: 

Bei der Arbeit auf mehreren Servern (nicht in der Produktion) glauben die meisten von uns, Remote-Server mit ssh zu verbinden. Eine gute Idee ist, ein wenig Code auf Anwendungsebene zu haben (möglicherweise Java mit jsch), um SSH-Vertrauensstellungen zwischen Servern zu erstellen. Auf diese Weise ist die Verbindung ohne Passwort. Wenn Perl installiert ist, kann auch das net ssh-Modul verwendet werden.

2
Piyush Baijal

Ich habe den Fehler in meinem Windows 10, also habe ich folgende Berechtigung gesetzt und es funktioniert.

 Permission for id_rsa of windows 10

Entfernen Sie im Detail andere Benutzer/Gruppen, bis nur "SYSTEM" und "Administratoren" vorhanden sind. Fügen Sie dann Ihr Windows-Login nur mit Leseberechtigung hinzu.

Beachten Sie, dass sich die id_rsa-Datei im Ordner c:\users\<username> befindet.

1

Das hat bei mir funktioniert (auf Mac)

Sudo chmod 600 path_to_your_key.pem 

dann :

ssh -i path_to_your_key [email protected]_ip

Ich hoffe es hilft

0
lansanalsm

Ich habe die Berechtigungsstufe 600 für meinen privaten Schlüssel ausprobiert, und es funktionierte für mich . chmod 600 privateKey [Dev] $ ssh -i privateKey [email protected]

chmod 755 privateKey [dev] $ ssh -i privateKey-Benutzer @ ip Das folgende Problem wurde ausgegeben: Berechtigungen 0755 für 'privateKey' sind zu offen . Es ist erforderlich Ihre privaten Schlüsseldateien sind für andere NICHT zugänglich. Dieser private Schlüssel wird ignoriert. Ein Schlüssel "privateKey" wird geladen: falsche Berechtigungen

0

Ich bin auf diesen Fehler gestoßen, als ich mit Ansible spielte. Ich habe die Berechtigungen des privaten Schlüssels auf 600 geändert, um dieses Problem zu lösen. Und es hat funktioniert!

chmod 600 .vagrant/machines/default/virtualbox/private_key
0
vildhjarta

Für mich (unter Verwendung des Ubuntu-Subsystems für Linux) wurde die Fehlermeldung folgendermaßen geändert:

 Permissions 0555 for 'key.pem' are too open

nach der Verwendung von chmod 400 ..__ stellt sich heraus, dass die Verwendung von root als Standardbenutzer der Grund war.

Ändern Sie dies mit dem Befehl cmd:

 ubuntu config --default-user your_username
0