web-dev-qa-db-fra.com

Comment afficher toutes les clés_autorisées SSH pour un serveur Unix

Comment afficher tous les clients SSH autorisés à partir d'un serveur Unix?

Je le sais cat ~/.ssh/authorized_keys affiche les clés autorisées si vous êtes connecté depuis root. D'autres utilisateurs peuvent-ils également définir leurs propres clés autorisées? Dans ce cas, comment afficher toutes les clés autorisées par le système?

authenticationlinuxsshunix
15
user2761030

Pour répondre à vos questions dans l'ordre:

  1. Vous pouvez voir toutes les clés autorisées en exécutant le script suivant avec les privilèges root.

    #!/bin/bash
for X in $(cut -f6 -d ':' /etc/passwd |sort |uniq); do
    if [ -s "${X}/.ssh/authorized_keys" ]; then
        echo "### ${X}: "
        cat "${X}/.ssh/authorized_keys"
        echo ""
    fi
done

  2. Tout utilisateur valide peut créer un $HOME/.ssh/authorized_keys fichier et ajoutez-y un nombre illimité de clés publiques. Quelqu'un avec la clé privée correspondante pourra alors se connecter en tant qu'utilisateur particulier. Le processus que sshd suit est le suivant. Lorsqu'une nouvelle connexion arrive, sshd demande au client le nom d'utilisateur. Si le nom d'utilisateur existe dans /etc/passwd, sshd lit ensuite le nom du répertoire personnel de l'utilisateur dans le sixième champ de /etc/passwd. Il vérifie ensuite si .ssh/authorized_keys existe dans le répertoire de base de cet utilisateur et si les autorisations sont correctement définies à la fois dans le répertoire .ssh et dans le fichier authorized_keys. Si ces conditions sont remplies, sshd tentera alors d'authentifier la clé privée du client par rapport à la clé publique stockée dans $HOME/.ssh/authorized_keys. Si le client possède la clé privée correspondante, sshd lui permettra d'accéder.

  3. Vous pouvez utiliser le script ci-dessus.

S.L. Barth fait un excellent point sur l'accès root. Il est considéré comme un risque d'autoriser l'accès root via ssh. La pratique généralement acceptée consiste à créer un compte utilisateur, à lui accorder un accès root avec Sudo ou un outil similaire et à désactiver les connexions root via ssh en ajoutant la ligne suivante à /etc/ssh/sshd_config et redémarrer sshd.

PermitRootLogin no

Les chances sont de près de 100% que si votre machine est sur Internet, le "Hail Mary Cloud" frappera à votre porte. Pour Linux, iptables et sshd où vous autorisez les connexions par mot de passe, vous voudrez probablement installer et configurer quelque chose comme fail2ban il est donc plus difficile pour les attaquants de forcer brutalement votre machine.

Et, puisque nous parlons déjà de clés ssh, et parce que cela a été publié aujourd'hui, vous voulez probablement ajouter UseRoaming no à la Host * section dans votre /etc/ssh/ssh_config

11
Liczyrzepa

La commande cat ~/.ssh/authorized_keys Vous montre le fichier authorized_keys de l'utilisateur actuellement connecté. Une fois connecté en tant que root, ou en utilisant Sudo, cela vous donnera le fichier authorized_keys de l'utilisateur root.

Le fichier authorized_keys, au moins sur Ubuntu, appartient généralement à l'utilisateur. Ainsi, l'utilisateur actuellement connecté (root ou non) peut le voir.
Le répertoire .ssh se trouve dans le répertoire personnel de l'utilisateur et lui appartient généralement avec des privilèges de lecture, d'écriture et d'exécution; donc normalement un utilisateur devrait pouvoir ajouter son propre fichier authorized_keys.

Pour voir toutes les clés autorisées, vous pouvez simplement créer un script qui itère sur tous les répertoires personnels et/root et imprime le fichier .ssh/authorized_keys. Évidemment, ce script nécessitera des privilèges Sudo.

En remarque, sur Ubuntu, le compte root est généralement désactivé, car il s'agit d'une cible préférée des attaquants. Il peut ne pas contenir de fichier authorized_keys pour cette raison.

4
S.L. Barth - Reinstate Monica

OMI, c'est une bonne idée de vérifier également le ~/.ssh/authorized_keys2 fichier. De https://marc.info/?l=openssh-unix-dev&m=100508718416162&w=2 :

Pour des raisons de compatibilité descendante, ~/.ssh/authorized_keys2 sera toujours utilisé pour l'authentification et les clés d'hôte sont toujours lues à partir des known_hosts2.

Code amélioré de Liczyrzepa:

#!/bin/bash
for X in $(cut -f6 -d ':' /etc/passwd |sort |uniq); do
  for suffix in "" "2"; do
    if [ -s "${X}/.ssh/authorized_keys$suffix" ]; then
      echo "### ${X}: "
      cat "${X}/.ssh/authorized_keys$suffix"
      echo ""
     fi;
   done;
done
1
coffeemakr