Comment faire fonctionner les clés partagées .ssh / authorized_keys et sudo?

J'ai installé le .ssh / authorized_keys et je peux me connecter avec le nouvel "utilisateur" en utilisant la clé pub / privée ... J'ai également ajouté "user" à la liste des sudoers ... le problème que j'ai maintenant c'est quand J'essaie d'exécuter une commande sudo, quelque chose de simple comme:

$ sudo cd /root

il me demandera mon mot de passe, que j'entre, mais cela ne fonctionne pas (j'utilise le mot de passe de clé privée que j'ai défini)

De plus, j'ai désactivé le mot de passe de l'utilisateur à l'aide de

$ passwd -l user

Qu'est-ce que je rate?

Quelque part mes premières remarques sont mal comprises ...

J'essaie de durcir mon système ... le but ultime est d'utiliser des clés pub / privées pour effectuer des connexions par opposition à une simple authentification par mot de passe. J'ai compris comment configurer tout cela via le fichier authorized_keys.

De plus, je vais finalement empêcher les connexions au serveur via le compte root. Mais avant de faire cela, j'ai besoin de sudo pour travailler pour un deuxième utilisateur (l'utilisateur avec lequel je serai connecté au système avec tout le temps).

Pour ce deuxième utilisateur, je veux empêcher les connexions par mot de passe régulières et ne forcer que les connexions pub / clé privée, si je ne verrouille pas l'utilisateur via "passwd -l user ... alors si je n'utilise pas de clé, je peux toujours entrer dans le serveur avec un mot de passe normal.

Mais plus important encore, je dois faire fonctionner sudo avec une configuration pub / clé privée avec un utilisateur dont le mot de passe a été désactivé.

Edit: OK, je pense que je l'ai (la solution):

1) J'ai ajusté / etc / ssh / sshd_config et défini PasswordAuthentication no Cela empêchera les connexions de mot de passe ssh (assurez-vous d'avoir une configuration de clé publique / privée fonctionnelle avant de faire cela

2) J'ai ajusté la liste des sudoers visudoet ajouté

root      ALL=(ALL) ALL
dimas     ALL=(ALL) NOPASSWD: ALL

3) root est le seul compte utilisateur qui aura un mot de passe, je teste avec deux comptes utilisateur "dimas" et "sherry" qui n'ont pas de mot de passe (les mots de passe sont vides, passwd -d user)

Ce qui précède empêche essentiellement tout le monde de se connecter au système avec des mots de passe (une clé publique / privée doit être configurée).

De plus, les utilisateurs de la liste sudoers ont des capacités d'administrateur. Ils peuvent également suaccéder à différents comptes. Donc, fondamentalement, "dimas" peut sudo su sherry, cependant "dimas ne peut PAS faire su sherry. De même, tout utilisateur NON dans la liste sudoers ne peut PAS faire su userou sudo su user.

REMARQUE Ce qui précède fonctionne mais est considéré comme une mauvaise sécurité. Tout script capable d'accéder au code en tant qu'utilisateur "dimas" ou "sherry" pourra exécuter sudo pour obtenir un accès root. Un bogue dans ssh qui permet aux utilisateurs distants de se connecter malgré les paramètres, une exécution de code à distance dans quelque chose comme Firefox, ou toute autre faille qui permet à du code indésirable de s'exécuter car l'utilisateur pourra désormais s'exécuter en tant que root. Sudo devrait toujours exiger un mot de passe ou vous pouvez aussi vous connecter en tant que root au lieu d'un autre utilisateur.

sshet sudon'ont rien à voir les uns avec les autres. La mise en place d'une sshméthode d'authentification ne fera rien pour sudo. sudone va pas comprendre un sshmot de passe.

passwd -lest destiné à verrouiller le compte d'un utilisateur, afin qu'il ne puisse plus s'authentifier par mot de passe. C'est à peu près le contraire de ce que vous voulez, ce qui permet à l'utilisateur de s'authentifier sans mot de passe.

Je pense que ce que vous voulez, c'est l' NOPASSWDoption dans votre sudoersdossier .

(PS, il n'y a aucune raison d'exécuter une cdcommande avec sudo. cdNe se propage pas aux processus parents, donc dès que sudovous quittez, vous êtes de retour là où vous avez commencé.)

Edit: Vous continuez à dire que vous souhaitez verrouiller le mot de passe du compte et que sudo comprend les clés publiques / privées. Désolé, sudo n'utilisera pas les clés ssh. Ce n'est pas ssh. Si vous ne voulez pas que les utilisateurs puissent se connecter avec leurs mots de passe, je pense que la réponse est de désactiver l'authentification par mot de passe ssh , pas de verrouiller le compte. Ensuite, vous pouvez conserver un mot de passe pour les utilisateurs, qu'ils peuvent utiliser pour sudo après leur connexion via ssh authorized_keys.

Ce que vous voulez faire est possible mais cela demandera de l'expérience car vous devrez compiler un module PAM appelé pam-ssh-agent-auth .

Le processus est assez simple:

$ sudo aptitude install libssl-dev libpam0g-dev build-essential checkinstall
$ wget "http://downloads.sourceforge.net/project/pamsshagentauth/pam_ssh_agent_auth/v0.9.3/pam_ssh_agent_auth-0.9.3.tar.bz2"
$ tar -xjvf pam_ssh_agent_auth-0.9.3.tar.bz2
$ cd pam_ssh_agent_auth-0.9.3

$ ./configure --libexecdir=/lib/security --with-mantype=man

$ make
$ sudo checkinstall

L'édition de la configuration sudo:

$ sudo visudo

Ajoutez ce qui suit:

Defaults env_keep += SSH_AUTH_SOCK

Continuez en modifiant les paramètres sudo PAM:

$ sudo vi /etc/pam.d/sudo

Ajoutez (juste au-dessus des lignes @include):

**auth [success=2 default=ignore] pam_ssh_agent_auth.so file=~/.ssh/authorized_keys**
@include common-auth
@include common-account

La réponse d'André de Miranda fournit une bonne solution en utilisant pam_ssh_agent_auth , mais les pièces sont obsolètes. En particulier les /etc/pam.d/sudoinstructions lors de l'utilisation de nombreuses versions Linux actuelles.

Si vous exécutez Ubuntu 12.04 précis, j'ai en fait simplifié le processus en fournissant une construction pam_ssh_agent_auth à partir d'un ppa: ppa: cpick / pam-ssh-agent-auth .

Vous pouvez installer le package en exécutant:

sudo add-apt-repository ppa:cpick/pam-ssh-agent-auth
sudo apt-get install pam-ssh-agent-auth

Après l'installation, si vous souhaitez utiliser ce module PAM avec sudo, vous devrez configurer les paramètres de sudo et la configuration PAM, dans Ubuntu 12.04 précis, vous pouvez le faire en créant les deux fichiers suivants:

/etc/sudoers.d/pam-ssh-agent-auth:

Defaults    env_keep+="SSH_AUTH_SOCK"

/etc/pam.d/sudo:

ent#%PAM-1.0

auth       required   pam_env.so readenv=1 user_readenv=0
auth       required   pam_env.so readenv=1 envfile=/etc/default/locale user_readenv=0
auth       sufficient pam_ssh_agent_auth.so file=/etc/security/authorized_keys
@include common-auth
@include common-account
@include common-session-noninteractive

Si vous utilisez chef, le processus ci-dessus peut être automatisé avec mon livre de cuisine, disponible à l'un des deux emplacements suivants:
https://github.com/cpick/pam-ssh-agent-auth
http: //community.opscode .com / livres de cuisine / pam-ssh-agent-auth .

Le filesrépertoire du livre de recettes contient les fichiers /etc/pam.d/sudoet /etc/sudoers.d/pam-ssh-agent-authdécrits ci-dessus qui fonctionnent avec Ubuntu 12.04 précis et devraient être un point de départ utile lors de l'utilisation d'autres versions / distributions.

Le seul moyen que je connaisse pour contourner la saisie d'un mot de passe est de le désactiver dans votre sudoersfichier.

Quelque chose comme ça donnera rootet tous les membres d' wheel un accès complet sans mot de passe:

root    ALL=(ALL)   NOPASSWD: ALL
%wheel  ALL=(ALL)   NOPASSWD: ALL

Ce n'est absolument pas conseillé , cependant. Si vous avez une commande spécifique à exécuter pour ce serveur, donnez-leur uniquement accès à cette commande. Ou mieux encore, trouvez une manière différente d'accomplir ce que vous voulez faire qui ne nécessite pas de percer un trou de sécurité.