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

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 exigir que o sudo execute comandos no nível raiz, como contornar isso?

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

Existe uma maneira de manter a autenticação do sudo e da chave.

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

Eu entendo como fazer o tunelamento SSH para administrar os serviços do sistema. Atualmente, eu uso o login do usuário root diretamente, mas o login da senha está desativado. Não entendi como usar o sudo e o SFTP ao mesmo tempo. Parece ser uma prática recomendada exigir o login como um usuário não root e, em seguida, exigir o uso do sudo, pois os logs registrarão quem recebeu privilégios escalados para cada comando.

Devo me preocupar com isso ao usar autenticação baseada em chave ou isso é uma diferença trivial na 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 raiz identificar cada usuário. Este parece ser o mesmo efeito que usar o sudo para mim. Estou errado?

SFTP é um comando de acesso às operações de arquivo, com as restrições da conta que você usa. Você deve usar o ssh para realizar mais operações administrativas, impossibilitando o uso do sudo e do SFTP ao mesmo tempo. Se você precisar acessar o disco inteiro sem restrição usando SFTP, faça-o usando a conta raiz. De qualquer forma, você pode fazer um login com root no sftp e 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 do teclado. Só ajuda a fazer o login, você pode ter várias senhas para cada usuário da conta e ter o mesmo efeito.

EDIT: Esqueci: você pode criar outra conta com o mesmo efeito que root se atribuir o ID de usuário a 0, mas não teve nenhum sentido, sendo perigoso da mesma maneira. Poderia dar alguma ofuscação se alguém tentar fazer login como root, mas, além disso, não teve muito sentido.

Ligar para o subsistema com sudo funcionou para mim.

Para um host Ubuntu, por exemplo:

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

Além do que o @MartinVonWittich sugeriu nos comentários acima, você pode configurar um par de chaves SSH dedicado apenas para esta atividade e adicioná-los ao /root/.ssh/authorized_keysarquivo do usuário raiz, 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 que outro sistema com a chave correspondente desse par fosse transferida para SFTP nesse sistema como raiz. Você ainda teria um registro dessa conexão em seus arquivos sysloge / ou secure.log(supondo que sua distribuição forneça esse nível de registro).

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

chroot e somente leitura

A outra técnica que você poderia explorar aqui seria limitar a conexão SFTP para que ela fosse chroot em locais específicos como raiz, com base na qual chave SSH foi usada. Veja minha resposta a esta sessão de perguntas e respostas da U&L intitulada: " Restringir backup sem senha com SFTP " para obter mais detalhes.

Você também pode controlar sftp-serveratravés de seus switches -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.

A abordagem simples que eu segui foi apenas sftp e colocar os arquivos em uma área de palco ( mkdirnovo diretório onde você tem permissões no servidor) e depois ssh novamente para mover os arquivos de lá para o destino com sudo cpor sudo mv.

Eu tive um problema semelhante porque queria usar o vimdiff para editar arquivos de configuração em um grupo de hosts principalmente similares, com cssh e sudo, e você poderá adaptar minha solução ao seu fluxo de trabalho.

O sudoedit (parte do sudo) permite usar qualquer editor como usuário comum para editar um arquivo para o qual você não tem permissão de gravação e pode especificar o editor com uma variável de ambiente. O sudoedit copia o (s) arquivo (s), chama o editor com os nomes das cópias e aguarda a saída do editor e copia a cópia modificada de volta para onde estava. então eu criei um 'editor' que não edita, apenas anota o arquivo para uso posterior e aguarda e um invólucro 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 os uso é o uso do cssh para abrir uma conexão com todos os quatro hosts e, em seguida, uso um comando como esse EDITOR=~/.bin/redit sudoedit /etc/conf/filee, em uma janela diferente, execute ~/.bin/redit1minhas alterações, salve e saia, volte para o cssh e pressione enter para confirmar as alterações e saia do sudoedit (a menos que eu esteja editando mais de um arquivo, nesse caso, o redit avança para o próximo arquivo na 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 ao trabalho apenas com um host remoto, basta apontar o editor do sftp para o host: .var / redit / host ou equivalente.

O que faço é usar scp em vez de ftp e alterar o shell para sudo su -no WinSCP, isso é em Advanced \ SCP \ Shell, mas isso funciona apenas com o protocolo scp.

Para sftp: se você tiver acesso ao ssh shell sudo, poderá adicionar seu nome de usuário ao grupo de usuários raiz em / etc / group e, em seguida, conceder permissões a esse grupo rx nas pastas que deseja acessar.

Você pode inserir no 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 NOPASSWD sudo certo obterá um acesso sftp enraizado.

A adição desta linha em / etc / ssh / sshd_config foi uma correção para mim e comente a linha de 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