☰

일반 사용자가 읽을 수 없는 개인 키를 사용하여 SSH를 수행하도록 허용

tag-icon • tag-icon ssh security key-authentication privileges
일반 사용자가 읽을 수 없는 개인 키를 사용하여 SSH를 수행하도록 허용

머신당 하나의 계정(지원 액세스 계정)만 사용하여 소수의 사람들(지원이라고 함)만 SSH를 통해 액세스할 수 있도록 허용하는 머신 세트(여기서는 고객 머신이라고 함)가 있다고 가정해 보겠습니다.

지원 직원은 고객의 컴퓨터에 로그인하는 데에만 키를 사용할 수 있습니다. 또한 지원 직원이 발전하여 지원 직원을 떠나는 사람은 고객 컴퓨터에 로그인할 수 없습니다. 따라서 직원은 고객 컴퓨터에 로그인하는 데 사용되는 개인 키를 읽는 것이 금지되어 있습니다. 또한 authorized_keys클라이언트 컴퓨터의 파일을 수정하는 것도 금지됩니다.

이 구성을 구현하기 위해 지원 담당자가 로그인하고(LDAP 인증을 사용하지만 이는 또 다른 질문임) 개인 키를 포함하는 SSH 에이전트를 사용하는 것을 생각했습니다.

문제는 지원팀이 SSH 개인 키를 읽지 않고도 사용하도록 허용하려면 어떻게 해야 합니까?

사용자의 요청을 수락하고 SSH 세션을 열 수 있는 에이전트 시스템에서 루트로 실행되는 데몬을 만들어야 한다고 생각하지만 어떻게 해야 할지 모르겠습니다. 어떤 아이디어가 있나요?

답변1

실제로 원하는 것은 SSH CA를 사용하고 각 지원 담당자가 사용하는 키에 서명하고(여권과 같은 자체 SSH 키가 있어야 함) TrustedUserCAKeys /etc/ssh/users_ca.pub/etc/ssh/sshd_config.conf SSH CA를 사용하도록 클라이언트 서버를 구성하는 것입니다. 에서 키에 서명합니다. 이렇게 하면 서버는 CA 키(액세스 권한이 있는)로 서명된 모든 키를 수락하고 인증된 키를 건드리지 않고도 더 이상 지원되지 않는 사람들의 키를 취소할 수 있습니다.

"ssh ca"를 빠르게 검색하면 이 튜토리얼을 찾을 수 있습니다.https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu("사용자 키 구성 방법"까지 아래로 스크롤) - 튜토리얼에서 Ubuntu가 언급되어 있지만 배포에 독립적이지만 SSH CA를 지원하는 최신 버전의 OpenSSH가 필요합니다.

이 주제에 대한 또 다른 좋은 블로그 게시물은 다음과 같습니다.https://ef.gy/hardening-ssh("SSH 인증서"까지 아래로 스크롤합니다).

특히 제한된 시간 동안 유효한 키에 서명할 수 있으므로 키가 자동으로 만료된다는 점에 유의하세요!

답변2

몇 가지 옵션을 제안하겠습니다.

  1. sudoSSH 키를 보호하고 지원팀에 이를 사용하도록 요청하세요. 래퍼를 사용하면 이 작업을 투명하게 수행할 수 있습니다. 예를 들어 래퍼를 호출하여 /usr/local/bin/ssh-support다음과 같은 내용을 포함하게 합니다(테스트되지 않음). 

    #!/bin/bash
export PATH=/usr/local/bin:/usr/bin:/bin
export IFS=$' \t\n'
export SUSER=ssupport

# Restart if not running under sudo
test "X$1" != 'X-S' && exec sudo -u "$SUSER" /usr/local/bin/ssh-support -S "$@"
shift
export SHOME="$(getent passwd "$SUSER" | cut -d: -f6)"

# Extract single argument as hostname LABEL and validate that we have
# an RSA private key for it. The target username, real hostname, port,
# etc. can be defined in ~/.ssh/config for the user $SUSER (ssupport)
label="$1"
idfile="$SUSER/.ssh/id_rsa_for_$label"
cgfile="$SUSER/.ssh/config"

ok=true
[[ "$label" =~ '/' ]] && { echo "Invalid label: $label" >&2; ok=; }
[[ ! -s "$idfile" ]] && { echo "Missing identity file: $idfile" >&2; ok=; }
[[ ! -s "$cgfile" ]] && { echo "Missing configuration file: $cgfile" >&2; ok=; }

if test -n "$ok"
then
    logger -t ssh-support "$SUDO_USER requested ssh to $label"
    exec ssh -i "$idfile" -F "$cgfile" "$label"
fi
exit 1

    그룹의 사용자가 도구를 사용할 sudoers수 있도록 하려면 파일에 항목이 필요합니다 . 이 명령을 사용하면 support사용자로 ssh-support도구 를 실행할 수 있습니다 ssupport. 해당 사용자를 생성해야 합니다. 그것확실히루트 권한을 부여하십시오.

    %support ALL = (ssupport) /usr/local/bin/ssh-support

    도구를 실행하기 위해 사용자가 자신의 비밀번호를 제공할 필요가 없도록 지원한다면( sudo스크립트 자체 내 호출에서 필요함) sudoers다음과 같이 정의를 수정할 수 있습니다.

    %support ALL = (ssupport) NOPASSWD: /usr/local/bin/ssh-support

    PATH포함되어 있다고 가정하면 /usr/local/bin/를 사용하여 호출합니다 ssh-support clientname. 또한 인증서 쌍을 사용하여 사용자를 생성했으며 ssupport대상 시스템에 대한 사용자, 호스트, 포트 등을 정의하는 호스트 항목이 있다고 가정합니다. X11 전달, 포트 전달 등을 명시적으로 비활성화할 수 있습니다. 평소와 마찬가지로 디렉토리는 권한으로 보호되어야 합니다./home/ssupport/home/ssupport/.ssh/id_rsa_clientname/home/ssupport/.ssh/id_rsa_clientname.pub/home/ssupport/.ssh/configclientname/home/ssupport/.ssh0700

  2. 각 지원 구성원에게 자신의 로컬 사용자 계정을 제공하고 각자 자신의 개인 SSH 키를 사용하여 클라이언트 서버에 액세스하도록 하십시오. 누군가 지원 그룹을 떠나면 클라이언트 서버에서 해당 SSH 키를 삭제합니다. 이는 더 이상 직원이 SSH 개인 키를 알지 못하도록 걱정할 필요가 없음을 의미합니다.

답변3

sudo 또는 setuid 실행 파일을 통해 호출되는 ssh 래퍼 스크립트와 관련된 몇 가지 다른 답변이 있습니다(특수 목적의 경우).루트가 아닌계정). ~처럼nkms 라고, 모든 매개변수를 ssh에 전달하면 사용자는 보호하려는 SSH 키를 사용하여 임의의 작업을 수행할 수 있습니다. 일부 사람들이 제안하는 또 다른 극단적인 방법은 호스트 이름만 허용하는 것입니다.

OP는 관리자가 콘텐츠를 업로드할 수 있어야 한다고 말합니다.

SSH 래퍼에는 두 가지 다른 고정 매개변수가 있을 수 있습니다. 하나는 로그인 셸용이고 다른 하나는 scp용입니다. 호스트 이름(및 업로드할 파일 이름) 외에는 사용자가 제공하는 매개변수가 없습니다.

getopt또는 자체적으로 매우 제한된 옵션 세트를 구문 분석하고 대부분 고정된 SSH 명령에 콘텐츠를 삽입하는 래퍼 스크립트입니다 . 인식할 수 없는 옵션을 무시(또는 오류)하는 것이 올바른 접근 방식입니다.

"위험한" SSH 옵션을 필터링하려고 하지 말고 대화형 로그인이나 파일 업로드(로컬 및 원격 파일 이름)라는 두 가지 작업을 수행하는 래퍼를 작성하세요. 내 생각에는 아직 거기에서 소독 작업을 좀 해야 할 것 같아요.

사실, 이것은 여전히 ​​실수하기가 매우 쉽습니다. 사용자가 SSH 키를 보유한 파일을 로컬 파일로 제공하지 못하도록 하는 방법을 찾아야 합니다. 그래서 아무것도 허용하지 않는 것부터 시작하기보다는 여전히 금지해야 할 모든 것을 생각하려고 노력하고 있습니다. 먼저 파일 이름에 @또는 가 포함되어 있지 않은지 확인하십시오 :.

답변4

지원 직원은 항상 이 에이전트 시스템을 통해서만 연결되므로 고객은 간단히HostbasedAuthentication을 사용하여 프록시 컴퓨터 인증.

에이전트 시스템이 있고 supporters.pc지원을 제공한다고 가정customer.pc

클라이언트.PC가질 것이다호스트 기반 인증은존재하다 /etc/ssh/ssd_config,서포터.pc에 나열되어 /etc/ssh/shosts.equiv있으며 공개 키는 에 있습니다 /etc/ssh/ssh_known_hosts.

지원 담당자가 로그인할 때[이메일 보호됨], 실행하면 ssh customer.pc다음이 생성됩니다.ssh-keysign(8)(uid를 설정해야 함) 읽을 수 없는 파일을 사용하여 키 서명을 처리하고 실제로 연결이 이루어지고 있다는 증거를 support.pc에 제공합니다.서포터.pc. ~처럼클라이언트.PC신뢰하다서포터.pc, 귀하의 직원은 다음으로 로그인되어 있습니다지원하다.

관련 정보