Setembro 11, 2020
Articles
Sem comentários

rsync com um usuário diferente

Estou trabalhando com duas instâncias do Ubuntu no AWS (que uso uma chave pem para acessá-los).

Eu configurei o rsync para ambas as instâncias e funciona se eu usar o usuário padrão que é ubuntu @ ipaddress. No entanto, se eu tentar usar o rsync com outro usuário (estou digitando sudo su - jenkins por exemplo, ou mesmo digitando sudo antes do comando rsync), recebo o seguinte erro. 

Permission denied (publickey). rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: unexplained error (code 255) at io.c(226) [Receiver=3.1.0]

Etapas que dei:

Tentei criar uma chave ssh (usando ssh-keygen) enquanto estava conectado como jenkins e adicionei isso ao authorized_keys arquivo em /home/ubuntu/.ssh/authorized_keys (onde estou executando o rsync) e até mesmo $JENKINS_HOME/.ssh/authorized_keys (onde também tentei executar o rsync a partir daí).

Até tentei usar a chave pem para fazer a mesma coisa, mas também não funcionou.

Aqui está o que eu “estou tentando executar

rsync -avuh --delete -e ssh jenkins@ipaddress:/var/lib/jenkins/* /var/lib/jenkins

E h Existem com o arquivo de chave

rsync -avuh --delete -e "ssh -i path/to/key.pem" [email protected]:/var/lib/jenkins/* /var/lib/jenkins

PS: A única razão pela qual eu não quero executá-lo com o ubuntu usuário é porque eu recebo failed: Permission denied (13) em muitas coisas (já que os arquivos são de propriedade de Jenkins).

Objetivo final:

I “estou tentando manter o backup da instância jenkins de backup constantemente com a instância primária fazendo um cronjob:

*/30 * * * * /usr/bin/rsync -avuh --delete -e ssh root@jenkinsprimary:/var/lib/jenkins/* /var/lib/jenkins

Comentários

  • Você adicionou a chave ssh no arquivo hosts autorizados_keys remotos ou no servidor onde está executando o comando rsync?
  • A questão isn ‘ t muito claro. Em cada execução do rsync, você tem uma origem e um destino. Você pode esclarecer os sistemas de origem e destino? Para fins de solução de problemas, recomendo usar apenas o ssh em vez do rsync, porque o rsync usará o ssh. Tente usar ssh -vvv jenkins @ < target > da fonte e cole a saída aqui.
  • Recebo falha: permissão negada (13) em várias coisas (já que os arquivos são de propriedade de jenkins) Então, por que não executar o rsync como o ” jenkins ” usuário?
  • Você escreveu Eu ‘ tentei criar uma chave ssh (usando ssh-keygen) enquanto conectado como jenkins e adicionado ao arquivo authorized_keys em /home/ubuntu/.ssh/authorized_keys (onde i ‘ estou executando o rsync de) , mas você deve adicionar a chave ao arquivo authorized_keys no sistema de destino .

Resposta

Eu sei que é uma postagem antiga, mas caso possa ajudar outras pessoas …

Você tem que diferenciar 2 coisas:

  • quem estabelece a conexão SSH .
  • qual usuário remoto possui os arquivos que você deseja copiar.

Visão geral 

(srcmachine) (rsync) (destmachine) srcuser -- SSH --> destuser | | sudo su jenkins | v jenkins

Digamos que você queira fazer o rsync:

  • De:
    • Máquina: srcmachine
    • Usuário: srcuser
    • Diretório: /var/lib/jenkins
  • Para:
    • Máquina: destmachine
    • Usuário: destuser para estabelecer a conexão SSH .
    • Diretório: /tmp
    • Proprietário dos arquivos finais: jenkins.

Solução 

rsync --rsync-path "sudo -u jenkins rsync" -avP --delete /var/lib/jenkins destuser@destmachine:/tmp

Explicações 

 --rsync-path=PROGRAM specify the rsync to run on the remote machine

O truque é dizer para executar rsync na máquina remota com outro usuário (jenkins) que não aquele que estabelece a conexão SSH (destuser).

Requisitos

acesso SSH 

(srcmachine) (rsync) (destmachine) srcuser -- SSH --> destuser [~/.ssh/id_rsa] [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside [~/.ssh/id_rsa.pub]

Não se esqueça de restringir as permissões em ~/.ssh : 

chmod 700 ~/.ssh

sudoer para o destuser

O destuser deve ter o privilégio de fazer sudo -u jenkins rsync.

Em geral, definimos destuser como um membro do sudoers. Para fazer isso, no root @ destmachine: 

cat > /etc/sudoers.d/destuser << EOF destuser ALL=(ALL) NOPASSWD:ALL EOF

Para testá-lo antes de rsync, você pode fazer login no destuser @ destmachine e executar isto: 

sudo su jenkins echo $USER

Se retornar: 

jenkins

significa que você está conectado como jenkins usuário, e isso significa que seu comando rsync também funcionará, porque o privilégio de escalada para jenkins funciona.

Nota sobre uma solução ruim: estabeleça a conexão SSH com o usuário de destino jenkins

Por que não ” não apenas fazemos isso?

(srcmachine) (rsync) (destmachine) srcuser -- SSH --> jenkins [~/.ssh/id_rsa] [~/.ssh/authorized_keys] <-- "id_rsa.pub" inside [~/.ssh/id_rsa.pub]

porque jenkins é uma conta de “serviço”, o que significa que executa um serviço que expõe uma porta (80 ou assim) para acesso HTTP externo, e isso significa que é POSSÍVEL que haja uma violação de segurança por meio do serviço Jenkins por HTTP para obter acesso.

É por isso que temos www-data usuário e semelhantes para executar os diferentes serviços. No caso de serem hackeados das portas que expõem, eles não podem fazer muito:

  • tudo é somente leitura para eles.
  • exceto a escrita em /var/log/THE_SERVICE.

Permitindo assim O acesso SSH para o usuário jenkins expõe um ataque de superfície (e assim é para o acesso SSH como root !!).

Além disso, se você deseja sincronizar com outro usuário (root, www-data, etc.), você terá que copiar seu Chave SSH chave pública para essas contas (problemático).

Boa solução : você deve definir acesso SSH o mínimo possível às contas de usuário (destuser) que PODE escaladar para a conta de “serviço” que você deseja (jenkins, root etc.).

Resposta

Tive um problema semelhante com o rsyncing como outro usuário. Resolvido executando o próximo comando: 

rsync -avu -e "ssh -i my-key -o StrictHostKeyChecking=no -l user-i-want-to-use-in-rsync" ./local_dir remote_host:remote-host-dir

Observe que talvez você precise brincar com as teclas para poder executar o rsync como outro usuário.

Resposta 

sudo -u jenkins -i rsync ...

sem sem aspas .

A opção -i faz com que o comando sudo seja executado com o ambiente do usuário, incluindo chaves ssh, .profile, .bash_profile etc.

Do sudo homem:

-i, --login

Execute o shell especificado pela entrada do banco de dados de senha do usuário de destino como um shell de login . Isso significa que arquivos de recursos específicos de login, como .profile, .bash_profile ou .login, ser lido pelo shell. Se um comando for especificado, ele será passado ao shell para execução por meio da opção shell “s -c. Se nenhum comando for especificado, um shell interativo será executado. sudo tenta mudar para o diretório inicial do usuário antes de executar o shell. O comando é executado em um ambiente semelhante ao que um usuário receberia ao efetuar login. Observe que a maioria dos shells se comporte de maneira diferente quando um comando é especificado em comparação com uma sessão interativa; consulte o manual do shell para obter detalhes. A seção Ambiente de comando no manual sudoers(5) documenta como a opção -i afeta o ambiente no qual um comando é executado quando a política de sudoers está em use.

Resposta

Tenho um problema semelhante.
I resolva isso usando o cron. Mas o cron deve ser executado com um usuário específico (ex: jenkins)

Basta fazer o cron job: 

$ crontab -u jenkins -e

e preencher o cron com sua necessidade. 

*/2 * * * * sh /home/user/scp.sh 2>&1 >> /home/user/errmail.log

Comentários

  • Se rsync for falhou devido a um problema de autenticação, como sua sugestão ajudará?

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *