Sergey Zabolotny написал(а) к Eugene Grosbein в Jun 19 21:59:36 по местному времени:

Нello Eugene.

Friday 07 June 2019 02:30, Eugene Grosbein wrote to Sergey Zabolotny:

SZ>> подключаюсь к серверу по ссх с включенным ForwardAgent, локальные
SZ>> ключи на сервер прокидываются и все работает. не устраивает
SZ>> только то, что сокет создается в
SZ>> $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>. хочу, чтоб он лежал,
SZ>> например, где-то тут $TMPDIR/SSНAUTНSOCK/agent.<ppid>. как
SZ>> такое можно сделать не трогая клиентскую сторону? в интернетах
SZ>> пишут, что это прям боль и ничего не получится. но вдруг есть
SZ>> какие-то обходные пути?

EG> Но зачем? Это, вообще говоря, плохое и глупое требование,
есть система в которую могут логиниться множество разных пользователей. у каждого есть свои ссх ключи. пользователь после логина стартует некий скрипт который поднимает набор докер контейнеров, в один из которых нужно прокинуть пользовательские ключи.
пакет докер контейнеров поднимается при помощи docker-composer, конфиг которого изменять нельзя. кроме того, если клиент пришел с отключеным агентом (SSНAUTНSOCK не засечена) внутрь вышеупомянутого контейнера должен быть прокинут дефолтный ключ, который лежит в соседнем контейнере и подключается так:

volumes:
- defaultsshkey:/.ssh-agent:ro

идея, как советуют в интернетах, прокинуть сокет внутрь контейнера используя:
docker run -v ${SSНAUTН_SOCK}:${SSН_AUTН_SOCK} -e SSН_AUTН_SOCK="${SSН_AUTНSOCK}"
не подходит т.к., если в конфиг docker-composer написать что-то типа:

volumes:
- defaultsshkey:/.ssh-agent:ro
- ${SSНAUTН_SOCK}:${SSН_AUTНSOCK}:ro
environment:
- SSНAUTНSOCK

и клиент придет с отключеным ссх-агентом мы получим ошибку при попытке поднять этот контейнер.
поэтому я подумал, что можно было бы прокинуть всю директорию (весь $TMPDIR не вариант) с сокетами внутрь контейнера используя:

volumes:
- defaultsshkey:/.ssh-agent:ro
- $TMPDIR/SSНAUTН_SOCK:$TMPDIR/SSН_AUTНSOCK:ro
environment:
- SSНAUTНSOCK

в таком случае, если клиент придет со своими ключами переменная SSНAUTН_SOCK будет переопределена и клиентские ключи будут видны в контейнере. в противном случае будет использовано дефолтное значение SSН_AUTНSOCK, которое смотрит на дефолтный ключ.

EG> потому что ниоткуда не следует, что по этому пути уже нет файла,
EG> который мог остаться с прошлого ребута или по любой другой причине.
так же как и нет гарантии, что с прошлого ребута мог остаться файл $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>

EG> И тогда выйдет обломчикус. То есть ты предлагаешь заменить
EG> надежную схему на ненадежную.
другого, более правильного способа я не придумал, к сожалению.


--- GoldED+ 1.1.5-031023 (WinNT 5.1.2600-ServicePack3 i1586)