다음 시나리오를 고려하십시오.
나는 'common' 사용자로 serverA에 로그온했습니다. 핵심은흔한 사용자는 많은 사람들이 이에 액세스할 수 있다는 점입니다. 이는 설계상 제한이 없고 안전하지 않습니다.
예를 들어, 이 사용자/서버에서 정기적으로 로그인해야 한다고 가정해 보겠습니다.서버B사용자로서안전한- 즉, 소유한 scp 파일이 필요합니다.보안@서버B.
내가 모든 것에 접근하고 통제할 수 있는 동안안전한사용자, 나는 확실히 추가하고 싶지 않습니다흔한의 공개 키를 신뢰할 수 있는 키로안전한사용자 - 다음으로 로그인할 수 있는 사람을 원하지 않습니다.흔한다음으로 로그인할 수 있도록안전한또한.
나도 입력하고 싶지 않아안전한의 비밀번호는 시간당 5번입니다. 이상적으로는 한 번만 입력하고 에이전트에게 마법처럼 기억하게 하고(단, 이 로그인 세션에 대해서만) 제한 시간이 만료될 때까지 이 세션에서 연결할 때마다 사용하고 싶습니다. 실제로 는 다르지 않습니다 kinit.
이 목표를 달성할 수 있는 것이 있습니까?
답변1
중간 서버에 공유 사용자가 있고 해당 사용자가 기본적으로 서로의 세션에서 액세스할 수 있는 거의 모든 것에 대해 셸 액세스 권한을 갖고 있는 경우에는 쉽지 않습니다.
물론 최신 커널에도 방법이 있습니다.
커널에 개인 데이터를 저장하기 위해 세션(프로세스/스레드) 키링을 활용하는 도구가 있을 수도 있고, 시스템이 동일한 사용자의 서로 다른 프로세스가 서로 액세스하는 것을 허용하지 않을 만큼 충분히 안전하여 프로그램이 인증 정보는 다른 세션으로부터 보호되는 일반 사용자 공간 메모리에도 있습니다. 어쨌든 둘 다 기본 사용에 적합한 일부 PID/SID 정보를 기반으로 인증 수행 요청을 식별해야 했습니다. 마지막에는 sshpass 도구 등을 사용하여 사용할 수 있도록 세션 설정을 수행하거나 저장된 비밀번호를 프로세스에 전달하는 데몬이 필요합니다.
또 다른 접근 방식은 네임스페이스를 활용하고 개인용 tmpfs 또는 tmpdir을 마운트하는 것입니다(tmpfs는 tmpdir보다 더 잘 보호되거나 최소한 루트 사용자의 액세스가 덜 쉽습니다).
해당 사용자에 대한 네임스페이스 환경을 설정하는 래퍼가 있는 별도의 포트에서 sshd를 사용하거나 최소한 최신 시스템에서 가장 쉽게 사용할 수 있습니다. pam 및 pam_namespace.so를 사용하여 개인 사용자 tmpdir 또는 tmpfs를 설정할 수 있습니다. 거기에서 sshpass 등에서 사용할 수 있도록 비밀번호를 일반 텍스트로 저장할 수 있습니다. 또는 더 나은 방법으로는 ssh-agent용 소켓을 해당 디렉토리에 넣고 개인 개인 키를 해당 에이전트에 로드하는 동시에 에이전트에 대한 액세스가 다른 사람의 액세스로부터 보호되도록 할 수 있습니다. 동일한 사용자의 다른 세션. 강력한 비밀번호를 가진 개인 키가 있는 경우 이를 컴퓨터에 저장할 수도 있습니다. 그렇지 않으면 전송해야 했습니다. 전체 /tmp 디렉토리를 개인 디렉토리(일부 하위 디렉토리가 공유될 수도 있음)로 만들고 매우 안전한 방식으로 SSH 에이전트 전달을 활용할 수도 있습니다(루트 사용자가 이를 남용하지 않도록 실제로 보호할 수는 없지만 적어도 tmpfs를 사용하는 경우). 루트에게는 어렵고 일반 사용자가 Auth-Sock을 사용하는 것은 불가능합니다.
어쨌든 서버를 충분히 구성할 수 있어야 합니다. 또는 적어도 사용자 프로세스가 서로 연결할 수 없는 정도까지 구성해야 합니다.
답변2
아마도 당신은 찾고있을 것입니다ssh-agent, OpenSSH와 함께 제공됩니다. 이 옵션을 사용하여 -t시간 초과를 설정하세요.