다음 시나리오를 이해하려고 노력하고 있습니다.
서버도 있고 A서버도 있고B
서버는 SSH 키 메커니즘을 통해 A파일을 서버에 푸시합니다 .B
서버가 B서버에 푸시된 파일을 받으면 A서버에 푸시된 파일에 대해 어떤 사용자 ID가 표시됩니까 B?
B서버가 특정 userId를 사용하여 A서버에 파일을 푸시하는 것만 허용할 수 있습니까 ? 그렇다면 어떻게 달성할 수 있나요?
리눅스에서는 이 논리를 모릅니다.
공유해주세요.
업데이트: B서버의 userID 이름은 이며 서버 에서도 동일한 userID를 사용하기를 serverB원합니다 . 가능합니까?AserverB
답변1
서버 B는 서버 A가 특정 userId를 사용하여 파일을 푸시하도록 허용합니다. 이것이 가능합니까? 그렇다면 어떻게 달성할 수 있나요?
SSH 키 인증을 설정할 때마다 이 작업을 수행합니다.특정 사용자에 대해대상 서버에서. 개인 키를 안전하게 보관하는 것은 소스에서 사용자의 책임입니다. 또는 authorized_keys사용자가 키를 분실한 경우 대상 서버의 관리자에게 문의하여 해당 파일에서 공개 키를 제거해야 합니다.
연결 양쪽 끝에 있는 UID 번호나 사용자 이름은 일치할 필요가 없습니다. 이론적으로 SSH 클라이언트는 내장형 시스템에 있을 수 있으며 사용자 계정에 대한 개념이 전혀 없을 수도 있습니다.
여러 연결에 동일한 키 쌍을 사용하거나 각 연결에 별도의 키 쌍을 사용하거나 그 사이의 조합을 사용할 수 있습니다. 기술적으로 동일한 공개 키를 서버 B의 모든 사용자 계정에 추가하면 해당 개인 키를 보유한 사용자가 서버 B의 모든 사용자로 로그인할 수 있지만 이는 일반적으로 매우 어리석은 일입니다.
(서버 B에 안타까운 일이 발생할 때마다 다른 모든 사용자는 "내가 아니라 내 계정으로 로그인한 마스터 키 소유자였나 봐요."라고 말할 수 있습니다. 그러면 비난이 전가됩니다.)
기본적으로 SSH 키 쌍의 개인 키를 가진 사람은 누구나 서버의 계정에 로그인할 수 있으며, 이는 동일한 키 쌍의 공개 부분을 사용자 계정 authorized_keys파일에 추가합니다.연결이 어디에서 왔는지, 키 보유자가 연결의 반대편에 있다고 주장하는지에 관계없이.
authorized_keys파일에 추가 제약 조건을 설정할 수 있습니다 . 특정 IP 주소나 호스트 이름에서 연결이 올 때나 IP나 호스트 이름의 와일드카드 패턴을 기반으로 하는 경우에만 키 인증이 작동하도록 제한할 수 있습니다. 자세한 내용은 AUTHORIZED_KEYS FILE FORMAT시스템에 대한 단락을 참조하세요 man sshd. 버전에 따라 사용 가능한 정확한 옵션이 다를 수 있습니다 sshd.
일반적으로 클라이언트 사용자 이름으로 제한하는 것은 의미가 없습니다. 서버는 일반적으로 SSH 클라이언트에 요청하는 것보다 해당 사용자 이름을 찾는 더 좋은 방법이 없으며 클라이언트가 해킹되어 이에 대해 거짓말을 할 수 있기 때문입니다. 사용자가 자신의 개인 키가 잘못된 손에 들어가도록 허용하지 않는 한, 성공적인 키 기반 인증은 사용자가 대상 서버에서 해당 특정 계정을 사용할 권한이 있다는 강력한 증거입니다.
따라서 귀하의 경우 서버가 serverA서버에 푸시 파일을 사용하고 명령이 사용자로 실행되면 명령은 기본 로그인을 통해 파일을 서버로 전송하려고 시도합니다.serverBscp /some/files B:/some/directoryuserAscpuserAserverB
기본값은 명령에 대상 사용자 이름을 지정하여 변경할 수 있습니다. scp /some/files userB@serverB:/some/directory로그인하면 파일이 전송됩니다.userBserverB
대상 사용자 이름은 SSH 클라이언트 구성 파일에서 지정할 수도 있습니다. userA의 파일에 해당 구성이 있는 경우 에서 명령을 실행할 때와 같이 로그인하여 파일도 전송됩니다.~/.ssh/configserverAscp /some/files serverB:/some/directoryserverBuserBuserAserverA
Host serverB
User userB