Comment autoriser ssh à rooter l'utilisateur uniquement à partir du réseau local?

J'ai installé Google-Authenticator sur une machine CentOS 6.5 et configuré certains utilisateurs pour fournir le protocole OTP.

Lors de l'édition, /etc/ssh/sshd_configj'ai vu une directive " PermitRootLogin" qui est commentée par défaut.

Je voudrais mettre " PermitRootLogin no" mais pouvoir toujours ssh sur la machine en tant que root uniquement à partir du réseau local.

Est-ce possible?

linux ssh centos6

— Itai Ganot
source

Ne fais jamais ça. SSH dans vos utilisateurs, puis utilisez sudo pour élever les autorisations. Faites-le de manière à laisser une trace écrite et vous saurez ainsi quel compte a été compromis.

— SnakeDoc

@ SnakeDoc: C'est une école de pensée, mais ce n'est pas clair et je dirais le contraire. sudo est une énorme surface d’attaque complexe et n’est pas quelque chose que je souhaiterais avoir installé. L'authentification de la clé de publication SSH est une surface d'attaque beaucoup plus petite. L'un ou l'autre peut être connecté, mais la journalisation n'est pas très utile lorsque l'utilisateur (root) peut modifier ou supprimer des journaux, ce qui est toujours le cas, sauf si vous vous connectez à un stockage externe avec ajout uniquement.

— R ..

@R .. Si vous configurez correctement les sudoers, en utilisant le principe de moindre privilège, les problèmes que vous avez décrits ne le sont généralement pas. Aucun utilisateur ne devrait être capable de ssh dans et sudo - sudans la racine, ou faire tout ce dont ses utilisateurs n'ont pas besoin (dans sudoers, vous utilisez la liste blanche pour les commandes). Si vous avez besoin de root, vous devez être physiquement sur la console - c'est-à-dire. La racine sur SSH ne devrait jamais être autorisée… clés ou non.

— SnakeDoc

@ SnakeDoc: Vous vous trompez. Sudo possède à la fois ses propres surfaces d’attaque complexes et une surface d’attaque complexe fondamentale inhérente au binaire suid, sous la forme de tout l’état hérité par l’exécution. Dans certains cas, un bogue dans le programme suid lui-même (suid) n’est même pas nécessaire; des bogues dans l'infrastructure sous-jacente tels que l'éditeur de liens dynamique (par exemple, CVE-2010-3856) peuvent être suffisants.

— R ..

@R .. Vous supposez que vous saurez toujours si une clé a été divulguée. C'est une sacrée hypothèse. De plus, une fois dedans, votre attaquant a les privilèges root. Il est toujours préférable de les envoyer via un compte non privilégié et de les obliger à s’élever pour devenir root. De cette façon, vous avez une clé qui doit être divulguée, une phrase secrète de clé à déchiffrer, puis un mot de passe de compte d'utilisateur normal à décomposer. Et si l'attaquant parvient à traverser tout cela ... il ne peut rien faire car cet utilisateur est configuré sous sudoers avec une capacité très limitée ... Vous voyez le bénéfice maintenant? Ne pas autoriser la connexion directe à la racine sur ssh ... période. C'est une bonne hygiène

— SnakeDoc

Réponses:

Utilisez le Matchparamètre config dans /etc/ssh/sshd_config:

# general config
PermitRootLogin no 

# the following overrides the general config when conditions are met. 
Match Address  192.168.0.*
    PermitRootLogin yes

Voir man sshd_config

— Sven
source

Pourquoi n'y ai-je pas pensé? Merci compagnon

— Itai Ganot

Vous pouvez également limiter la source des clés d'authentification dans ~root/.ssh/authorized_keys. Préfixez la clé avec from="192.168.0.0/24 ".

— BillThor

Je le changerais pour autoriser également les adresses IPv6 de lien local. La manière dont les adresses lien-locales fonctionnent dans IPv6 les rend très robustes pour les réseaux mal configurés. Ce qui signifie que si vous avez besoin de ssh pour corriger une mauvaise configuration du réseau, il est possible d'utiliser une adresse IPv6 link-local.

— Kasperd

FYI Si vous utilisez également la directive AllowUser , vous devez également (et contre-intuitivement) égalementAllowUser root

— Robert Riedl

La Match addressméthode a déjà été mentionnée, mais vous pouvez également limiter les utilisateurs (ou groupes) autorisés à se connecter à un système. Par exemple, pour limiter les connexions à l'utilisateur itai(de n'importe où) et root(d'un réseau spécifique), utilisez:

AllowUsers itai root@192.168.0.*

Cela empêche tous les autres utilisateurs (comme apache) de se connecter via SSH.

Voir aussi le AllowUsersmot - clé dans le manuel sshd_config (5) .

— Lekensteyn
source

Je préfère AllowGroupset ajoute tous les utilisateurs qui devraient pouvoir se connecter en utilisant SSH à un groupe spécifique. Je suppose que c'est une question de goût, mais cela semble être moins l'édition de sshd_config (ce qui signifie moins de risque de gâcher et de mettre tout le monde en sécurité).

— un CVn

@ MichaelKjörling De plus, AllowGroups signifie que vous n'avez pas besoin d'autorisations de modification pour sshd_config si votre équipe se développe ou se réduit. Cela pourrait même permettre à davantage de types de direction ou de stagiaires de le faire.

— Nzall

Bons points, notez que vous pouvez combiner les options, avoir AllowUsers itai root@192.168.0.*et AllowGroups ssh-userset vous ne provoquerez pas accidentellement un lock-out au cas où le stagiaire

— effacerait