scp(1)을 사용하여 한 호스트에서 다른 호스트로 파일을 복사하는 실행 중인 시스템이 있습니다. 시스템이 일련의 파일을 처리하고 있지만 그 중 하나에서 멈췄습니다. 즉, 어제 scp 명령을 시작했는데 오늘날에도 계속 실행되고 있습니다.
strace를 실행하면 scp가 ssh 하위 프로세스의 stdout에 연결된 파이프 파일을 읽기를 기다리고 있음을 알 수 있습니다. 즉, 이 하위 프로세스는 fd 4를 읽기를 기다리고 있습니다 /dev/tty.
known_hostsSSH 대상의 호스트 키가 소스 호스트의 호스트 키와 충돌합니다. 오랫동안 실행되는 SCP 시작을 만지작거렸습니다. 이제 known_hosts모든 것이 설정되었으므로 아무 메시지도 표시하지 않고 소스에서 모든 대상으로 SSH를 연결할 수 있습니다.
내 가정은 ssh작은 타이밍 창이 발생했고 사용자에게 알 수 없는 호스트 키가 표시되었으며 확인( "yes\n")이 계속되기를 기다리고 있다는 것입니다.
사용자가 입력한 것처럼 read호출이 작동 하도록 하는 방법이 있습니까 (만약 그렇다면 어떻게)?sshyes
echo foobar > /dev/tty내가 xterm (다른 컴퓨터)에 있을 때 foobar내 콘솔에 씁니다. 당연히 echo foobar > /proc/<pid>/fd/4I 가 에 대한 심볼릭 링크인 경우에도 동일한 결과가 발생합니다 /dev/tty. 그렇다면 ssh에 어떻게 입력을 받나요?
내 가설을 테스트하거나 다르게 작동시키는 방법을 아는 사람이 있다면 ssh그 이야기도 듣고 싶습니다.
답변1
작성할 때 프로세스 ID를 고려하지 마십시오 /dev/tty. 이렇게 하면 성공할 수 없습니다.
똑같긴 하지만장비, 프로세스는 특정 장치에서 다른 파일 설명자를 엽니다. Linux의 경우 프로세스 ID(/proc/)를 알고 있으면 개별 파일 설명자를 조작할 수 있습니다.PID/fd/0은 ID가 있는 프로세스의 표준 입력입니다.PID.
귀하의 경우, 프로그램은 장치를 열고 해당 파일 설명자는 /proc/에도 있습니다.PID/fd (그러나 확실하지 않음). 응용프로그램은 이 디렉토리에 있는 기호 링크 정보를 "보고" 작동할 수 있습니다.
자세히 보면 /proc/에 있는 항목들은PID/fd는 모두 다른 inode 값을 갖습니다(파일 설명자가 다르기 때문입니다). proc/의 항목을 에코합니다.PID/fd는 파일 설명자를 에코한다는 의미입니다.
그러나 ssh는 해당 방향의 입력을 기대하지 않으며 보충 힌트를 제공하지 않습니다. 사용 중인 해결 방법이 아마도 최선일 것입니다.
답변2
자주 다시 설치되는(따라서 새 호스트 키 생성) 임베디드 시스템을 사용할 때 이 문제를 피했습니다. 새로운 호스트 키를 맹목적으로 받아들이고 싶다면 그렇게 할 수 있지만, 이 점에 유의하세요.상대방을 사칭하는 것에 대한 방어 수단을 제거하세요.. 잘 제어되는 네트워크에서 위험도가 낮은 작업에 적합할 수 있지만 공용 인터넷에서는 사용하지 않는 것이 좋습니다!
문제의 호스트에 대해 ssh write가 새 호스트 키를 자동으로 수락하도록 하고 대신 작성하십시오 /dev/null.
Host h
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
SSH에는 절대 확인하지 않는 옵션이 없는 것 같습니다 known_hosts.
귀하의 질문에 있는 문제가 호스트 키가 클라이언트에 전혀 알려지지 않았다는 것이라면(알고 있었지만 지금 변경된 것과는 반대로) -o StrictHostKeyChecking=noSSH 명령줄에 추가하는 것으로 충분합니다.
다시 말하면,보안 축소를 수락한 경우에만 이 작업을 수행하십시오.. 나는 당신이 yes대화식 SSH가 무조건 응답하기를 원한다고 말했듯이 이것을 수행한다고 가정합니다 .