Problema com o sudoing ssh - 'sudo ssh…' falha

3

Eu estou tentando usar o acesso do git salt ssh (que roda com o root). O erro é sempre:

Permission denied (publickey).

Consegui reproduzir o problema, simulando o que o sal pode estar fazendo, executando um comando ssh no usuário root e depois o mesmo comando com sudo (ainda na conta root), recebendo o mesmo erro.

Isso é bem-sucedido:

root@server:/src# ssh -T [email protected]

logged in as XXXX.

Isso falha:

root@server:/src# sudo ssh -T [email protected]

Permission denied (publickey).

As permissões estão aparentemente corretas:

ls -la ~/.ssh
total 32
drwx------  2 root root 4096 Jun  2 12:18 .
drwx------ 12 root root 4096 Jun  2 12:10 ..
-rw-------  1 root root  550 Jun  1 16:31 authorized_keys
-r--------  1 root root   83 Jun  2 12:18 config
-rw-------  1 root root  134 Jun  1 18:18 environment
-rw-------  1 root root 1679 May 26  2015 id_rsa
-rw-r--r--  1 root root  393 Aug  3  2014 id_rsa.pub
-rw-r--r--  1 root root 3984 Jun  2 10:19 known_hosts

Adicionar -v ao comando com falha mostra todo o bem até o final, onde não há erro até a falha:

...
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Eu pesquisei e encontrei apenas coisas relacionadas a permissões, mas nada explicando sobre o fracasso do sudo ao executar com o root.

    
por Efren 02.06.2016 / 05:06

3 respostas

0

De alguma forma, isso estava relacionado ao arquivo id_rsa.pub . Para o usuário root, isso não causou problemas, mas para o sudo através do root, aparentemente ele não funciona.

Talvez seja um caso particular com raiz que bloqueia isso ou talvez precise de outra permissão especial, além das recomendadas ou configuração de grupo.

A "solução" era apenas remover o arquivo de chave pública.

    
por 03.06.2016 / 01:49
4

Como @Serge apontado em um comentário, esta linha

debug1: Offering RSA public key: /root/.ssh/id_rsa

na sua saída ssh -v informa que o ssh tentou autenticar com a chave pública no diretório inicial do root (/ root) e não no seu próprio diretório do usuário (/ home / yourusername).

Isso deixa você com três opções. Você pode tanto

  • execute o ssh com a opção -i para especificar explicitamente uma chave que o ssh usará (por exemplo, ssh -i /home/yourusername/.ssh/id_rsa ... ),
  • Crie uma nova chave ssh para o root e adicione-a às suas chaves autorizadas no controle remoto ou
  • Copie ou vincule seu próprio diretório .ssh a / root

Você pode querer repensar sua configuração. O SSH não requer privilégios de root na sua máquina e executá-lo como root não lhe trará nada no final remoto.

    
por 02.06.2016 / 11:36
-3

Eu acho que você precisa verificar o arquivo sudoer e adicionar o usuário através de privilégios de root. O arquivo sudoers localizado em: /etc/sudoers (depende do linux base), contém as regras que os usuários devem seguir ao usar o comando sudo.

Leia os suoders para sua versão do Linux / Unix. você vai ter muito material na web que definitivamente te ajuda

https://www.garron.me/en/linux/visudo-command-sudoers-file-sudo-default-editor.html

    
por 02.06.2016 / 07:39