Вопросы Теги

Аутентификация с открытым ключом Порт Windows OpenSSH

Я пытался заставить аутентификацию открытого ключа работать с портом PowerShell для OpenSSH на виртуальной машине под управлением Windows Server 2012 R2.

Я честно следовал инструкциям по установке и заверил, что мои права доступа к файлам верны для .ssh \ authorized_keys . (Не могу опубликовать ссылку на конкретные инструкции в вики Win32-OpenSSH, так как я слишком мал, чтобы размещать более двух ссылок, см. Комментарий ниже.)

Я могу войти в систему Windows с хост linux, как и ожидалось, с именем пользователя / паролем. Однако с аутентификацией ключа не повезло.

Локальный (хост Linux) Конфигурация

Мой локальный .ssh / config файл содержит: 

Host remotehostname
    HostName remotehostname
    User remoteuser
    Port 22
    IdentityFile /home/myusername/.ssh/id_dsa

Разрешения в локальном каталоге .ssh отображаются правильно: 

[me@localhost.ssh]$ ls -ltrh
total 56K
-rw------- 1 cengadmin cengadmin 1.6K Sep 11 10:01 known_hosts
-r-------- 1 cengadmin cengadmin  672 Sep 11 10:06 id_dsa
-r-------- 1 cengadmin cengadmin  580 Sep 11 10:13 config

Удаленный (хост Windows) Конфигурация

Каталог .ssh на моем удаленном хосте выглядит следующим образом: 

 Directory of C:\Users\REMOTEUSER\.ssh

09/11/2017  10:07 AM    <DIR>          .
09/11/2017  10:07 AM    <DIR>          ..
09/11/2017  10:07 AM               623 authorized_keys
09/11/2017  10:05 AM               672 id_dsa
09/11/2017  10:05 AM               623 id_dsa.pub
               5 File(s)          4,012 bytes
               2 Dir(s)  10,752,004,096 bytes free

C:\Users\REMOTEUSER\.ssh>icacls authorized_keys
authorized_keys NT SERVICE\sshd:(R)
                NT AUTHORITY\SYSTEM:(F)
                BUILTIN\Administrators:(F)
                FOODOM1\REMOTEUSER:(F)


C:\Users\REMOTEUSER\.ssh>icacls id_dsa
id_dsa BUILTIN\Administrators:(F)
       NT AUTHORITY\SYSTEM:(F)
       DHDOM1\REMOTEUSER:(R,W)

Мой authorized_keys файл содержит только вывод type id_dsa.pub> authorized_keys . 

C:\Users\REMOTEUSER\.ssh>fc id_dsa.pub authorized_keys
Comparing files id_dsa.pub and AUTHORIZED_KEYS
FC: no differences encountered

sshd_config имеет PubkeyAuthentication включен 

PubkeyAuthentication yes

Конфигурация и разрешения кажутся мне разумными. Однако я получаю вездесущую ошибку отсутствия начального маркера , которую я всегда получаю, когда проворачиваю разрешения.

sshd.log

Я вижу: 

C:\Users\REMOTEUSER\.ssh>fc id_dsa.pub authorized_keys
Comparing files id_dsa.pub and AUTHORIZED_KEYS
FC: no differences encountered

sshd_config имеет PubkeyAuthentication включен 

PubkeyAuthentication yes

Конфигурация и разрешения кажутся мне разумными. Однако я получаю вездесущую ошибку отсутствия начального маркера , которую я всегда получаю, когда проворачиваю разрешения.

sshd.log

Я вижу: 

C:\Users\REMOTEUSER\.ssh>fc id_dsa.pub authorized_keys
Comparing files id_dsa.pub and AUTHORIZED_KEYS
FC: no differences encountered

sshd_config имеет PubkeyAuthentication включен 

PubkeyAuthentication yes

Конфигурация и разрешения кажутся мне разумными. Однако я получаю вездесущую ошибку отсутствия начального маркера , которую я всегда получаю, когда проворачиваю разрешения.

sshd.log

Я вижу: debug2: key not found

, что обычно означает, что у меня неправильный ключ в authorized_keys , но я думаю, что приведенная выше разница опровергает эту проблему.

Подсказки? Будьте осторожны, я не использовал Windows в гневе почти 10 лет.

ssh -v output

(обратите внимание, что у меня есть другие ключи rsa в этом каталоге, не включенные выше для ясности) 

$ ssh -v -i .ssh/id_dsa myhostname
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/localuser/.ssh/config
debug1: /home/localuser/.ssh/config line 21: Applying options for raleys-etl
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/localuser/.ssh/config
debug1: /home/localuser/.ssh/config line 15: Applying options for remotehostname
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Connecting to remotehostname [00:00:00:00] port 22.
debug1: Connection established.
debug1: identity file /home/localuser/.ssh/id_dsa type -1
debug1: identity file /home/localuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/localuser/.ssh/ssis_rsa type -1
debug1: identity file /home/localuser/.ssh/ssis_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5
debug1: match: OpenSSH_7.5 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none
debug1: kex: curve25519-sha256@libssh.org need=20 dh_need=20
debug1: kex: curve25519-sha256@libssh.org need=20 dh_need=20
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA e7:aa:c8:d4:8b:02:58:da:64:e6:18:26:d3:be:6a:b2
debug1: Host 'remotehostname' is known and matches the ECDSA host key.
debug1: Found key in /home/localuser/.ssh/known_hosts:5
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: localuser@localhost.localdomain
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering RSA public key: localuser@localhost.localdomain
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering RSA public key: localuser@localhost.localdomain
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/localuser/.ssh/id_dsa
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Received disconnect from 00:00:00:00: 2: Too many authentication failures
2
задан 11 September 2017 в 20:39
4 ответа

Вау. Просто потратил пару часов на отладку.

Итак, включите ведение журнала для ssh-сервера:

  • Edit / ProgramData / ssh / sshd_config
    • Убедитесь, что у вас есть SyslogFacility LOCAL0
    • Убедитесь, что вы иметь LogLevel DEBUG3
  • Перезапустить OpenSSH SSH Server в Services
    (быстрый способ получить Services ] - нажать Windows + R комбинация клавиш и введите services.msc в появившемся диалоговом окне Выполнить )

Теперь вы обнаружите, что полная отладочная информация записывается в / ProgramData /ssh/logs/sshd.log . Просто загляните в файл журнала после того, как вы попытались ввести ssh в машину.

У меня было две проблемы:

Проблема 1: правильный файл authorized_keys

В журнале отладки сказано: 

2019-03-08 … debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys

Ах, тогда не .ssh / authorized_keys . Я нахожусь в группе администраторов , а sshd_config имеет специальный раздел для нас, ребят. Я скопировал содержимое моего файла .ssh / authorized_keys в / ProgramData / ssh / administrators_authorized_keys и перезапустил сервер.

Проблема 2: Слабые права доступа

Теперь у меня были 

2019-03-08 … debug3: Bad permissions. Try removing permissions for user: S-1-9-22 on file C:/ProgramData/ssh/administrators_authorized_keys.

icacls сказал 

C:\ProgramData\ssh> icacls administrators_authorized_keys
administrators_authorized_keys NT AUTHORITY\SYSTEM:(F)
                           BUILTIN\Administrators:(F)
                           NT AUTHORITY\SYSTEM:(I)(F)
                           BUILTIN\Administrators:(I)(F)
                           NT AUTHORITY\Authenticated Users:(I)(RX)

Есть много разрешений, унаследованных от папки и выше (это то, что означает (I) ). Снять наследство. / наследование: r здесь ваш друг. 

C:\ProgramData\ssh> icacls administrators_authorized_keys /inheritance:r
processed file: administrators_authorized_keys
Successfully processed 1 files; Failed processing 0 files

Теперь все хорошо: 

C:\ProgramData\ssh> icacls administrators_authorized_keys
administrators_authorized_keys NT AUTHORITY\SYSTEM:(F)
                           BUILTIN\Administrators:(F)

Итак, я перезапустил сервер, и он работает. Шиш.

Не забудьте отменить изменения в LogLevel и SyslogFacility в sshd_config .

1
ответ дан 3 December 2019 в 12:35

Просто хотел добавить несколько заметок в дополнение к фантастическому ответу @bobbogo.

За: https://github.com/PowerShell/Win32-OpenSSH/wiki/Security-protection-of-various-files-in-Win32-OpenSSH#administrators_authorized_keys

Мне удалось отправить свой закрытый ключ в рабочую группу (не присоединенная к домену) рабочая станция:

:From WSL(linux) --> Win10 machine
scp ./my/public/key someadmin@somedesktop:'C:\ProgramData\ssh\administrators_authorized_keys'

Затем я выполнил следующее через WinRM/PSRemoting (хотя ssh с паролем, вероятно, сработал бы):

PS C:\> cd C:\programdata\ssh

PS C:\programdata\ssh>icacls administrators_authorized_keys /inheritance:r
PS C:\programdata\ssh>icacls administrators_authorized_keys /grant SYSTEM:`(F`)
PS C:\programdata\ssh>icacls administrators_authorized_keys /grant BUILTIN\Administrators:`(F`)

PS C:\programdata\ssh>net stop sshd
PS C:\programdata\ssh>net start sshd

Затем я смог использовать ssh с keyauth, как и ожидалось.

Примечание: поскольку это не было присоединено к домену, при первой попытке я потерял доступ, так как первая команда удалила наследование, что отключило мое стандартное разрешение администратора OOBE 1909 года на файл administrators_authorized_keys. Рядом с грантами и перезапуском службы все заработало, как и ожидалось.

1
ответ дан 21 April 2020 в 07:01

Измените конфигурацию sshd (C:\ProgramData\ssh\sshd_config)

Закомментируйте эти строки (должна быть последняя пара строк sshd_config)

#Match Group administrators
#    AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

После этого добавьте свой открытый ключ в __HOME__/. ssh/authorized_keys как обычно.

0
ответ дан 9 July 2020 в 06:23

Как упоминалось в https://stackoverflow.com/a/66008728, существует конкретная не-англоязычная проблема с этой проблемой

Мы столкнулись с той же проблемой в Windows 2019 и Windows 2016 И в неанглийской системе (французский)

Нам пришлось изменить acl сАдминистраторынаАдминистраторыИ изменить содержимое sshd_config в programData/ssh следующим образом

СтрокаАдминистраторы группы соответствиябыла раскомментирована И изменена наАдминистраторы группы соответствия

Эти конкретные неанглийские настройки не были необходимы в системе Windows 2012 R2

Удачи

0
ответ дан 3 November 2021 в 06:06

Теги

Похожие вопросы