국제 대회 SSH와 sudo의 우승자가 다시 무대에 올랐습니다. 저명한 Active Directory 지휘자가 주도합니다.

역사적으로 sudo 권한은 다음 파일의 내용에 따라 결정되었습니다. /etc/sudoers.d и 시각 장애인, 키 승인은 다음을 사용하여 수행되었습니다. ~/.ssh/authorized_keys. 그러나 인프라가 성장함에 따라 이러한 권한을 중앙에서 관리하려는 욕구가 있습니다. 오늘날에는 여러 가지 솔루션 옵션이 있을 수 있습니다.

• 구성 관리 시스템 - 요리사, 인형, 책임감있는, 소금
• Active Directory의 + SSD
• 스크립트 및 수동 파일 편집 형태의 다양한 왜곡

내 주관적인 의견으로는 중앙 집중식 관리를 위한 최선의 선택은 여전히 ​​조합입니다 Active Directory의 + SSD. 이 접근 방식의 장점은 다음과 같습니다.

• 진정한 단일 중앙 사용자 디렉터리입니다.
• 권리의 분배 sudo는 특정 보안 그룹에 사용자를 추가하는 것입니다.
• 다양한 Linux 시스템의 경우 구성 시스템을 사용할 때 OS를 결정하기 위한 추가 검사를 도입할 필요가 있습니다.

오늘의 스위트는 특히 연결에 전념할 것입니다 Active Directory의 + SSD 권리 관리를 위해 sudo는 그리고 저장 SSH 단일 저장소의 키.
그래서 홀은 긴장된 침묵 속에 얼어붙었고 지휘자는 지휘봉을 들었고 오케스트라는 준비를 마쳤습니다.
어서.

감안할 때 :
— Active Directory 도메인 testopf.local 윈도우 서버 2012 R2에서.
— Centos 7을 실행하는 Linux 호스트
— 다음을 사용하여 구성된 인증 SSD
두 솔루션 모두 스키마를 변경합니다. Active Directory의, 따라서 테스트 환경에서 모든 것을 확인한 다음 작업 인프라를 변경합니다. 모든 변경 사항은 대상으로 지정되었으며 실제로 필요한 속성과 클래스만 추가되었다는 점을 말씀드리고 싶습니다.

작업 1: 제어 sudo는 역할을 통해 Active Directory의.

회로를 확장하려면 Active Directory의 최신 릴리스를 다운로드해야 합니다 sudo는 — 오늘 기준으로 1.8.27입니다. 압축을 풀고 파일을 복사하세요 스키마.ActiveDirectory ./doc 디렉터리에서 도메인 컨트롤러로. 파일이 복사된 디렉터리의 관리자 권한으로 명령줄에서 다음을 실행합니다.
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(귀하의 값을 대체하는 것을 잊지 마십시오)
오픈 adsiedit.msc 기본 컨텍스트에 연결합니다.
도메인 루트에 디비전 생성 sudoers. (부르주아지는 악마가 이 부대에 있다고 고집스럽게 주장한다. SSD 항목을 검색합니다. sudoRole 사물. 그러나 상세 디버깅을 켜고 로그를 살펴본 결과 디렉토리 트리 전체에 걸쳐 검색이 이루어진 것으로 드러났습니다.)
Division의 클래스에 속하는 첫 번째 개체를 만듭니다. sudoRole. 이름은 편리한 식별을 위해서만 사용되므로 임의로 선택할 수 있습니다.
스키마 확장에서 사용 가능한 속성 중 주요 속성은 다음과 같습니다.

• sudo명령 — 호스트에서 실행이 허용되는 명령을 결정합니다.
• sudoHost — 이 역할이 적용되는 호스트를 결정합니다. 다음과 같이 지정할 수 있습니다. 모든, 개별 호스트의 경우 이름으로 표시됩니다. 마스크를 사용하는 것도 가능합니다.
• sudo사용자 — 실행이 허용된 사용자를 나타냅니다. sudo는.
  보안 그룹을 지정하는 경우 이름 시작 부분에 "%" 기호를 추가합니다. 그룹명에 공백이 있어도 걱정하지 않으셔도 됩니다. 로그에 따르면 공간을 탈출하는 작업은 메커니즘에 의해 인계됩니다. SSD.

그림 1. 디렉토리 루트에 있는 sudoers 하위 부문의 sudoRole 객체

그림 2. sudoRole 객체에 지정된 보안 그룹의 멤버십.

다음 설정은 Linux 측에서 수행됩니다.
파일에서 /etc/nsswitch.conf 파일 끝에 줄을 추가하십시오.

sudoers: files sss

파일에서 /etc/sssd/sssd.conf 섹션에서 [SSD] 서비스에 추가 sudo는

cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo

모든 작업이 끝나면 SSD 데몬 캐시를 지워야 합니다. 자동 업데이트는 6시간마다 이루어지는데, 지금 원할 때 왜 그렇게 오래 기다려야 합니까?

sss_cache -E

캐시를 지워도 도움이 되지 않는 경우가 종종 있습니다. 그런 다음 서비스를 중지하고 데이터베이스를 정리한 후 서비스를 시작합니다.

service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start

첫 번째 사용자로 연결하고 sudo에서 해당 사용자가 사용할 수 있는 항목을 확인합니다.

su user1
[user1@testsshad log]$ id
uid=1109801141(user1) gid=1109800513(domain users) groups=1109800513(domain users),1109801132(admins_)
[user1@testsshad log]$ sudo -l
[sudo] password for user1:
Matching Defaults entries for user1 on testsshad:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
    env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
    env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
    env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
    env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
    secure_path=/sbin:/bin:/usr/sbin:/usr/bin

User user1 may run the following commands on testsshad:
    (root) /usr/bin/ls, /usr/bin/cat

두 번째 사용자에 대해서도 동일한 작업을 수행합니다.

su user2
[user2@testsshad log]$ id
uid=1109801142(user2) gid=1109800513(domain users) groups=1109800513(domain users),1109801138(sudo_root)
[user2@testsshad log]$ sudo -l
Matching Defaults entries for user2 on testsshad:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
    env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
    env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
    env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
    env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
    secure_path=/sbin:/bin:/usr/sbin:/usr/bin

User user2 may run the following commands on testsshad:
    (root) ALL

이 접근 방식을 사용하면 다양한 사용자 그룹에 대한 sudo 역할을 중앙에서 정의할 수 있습니다.

Active Directory에 SSH 키 저장 및 사용

체계를 약간 확장하면 SSH 키를 Active Directory 사용자 속성에 저장하고 Linux 호스트에서 인증할 때 이를 사용할 수 있습니다.

SSD를 통한 인증을 구성해야 합니다.
PowerShell 스크립트를 사용하여 필수 속성을 추가합니다.
shPublicKeyAttribute.ps1을 추가합니다.함수 New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$부품=@()
$Parts+=[UInt64]::Parse($guid.SubString(0,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(4,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(9,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(14,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(19,4),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(24,6),“AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(30,6),“AllowHexSpecifier”)
$oid=[String]::Format(«{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}»,$prefix,$Parts[0],
$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = 새 속성ID
$속성 = @{
lDAPDisplayName = 'sshPublicKey';
속성ID = $oid;
oMS 구문 = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'SSH 로그인을 위한 사용자 공개 키';
}

New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$user스키마 | Set-ADObject - @{mayContain = 'sshPublicKey'} 추가

특성을 추가한 후에는 Active Directory 도메인 서비스를 다시 시작해야 합니다.
Active Directory 사용자로 넘어가겠습니다. 귀하에게 편리한 방법을 사용하여 SSH 연결을 위한 키 쌍을 생성하겠습니다.
PuttyGen을 실행하고 "생성" 버튼을 누른 다음 빈 영역 내에서 마우스를 미친 듯이 움직입니다.
프로세스가 완료되면 공개 키와 개인 키를 저장하고 공개 키를 Active Directory 사용자 속성에 업로드하여 프로세스를 즐길 수 있습니다. 단, 공개키는 "OpenSSHauthorized_keys 파일에 붙여넣기 위한 공개 키:".

사용자 속성에 키를 추가합니다.
옵션 1 - GUI:

옵션 2 - 파워셸:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
따라서 현재 sshPublicKey 속성이 채워진 사용자, 키를 사용하여 인증을 위해 구성된 Putty 클라이언트가 있습니다. 한 가지 작은 요점이 남아 있습니다. sshd 데몬이 사용자 속성에서 필요한 공개 키를 추출하도록 강제하는 방법입니다. 부르주아 인터넷에서 발견된 작은 스크립트는 이에 성공적으로 대처할 수 있습니다.

cat /usr/local/bin/fetchSSHKeysFromLDAP
#!/bin/sh
ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D [email protected] -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/n *//g;s/sshPublicKey: //gp'

루트에 대한 권한을 0500으로 설정했습니다.

chmod 0500  /usr/local/bin/fetchSSHKeysFromLDAP

이 예에서는 관리자 계정을 사용하여 디렉터리에 바인딩합니다. 전투 상황에서는 최소한의 권리를 가진 별도의 계정이 있어야 합니다.
저는 개인적으로 권한 설정에도 불구하고 비밀번호가 스크립트에 순수한 형태로 표시되는 순간 매우 혼란스러웠습니다.
솔루션 옵션 :

• 비밀번호를 별도의 파일에 저장합니다.

  echo -n Supersecretpassword > /usr/local/etc/secretpass

• 루트에 대한 파일 권한을 0500으로 설정했습니다.

  chmod 0500 /usr/local/etc/secretpass

• ldapsearch 시작 매개변수 변경: 매개변수 -w superSecretPassword 나는 그것을로 바꾼다 -y /usr/local/etc/secretpass

오늘 모음의 마지막 코드는 sshd_config 편집입니다.

cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root

결과적으로 SSH 클라이언트에 구성된 키 인증과 함께 다음 순서를 얻습니다.

1. 사용자는 자신의 로그인을 표시하여 서버에 연결합니다.
2. sshd 데몬은 스크립트를 통해 Active Directory의 사용자 속성에서 공개 키 값을 추출하고 해당 키를 사용하여 인증을 수행합니다.
3. sssd 데몬은 그룹 멤버십을 기반으로 사용자를 추가로 인증합니다. 주목! 이것이 구성되지 않으면 모든 도메인 사용자가 호스트에 액세스할 수 있습니다.
4. sudo를 시도하면 sssd 데몬이 Active Directory에서 역할을 검색합니다. 역할이 있는 경우 사용자의 속성과 그룹 멤버십이 확인됩니다(sudoRoles가 사용자 그룹을 사용하도록 구성된 경우).

요약.

따라서 키는 Active Directory 사용자 속성, sudo 권한에 저장됩니다. 마찬가지로 도메인 계정을 통한 Linux 호스트 액세스는 Active Directory 그룹의 멤버십을 확인하여 수행됩니다.
지휘봉의 마지막 물결 - 홀은 경건한 침묵 속에 얼어 붙습니다.

글쓰기에 사용된 리소스:

Active Directory를 통한 Sudo
Active Directory를 통한 SSH 키
Powershell 스크립트, Active Directory 스키마에 속성 추가
sudo 안정 릴리스

출처 : habr.com