항상 apt-get수동으로 서버에서 실행 하는 경우 ( apt-get크론에서 자동 명령을 실행 하지 않음 ) ssh 에이전트 전달 사용을 고려할 수 있습니다 . 이렇게하면 관리하는 서버 당 하나의 공개 / 개인 키 쌍을 관리 할 필요가 없으며 모든 서버에 개인 키를 두는 것보다 안전합니다.

초기 구성
-관리하려는 서버에 연결하고 다음과 같이 추가하십시오 /etc/apt/sources.list(이 예에서는 서버가 manager계정 에 연결되기를 원한다고 가정 ).

    deb ssh://manager@my.repository.org/path other stuff

• johndoe예를 들어 로그인 을 사용하여 자신의 컴퓨터에 개인 / 공개 키 쌍을 만듭니다 (컴퓨터가 데비안에서 실행되는 경우 : 그렇지 않은 경우 관리 전용 데비안 서버에서이 작업을 수행 할 수 있음).

  ssh-keygen
  

• 강력한 키 프레이즈로 보호되는지 확인하십시오

• 다음 위치에서 공개 키를 저장소 서버에 복사하십시오 /home/manager/.ssh/authorized_keys.

  ssh-copy-id manager@my.repository.org
  

관리 세션 당 한 번

• 다음을 입력하여 머신에서 ssh 에이전트를 시작하십시오.

  eval `ssh-agent`
  

• 에이전트에 키를 추가하십시오 (암호가 필요함).

  ssh-add
  

서버 관리

• 를 사용하여 관리하려는 서버에 연결합니다 ssh -A( -A에이전트 전달 활성화).

  ssh -A some.server.org
  

• 루트로 전환하십시오 (사용 sudo하려면 에이전트 전달 을 구성해야합니다. /etc/sudoers그렇지 않으면 sudo에이전트 전달을 중단 하십시오 ).

  su
  

• 이제 에이전트 전달 덕분에 비밀번호를 다시 입력하지 않고 ssh를 사용하여 저장소의 관리자 계정에 연결할 수 있습니다. 따라서 apt-get제대로 작동해야합니다.

  apt-get udate
  

관리 세션 종료

• 서버 관리가 끝나면 에이전트에서 키를 제거하십시오.

  ssh-add -D
  

장점

• 초기 구성이 많이 필요하지 않습니다
• 하나의 개인 키만 필요
• 개인 키는 강력한 암호로 보호됩니다
• 누군가 서버 중 하나에 대한 루트 액세스 권한을 얻는 경우 리포지토리 서버에 즉시 액세스 할 수 없습니다.
  • 해커가 참을성 있고 자격이 있다면 에이전트 전달을 사용하여 서버에 연결할 때까지 기다릴 수 있으며, 저장소 서버에 액세스하기 위해 전달 메커니즘을 가로 챌 수 있습니다.
  • 이를 방지 ssh-ask하기 위해 키를 사용하려는 모든 시도를 수락 / 거부하기 위해 사용할 수 있습니다.
  • 어떤 경우, 해커는 것 없는 그는 단지하기 위해 전달 메커니즘을 납치 할 수있을 것입니다 : 개인 키 자체에 액세스 사용 키를, 만 시간 동안 해당 서버에 연결되어 있습니다.

답변