O SSH sem senha não está funcionando no terminal quando eu recebo a senha RSA

Question

Nós configuramos uma caixa do CentOS 6.4 com SSH sem senha para vários outros sistemas. Isso funciona bem ao usar um terminal como o usuário correto diretamente no computador CentOS. No entanto, se eu fizer login na caixa do CentOS como um desses mesmos usuários de outro sistema, será solicitada a frase secreta da chave RSA. Por que isso é necessário quando eu estou logado como o usuário correto?

Então, se temos três máquinas (A, B e C). A foi configurado para poder conectar-se sem senha à máquina B através do SSH. Isso funciona bem. No entanto, se nós SSH em A da máquina C e, em seguida, a partir dessa tentativa de terminal SSH remoto para SSH em B, isso requer uma senha.

A Máquina A possui scripts que acessam várias outras máquinas (sem senha). Precisamos ser capazes de fazer login remotamente na máquina A da Máquina C e, em seguida, lançar os scripts que acessam a máquina B.

    

Answer 1

Sua pergunta é um pouco incerta. Parece que você está usando uma chave SSH, mas a chave SSH é protegida por uma frase secreta. Mas, na verdade, ele também deve pedir essa frase secreta também quando você estiver conectado diretamente.

O que eu faria:

1. Crie um usuário especial (vamos chamá-lo de 'runscripts') na máquina A que é usada para executar os scripts.
2. Para este usuário, crie uma chave SSH que não seja criptografada por uma frase secreta.
3. Configure o sudo para permitir que usuários "normais" na máquina A executem esses scripts com os privilégios de usuário do usuário 'runscripts' e sem precisar digitar uma senha.

Aqui está um exemplo completo de como configurar isso:

Crie um novo usuário que não pode estar logado (no meu sistema isso também criará um novo grupo com o mesmo nome que eu usarei no seguinte):

# adduser --disabled-password runscripts

Torne-se este usuário e crie uma chave ssh. Não defina uma frase secreta na chave, basta pressionar enter no prompt da frase secreta.

# su runscripts
$ ssh-keygen

Adicione a chave pública (em ~ / .ssh / id_rsa.pub) às authorized_keys na máquina de destino (máquina B em seu exemplo), em seguida, tente o login por chave SSH (que também adicionará a chave pública remota para o known_hosts, para que ele não seja solicitado novamente mais tarde).

$ ssh [email protected]

De volta à máquina A: adicione a (s) conta (s) do usuário normal ao grupo:

# adduser kju runscripts

Crie algum script que use a chave SSH e faça algo em B:

# cat > /usr/local/bin/script1
#!/bin/sh
echo -n "Running as "
whoami
ssh remoteuser@machineB whoami
^D
# chmod +x /usr/local/bin/script1

Por fim, permita que os usuários em runcripts de grupo executem esse script como usuário em runcript sem uma senha. Esta é a linha do / etc / sudoers:

%runscripts  ALL=(runscripts) NOPASSWD:/usr/local/bin/script1

Agora, como um dos usuários em runcripts de grupo, tente executar o script:

$ sudo -u runscripts /user/local/bin/script1
Running as user runscripts
remoteuser
$

Como você pode ver nesta saída, o script foi executado como scripts de usuário. Em seguida, ele efetuou login na Máquina B como usuário 'remoteuser' e executou o comando 'whoami' (que, é claro, retornou 'remoteuser').

Fazer isso dessa forma tem o benefício de ninguém poder roubar a chave SSH (desprotegida) porque ela só é acessível como scripts de usuário, mas as pessoas só podem executar os scripts predeterminados com privilégios de usuário.

    

Answer 2

Você precisa gerar a chave sem uma frase secreta e usar a autenticação de chave pública se quiser evitar isso. Faça algo como:

a@A:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/a/.ssh/id_rsa): 
Created directory '/home/a/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/a/.ssh/id_rsa.
Your public key has been saved in /home/a/.ssh/id_rsa.pub.
The key fingerprint is:
3e:4f:05:79:3a:9f:96:7c:3b:ad:e9:58:37:bc:37:e4 a@A

Em outras palavras, basta pressionar enter quando ele solicitar a você Enter passphrase (empty for no passphrase):

link

    

Answer 3

Você disse:

as one of those same users

Por isso, estamos falando de mais de um usuário .

Se eu estiver correto, o que parece estar acontecendo é isso:

• você faz logon em A como usuário foo
• o usuário bar na máquina B tem em B:/home/bar/.ssh/authorized_keys a chave pública de foo , cuja identidade está em A:/home/foo/.ssh/identity.rsa .
• então é claro que foo de A pode emitir ssh bar@B e fazer com que funcione sem senha .

Agora, se o usuário bar da máquina C efetuar logon na máquina A como ele mesmo ("um desses usuários"), ou seja, como bar , ele se tornará bar@A ; não foo@A . E quando ele tentar logar como bar@B , a chave de identidade recuperada por ssh para realizar o login será bar 's; não é A: / home / foo /. ssh / identity.rsa, mas A: / home / barra /. ssh / identity.rsa. E talvez esse arquivo esteja bloqueado por uma frase secreta.

Então, verifique seus usuários e quais identidades eles estão usando.

    

Answer 4

Gere a chave sem uma frase secreta ou crie um script especial que leia a frase secreta do terminal atual usando SSH_ASKPASS variable. Isso é particularmente útil ao chamar o ssh-add de um script relacionado. Por exemplo:

install -vm700 <(echo "echo 'my_passphrase'") $HOME/.ps
cat /path/id_rsa | ssh-add DISPLAY= SSH_ASKPASS=$HOME/.ps -

Notas:

• Criar o script .ps é apenas um trabalho único, o restante pode ser adicionado aos seus arquivos rc .
• Não funcionará se ssh tiver um terminal associado ou DISPLAY estiver definido.
• Caso seu agente ssh não esteja em execução, se não - execute: eval "$(ssh-agent -s)"