Posso transferir um arquivo para uma pasta (em um servidor remoto) que é gravável somente pelo root (via sudo)?

Question

Eu tenho um shell script para configurar o ambiente e instalar um aplicativo da Web relativamente complexo em um servidor da web, que gradualmente evoluiu de um rápido hack para um hack maior e um pouco menos ruim.

Anteriormente, meu script tinha uma função integrada de "bootstrap" para permitir que eu copiasse facilmente do meu computador de desenvolvimento para o servidor remoto, solicitando login root para criar uma pasta para colocar o script e depois copiar o script.

À medida que este projeto evoluiu, agora descobrimos que um software adicional no qual precisaremos contar espera um ambiente 'sudo' (em vez de login root) para seu próprio script de configuração, e então eu gostaria de mudar o Trabalhando do meu script de configuração de esperar que o root use o sudo (especialmente como podemos compartilhar isso com os outros, e para que ele seja capaz de trabalhar em servidores onde o root não está disponível (por exemplo, Ubuntu)).

Atualmente, minha função de bootstrap faz:

bootstrap()
{
    INSTALL_DIR=/local/bin
    SCRIPT='basename $0'

    echo "Copying script '${SCRIPT}' onto server: '${RHOST}' into '${INSTALL_DIR}'"
    echo "(You need to login (as root) 2 times.)"
    ssh root@$RHOST "umask 027; mkdir -p $INSTALL_DIR"
    scp -p "$SCRIPT" root@$RHOST:/$INSTALL_DIR
    echo "Done. Now login to the server and run the script as root."
    exit
}

Não tenho certeza de como posso traduzir isso para o uso do sudo? scp espera que eu faça o login como o usuário que será capaz de escrever para a pasta onde o arquivo deve ir, o que eu não poderei fazer se não houver uma conta root?

Ou talvez eu esteja fazendo isso muito complicado? Se o usuário normal no servidor remoto for essencialmente removido de uma só etapa, talvez, em vez de tentar criar um local 'arrumado' para armazenar esses scripts de administração, eu poderia simplesmente esclá-lo em algum lugar no espaço de arquivo do usuário e o usuário poderia, então, executar a parte de instalação do script usando o sudo. (Suponho que o único problema que possa surgir então seja se um administrador diferente precisasse executar o script e não pudesse acessar os arquivos do outro usuário.)

    

Answer 1

Existem várias maneiras de resolver esse problema fora do SSH. Além disso, você é um pouco ambíguo sobre a conta root e o ambiente "sudo". O que eu estou supondo é que você quer dizer que a conta root não permite o acesso ao shell (que é o padrão no Ubuntu) e você tem que dar acesso sudo aos usuários para poder conceder permissões de administrador. A própria conta root ainda existe (uid / gid 0).

Furar com SSH e sudo

No caso de SSH, sudo e cópia segura de arquivos. Você pode copiar o arquivo para um local público e usar o sudo para copiá-lo ou movê-lo para o local restrito. Isso tem algumas implicações de segurança, pois o arquivo está, pelo menos temporariamente, em um local público. Existem também inúmeras abordagens para atenuar o fator de segurança deste problema.

Copie com segurança o arquivo para um local temporário no servidor remoto.

scp -p xfer_file jschaeffer@aiur:/tmp

Agora conecte-se ao servidor usando o SSH e copie ou mova-o para o local permanente.

ssh -t jschaeffer@aiur: sudo cp /tmp/xfer_file /perm

A principal conclusão aqui é -t para ssh. Da página man.

 -t      Force pseudo-tty allocation.  This can be used to execute arbitrary screen-based programs on a
         remote machine, which can be very useful, e.g. when implementing menu services.  Multiple -t options
         force tty allocation, even if ssh has no local tty.

Não solicite uma senha em tudo

Além disso, você pode definir sua regra sudo para não exigir uma senha e não solicitará o usuário.

Permitir que a autenticação sem senha faça root para usuários não-root

Alternativas para essa abordagem seria usar chaves públicas. Você pode conceder aos usuários acesso a outra conta por meio do uso de chaves públicas. Isso também tem suas próprias implicações de segurança. Você está dando aos usuários acesso root completo a uma caixa (um pequeno detalhe sobre isso abaixo).

jschaeffer@defiler:~# ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/jschaeffer/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /jschaeffer/.ssh/id_rsa.
Your public key has been saved in /jschaeffer/.ssh/id_rsa.pub.

Em seguida, copie a chave pública para o servidor remoto (certifique-se de copiar a chave pública e não a privada). Como toda a discussão envolve a cópia de arquivos para um servidor que não permite acesso direto ao root, não exibirei os comandos ssh-copy-id ou scp que se conectam à conta root. Independentemente disso, você tem que encontrar uma maneira de transferir a chave para ~ root / .ssh / authorized_keys. Poderia usar a estratégia acima ou copiar para uma unidade flash ou algum outro método (rsync, ftp, etc)

A conta raiz deve permitir a autenticação sem senha no servidor. Certifique-se de que as configurações estão corretas em / etc / ssh / sshd_config

# Authentication:
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes

Depois é só copiar o arquivo diretamente para a conta root.

scp -p xfer_file root@aiur:/perm_location

Você pode restringir o que os usuários podem realmente fazer quando eles adicionam opções ao arquivo authorized_keys

Outras opções

É claro que existem muitas outras opções que listarei, mas não entrarei em detalhes:

• Use o Kerberos. O Kerberos é um protocolo inteiro projetado em torno da segurança em redes não seguras. Isso, obviamente, requer um ambiente inteiro, manutenção, hardware, etc, provavelmente não é o que você está procurando. O SSH integra-se ao Kerbero ou você pode usar um de substituições Kerberos de uma transferência insegura.
• Copie o arquivo para um local temporário no servidor e tenha um cron trabalho que é executado como root no servidor remoto pegar arquivos em que diretório e transferi-los para o local permanente
• Rincronizar o arquivo
• Coloque o arquivo em um local público (ou seja, ftp, sftp, http) que ambos os servidores têm acesso a.
• Reabilite a conta raiz.

Answer 2

Para o rsync, existe um padrão que as pessoas usaram para implementar isso. A maioria das instalações do Linux inclui o rsync por padrão.

rsync -e "ssh -t" --rsync-path="sudo rsync" ...

- link

    

Answer 3

Em vez de empurrar os dados em algum lugar que você não pode escrever facilmente, que tal puxar os dados? Ou empurrando os dados para outro lugar que possa ser gravado, seguido por algo no sistema remoto colocando os dados no lugar? - provavelmente quando o aplicativo for devolvido para pegar os novos arquivos?

Tenha também cuidado com algumas sugestões que estão enfraquecendo a segurança do seu sistema de produção.