호스트에서비다양한 다른 호스트에 SSH를 통해 연결할 수 있습니다(CD) 공개 키를 해당 Authorized_keys 파일(호스트 C 및 D에 있음)에 넣었으므로 비밀번호를 사용하지 않았습니다.
호스트에서ㅏSSH 호스트를 사용할 수 있습니다비(을 통해비밀번호입증). 그러나 일단 호스트에 로그인하면비나매번 내 키를 인증해야 해C와 D에 연결할 때(원칙적으로는 그렇지 않더라도).
요약하자면, 호스트 B(예: 사무실)에 직접 연결하는 경우 C 또는 D에 연결하기 위해 비밀번호를 입력할 필요가 없습니다. A(예: 집)에 연결한 다음 AI에서 B에 연결하면 일단 로그인하면 됩니다. BI는 D 또는 C에 연결하려면 비밀번호가 필요합니다. ssh-agent에 비밀번호를 추가하면(ssh-add 사용) 문제를 부분적으로 해결할 수 있지만 BI에서 새 셸을 열 때마다 이 작업을 다시 수행해야 합니다.
업데이트
유용한 댓글 덕분에 문제는 다음과 같은 것으로 나타났습니다. B에 직접 연결하면 키링 프로그램이 실행됩니다(내 특별한 경우에는 해마입니다). 따라서 암호화된 모든 개인 키의 비밀번호는 자동으로 사용될 수 있습니다. A에서 B에 연결하면 이런 일이 발생하지 않습니다. 알 수 없는 이유로 A에서 B로 원격 세션(vnc/remmina)을 시작해도 해마 프로그램이 B에서 활성화되지 않으므로 수동으로 비밀번호를 계속해서 입력해야 합니다.
설치했습니다열쇠고리문제가 해결되었습니다.
그러나 특정 서버에 대한 SSH 연결에만 사용되는 개인 키를 암호화할 가치가 있는지 잘 모르겠습니다.개인 키를 암호화하지 않으면 구체적인 보안 위험이 있습니까?원칙적으로 개인 키에 접근할 수 있으면 키체인에 저장된 비밀번호도 사용할 수 있으므로 개인 키를 암호화해도 큰 이점은 없을 것 같습니다.
답변1
keychainSSH 키의 암호 문구 저장소 역할을 하는 를 사용하여 문제의 일부를 해결했습니다 . 다른 질문에 관해서는:
그러나 특정 서버에 대한 SSH 연결에만 사용되는 개인 키를 암호화할 가치가 있는지 잘 모르겠습니다. 개인 키를 암호화하지 않으면 구체적인 보안 위험이 있습니까? 원칙적으로 개인 키에 접근할 수 있으면 키체인에 저장된 비밀번호도 사용할 수 있으므로 개인 키를 암호화해도 큰 이점은 없을 것 같습니다.
개인 키가 암호화되지 않은 상태로 남아 있는 것이 아니라 암호로 보호되지 않는다는 것입니다. 따라서 홈 디렉터리의 디렉터리에 액세스할 수 있는 사람은 누구나 .ssh문제 없이 SSH 키를 제어할 수 있습니다.
완전히 제어할 수 있는 시스템에 이러한 키를 남겨 두는 것이 편하다면 암호 없이 그대로 두는 데 아무런 문제가 없다고 생각합니다. 또한 이와 같은 보조 시스템에 남길 수 있는 다른 키 세트 또는 이 서버에만 사용할 수 있는 고유한 세트를 생성하여 손상된 것을 발견한 경우 큰 문제 없이 완전히 버릴 수 있도록 권장합니다.
키를 관리하는 데 사용하는 경우 SSH 키를 관리하는 데 keychain사용하는 경우 SSH 키에 암호 문구를 사용하면 얻을 수 있는 것이 많지 않습니다. 단 , SSH 키를 사용할 때만 저장한다는 점만 제외하면 됩니다. 키를 자주 사용하지 않고 작업을 마친 후 부지런히 정리한다면 암호가 유리할 수 있지만 IMO에서는 작은 것입니다.keychainkeychainkeychain