Jak korzystać z SFTP w systemie, który wymaga sudo do dostępu do roota i uwierzytelniania na podstawie klucza SSH?

Chcę móc używać SFTP do edycji plików wymagających uprawnień roota.

Używam uwierzytelniania opartego na kluczu SSH - klucz rsa na karcie inteligentnej.

Jeśli system wymaga sudo do wykonywania poleceń poziomu root, jak to obejść?

Czy mogę stworzyć sposób na ominięcie sudo tylko dla SFTP?

Czy istnieje sposób na utrzymanie sudo i uwierzytelnienia klucza.

Korzystam z systemu Windows, aby połączyć się z Ubuntu. Potrzebuję tego do pracy z komputerem Mac łączącym się również z Ubuntu.

Rozumiem, jak wykonać tunelowanie SSH w celu administrowania usługami systemowymi. Obecnie używam logowania użytkownika root bezpośrednio, ale logowanie hasłem jest wyłączone. Nie rozumiałem, jak używać sudo i SFTP w tym samym czasie. Wydaje się, że najlepszą praktyką jest wymaganie zalogowania się jako użytkownik inny niż root, a następnie użycie sudo, ponieważ dzienniki będą rejestrować, kto otrzymał eskalowane uprawnienia do każdej komendy.

Czy powinienem się tym przejmować podczas korzystania z uwierzytelniania opartego na kluczach, czy jest to trywialna różnica w bezpieczeństwie / logowaniu? Wygląda na to, że uwierzytelnianie oparte na kluczach rejestruje numer seryjny użytkownika w dziennikach i użytkownik może mieć wiele kluczy, aby użytkownik root mógł zidentyfikować każdego użytkownika. Wydaje mi się, że jest to ten sam efekt, co używanie sudo. Czy się mylę?

SFTP to dostęp do poleceń dla operacji na plikach, z ograniczeniami z konta, którego używasz. Musisz użyć ssh do wykonania większej liczby operacji administracyjnych, co uniemożliwi korzystanie z sudo i SFTP w tym samym czasie. Jeśli potrzebujesz dostępu do całego dysku bez ograniczeń za pomocą SFTP, zrób to przy użyciu konta root. W każdym razie możesz zalogować się przy użyciu roota na sftp i ssh w tym samym czasie, oczywiście, używając dwóch różnych sesji.

Klucze bezpieczeństwa zwiększają bezpieczeństwo i ułatwiają logowanie, nie wymagając klawiatury. Pomaga tylko przy logowaniu, możesz mieć kilka haseł dla każdego użytkownika konta i mieć ten sam efekt.

EDYCJA: Zapomniałem: możesz utworzyć inne konto z takim samym efektem jak root, jeśli przypiszesz identyfikator użytkownika do 0, ale nie miało to sensu, będąc niebezpiecznym w ten sam sposób. Może dać trochę zaciemnienia, jeśli ktoś spróbuje zalogować się jak root, ale poza tym nie miał wiele sensu.

Wywołanie podsystemu sudo działało dla mnie.

Na przykład do hosta Ubuntu:

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

Poza tym, co @MartinVonWittich zasugerował w powyższych komentarzach, możesz skonfigurować dedykowaną parę kluczy SSH tylko dla tego działania i dodać je do /root/.ssh/authorized_keyspliku użytkownika root, ograniczając ich zakres do jednego polecenia.

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

Pozwoliłoby to innemu systemowi z odpowiednim kluczem do tej pary na SFTP w tym systemie jako root. Nadal będziesz mieć zapis tego połączenia w swoich syslogi / lub secure.logplikach (zakładając, że Twoja dystrybucja zapewnia taki poziom logowania).

UWAGA: Każdy, kto uzyskuje dostęp do serwera w tej metodzie, miałby dostęp do kart bez dostępu, więc używaj go mądrze. Lepiej nadal czytaj dalej i łącz tę możliwość z chroot i dostępem tylko do odczytu, aby stworzyć ściślejsze ograniczenia i ukierunkowany dostęp do określonych lokalizacji jako root.

chroot i tylko do odczytu

Inną techniką, którą można tu wykorzystać, byłoby ograniczenie połączenia SFTP, tak aby było ono chrootowane w określonych lokalizacjach jako root, na podstawie którego użyto klucza SSH. Zobacz moją odpowiedź na pytania i odpowiedzi U&L zatytułowane: „ Ogranicz tworzenie kopii zapasowych bez hasła za pomocą SFTP ”, aby uzyskać więcej informacji.

Możesz także kontrolować sftp-serverza pomocą jego przełączników -Ri -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.

Proste podejście, które zastosowałem, to po prostu sftp i umieścić pliki w obszarze sceny ( mkdirnowy katalog, w którym masz uprawnienia na serwerze), a następnie ponownie ssh, aby przenieść pliki stamtąd do miejsca docelowego za pomocą sudo cplub sudo mv.

Miałem podobny problem, ponieważ chciałem użyć vimdiff do edycji plików konfiguracyjnych na grupie najczęściej podobnych hostów, z cssh i sudo, i możesz być w stanie dostosować moje rozwiązanie do twojego przepływu pracy.

sudoedit (część sudo) pozwala używać dowolnego edytora jako zwykłego użytkownika do edycji pliku, do którego nie masz uprawnień do zapisu i możesz określić edytor za pomocą zmiennej środowiskowej. sudoedit kopiuje plik (i), wywołuje edytor z nazwami kopii i czeka na zakończenie edytora, a następnie kopiuje zmodyfikowaną kopię z powrotem tam, gdzie była. więc stworzyłem „edytor”, który nie edytuje, po prostu zapisuje plik do późniejszego użycia i czeka oraz otacza vimdiff, który używa tego znacznika.

pierwszy plik to ~ / .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;
}

drugi to ~ / .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;

Używam ich za pomocą cssh, aby otworzyć połączenie ze wszystkimi czterema hostami, a następnie użyć polecenia podobnego, EDITOR=~/.bin/redit sudoedit /etc/conf/filea następnie W innym uruchomieniu okna ~/.bin/redit1dokonaj moich zmian, zapisz i wyjdź, przełącz się z powrotem na cssh i naciśnij enter, aby zatwierdzić zmiany i wyjdź z sudoedit (chyba że edytuję więcej niż jeden plik, w takim przypadku redit przechodzi do następnego pliku na liście i ponownie uruchamiasz redit1 dla następnego pliku).

Ponieważ to, co robisz, jest mniej skomplikowane, nie potrzebujesz redit1 ze względu na pracę tylko z jednym zdalnym hostem, możesz po prostu skierować swój edytor sftp na host: .var / redit / host lub równoważny.

Używam scp zamiast ftp i zmieniam powłokę na sudo su -WinSCP w Advanced \ SCP \ Shell, ale działa to tylko z protokołem scp.

Dla sftp: Jeśli masz dostęp do sudo w ssh shell, możesz dodać swoją nazwę użytkownika do głównej grupy użytkowników w / etc / group, a następnie nadać tej grupie uprawnienia rx do folderów, do których chcesz uzyskać dostęp.

Możesz wstawić do pliku sshd_config po stronie serwera:

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

W ten sposób każdy, kto ma prawo NOPASSWD sudo, uzyska dostęp do rootowania sftp.

Dodanie tej linii w / etc / ssh / sshd_config było dla mnie poprawką i skomentowało istniejącą linię podsystemu Subsystem sftp sudo -n true && sudo -n /usr/lib/openssh/sftp-server || /usr/lib/openssh/sftp-server

następnie sudo systemctl sshd restart