Salut à tous,
J’ai un serveur dont la config de SSH fait qu’il est impossible de se connecter avec l’identité root.(PermitRootLogin no).
J’ai l’habitude d’utiliser WinSCP ou SCP pour les opérations d’admin.
Est-il possible avec ces outils de se connecter avec une identité précise, et de monter ensuite vers une l’identité root pour modifier les fichiers stockés dans les répertoires protégés (comme /etc,…).
Merci
Le plus simple c’est d’ajouter ton utilisateur avec lequel tu utilises scp au groupe root. Mais c’est absolument pas recommandé pour des raisons évidentes de sécurité, donc je détaillerais pas, car je suis sûr que certains ont mieux à proposer.
Question un peu curieuse : pourquoi tu prends pas putty et effectues les taches administratives directement sur la machine 
?
Ben oui, justement avec Putty, tu peux faire un “su root” une fois connecté en user, même avec “PermitRootLogin=no”
En fait, je fais régulièrement des fix sur les fichiers de configuration des serveurs pour corriger tel ou tel problème.
Je valide donc le nouveau fichier de conf sur un serveur de test, et une fois le problème fixé, je recopie le fichier de conf sur le serveur de prod.
Normalement, un coup de scp ou WinSCP et c’est fini.
Mais avec ce serveur qui refuse le root login, ca me complique le travail: je copie le fichier une première fois dans le home folder d’un utilisateur.
Puis je me connecte en SSH pour recopier le fichier dans le répertoire /etc, vérifier comment les droits sont positionnés et enfin je l’efface du home folder initial.
Il y a beaucoup plus de manip qu’avant, et donc beaucoup plus de risques de se tromper 
J’aimerais (dans l’idéal) que mon client scp, en lui fournissant les deux login et les deux passwords, parviennent à copier le fichier de conf dans le répertoire “protégé” /etc.
C’est possible d’après vous ?
Je viens de trouver une info sur WinSCP: winscp.net/eng/docs/faq_su
Ok, j’ai trouvé une réponse intéressante sur le net.
Si PermitRootLogin est positonné à No, il est impossible de faire un transfert de fichiers directement dans un répertoire protégé (il faut scripter le transfert).
Par contre à positionnant PermitRootLogin à without-password, bien qu’on authorise la connexion en root, on se limite à une authentification par clef publique (bien plus sécurisée que par mot de passe).
Il me reste donc à convaincre mon ami à changer sa politique de connexion à distance !
[quote]PermitRootLogin
Spécifie si root peut se connecter par ssh(1). L’argument est « yes », « without-password », « forced-commands-only » ou « no ». Par défaut « yes ».
Si cette option est réglée à « without-password », l'authentification par mot de passe est désactivée pour root.[/quote]