비밀번호를 스크립트에 전달

내 개인 키 파일이 손상될 수 있기 때문에 비밀번호 없는 SSH를 사용하고 싶지 않습니다. 이는 더욱 악화됩니다.

아니요, 이것은 잘못된 것입니다. 개인 키 파일은 비밀번호보다 더 강력한 보안을 제공합니다. 개인 키 파일을 사용하십시오. 개인 키 파일은 비밀번호로 암호화됩니다. 누군가가 키 파일을 획득하더라도 여전히 비밀번호가 필요합니다. 비밀번호 인증을 사용하면 비밀번호를 아는 사람은 누구나 빠져나갈 수 있습니다.

ssh-agent세션 중에 실행됩니다. 특정 키를 사용하기 전에 비밀번호를 입력하십시오 ssh-add(또는 일부 GUI에서 프롬프트가 표시됨). 이렇게 하면 이 키를 사용하여 연결할 때 메시지가 나타나지 않습니다.

하나의 비밀번호를 사용하여 원격 시스템에서 명령을 복사하고, ssh하고, 실행할 수 있는 방법이 있습니까?

두 가지 접근 방식이 있으며 각각 서로 다른 편의성과 장단점이 있습니다.

하나는 파일을 인라인으로 전송하는 것입니다. 파일 내용 이상의 입력이 필요합니까? 그렇지 않다면 ssh example.com 'cat > the_file ; process the_file' < the_file원하는 대로 작동할 것입니다.

또 다른 방법은 SSH 연결을 재사용하는 작업을 수행하는 것입니다. ControlMaster그리고 SSH 친구가 도움이 될 수 있습니다. ssh_config(1)자세한 내용을 보거나 도움이 될 수 있는 다양한 프로그래밍 언어로 된 SSH 구현 또는 다양한 래퍼가 있습니다.

또한 비밀번호를 입력하기 위해 사용자와의 상호 작용이 필요한 스크립트를 어떻게 작성합니까?

TTY에서 읽습니다. 일반적으로 가장 좋은 전략은 ssh가 방해받지 않고 사용자와 직접 상호 작용할 수 있도록 허용하는 것입니다. 이러한 방식으로 상호 작용하기 위한 구현은 더 잘 테스트되고 입증되었기 때문입니다.

안전하지 않기 때문에 읽기를 사용하고 싶지 않습니다.

사용자 상호작용을 위한 것이라고 생각합니다. 현실적으로 보안 관점에서 이는 SSH가 요청하도록 하는 것과 근본적으로 다르지 않지만 방해하지 않는 것이 가장 좋습니다.

내 개인 키 파일이 손상될 수 있기 때문에 비밀번호 없는 SSH를 사용하고 싶지 않습니다. 이는 더욱 악화됩니다.

...그리고 같은 이유로 SSH 프록시는 허용되지 않는다고 생각합니다.

요구사항을 표현하기 위해 "expect"를 사용하는 것이 가능하며, 일부 사람들은 여전히 ​​이를 사용합니다. Expect 스크립트는 명령 출력을 "캡처"할 수 있으며 출력을 기반으로 "응답"할 수 있습니다. 스크립트는 다음과 같습니다.

spawn scp some_file user@host:/destination
expect "*?assword:*"
send -- "Your Super Secret Password Here\r"
send -- "\r"

물론 이것은 효과가 있지만 또 다른 문제를 야기합니다. 귀하의 비밀번호는 일반 텍스트로 저장되며 이 파일을 읽는 모든 사람에게 공개됩니다.

내 개인적인 의견은 가장 안전한 비대화형 방법은 개인 키 인증이라는 것입니다.

키를 사용할 수 있지만 ssh셸이 실제 셸이 아닌 실행하려는 명령으로 설정되어 있는 원격 시스템의 사용자 지정 사용자에게 키를 할당합니다. 결과적으로 로그인하면 명령이 실행되고 터미널이 닫힙니다. 따라서 비밀번호가 손상되면 대화형으로 명령을 입력할 수 없고 일련의 명령만 셸로 실행할 수 있습니다.