Como usar o SFTP em um sistema que requer sudo para acesso root e autenticação baseada em chave ssh?

21

Eu quero poder usar o SFTP para editar arquivos que exigem permissões de root.

Estou usando a autenticação baseada em chave SSH - chave rsa no cartão inteligente.

Se o sistema requer o sudo para executar comandos de nível de raiz, como posso contornar isso?

Posso criar uma maneira de ignorar o sudo apenas para SFTP?

Existe uma maneira de manter o sudo & autenticação de chaves.

Estou usando o Windows para conectar ao Ubuntu. Eu preciso disso para trabalhar com o Mac conectando-se ao Ubuntu também.

Eu entendo como fazer o SSH Tunneling para administrar os serviços do sistema. Atualmente, eu uso login de usuário root diretamente, mas o login de senha está desabilitado. Não entendi como usar o sudo e o SFTP ao mesmo tempo. Parece ser uma prática recomendada exigir login como usuário não raiz e, em seguida, exigir o uso de sudo, já que os registros registrarão quem recebeu privilégios escalonados para cada comando.

Devo me preocupar com isso ao usar a autenticação baseada em chave ou essa é uma diferença trivial em segurança / registro? Parece que a autenticação baseada em chave registra o número de série do usuário nos logs, e você pode ter várias chaves para o usuário root identificar cada usuário. Este parece ser o mesmo efeito que usar o sudo para mim. Estou errado?

    
por Bruce Kirkpatrick 26.01.2014 / 20:01

8 respostas

7

SFTP é um acesso de comando para operações de arquivo, com as restrições da conta que você usa. Você deve usar o ssh para fazer mais operações administrativas, tornando impossível o uso de sudo e SFTP ao mesmo tempo. Se você precisar acessar o disco inteiro sem restrições usando o SFTP, faça-o usando a conta root. De qualquer forma, você pode fazer um login com root no sftp e no ssh ao mesmo tempo, é claro, usando duas sessões diferentes.

As chaves de segurança melhoram a segurança e facilitam o registro, não exigindo entrada de teclado. Só ajuda a fazer login, você pode ter várias senhas para cada usuário da conta e teve o mesmo efeito.

EDIT: Eu esqueci: você pode criar outra conta com o mesmo efeito que o root se você atribuir o ID do usuário para 0, mas não tinha nenhum sentido, sendo perigoso da mesma maneira. Poderia dar alguma ofuscação se alguém tentar entrar como root, mas, além disso, não tinha muito sentido.

    
por 26.01.2014 / 21:46
10

Chamar o subsistema com o sudo funcionou para mim.

Para um host Ubuntu, por exemplo:

sftp -s "sudo /usr/lib/openssh/sftp-server" targethost.fqdn
    
por 21.11.2014 / 22:01
7

Além do que @ MartinVonWittich sugeriu nos comentários acima que você poderia configurar um par de chaves SSH dedicado apenas para esta atividade e adicioná-los ao arquivo /root/.ssh/authorized_keys do usuário root limitando seu escopo a apenas um único comando.

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

Isso permitiria outro sistema com a chave correspondente a este par para SFTP neste sistema como root. Você ainda teria um registro dessa conexão em seus arquivos syslog e / ou secure.log (supondo que sua distro forneça esse nível de registro).

OBSERVAÇÃO: Quem acessa o servidor com esse método teria acesso de cartes blanche, portanto, use-o com sabedoria. Melhor ainda continuar lendo e combinar esse recurso com chroot e acesso somente leitura, para construir restrições mais restritas e acesso direcionado a locais específicos como root.

chroot & readonly

A outra técnica que você poderia explorar aqui seria limitar a conexão SFTP para que ela fosse chrootada em locais específicos como raiz, com base em qual chave SSH foi usada. Veja minha resposta a estas perguntas e respostas intituladas " Restringir backup sem senha com SFTP "para mais detalhes.

Você também pode controlar sftp-server por meio de suas opções -R e -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.
    
por 26.01.2014 / 22:26
1

Eu tive um problema semelhante, pois queria usar o vimdiff para editar arquivos de configuração em um grupo de hosts em grande parte semelhantes, com o cssh e o sudo, e você pode adaptar minha solução ao seu fluxo de trabalho.

sudoedit (parte do sudo) permite usar qualquer editor como um usuário comum para editar um arquivo para o qual você não tem permissão de gravação e você pode especificar o editor com uma variável de ambiente. O sudoedit copia o (s) arquivo (s), invoca o editor com os nomes das cópias e espera que o editor saia, depois copia a cópia modificada de volta para onde estava. então criei um 'editor' que não edita, apenas anota o arquivo para uso posterior e espera e um wrapper em torno do vimdiff que usa esse marcador.

o primeiro arquivo é ~ / .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;
}

o segundo é ~ / .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;

A maneira como eu os uso é usar o cssh para abrir uma conexão com todos os quatro hosts e usar um comando como EDITOR=~/.bin/redit sudoedit /etc/conf/file e depois Em uma janela diferente, executar ~/.bin/redit1 , fazer minhas alterações, salvar e sair, voltar para cssh e pressione enter para confirmar as alterações e sair do sudoedit (a menos que eu esteja editando mais de um arquivo, caso em que redit avança para o próximo arquivo da lista e você executa redit1 novamente para o próximo arquivo).

Como o que você está fazendo é menos complicado, você não precisa do redit1 devido a trabalhar apenas com um host remoto, basta apontar seu editor sftp no host: .var / redit / host ou equivalente.

    
por 26.01.2014 / 23:29
1

O que eu faço é usar scp ao invés de (s) ftp, e mudar o shell para sudo su - no WinSCP isso é em Advanced \ SCP \ Shell, mas este somente funciona com o protocolo scp .

    
por 09.02.2015 / 16:23
0

Para o sftp: Se você tiver acesso ao sudo do shell ssh, você pode adicionar seu nome de usuário ao grupo de usuários root em / etc / group e então dar a esse grupo permissões rx para as pastas que deseja acessar.

    
por 18.02.2017 / 02:08
0

Você pode inserir em seu arquivo sshd_config no lado do servidor:

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

Dessa forma, quem tiver o comando NOPASSWD sudo receberá um acesso sftp enraizado.

    
por 19.12.2017 / 05:30
0

Adicionar essa linha em / etc / ssh / sshd_config foi uma correção para mim e comentar a linha do subsistema existente Subsystem sftp sudo -n true && sudo -n /usr/lib/openssh/sftp-server || /usr/lib/openssh/sftp-server

então sudo systemctl sshd restart

    
por 30.10.2018 / 09:05

Tags