Ik had een probleem met mijn mac waarbij ik geen enkel bestand meer op de schijf kon opslaan.
Ik moest OSX lion opnieuw opstarten en de machtigingen voor bestanden en acls opnieuw instellen.
Maar als ik nu een repository wil committen, krijg ik de volgende foutmelding van 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.
Welke machtigingsniveaus moet ik aan het id_rsa-bestand geven?
Antwoord 1, autoriteit 100%
Sleutels moeten alleen door u leesbaar zijn:
chmod 400 ~/.ssh/id_rsa
Als sleutels door u leesbaar moeten zijn:
chmod 600 ~/.ssh/id_rsa
600lijkt ook in orde te zijn (in de meeste gevallen zelfs beter, omdat u de bestandsrechten later niet hoeft te wijzigen om het te bewerken).
Het relevante gedeelte van de manpagina (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.
Antwoord 2, autoriteit 3%
Bij gebruik van Cygwin in Windows 8.1 moet een commando worden uitgevoerd:
chgrp-gebruikers ~/.ssh/id_rsa
Dan kan de hier geposte oplossing worden toegepast, 400 of 600 is OK.
chmod 600 ~/.ssh/id_rsa
Ref: http://vineetgupta.com/blog/cygwin-permissions-bug-on -windows-8
Antwoord 3
De locale-onafhankelijke oplossing die werkt op Windows 8.1 is:
chgrp 545 ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
GID 545 is een speciale IDdie altijd verwijst naar de groep ‘Gebruikers’, zelfs als u locale gebruikt een ander woord voor gebruikers.
Antwoord 4
Ik heb de fout in mijn Windows 10, dus ik heb de toestemming als volgt ingesteld en het werkt.
In details, verwijder andere gebruikers/groepen totdat het alleen ‘SYSTEEM’ en ‘Beheerders’ heeft. Voeg vervolgens uw Windows-login toe met alleen de machtiging Lezen.
Let op: het bestand id_rsabevindt zich in de map c:\users\<username>.
Antwoord 5
0600 is waar de mijne op is ingesteld (en het werkt)
Antwoord 6
AFAIK de waarden zijn:
700 voor de verborgen map “.ssh” waar het sleutelbestand zich bevindt
600 voor het sleutelbestand “id_rsa”
Antwoord 7
Windows 10 ssh naar Ubuntu EC2 “permissies zijn te open” fout op AWS
Ik had dit probleem toen ik probeerde te ssh-en naar een Ubuntu EC2-instantie met behulp van het .pem-bestand van AWS.
In Windows werkte dit toen ik deze sleutel in een map plaatste die was aangemaakt onder de .ssh-map
C:\Users\USERNAME\.ssh\private_key
Om toestemmingsinstellingen in Windows 10 te wijzigen:
Bestandsinstellingen > Beveiliging > Geavanceerd
Overerving uitschakelen
Overgenomen machtigingen omzetten in expliciete machtigingen
Verwijder alle machtigingsvermeldingen behalve beheerders
Kon dan veilig verbinding maken.
Antwoord 8
geef 400 toestemming,
voer onderstaande opdracht uit
chmod 400 /Users/username/.ssh/id_rsa
Antwoord 9
Er is één uitzondering op de ‘0x00’-machtigingsvereiste voor een sleutel. Als de sleutel eigendom is van root en eigendom is van een groep met gebruikers erin, dan kan het “0440” zijn en kan elke gebruiker in die groep de sleutel gebruiken.
Ik geloof dat dit zal werken met alle rechten in de set “0xx0”, maar ik heb niet elke combinatie met elke versie getest. Ik heb 0660 geprobeerd met 5.3p1-84 op CentOS 6, en de groep is niet de primaire groep van de gebruiker, maar een secundaire groep, en het werkt prima.
Dit wordt normaal gesproken niet gedaan voor iemands persoonlijke sleutel, maar voor een sleutel die wordt gebruikt voor automatisering, in een situatie waarin je niet wilt dat de applicatie met de sleutel kan knoeien.
Vergelijkbare regels zijn van toepassing op de .ssh directory-beperkingen.
Antwoord 10
Op Windows 10 waren de chmod en chgrp van cygwin niet genoeg voor mij. Ik moest met de rechtermuisknop op het bestand klikken -> Eigenschappen -> Beveiliging (tabblad) en verwijder alle gebruikers en groepen behalve mijn actieve gebruiker.
Antwoord 11
Dit is wat voor mij werkte (op mac)
sudo chmod 600 path_to_your_key.pem
dan :
ssh -i path_to_your_key user@server_ip
Ik hoop dat het helpt
Antwoord 12
Alleen voor Windows-gebruikers.
Ga naar bestandseigenschap–> beveiliging –> geavanceerd
- Overervingseigenschap uitschakelen
- Overerfde machtigingen omzetten in expliciete machtigingen.
- Verwijder alle machtigingsvermeldingen behalve de beheerders.
Antwoord 13
wat voor mij werkte
chgrp Gebruikersmap
chmod 600 MAP
Antwoord 14
Voor mij (met het Ubuntu-subsysteem voor Windows) is de foutmelding gewijzigd in:
Permissions 0555 for 'key.pem' are too open
na gebruik van chmod 400.
Het blijkt dat het gebruik van root als standaardgebruiker de reden was.
Wijzig dit met de cmd:
ubuntu config --default-user your_username
Antwoord 15
Ik kreeg hetzelfde probleem na de migratie van een andere mac.
En het blokkeerde om github te verbinden met mijn sleutel.
Ik reset de toestemming zoals hieronder en het werkt nu goed.
chmod 700 ~/.ssh # (drwx------)
cd ~/.ssh
chmod 644 *.pub # (-rw-r--r--)
chmod 600 id_rsa # (-rw-------)
Antwoord 16
Interessant bericht hier.
Besturingssystemen zijn slim genoeg om externe verbindingen te weigeren als uw privésleutel te open is. Het begrijpt het risico waar machtigingen voor id_rsa wijd open zijn (lees, kan door iedereen worden bewerkt).
{Men kan eerst uw slot vervangen en dan openen met de sleutels die hij al heeft}
cd ~/.ssh
chmod 400 id_rsa
Tijdens het werken aan de meerdere servers (niet-productie), hebben de meesten van ons nodig om de externe server met SSH aan te sluiten. Een goed idee is om een stukje toepassingsniveau-code te hebben (kan JAVA zijn met JSCH) om SSH-trusts tussen servers te maken. Op deze manier is aansluiting wachtwoordloos. Incase, Perl is geïnstalleerd – men kan ook een Net SSH-module gebruiken.
Antwoord 17
Zoals mensen hebben gezegd, in Windows, heb ik net mijn PEM-bestand in C: \ -gebruikers [Gebruiker] .SSH \ en die het opgelost heeft. Hoewel je chmod en andere opdrachtregelopties kunt doen van een bash of powershell-prompt die niet werkte. Ik heb RSA of iets anders niet veranderd. Wanneer u vervolgens de verbinding uitvoert, moet u het pad naar het PEM-bestand plaatsen in de MAP .SSH:
SSH -I “C: \ -gebruikers [Gebruiker] .SSH \ UbuntUKP01.PEM” Ubuntu @ EC [ipaddress] .us-west-2.compute.amazonaws.com
Antwoord 18
Typ deze opdracht om uw probleem op te lossen.
chmod 600 ~/.ssh/id_rsa
Antwoord 19
Ik bewaar alle eigen certificaten en sleutels in één directory, en dit werkt voor gereedschappen zoals Putty, maar ik heb dit “Too Open” -foutbericht van de SCP-opdracht. Ik ontdekte dat Windows al een C: \ -gebruikers \ AccountName \ .ssh-map onderhoudt met de juiste toegangsrechten voor het opslaan van SSH-sleutels. Zolang u de inhoud behoudt (Windows verwijdert het soms tijdens updates) of maak u uw eigen map voor SSH-toetsen in uw gebruikersmap, dit werkt prima, omdat alleen u en de beheerders toegang hebben tot die oudermap.
Wees voorzichtig met het wijzigen van toegangsrechten op Windows-mappen. Ik deed dit, en eenmaal per dag scannen Windows, lezen en het schrijven van alle bestanden op mijn C: Drive, een proces dat de computer gedurende vele minuten vertraagt.
Antwoord 20
Ik ben deze fout tegengekomen terwijl ik met Ansible aan het spelen was. Ik heb de rechten van de privésleutel gewijzigd in 600om dit probleem op te lossen. En het werkte!
chmod 600 .vagrant/machines/default/virtualbox/private_key
Antwoord 21
Ik heb het machtigingsniveau van 600 geprobeerd voor mijn privésleutel en het werkte voor mij.
chmod 600 privateKey
[dev]$ ssh -i privateKey gebruiker@ip
werkte
chmod 755 privateKey
[dev]$ ssh -i privateKey gebruiker@ip
het gaf onderstaand probleem:
Permissies 0755 voor ‘privateKey’ zijn te open.
Het is vereist dat uw privésleutelbestanden NIET toegankelijk zijn voor anderen.
Deze privésleutel wordt genegeerd.
Laad sleutel “privateKey”: slechte rechten
Antwoord 22
Voor Windows 10 is dit wat ik heb gevonden voor mij werkt:
- Verplaats je sleutel naar het Linux-bestandssysteem:
mv ~/.ssh /home/{username} - Stel de toestemming voor die sleutel in:
chmod 700 /home/{username}/.ssh/id_rsa - Maak een symbolische link naar de sleutel:
ln -s /home/{username}/.ssh ~/.ssh
Dit gebeurt als je hebt ingesteld dat je homedirectory (~) wordt opgeslagen in Windows in plaats van Linux (onder /mnt/vs /home/).
Antwoord 23
De andere truc is om dat in de downloadmap te doen.
Nadat u de privésleutel van de AWS EC2-instantie hebt gedownload, bevindt het bestand zich in deze map en typt u eenvoudig de opdracht
ssh-keygen -y -f mijnprivateKey.pem > mijnpublicKey.pub
Antwoord 24
700 folder
644 id_rsa.pub
dit werkt voor mij.
Antwoord 25
I have got the similar issue when i was trying to login to remote ftp server using public keys..
To solve this issue initially i have done the following process
Zoek eerst de locatie van de openbare sleutels, want wanneer u probeert in te loggen op ftp met deze openbare sleutel. eerst moeten we een sleutel maken en we stellen de machtigingen voor die sleutels in op 600.
Zorg ervoor dat u zich op de juiste locatie bevindt.
stap 1:
ga naar de juiste locatie
stap 2:
Nadat u zich op de juiste locatie bevindt
opdracht:
chmod 600 id_rsa
This has solved my issue.
Antwoord 26
In mijn geval probeerde ik verbinding te maken vanuit de Ubuntu-app in Windows 10 en kreeg de bovenstaande foutmelding.
Het kan worden opgelost zonder enige wijziging van de toestemming door sudo suuit te voeren in de Ubuntu-console voorafgaand aan de eigenlijke opdracht
Antwoord 27
Putty kan het werk doen op Windows 10. Het genereert een openbare sleutel met een privésleutel als invoer.
- download stopverf van https://www.putty.org/
- plamuur installeren. Twee toepassingen komen bij de installatie: putty config, putty key gen
- start puttyGen
- klik op laden en selecteer een privésleutelbestand. Houd er rekening mee dat u uw privésleutelbestand moet hernoemen met de extensie .ppk, bijvoorbeeld privésleutel.ppk
Antwoord 28
Ik kreeg dit probleem op WSL op Windows terwijl ik verbinding maakte met de AWS-instantie. Mijn probleem is opgelost door naar de klassieke opdrachtprompt te gaan. Je kunt proberen over te schakelen naar een andere terminalinterface en kijken of dat helpt.
Antwoord 29
Ik heb succes met ‘sudo’
sudo chmod 400 pem-file.pem
sudo ssh -i pem-file.pem [email protected]
Antwoord 30
In mijn geval was het probleem te veel witruimte.
ssh -i mykey.pem [email protected]
maar
ssh -i mykey.pem [email protected]
werkte prima. Het probleem is dat de witruimte wordt gebruikt als onderdeel van de gebruikersnaam.