Come utilizzare SFTP su un sistema che richiede sudo per l'accesso root e l'autenticazione basata su chiave ssh?

Voglio essere in grado di utilizzare SFTP per modificare i file che richiedono i permessi di root.

Sto usando l'autenticazione basata su chiave SSH - chiave rsa su smart card.

Se il sistema richiede sudo per eseguire comandi a livello di root, come posso aggirare questo?

Posso creare un modo per bypassare sudo solo per SFTP?

C'è un modo per mantenere l'autenticazione sudo e chiave.

Sto usando Windows per connettermi a Ubuntu. Ho bisogno che funzioni anche con Mac che si connette a Ubuntu.

Capisco come eseguire il tunneling SSH per amministrare i servizi di sistema. Attualmente, utilizzo direttamente l'accesso dell'utente root, ma l'accesso alla password è disabilitato. Non ho capito come usare sudo e SFTP allo stesso tempo. Sembra essere una buona pratica richiedere l'accesso come utente non root e quindi richiedere l'uso di sudo poiché i registri registreranno a chi sono stati assegnati i privilegi di escalation per ciascun comando.

Dovrei preoccuparmi di questo quando uso l'autenticazione basata su chiave o questa è una banale differenza nella sicurezza / registrazione? Sembra che l'autenticazione basata su chiave registri il numero di serie dell'utente nei registri e puoi avere più chiavi affinché l'utente root possa identificare ciascun utente. Questo sembra avere lo stesso effetto dell'utilizzo di sudo per me. Ho sbagliato?

SFTP è un comando di accesso alle operazioni sui file, con le restrizioni dall'account utilizzato. È necessario utilizzare ssh per eseguire più operazioni amministrative, rendendo impossibile usare contemporaneamente sudo e SFTP. Se hai bisogno di accedere all'intero disco senza restrizioni usando SFTP, fallo usando l'account root. Ad ogni modo puoi fare un login con root su sftp e ssh contemporaneamente, ovviamente, usando due sessioni diverse.

Le chiavi di sicurezza migliorano la sicurezza e rendono più semplice la registrazione, senza richiedere l'immissione da tastiera. Aiuta solo a effettuare l'accesso, puoi avere diverse password per ogni utente dell'account e avere lo stesso effetto.

EDIT: Ho dimenticato: puoi creare un altro account con lo stesso effetto di root se assegni l'id utente a 0, ma non hai alcun senso, essendo pericoloso allo stesso modo. Potrebbe dare qualche offuscamento se qualcuno provasse ad accedere come root, ma a parte questo, non aveva molto senso.

Chiamare il sottosistema con sudo ha funzionato per me.

Ad un host Ubuntu per esempio:

sftp -s "sudo /usr/lib/openssh/sftp-server" targethost.fqdn

Oltre a quanto suggerito da @MartinVonWittich nei commenti sopra, è possibile impostare una coppia di chiavi SSH dedicata solo per questa attività e aggiungerli al /root/.ssh/authorized_keysfile dell'utente root limitandone l'ambito a un solo comando.

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

Ciò consentirebbe a un altro sistema con la chiave corrispondente di questa coppia di SFTP in questo sistema come root. Avresti ancora una registrazione di questa connessione nel tuo sysloge / o secure.logfile (supponendo che la tua distribuzione fornisca questo livello di registrazione).

NOTA: chiunque acceda al server con questo metodo avrebbe accesso blanche ai cartes, quindi usalo con saggezza. Meglio ancora continuare a leggere e combinare questa capacità con chroot e accesso in sola lettura, per costruire restrizioni più rigorose e accesso mirato a posizioni specifiche come root.

chroot e di sola lettura

L'altra tecnica che potresti sfruttare qui sarebbe quella di limitare la connessione SFTP in modo che sia stata chrootata in posizioni specifiche come root, in base alla chiave SSH utilizzata. Vedi la mia risposta a queste domande e risposte U&L intitolata " Limita backup senza password con SFTP " per maggiori dettagli.

Puoi anche controllare sftp-serverattraverso i suoi interruttori -Re -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.

L'approccio semplice che ho seguito è stato semplicemente sftp e posizionare i file su un'area dello stage ( mkdirnuova directory in cui si dispone delle autorizzazioni sul server) e quindi di nuovo ssh per spostare i file da lì a destinazione con sudo cpo sudo mv.

Ho avuto un problema simile in quanto volevo usare vimdiff per modificare i file di configurazione su un gruppo di host per lo più simili, con cssh e sudo e potresti essere in grado di adattare la mia soluzione al tuo flusso di lavoro.

sudoedit (parte di sudo) consente di utilizzare qualsiasi editor come utente normale per modificare un file per il quale non si dispone dell'autorizzazione di scrittura e che è possibile specificare l'editor con una variabile di ambiente. sudoedit copia i file, richiama l'editor con i nomi delle copie e attende la chiusura dell'editor, quindi copia la copia modificata nel punto in cui si trovava. così ho creato un 'editor' che non modifica, nota solo il file per un uso successivo e attende e un wrapper attorno a vimdiff che usa quel marcatore.

il primo file è ~ / .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;
}

il secondo è ~ / .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;

Il modo in cui li uso è che uso cssh per aprire una connessione a tutti e quattro gli host e quindi uso un comando come EDITOR=~/.bin/redit sudoedit /etc/conf/filee poi In una finestra diversa ~/.bin/redit1, apporta le mie modifiche, salva ed esci, torna a cssh e premi Invio per confermare le modifiche ed esci da sudoedit (a meno che non stia modificando più di un file, nel qual caso redit avanza al file successivo nell'elenco e si esegue nuovamente redit1 per il file successivo.)

Dato che ciò che stai facendo è meno complicato, non hai bisogno di redit1 a causa del solo lavoro con un host remoto, puoi semplicemente puntare il tuo editor sftp su host: .var / redit / host o equivalente.

Quello che faccio è usare scp invece di (s) ftp e cambiare la shell sudo su -in WinSCP, questo è in Advanced \ SCP \ Shell, ma funziona solo con il protocollo scp.

Per sftp: se si dispone dell'accesso sudo shell ssh, è possibile aggiungere il proprio nome utente al gruppo utenti root in / etc / group e quindi assegnare a quel gruppo autorizzazioni rx per le cartelle a cui si desidera accedere.

È possibile inserire nel file sshd_config sul lato server:

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

In questo modo chiunque abbia NOPASSWD sudo otterrà un accesso sftp con root.

Aggiungere questa riga a / etc / ssh / sshd_config è stata una soluzione per me e commentare la riga del sottosistema esistente Subsystem sftp sudo -n true && sudo -n /usr/lib/openssh/sftp-server || /usr/lib/openssh/sftp-server

poi sudo systemctl sshd restart