web-dev-qa-db-fra.com

Comment utiliser SFTP sur un système qui nécessite Sudo pour l'accès root et l'authentification basée sur la clé ssh?

Je veux pouvoir utiliser SFTP pour modifier des fichiers qui nécessitent des autorisations root.

J'utilise l'authentification basée sur la clé SSH - clé rsa sur la carte à puce.

Si le système nécessite Sudo pour exécuter des commandes de niveau racine, comment puis-je contourner ce problème?

Puis-je créer un moyen de contourner Sudo pour SFTP uniquement?

Existe-t-il un moyen de conserver l'authentification Sudo et la clé.

J'utilise Windows pour me connecter à Ubuntu. J'ai besoin de cela pour que Mac fonctionne également avec Ubuntu.

Je comprends comment faire le tunneling SSH pour administrer les services système. Actuellement, j'utilise directement la connexion de l'utilisateur root, mais la connexion par mot de passe est désactivée. Je n'ai pas compris comment utiliser Sudo et SFTP en même temps. Il semble être une meilleure pratique d'exiger une connexion en tant qu'utilisateur non root, puis d'exiger l'utilisation de Sudo, car les journaux enregistreront à qui ont été accordés des privilèges élevés pour chaque commande.

Dois-je m'en préoccuper lorsque j'utilise l'authentification par clé ou s'agit-il d'une différence triviale en matière de sécurité/journalisation? Il semble que l'authentification basée sur les clés enregistre le numéro de série de l'utilisateur dans les journaux, et vous pouvez avoir plusieurs clés pour que l'utilisateur root identifie chaque utilisateur. Cela semble être le même effet que d'utiliser Sudo pour moi. Ai-je tort?

sshsftp
28
Bruce Kirkpatrick

SFTP est une commande d'accès aux opérations sur les fichiers, avec les restrictions du compte que vous utilisez. Vous devez utiliser ssh pour effectuer plus d'opérations administratives, rendant impossible l'utilisation de Sudo et SFTP en même temps. Si vous avez besoin d'accéder à l'intégralité du disque sans restriction à l'aide de SFTP, faites-le à l'aide du compte root. Quoi qu'il en soit, vous pouvez faire une connexion avec root sur sftp et ssh en même temps, bien sûr, en utilisant deux sessions différentes.

Les clés de sécurité améliorent la sécurité et facilitent la journalisation, ne nécessitant pas de saisie au clavier. Aide uniquement à se connecter, vous pouvez avoir plusieurs mots de passe pour chaque utilisateur du compte et avoir le même effet.

EDIT: J'ai oublié: vous pouvez créer un autre compte avec le même effet que root si vous attribuez l'ID utilisateur à 0, mais n'a aucun sens, étant dangereux de la même manière. Pourrait donner un peu d'obscurcissement si quelqu'un essaie de se connecter comme root, mais à part cela, cela n'avait pas beaucoup de sens.

7
gabrign

L'appel du sous-système avec Sudo a fonctionné pour moi.

À un hôte Ubuntu par exemple:

sftp -s "Sudo /usr/lib/openssh/sftp-server" targethost.fqdn
14
kiwi

Au-delà de ce que @ MartinVonWittich a suggéré dans les commentaires ci-dessus vous pouvez configurer une paire de clés SSH dédiée juste pour cette activité et les ajouter à la racine de l'utilisateur /root/.ssh/authorized_keys fichier limitant leur portée à une seule commande.

# User backup's $HOME/.ssh/authorized_keys file
command="/usr/libexec/openssh/sftp-server" ssh-dss AAAAC8ghi9ldw== backup@Host

Cela permettrait à un autre système avec la clé correspondante à cette paire de SFTP dans ce système en tant que root. Vous auriez toujours un enregistrement de cette connexion dans vos syslog et/ou secure.log fichiers (en supposant que votre distribution fournit ce niveau de journalisation).

REMARQUE: Quiconque accède au serveur dans cette méthode aurait un accès cartes blanches, alors utilisez-le judicieusement. Mieux encore, continuez à lire et combinez cette capacité avec un accès en chroot et en lecture seule, pour créer des restrictions plus strictes et un accès ciblé à des emplacements spécifiques en tant que root.

chroot & readonly

L'autre technique que vous pourriez exploiter ici serait de limiter la connexion SFTP afin qu'elle soit chrootée dans des emplacements spécifiques en tant que root, en fonction de la clé SSH utilisée. Voir ma réponse à cette Q&R U&L intitulée: " Restreindre la sauvegarde sans mot de passe avec SFTP " pour plus de détails.

Vous pouvez également contrôler sftp-server par ses commutateurs -R et -d.

 -d start_directory
         specifies an alternate starting directory for users.  The pathname 
         may contain the following tokens that are expanded at runtime: %%
         is replaced by a literal '%', %h is replaced by the home directory
         of the user being authenticated, and %u is replaced by the user‐
         name of that user.  The default is to use the user's home 
         directory.  This option is useful in conjunction with the 
         sshd_config(5) ChrootDirectory option.

 -R      Places this instance of sftp-server into a read-only mode.  
         Attempts to open files for writing, as well as other operations 
         that change the state of the filesystem, will be denied.
7
slm

L'approche simple que j'ai suivie consistait à simplement sftp et à placer les fichiers sur une zone de scène (mkdir nouveau répertoire où vous avez des autorisations sur le serveur), puis à nouveau ssh pour déplacer les fichiers de là vers la destination avec Sudo cp ou Sudo mv.

4
Akshay Rathod

Ce que je fais, c'est utiliser scp au lieu de (s) ftp, et changer le Shell en Sudo su - dans WinSCP c'est dans Advanced\SCP\Shell, mais cela seulement fonctionne avec le protocole scp.

1
SilentVoid

Réponse spécifique à WinSCP et Amazon EC2 Ubuntu:

Pour une AMI de serveur AWS EC2 Ubuntu 18.04 de novembre 2019, l'utilisateur ubuntu par défaut est déjà configuré pour Sudo sans mot de passe. Vérifier /etc/sudoers.d/90-cloud-init-users, qui contient (dans mon cas):

# Created by cloud-init v. 19.2-36-g059d049c-0ubuntu1~18.04.1 on Wed, 27 Nov 2019 09:23:42 +0000
# User rules for ubuntu
ubuntu ALL=(ALL) NOPASSWD:ALL

Pour WinSCP, modifiez les paramètres de site avancés en:

Sudo /usr/lib/openssh/sftp-server

(devrait être l'une des options de liste déroulante suggérées, à mon avis)

enter image description here

1
Reto Höhener

J'ai eu un problème similaire en ce sens que je voulais utiliser vimdiff pour éditer des fichiers de configuration sur un groupe d'hôtes principalement similaires, avec cssh et Sudo et vous pourrez peut-être adapter ma solution à votre flux de travail.

sudoedit (qui fait partie de Sudo) vous permet d'utiliser n'importe quel éditeur en tant qu'utilisateur normal pour éditer un fichier pour lequel vous n'avez pas l'autorisation d'écriture et vous pouvez spécifier l'éditeur avec une variable d'environnement. sudoedit copie le (s) fichier (s), appelle l'éditeur avec le nom de la ou des copie (s) et attend la fermeture de l'éditeur, puis copie la copie modifiée à son emplacement d'origine. j'ai donc créé un "éditeur" qui ne modifie pas, note simplement le fichier pour une utilisation ultérieure et attend et un wrapper autour de vimdiff qui utilise ce marqueur.

le premier fichier est ~/.bin/redit

#!/usr/bin/Perl -w
use strict;
use warnings;
use Sys::Hostname;
my $file = $ENV{HOME}.'/.var/redit/'.hostname();
sub cmkdir($){
    my $_=shift;
    mkdir $_ unless -d $_;
}
cmkdir $ENV{HOME}.'/.var/';
cmkdir $ENV{HOME}.'/.var/redit/';
foreach (@ARGV){
    my $fh;
    open $fh, '>', $file.'na' or warn;
    print {$fh} $_;
    close $fh;
    symlink $_, $file or die;
    print;
    <STDIN>;
    unlink $file or die;
    unlink $file.'na' or die;
}

le second est ~/.bin/redit1

#!/usr/bin/Perl -w
use strict;
use warnings;
use Sys::Hostname;
my $h=hostname();
@ARGV=qw(Host1 Host2 Host3 Host4) unless @ARGV;
print join " ", qw(gvimdiff), $ENV{HOME}.'/.var/redit/'.$h, map {'scp://'.$_.'/.var/redit/'.$_} grep {$_ ne $h} @ARGV;
exec qw(gvimdiff), $ENV{HOME}.'/.var/redit/'.$h, map {'scp://'.$_.'/.var/redit/'.$_} grep {$_ ne $h} @ARGV;

La façon dont je les utilise est d'utiliser cssh pour ouvrir une connexion aux quatre hôtes, puis utiliser une commande comme EDITOR=~/.bin/redit sudoedit /etc/conf/file puis dans une autre fenêtre, exécutez ~/.bin/redit1, effectuez mes modifications, enregistrez et quittez, revenez à cssh et appuyez sur entrée pour valider les modifications et quitter sudoedit (sauf si je modifie plusieurs fichiers, auquel cas redit passe au fichier suivant dans la liste et vous exécutez redit1 à nouveau pour le fichier suivant.)

Comme ce que vous faites est moins compliqué, vous n'avez pas besoin de redit1 car vous ne travaillez qu'avec un seul hôte distant, vous pouvez simplement pointer votre éditeur sftp sur Host: .var/redit/Host ou équivalent.

1
hildred

Pour sftp: Si vous disposez d'un accès ssh Shell Sudo, vous pouvez ajouter votre nom d'utilisateur au groupe d'utilisateurs racine dans/etc/group, puis accorder à ce groupe des autorisations rx pour les dossiers auxquels vous souhaitez accéder.

0
physicsgeekn

Vous pouvez insérer dans votre fichier sshd_config côté serveur:

Subsystem sftp Sudo -n true && Sudo -n /usr/lib/openssh/sftp-server || /usr/lib/openssh/sftp-server

De cette façon, quiconque a le droit NOPASSWD Sudo obtiendra un accès sftp enraciné.

0
János Konkoly

L'ajout de cette ligne dans/etc/ssh/sshd_config était un correctif pour moi, et commente la ligne de sous-système existante Subsystem sftp Sudo -n true && Sudo -n /usr/lib/openssh/sftp-server || /usr/lib/openssh/sftp-server

puis Sudo systemctl sshd restart

0
Rakib Fiha