Аутентификация SSHD с помощью AWS Simple Directory Service

Аутентификация SSHD с помощью AWS Simple Directory Service

Я пытаюсь настроить сеть машин Centos 7 с sshd, которая аутентифицирует открытые ключи в каталоге AWS Simple Directory Service.

В настоящее время у меня есть несколько хостов Centos, экземпляр Windows Server 2008 и каталог, использующий Amazon Web Service (AWS) Simple Directory Service. Ящик Windows используется для администрирования каталога, а ящики Centos используют каталог для аутентификации сеансов SSH. Все машины были присоединены к каталогу.

Я проверил, что могу подключаться по SSH к Centos-боксам как локальные и доменные пользователи, используя простую аутентификацию по паролю. Аналогично, я могу подключаться по RDP к Windows-боксу, используя как локальные, так и доменные учетные записи, используя простую аутентификацию по паролю.

Однако схема, настроенная AWS в моем каталоге, не включала в себя ни одного класса с sshPublicKeyполем, так сказать, из коробки.

Итак, я использовал оснастку схемы Active Directory на компьютере с Windows, чтобы добавить в свою схему следующий атрибут:

Common Name: sshPublicKey
OOID: 1.3.6.1.4.1.24552.1.1.1.13
Syntax: IA5-String
Multi-valued: true

Затем я создал следующий класс:

Common Name: LDAP Public Key
OOID: 1.3.6.1.4.1.24552.500.1.1.2.0 
Parent Class: top
Class Type: Auxiliary
Optional Attributes: sshPublicKey

Затем я использовал оснастку ADSI, чтобы добавить содержимое открытого ключа пользователя в sshPublicKeyполе его записи в каталоге.

На одном из моих компьютеров Centos я отключил аутентификацию по паролю, настроив PasswordAuthentication noфайл конфигурации sshd.

Затем я попытался подключиться по ssh к этому компьютеру Centos, используя пользователя каталога с sshPublicKeyустановленным атрибутом:

$ ssh -l [email protected] -i ~/.ssh/path.to.key.pub centos.box -vvv;
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/localuser/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to centos.box [ip addy] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "~/.ssh/path.to.key.pub" as a RSA1 public key
debug1: identity file ~/.ssh/path.to.key.pub type 1
debug1: identity file ~/.ssh/path.to.key.pub type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH*
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "centos.box" from file "/Users/localuser/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/localuser/.ssh/known_hosts:someLineNumber
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found [email protected]
debug1: kex: server->client aes128-ctr [email protected] none
debug2: mac_setup: found [email protected]
debug1: kex: client->server aes128-ctr [email protected] none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 116/256
debug2: bits set: 535/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA blah
debug3: load_hostkeys: loading entries for host "centos.box" from file "/Users/localuser/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /Users/localuser/.ssh/known_hosts:someLine
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'centos.box' is known and matches the RSA host key.
debug1: Found key in /Users/localuser/.ssh/known_hosts:27
debug2: bits set: 509/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/localuser/.ssh/path.to.key.pub (0x7fb3cb600000), explicit
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/localuser/.ssh/path.to.key.pub
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
$

А на Centos-боксе мы получаем:

$ sudo journalctl -felu sshd
....
Some Date centos.box sshd[a number]: Connection closed by 1.2.3.4 [preauth]

Разрешения на закрытый ключ: 600; разрешения на открытый ключ:644

Я не уверен, как проверить журналы сервера на хосте службы каталогов.

Есть идеи, что я делаю не так?

решение1

Чтобы убедиться, sshdчто протоколы используются sssdдля аутентификации с открытым ключом, выполните следующие действия на sshdхосте:

  1. Добавьте следующую строку в [sssd]раздел вашего /etc/sssd/sssd.confфайла:

    services = ssh, [ all the other services already listed there as well ]
    

Это говорит о том sssd, что ему следует обратиться к sshd.

  1. Если раздела еще нет [ssh], добавьте пустой [ssh]раздел в свой /etc/sssd/sssd.confфайл:

    [ssh]
    

Это обязательный раздел конфигурации для всех служб, с которыми sssdосуществляется взаимодействие.

  1. Добавьте следующую строку в [domain/directory.server]раздел вашего /etc/sssd/sssd.confфайла, где directory.serverуказано полное доменное имя вашего хоста службы каталогов:

    ldap_user_ssh_public_key = sshPublicKey
    

Это указывает sssd, какой атрибут использовать для поиска sshdоткрытых ключей SSH пользователей.Атрибут по умолчанию, используемый , sssd— это ipaSshPubKey, который можно найти в схеме для классов ipaSshUserи ipaSshHost.)

  1. Добавьте в свой файл следующие строки /etc/sshd/sshd_config:

    AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
    AuthorizedKeysCommandUser nobody
    

Это указывает sshdна необходимость выполнения файла /usr/bin/sss_ssh_authorizedkeysот имени пользователя nobody. /usr/bin/sss_ssh_authorizedkeysОн извлекает авторизованные ключи для пользователя, пытающегося пройти аутентификацию на sshdхосте.

  1. Добавьте в свой файл следующие строки /etc/sshd/ssh_config:

    GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts
    ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
    

Это говорит о том sssd, что нужно добавить имя клиента и открытые ключи /var/lib/sss/pubconf/known_hostsи подключиться к клиенту, направив все коммуникации через стандартный ввод-вывод, используя исполняемый файл /usr/bin/sss_ssh_knownhostsproxy.

  1. Перезапустите обе службы:

    $ sudo systemctl reload sshd;
    $ sudo systemctl restart sshd;
    $ sudo systemctl restart sssd;
    

Связанный контент