Как использовать ключи из /etc/ssh_known_hosts в скриптах git

Сценарий. Пользователь alice заходит на сервер msk-web-01 (centos7.2, selinux включен) по своему ssh ключу и хочет в папке /www/mysite.ru/htdocs/ (владелец папки -- пользователь apache) запустить команду git pull.
Для этого написан небольшой батник:
#!/bin/sh
#see http://ru.stackoverflow.com/questions/548545/ for details sudo setfacl -m apache:x $(dirname "$SSH_AUTH_SOCK") sudo setfacl -m apache:rwx "$SSH_AUTH_SOCK"
cd /www/mysite.ru/htdocs/ pwd sudo su -s /bin/sh apache -c "/usr/bin/git pull" ....
И он работает... выдавая многочисленные предупреждения:
/www/site1.ru/htdocs Could not create directory '/usr/share/httpd/.ssh'. Failed to add the ECDSA host key for IP address '1.2.3.4' to the list of known hosts (/usr/share/httpd/.ssh/known_ho). Already up-to-date. /www/site2.ru/htdocs Could not create directory '/usr/share/httpd/.ssh'. Failed to add the ECDSA host key for IP address '1.2.3.4' to the list of known hosts (/usr/share/httpd/.ssh/known_ho). Already up-to-date.
Задача -- избавиться от этих лишних записей, добившись чистого вывода при помощи добавления записей в глобальный known_hosts.
Требуемый эффект можно получить если создать /usr/share/httpd/.ssh/known_hosts со строкой CheckHostIP no
/www/site1.ru/htdocs Already up-to-date. /www/site2.ru/htdocs Already up-to-date. /www/site3.ru/htdocs Already up-to-date.
Разумеется, такой способ не рассматривается как решение задачи, так же как и другие обходные пути типа "совсем отключить проверку" (скажем, раз или два)
PS Ключи сохранял одним из двух способов, первый:
ssh-keyscan -t rsa,dsa git.mycomany.ru >> /etc/ssh/ssh_known_hosts
второй:
ssh-keyscan git.mycomany.ru >> /etc/ssh/ssh_known_hosts
Разница не особо велика: в первом случае Failed to add the RSA host, во втором - Failed to add the ECDSA host key.
И даже так с горя:
ssh-keyscan git.mycomany.ru,1.2.3.4 >> /etc/ssh/ssh_known_hosts

Ответ

В итоге, всё оказалось достаточно просто.
Сначала ещё раз о постановке задачи. Есть ряд доверенных серверов организации, между которыми сотрудникам нужно перемещаться с сохранением авторизации (ForwardAgent), поэтому нужно уметь заполнять файл /etc/ssh/ssh_known_hosts доверенными данными.
Во-первых, гит в своём общении с удалёнными репозиториями по протоколу ssh полагается на системные утилиты, особых настроек ssh-подключения нет -- можно почитать про хаки с созданием файла ssh и экспортированием переменной GIT_SSH. Поэтому изначально в вопросе было больше про ssh, чем про конкретно git.
Во-вторых, когда я начал разбираться с ключами (rsa, dsa, esdca) и версиями протоколов -- я решил не только абстрагироваться от гит, но и от ансибл - чтобы не влияло, на всякий случай.
После тестов у меня получилось, что ключи были сгенерированы правильно, настройки ssh (как дефолтные центоса, так и мои кастомные) тоже не влияют на работу.
Всё, что нужно -- это сдампить отпечатки и записать в общий known_hosts:
ssh-keyscan -t rsa,dsa git.mycomany.ru >> /etc/ssh/ssh_known_hosts
Включение хеширования не влияет на итог - тоже. А что влияет?
Как ни странно -- выяснилось, что влияет ansible. Если файла /etc/ssh/ssh_known_hosts на диске нет -- он создаёт файл с правами rw-r--r-- но стоит лишь ещё раз запустить повторно -- права чудесным образом становятся rw------- Разумеется, что процессы, которые хотят прочитать хранилище и проверить, нет ли там такого отпечатка обламываются и ничего не находят. Стоит лишь восстановить права на файл -- и работа снова восстанавливается.
Пример заполнения ключей практически такой же, как и в документации
- name: global pubkes for servers known_hosts: path='/etc/ssh/ssh_known_hosts' name='{{ item }}' key="{{ lookup('file', 'files/pubkeys/{{ item }}.pub') }}" with_items: - git.mycompany.ru
Я хотел было создать баг на гитхабе -- но перед заведением поискал, нет ли готового. И нашёл, вот: https://github.com/ansible/ansible-modules-extras/issues/2513