Alimente a entrada para um / dev / tty para fazer o ssh prosseguir

Question

Eu tenho um sistema em execução que usa scp (1) para copiar arquivos de um host para outro. O sistema está trabalhando em uma sequência de arquivos, mas ficou preso em um deles: isto é, iniciou um comando scp ontem que ainda está em execução hoje.

Correndo strace sugere que scp está esperando para ler em um arquivo pipe, que está conectado ao stdout do seu processo filho ssh; esta criança está esperando para ler no fd 4, que é /dev/tty .

Um destino ssh tinha uma chave de host que estava em conflito com known_hosts no host de origem. Eu brinquei com isso na época em que o scp de longa duração era iniciado; agora o known_hosts está todo configurado como deveria, e eu posso ssh da origem para todos os destinos sem ser solicitado por nada.

Minha hipótese é que ssh atingiu uma pequena janela de tempo e apresentou ao usuário uma chave de host desconhecida e está aguardando a confirmação ( "yes\n" ) para avançar.

Existe alguma maneira de fazer a chamada read feita por ssh se comportar como se o usuário digitasse yes (e se sim, como)?

Quando (em outra máquina) eu echo foobar > /dev/tty em um xterm, ele escreve foobar no meu console. O mesmo resultado acontece, sem surpresa, se eu echo foobar > /proc/<pid>/fd/4 , que é um symlink para /dev/tty . Então, como eu alimentei a entrada em ssh?

Se alguém souber como testar minha hipótese sobre ssh e / ou fazê-lo proceder de maneira diferente, ficarei feliz em saber disso também.

    

Answer 1

Gravar para /dev/tty não leva em conta o id do processo; você não terá sucesso dessa maneira.

Embora seja o mesmo dispositivo , existem diferentes descritores de arquivo que um processo terá aberto em um determinado dispositivo. Para o Linux, você pode manipular os descritores de arquivo separados se souber o id do processo, ou seja, / proc / PID / fd / 0 é a entrada padrão para o processo cujo ID é PID .

Para o seu caso, o programa está abrindo o dispositivo, e seu descritor de arquivo também estaria em / proc / PID / fd (mas não tão bem identificado). Um aplicativo pode "ver" as informações de links simbólicos desse diretório e manipulá-las.

Se você olhar de perto, os itens em / proc / PID / fd têm valores de inode diferentes (porque são descritores de arquivo diferentes). Ecoando para a entrada em proc / PID / fd significa que você está ecoando para esse descritor de arquivo.

Mas o ssh não está esperando informações a partir dessa direção, não tem provisão para prompts suplementares - uma solução alternativa como a que você está usando é provavelmente a melhor que você poderá fazer.

    

Answer 2

Eu evitei esse problema ao trabalhar com sistemas embarcados que eram frequentemente reinstalados (gerando novas chaves de host). Se você quiser aceitar cegamente a nova chave do host, poderá fazê-lo, mas esteja ciente de que isso elimina qualquer defesa contra a representação do outro lado . Pode ser apropriado para ações de baixo risco em uma rede bem controlada, mas não é recomendado para uso na Internet pública!

Para os hosts em questão, faça com que o ssh escreva a aceitação automática da nova chave do host, mas grave-a em /dev/null :

Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no

Parece não haver uma opção para o SSH nunca verificar known_hosts .

Se o problema na questão é que as chaves do host nunca foram conhecidas por esse cliente (em oposição a conhecido, mas agora alterado), então deve ser suficiente adicionar -o StrictHostKeyChecking=no à linha de comando SSH.

Para reiterar, faça isso somente se aceitar a redução na segurança . Estou assumindo que você faz, como você diz que deseja responder incondicionalmente yes ao SSH interativo.