Historicamente, as permissões sudo eram regidas pelo conteúdo dos arquivos de /etc/sudoers.d и visto, e a autorização da chave foi realizada usando ~ / .ssh / authorized_keys. Contudo, à medida que a infra-estrutura cresce, existe um desejo de gerir estes direitos de forma centralizada. Hoje pode haver várias opções de solução:
- Sistema de gerenciamento de configuração - Chefe de cozinha, Fantoche, Ansible, Sal
- Active Directory + ssd
- Várias perversões na forma de scripts e edição manual de arquivos
Na minha opinião subjectiva, a melhor opção para uma gestão centralizada continua a ser uma combinação Active Directory + ssd. As vantagens desta abordagem são:
- Verdadeiramente um único diretório de usuários centralizado.
- Distribuição de direitos sudo se resume a adicionar um usuário a um grupo de segurança específico.
- No caso de vários sistemas Linux, torna-se necessário introduzir verificações adicionais para determinar o sistema operacional ao usar sistemas de configuração.
A suíte de hoje será dedicada especificamente à conexão Active Directory + ssd para gerenciamento de direitos sudo e armazenamento ssh chaves em um único repositório.
Então, a sala congelou em um silêncio tenso, o maestro ergueu a batuta e a orquestra se preparou.
Vamos
Dado:
— Domínio do Active Directory testepf.local no Windows Server 2012 R2.
— Host Linux rodando Centos 7
— Autorização configurada usando ssd
Ambas as soluções fazem alterações no esquema Active Directory, então verificamos tudo em um ambiente de teste e só então fazemos alterações na infraestrutura de trabalho. Gostaria de ressaltar que todas as alterações são direcionadas e, de fato, adicionam apenas os atributos e classes necessários.
Ação 1: controle sudo papéis através Active Directory.
Para expandir o circuito Active Directory você precisa baixar a versão mais recente — 1.8.27 a partir de hoje. Descompacte e copie o arquivo esquema.ActiveDirectory do diretório ./doc para o controlador de domínio. Na linha de comando com direitos de administrador do diretório onde o arquivo foi copiado, execute:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Não se esqueça de substituir seus valores)
Abrir adsiedit.msc e conecte-se ao contexto padrão:
Crie uma divisão na raiz do domínio blusas. (A burguesia afirma teimosamente que é nesta unidade que o demônio ssd procura um item sudoRole objetos. No entanto, após ativar a depuração detalhada e estudar os logs, foi revelado que a pesquisa foi realizada em toda a árvore de diretórios.)
Criamos o primeiro objeto pertencente à classe na divisão sudoRole. O nome pode ser escolhido de forma absolutamente arbitrária, pois serve apenas para uma identificação conveniente.
Dentre os possíveis atributos disponíveis na extensão do esquema, os principais são os seguintes:
- comando sudo — determina quais comandos podem ser executados no host.
- sudoHost — determina a quais hosts esta função se aplica. Pode ser especificado como TODASe para um host individual por nome. Também é possível usar máscara.
- sudoUser — indique quais usuários têm permissão para executar sudo.
Se você especificar um grupo de segurança, adicione um sinal “%” no início do nome. Se houver espaços no nome do grupo, não há com o que se preocupar. A julgar pelos logs, a tarefa de escapar dos espaços é assumida pelo mecanismo ssd.
Figura 1. Objetos sudoRole na subdivisão sudoers na raiz do diretório
Figura 2. Associação em grupos de segurança especificados em objetos sudoRole.
A configuração a seguir é feita no lado do Linux.
No arquivo /etc/nsswitch.conf adicione a linha ao final do arquivo:
sudoers: files sssNo arquivo /etc/sssd/sssd.conf na seção [ssd] adicionar aos serviços sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Após todas as operações, você precisa limpar o cache do daemon sssd. As atualizações automáticas ocorrem a cada 6 horas, mas por que deveríamos esperar tanto quando queremos agora?
sss_cache -EMuitas vezes acontece que limpar o cache não ajuda. Então paramos o serviço, limpamos o banco de dados e iniciamos o serviço.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Nós nos conectamos como primeiro usuário e verificamos o que está disponível para ele no 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/catFazemos o mesmo com nosso segundo usuário:
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
Essa abordagem permite definir centralmente funções sudo para diferentes grupos de usuários.
Armazenando e usando chaves SSH no Active Directory
Com uma ligeira expansão do esquema, é possível armazenar chaves ssh nos atributos do usuário do Active Directory e usá-las ao autorizar em hosts Linux.
A autorização via sssd deve ser configurada.
Adicione o atributo necessário usando um script do PowerShell.
AdicionashPublicKeyAttribute.ps1Função Novo-AtributoID {
$Prefixo="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Partes=@()
$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 = Novo-AtributoID
$ atributos = @{
lDAPDisplayName = 'sshPublicKey';
atributoId = $oid;
oMSintaxe = 22;
atributoSintaxe = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Chave pública do usuário para login SSH';
}
New-ADObject -Name sshPublicKey -Type atributoSchema -Path $schemapath -OtherAttributes $atributos
$userSchema = get-adobject -SearchBase $schemapath -Filter 'nome -eq "usuário"'
$userSchema | Set-ADObject -Adicionar @{mayContain = 'sshPublicKey'}
Depois de adicionar o atributo, você deverá reiniciar os Serviços de Domínio Active Directory.
Vamos passar para os usuários do Active Directory. Geraremos um par de chaves para conexão ssh usando qualquer método conveniente para você.
Lançamos o PuttyGen, pressionamos o botão “Gerar” e movemos freneticamente o mouse dentro da área vazia.
Após a conclusão do processo, podemos salvar as chaves públicas e privadas, fazer upload da chave pública para o atributo de usuário do Active Directory e aproveitar o processo. No entanto, a chave pública deve ser usada a partir do "Chave pública para colar no arquivo autorizado_keys do OpenSSH:".
Adicione a chave ao atributo do usuário.
Opção 1 - GUI:
Opção 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Então, atualmente temos: um usuário com o atributo sshPublicKey preenchido, um cliente Putty configurado para autorização por meio de chaves. Resta um pequeno ponto: como forçar o daemon sshd a extrair a chave pública necessária dos atributos do usuário. Um pequeno script encontrado na Internet burguesa pode lidar com isso com sucesso.
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'Definimos as permissões para 0500 para root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Neste exemplo, uma conta de administrador é usada para vincular ao diretório. Em condições de combate, deve haver uma conta separada com um conjunto mínimo de direitos.
Pessoalmente, fiquei muito confuso com o momento da senha em sua forma pura no script, apesar dos direitos definidos.
Opção de solução:
- Eu salvo a senha em um arquivo separado:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Eu configurei as permissões de arquivo para 0500 para root
chmod 0500 /usr/local/etc/secretpass - Alterando os parâmetros de inicialização do ldapsearch: parâmetro -w senha supersecreta eu mudo para -y /usr/local/etc/secretpass
O acorde final da suíte de hoje é a edição de sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Como resultado, obtemos a seguinte sequência com autorização de chave configurada no cliente ssh:
- O usuário se conecta ao servidor indicando seu login.
- O daemon sshd, por meio de um script, extrai o valor da chave pública de um atributo do usuário no Active Directory e realiza a autorização utilizando as chaves.
- O daemon sssd autentica ainda mais o usuário com base na associação ao grupo. Atenção! Se isso não estiver configurado, qualquer usuário do domínio terá acesso ao host.
- Quando você tenta usar o sudo, o daemon sssd procura funções no Active Directory. Se funções estiverem presentes, os atributos do usuário e a associação ao grupo serão verificados (se sudoRoles estiver configurado para usar grupos de usuários)
Resumo.
Assim, as chaves são armazenadas em atributos de usuário do Active Directory, permissões sudo - da mesma forma, o acesso aos hosts Linux por contas de domínio é realizado verificando a adesão ao grupo do Active Directory.
O aceno final da batuta do maestro - e a sala congela em um silêncio reverente.
Recursos usados na escrita:
Fonte: habr.com