systemd service que precisa de uma senha .ssh / id_dsa

Question

Eu tenho um serviço systemctl que inicia um processo smd-loop em uma sessão screen . Esse processo requer acesso a fontes SSH remotas (para fins de sincronização) e, portanto, precisa acessar minha chave privada id_dsa .

Como posso configurar o serviço systemd para que funcione? O serviço a seguir inicia o processo corretamente, mas requer que eu me conecte à sessão de tela e digite manualmente a senha id_dsa .

[Unit]
Description=smd loop
After=local-fs.target network.target

[Service]
User=%i
Group=users
Type=Forking
ExecStart=/usr/bin/screen -S smd-loop-win -md "smd-loop"
RemainAfterExit=yes

Quando eu inicio manualmente smd-loop , a senha id_dsa não é necessária, já que eu insalava o módulo pam_ssh que inicia um ssh-agent que contém a senha no login.

    

Answer 1

Você precisa colocar os arquivos de identidade contendo a chave privada não criptografada no diretório ~/.ssh do usuário que o serviço está executando. Além disso, você precisa definir a variável de ambiente HOME para ela, por exemplo, se ela for executada como root:

ExecStart=/usr/bin/env HOME=/root /usr/bin/screen -S smd-loop-win -md "smd-loop"

Como alternativa, se você tiver um controle sobre como smd-loop chama ssh , adicione a opção -I para informar ao ssh um arquivo de identidade a ser usado.

Em qualquer caso, o arquivo de identidade deve pertencer a esse usuário e só pode ser acessado por esse usuário ( chmod 0400 ~/.ssh/id* ).

    

Answer 2

Eu geraria uma chave ssh própria sem passphrase para esse serviço.

No (s) sistema (s) de destino, eu usaria "command=" nas authorized_keys para restringir o uso dessa chave a um único comando.

Depois disso, para acionar o comando-alvo, basta conectar-se ao servidor - você não precisa especificar mais nada (não o evento, o comando).

    

Answer 3

Se você precisar que o serviço funcione enquanto estiver conectado, faça com que ele se conecte ao ssh-agent que você iniciou na sua sessão. A maneira mais fácil de fazer isso é usar um caminho fixo para o soquete do agente. Defina a variável de ambiente SSH_AUTH_SOCK como algo como /home/romeovs/.ssh/darkstar.agent.socket no trabalho systemd e no seu .profile . Observe que, se sua distribuição iniciar um processo ssh-agent para você, talvez seja necessário eliminá-lo ou deixá-lo sem uso e substituí-lo pelo seu. Se a variável SSH_AUTH_SOCK estiver presente no ambiente, ssh-agent usará o caminho que contém para seu soquete. Então, quando você fizer login, execute ssh-add em sua chave privada e o trabalho poderá usá-lo.

Se você precisar que o trabalho funcione o tempo todo, recomendo criar uma chave específica sem senha para esse fim ( ssh-keygen -t rsa -f ~/.ssh/smd.id_rsa -N '' ) e autorizá-lo apenas para executar um comando específico no servidor usando command= e from= de restrições no arquivo ~/.ssh/authorized_keys no servidor. A opção from= significa que a chave é válida apenas para tentativas de login de hosts específicos e command= especifica um comando que é executado em vez do comando especificado pelo cliente.

ssh-rsa AAAA…== romeovs@darkstar no-agent-forwarding no-port-forwarding no-x11-forwarding from="[email protected]" command="somecommand --foo"

O comando é executado pelo seu shell de login. Se você precisar passar parâmetros para esse comando, você tem duas opções:

• O comando original tentado pelo cliente está na variável de ambiente SSH_ORIGINAL_COMMAND . Cuidado ao citar problemas se você tentar analisá-lo.
• Algumas variáveis de ambiente são passadas pelo cliente. O conjunto exato depende da configuração do servidor ( AcceptEnv diretiva no arquivo sshd_config ).