Windows SSH: les autorisations pour 'clé privée' sont trop ouvertes

102

J'ai OpenSSH 7.6 installé dans Windows 7 à des fins de test. Le client et le serveur SSH fonctionnent parfaitement jusqu'à ce que j'essaye d'accéder à l'un de mes AWS EC2 à partir de cette fenêtre.

Il semble que je doive changer l'autorisation sur le fichier de clé privée. Cela peut être facilement fait sur unix / linux avec chmodcommande.

Qu'en est-il des fenêtres?

private-key.ppm est copié directement à partir d'AWS et j'imagine que l'autorisation aussi.

C:\>ssh -V
OpenSSH_7.6p1, LibreSSL 2.5.3

C:\>ver

Microsoft Windows [Version 6.1.7601]

C:\>


C:\>ssh [email protected] -i private-key.ppk
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'private-key.ppk' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "private-key.ppk": bad permissions
[email protected]: Permission denied (publickey).

C:\>
C:\>
C:\>ssh [email protected] -i private-key.ppm
Warning: Identity file private-key.ppm not accessible: No such file or directory.
[email protected]: Permission denied (publickey).

C:\>
Sabrina
la source
Avez-vous essayé de modifier la liste de contrôle d'accès?
Ignacio Vazquez-Abrams
1
Votre clé privée est-elle réellement dans le chemin racine C: \? Je peux voir pourquoi il se plaint, car tout le monde est accessible dans C: \. Avez-vous essayé de le déplacer dans un dossier auquel seul l'utilisateur en tant qu'utilisateur a accès (par exemple, C: \ Utilisateurs \ nom d'utilisateur \ bureau) et voir si ce message apparaît toujours?
Darius
@Darius, oui ça l'est. Lorsque vous copiez un fichier d'unix / linux vers Windows, les autorisations sont également copiées. J'ai besoin de changer cela, mais je ne sais pas comment le faire sous Windows. Cela peut être facilement fait sur unix / linux avec la commande chmod.
Sabrina
@ IgnacioVazquez-Abrams, ACL? Quel genre de LCA?
Sabrina
1
@Sabrina Soit vous utilisez la commande icacls pour modifier l'autorisation, soit cliquez simplement avec le bouton droit de la souris sur la clé privée, sélectionnez Propriétés, puis cochez la case dans l'onglet "Sécurité". Et assurez-vous qu’elle n’est accessible que par vous / quiconque est supposé pouvoir accéder à la clé privée. Si "Utilisateurs" ont un accès en lecture, toute personne ayant accès au système peut lire cette clé privée.
Darius

Réponses:

119

Vous localisez le fichier dans l'Explorateur Windows, faites un clic droit dessus, puis sélectionnez "Propriétés". Accédez à l'onglet "Sécurité" et cliquez sur "Avancé".

Changez le propriétaire pour vous, désactivez l'héritage et supprimez toutes les autorisations. Puis accordez-vous le "Contrôle total" et sauvegardez les permissions. Maintenant, SSH ne se plaindra plus de la permission de fichier trop ouverte.

Cela devrait ressembler à ceci:

entrez la description de l'image ici

iBug
la source
2
Je voudrais juste ajouter 1) Cette méthode fonctionne sur ma 10.0.17134.191boîte Windows 10 ( ) avec Cygwin ver CYGWIN_NT-10.0-WOW 2.3.1(0.291/5/3) 2015-11-14 12:42et ssh ver OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4, et 2) Merci! @ iBug!
Atreyu
SI le fichier de clé est sur la clé USB / le disque flash, cet onglet Sécurité n'est pas disponible!
Dylan B
@DylanB Pourquoi avez-vous mis les informations d'identification sur un lecteur amovible? (En fait, cet onglet n'est disponible que sur les systèmes de fichiers NTFS - vous pouvez facilement formater votre disque en NTFS).
iBug
11
En fait, je l'ai fait et il se plaint toujours que les autorisations 0777 sont trop ouvertes.
Aaron Bramson
11
Pourquoi est-ce si difficile sous Windows, quelqu'un peut-il simplement ajouter une option de commande --ignore-stupid-rule?
Liam Mitchell
22

Les clés ne doivent être accessibles qu'à l'utilisateur auquel elles sont destinées et à aucun autre compte, service ou groupe.

  • GUI:
    • [Fichier] Propriétés - Sécurité - Avancé
      1. Définir le propriétaire sur l'utilisateur de la clé
      2. Supprimer tous les utilisateurs, groupes et services, à l' exception de l'utilisateur de la clé , sous Entrées d'autorisation
      3. Définir l'utilisateur de la clé sur Contrôle total


  • CLI:

    :: Set Variable ::
    set key="C:\Path\to\key"
    
    :: Remove Inheritance ::
    cmd /c icacls %key% /c /t /inheritance:d
    
    :: Set Ownership to Owner ::
    cmd /c icacls %key% /c /t /grant %username%:F
    
    :: Remove All Users, except for Owner ::
    cmd /c icacls %key%  /c /t /remove Administrator "Authenticated Users" BUILTIN\Administrators BUILTIN Everyone System Users
    
    :: Verify ::
    cmd /c icacls %key%
JW0914
la source
Et si le propriétaire est en réalité un groupe? Dans mon cas, network serviceCygwin pense que l'autorisation est 0770 au lieu de 0700.
hyspace
Un fichier doit appartenir à un utilisateur et à un groupe, pas seulement à un groupe. Les autorisations de groupe sont au troisième octal [l'utilisateur est le deuxième] dans une spécification à quatre octales et les clés SSH ne peuvent pas être un groupe ou d'autres accessibles
JW0914
C'est le cas d'Unix. Dans Windows, network servicepeut posséder un fichier et c'est un groupe
hyspace
Cygwin autorise les fonctionnalités de l'API POSIX sous Windows, mais il fonctionne toujours sous les règles des programmes UNIX natifs (d'où des autorisations 3 et 4 octales dans une configuration UGO). Bien que vous puissiez ouvrir un problème sur le GitHub de Microsoft Win32-OpenSSH, étant donné que les clés SSH doivent être des groupes et que d'autres sont inaccessibles , la possession de la propriété que vous décrivez n'est probablement pas prise en charge. Il est préférable de se conformer à la norme d'un programme plutôt que d'essayer de le configurer d'une manière [probablement] non prise en charge.
JW0914
1
cela devrait être une réponse correcte. Merci pour les options CLI. L'interface graphique est toujours nul dans le cas Windows.
shyammakwana.me
11

En plus de la réponse fournie par ibug. Depuis que j'utilisais le système Ubuntu dans Windows pour exécuter la commande ssh. Cela ne fonctionnait toujours pas. Donc j'ai fait

sudo ssh ...

et puis ça a marché

Parv Sharma
la source
sudone doit pas être utilisé pour ouvrir une session SSH car cela pose un risque pour la sécurité. Le seul moment (du moins que je sache) du compte root qui devrait être utilisé pour ouvrir une session SSH est sur des systèmes mono-utilisateur (normalement situés sur le système d'exploitation du routeur [OpenWrt, DD-WRT, etc.] et sur d'autres systèmes intégrés ) . Les clés SSH doivent être accessibles uniquement à l'utilisateur auquel elles sont destinées et à aucun autre compte, service ou groupe.
JW0914
@ JW0914 LOL J'ai un serveur Debian mono-utilisateur et le seul utilisateur (identifiant) est root. Je ne pense pas qu'un utilisateur non root supplémentaire soit bénéfique car c'est mon serveur personnel et je ne me connecte que lors de travaux de maintenance.
iBug
@ iBug S'il vous plaît relire mon commentaire, car il semble que vous avez entièrement manqué la deuxième phrase ...
JW0914
5

J'ai eu le même problème, et il semble être lié à la version de SSH que vous utilisez.

Si je tape

where ssh

Je reçois...

C:\Windows\System32\OpenSSH\ssh.exe
C:\Program Files\Git\usr\bin\ssh.exe

Quand je cours ssh -Vdans les deux endroits, je reçois

OpenSSH_7.5p1, without OpenSSL
OpenSSH_7.3p1, OpenSSL 1.0.2k  26 Jan 2017

...respectivement

Ainsi, lorsque je lance à sshpartir du répertoire git / bin, cela fonctionne bien et ne se plaint pas des autorisations, mais l'exécution de la même ligne de commande, en utilisant l'ancienne installation de SSH, revient avec ceci.

Load key "t:\\mykeys\\rich-private.ppk": invalid format
[email protected]: Permission denied (publickey).

ps. les autorisations sur le fichier ne sont qu'un accès complet pour moi, et rien d'autre.

Rich S
la source
OpenSSH ne doit pas être installé dans le répertoire Windows pour de nombreuses raisons, de la sécurité à un inconvénient majeur en cas de nécessité de réparer un répertoire Windows corrompu via DISMou à l'aide de l'option Reset (qui a été améliorée pour utiliser le répertoire WinSxS). par rapport à l'original install.esd) .
JW0914
C'est ce qui m'a aidé, je n'ai jamais eu la version Windows ssh pour fonctionner dans ce scénario, seulement Git :(
cudacoder
C'était aussi la solution pour moi. Il semble que Windows 10 Pro intègre désormais une version d’openssh pochée. J'ai été obligé de supprimer le dossier C: \ Windows \ System32 \ OpenSSH et d'ajouter le fichier ssh.exe de git à PATH.
Shukri Adams
Cela "corrige" cela pour moi, en utilisant C: \ Program Files \ Git \ usr \ bin \ ssh.exe fonctionne comme C: \ Windows \ System32 \ OpenSSH \ ssh.exe ne fonctionne pas
smartins
3

Vous avez besoin de deux choses:

1) Désactiver l'héritage entrez la description de l'image ici

2) Convertir les autorisations héritées en autorisations explicites entrez la description de l'image ici

3) Supprimer le groupe d'utilisateurs entrez la description de l'image ici

4) Vous vous retrouverez avec aucun utilisateur ne peut accéder aux fichiers privés, cela devrait suffire pour ajouter id_rsa. entrez la description de l'image ici

Artur Mustafin
la source
2

J'avais un problème similaire, mais j'étais au travail et je n'ai pas la possibilité de modifier les autorisations de fichiers sur mon ordinateur de travail. Ce que vous devez faire est d’installer WSL puis de copier votre clé dans le répertoire ssh caché dans WSL:

cp <path to your key> ~/.ssh/<name of your key>

Vous devriez maintenant pouvoir modifier les autorisations normalement.

sudo chmod 600 ~/.ssh/<your key's name>

Puis ssh en utilisant WSL:

ssh -i ~/.ssh/<name of your key> <username>@<ip address>

JKauffman
la source
2

utiliser la commande ci-dessous sur votre clé cela fonctionne sur les fenêtres

icacls .\private.key /inheritance:r
icacls .\private.key /grant:r "%username%":"(R)"
Walter Ferrao
la source
1

Vous pouvez utiliser icacls dans Windows au lieu de chmod pour ajuster l’autorisation du fichier. Pour donner à l'utilisateur actuel la permission de lire et supprimer tout le reste,

icacls <file name> /inheritance:r
icacls <file name> /grant:r "%username%":"(R)"
manjuv
la source
1

Ceci est juste une version scriptée de la réponse CLI de @ JW0914, alors invitez-le en priorité. En outre, il s’agit de mon premier script PowerShell. Les suggestions sont donc les bienvenues.

# DO the following in powerhsell if not already done:
# Set-ExecutionPolicy RemoteSigned


# NOTE: edit the path in this command if needed
$sshFiles=Get-ChildItem -Path C:\DevContainerHome\.ssh -Force

$sshFiles | % {
  $key = $_
  & icacls $key /c /t /inheritance:d
  & icacls $key /c /t /grant %username%:F
  & icacls $key  /c /t /remove Administrator "Authenticated Users" BUILTIN\Administrators BUILTIN Everyone System Users
}

# Verify:
$sshFiles | % {
  icacls $_
}
barker
la source
1

Une seule ligne dans CMD pourrait faire l'affaire (comme décrit ici: https://serverfault.com/a/883338/550334 ), c'est-à-dire en ajoutant la clé de stdin au lieu de changer les permissons:

cat /path/to/permission_file | ssh-add -k 

Pour vérifier si la clé a été ajoutée:

ssh-add -l
majom
la source
0

Je suis un utilisateur de Windows, j'utilise Windows bash et ai suivi toutes les étapes pour définir les autorisations à l'aide de l'interface graphique Windows. Cela ne fonctionne toujours pas et se plaint:

Permissions 0555 for 'my_ssh.pem' are too open.
It is required that your private key files are NOT accessible by others.

Le j'ai ajouté sudoà l'avant de la commande ssh et cela fonctionne. J'espère que cela sera utile aux autres.

Alex Ramses
la source
Mais vous connectez-vous au serveur en tant que vous-même ou en tant que root?
G-Man dit 'Réintégrez Monica'
J'exécute le terminal Window bash comme moi-même, mais j'ai lancé «Exécuter en tant qu'administrateur» lorsque j'ai lancé Bash.
Alex Ramses
-1

Answer by iBug fonctionne bien! Vous pouvez suivre cela et vous débarrasser de ce problème.

Mais il n’ya que peu de choses à régler, car j’ai rencontré des problèmes lors de l’établissement des autorisations et il m’a fallu quelques minutes pour comprendre le problème!

Après la réponse d'iBug, vous supprimerez toutes les autorisations, mais comment définissez-vous l'autorisation Contrôle total pour vous-même? c'est là que je me suis retrouvé coincé au début, car je ne savais pas comment faire cela.

Après avoir désactivé l'héritage, vous pourrez supprimer tous les utilisateurs ou groupes autorisés.

Une fois fait avec ça,

Cliquez sur Addpuis cliquez sur Set a Principalpuis entrez Systemet Administratorset your email addredddans le champ en bas puis cliquez sur check names.

Il va charger le nom si l'utilisateur existe. Ensuite, cliquez sur OK> Type Allow> Permisisons de base Full Control>Okay

Cela configurera l’autorisation Contrôle total sur le système, les administrateurs et votre utilisateur.

Après cela, essayez de ssh en utilisant cette clé. Il devrait être résolu maintenant.

J'ai eu le même problème et j'ai résolu cela en utilisant cette méthode. S'il existe un utilisateur ou un groupe portant ce nom, il sera chargé.

-Captures d'écran-

Entrées d'autorisation Sélectionnez un principal / sélectionnez un utilisateur ou des groupes

lazycipher
la source