1 votes

Y a-t-il une raison pour que sshd_config ne puisse pas être défini sur un fichier authorized_keys qui n'est pas dans home ?

Dépannage de SSH et NX J'ai une connexion SSH qui fonctionne en utilisant une clé RSA. Le problème est que le serveur NX veut le paramètre sshd_config AuthorizedKeysFile à définir sur un fichier installé dans NX, /var/lib/nxserver/home/.ssh/authorized_keys2 . Une fois que j'ai fait ce changement, la connexion distante SSH ne pouvait pas être autorisée. J'ai essayé,

  • en ajoutant la maison authorized_keys dans ~/.ssh dans ce fichier /var....
  • Il appartient à nx groupe root et des autorisations 644, j'ai donc ajouté les paramètres suivants AllowUsers y AllowGroups avec les deux comptes jusqu'à la fin de sshd_config .
  • Redémarrage du serveur SSHD après chaque changement de sshd.

Malheureusement, ssh ne permet pas cette connexion.

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Si je change sshd_config AuthorizedKeysFile pour revenir aux paramètres d'origine et tout va bien. Donc, y a-t-il une raison pour que sshd n'accepte pas le fichier clé autorisé que NX veut ?


Il y a des questions confuses ici. Prenez par exemple authorized_keys2 était déprécié ? Pas ça. ces gars-là se souciaient parce qu'ils parlent de l'utilisation de authorized_keys2 pour NX deux ans après le premier post.

De nombreux utilisateurs de NX notent que le fichier AuthorizedKeysFile n'est que le nom du fichier, pourtant cette page de manuel sur sshd_config (le même que CentOS6) et dit "Après l'expansion de [token], AuthorizedKeysFile est considéré comme un chemin absolu ou relatif au répertoire personnel de l'utilisateur". Le chemin NX devrait être correct, non ?

Malheureusement, mon serveur CentOS est équipé d'OpenSSH 5.3, car la version 6.2 (sur mon client) prend en charge l'accès à l'Internet. liste délimitée par l'espace de fichier(s) clé(s) autorisé(s).

2voto

BigEd Points 41

Tout d'abord, dans de telles conditions, j'essaye toujours d'avoir mes logs au maximum en commençant par des logs personnalisés non démonétisés. sshd :

sshd -d -p 11122 -f /new/config/file

Et j'essaie de m'y connecter :

ssh -v -p 11122 this.host

Cela sécurise votre configuration actuelle et vous donne toutes les informations sur la façon dont la connexion a été établie.

Et maintenant vient une supposition sauvage. sshd exigera que les fichiers de clés soient :

  1. Accessible et lisible par le serveur.
  2. Ne peut être écrit que par l'utilisateur. Et cela signifie tous les dossiers (/var, /var/lib, etc.). ne doit pas être accessible en écriture par tout utilisateur ou groupe autre que root , wheel et l'utilisateur qui se connecte.

2voto

Hideo Points 249

C'est une question F'd, parce que après avoir utilisé l'astuce de Kworr pour tester sshd en arrêtant le service démon et en le démarrant manuellement en mode débogage, le chemin non domestique fonctionne tout simplement (ce qui est ce que l'on attend après "token expansion") Désolé les gars.

Ainsi, pour répondre à ma propre question : Non, il n'y a aucune raison pour que authorized_keys ne puisse pas être en dehors de la maison.

1voto

Amyunimus Points 163

La valeur par défaut est d'utiliser un fichier dans le répertoire personnel de l'utilisateur (voir ci-dessous). Le %h peut être utilisé explicitement pour le montrer. Ici, il montre une liste de chaque chemin séparé par un espace...

Ce que j'essaierais de faire, c'est de changer les permissions à 600. C'est la valeur de mon fichier autorized_keys pour tous mes comptes. Les mauvaises permissions se traduisent par une erreur "Permissions refusées". Cela vous donne une chance de vérifier que votre fichier authorized_keys ne comporte pas d'ajouts indésirables avant de fixer ses permissions.

Si différents utilisateurs sont censés utiliser les mêmes authorized_keys, alors vous avez un problème...

AuthorizedKeysFile
         Specifies the file that contains the public keys that can be used for user authentication.  The format is described in the AUTHORIZED_KEYS FILE
         FORMAT section of sshd(8).  AuthorizedKeysFile may contain tokens of the form %T which are substituted during connection setup.  The following
         tokens are defined: %% is replaced by a literal '%', %h is replaced by the home directory of the user being authenticated, and %u is replaced by
         the username of that user.  After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory.
         Multiple files may be listed, separated by whitespace.  The default is “.ssh/authorized_keys .ssh/authorized_keys2”.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X