#1
|
|||
|
|||
SSН_AUTН_SOCK
Sergey Zabolotny написал(а) к All в Jun 19 12:05:14 по местному времени:
Нello All. подключаюсь к серверу по ссх с включенным ForwardAgent, локальные ключи на сервер прокидываются и все работает. не устраивает только то, что сокет создается в $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>. хочу, чтоб он лежал, например, где-то тут $TMPDIR/SSНAUTНSOCK/agent.<ppid>. как такое можно сделать не трогая клиентскую сторону? в интернетах пишут, что это прям боль и ничего не получится. но вдруг есть какие-то обходные пути? --- GoldED+ 1.1.5-031023 (WinNT 5.1.2600-ServicePack3 i1586) |
#2
|
|||
|
|||
SSН_AUTН_SOCK
Alexey Vissarionov написал(а) к Sergey Zabolotny в Jun 19 21:00:00 по местному времени:
Доброго времени суток, Sergey! 06 Jun 2019 12:05:14, ты -> All: SZ> подключаюсь к серверу по ссх с включенным ForwardAgent, локальные SZ> ключи на сервер прокидываются и все работает. не устраивает только SZ> то, что сокет создается На сервере? SZ> в $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>. хочу, чтоб он лежал, например, SZ> где-то тут $TMPDIR/SSНAUTНSOCK/agent.<ppid>. Эээээ... А зачем? В него всегда указывает $SSНAUTНSOCK - этого вполне достаточно. SZ> как такое можно сделать не трогая клиентскую сторону? в интернетах SZ> пишут, что это прям боль и ничего не получится. но вдруг есть SZ> какие-то обходные пути? Уж извини, но пока я не прочитаю внятное объяснение, на кой ляд оно тебе вперлось именно в таком виде - хренушки тебе, а не рецепт. -- Alexey V. Vissarionov aka Gremlin from Kremlin gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii ... Профессионализм - умение оценить меру своей некомпетентности --- /bin/vi |
#3
|
|||
|
|||
Re: SSН_AUTН_SOCK
Eugene Grosbein написал(а) к Sergey Zabolotny в Jun 19 02:30:49 по местному времени:
06 июня 2019, четверг, в 12:05 NOVT, Sergey Zabolotny написал(а): SZ> подключаюсь к серверу по ссх с включенным ForwardAgent, локальные ключи на SZ> сервер прокидываются и все работает. не устраивает только то, что сокет SZ> создается в $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>. хочу, чтоб он лежал, например, SZ> где-то тут $TMPDIR/SSНAUTНSOCK/agent.<ppid>. как такое можно сделать не трогая SZ> клиентскую сторону? в интернетах пишут, что это прям боль и ничего не получится. SZ> но вдруг есть какие-то обходные пути? Но зачем? Это, вообще говоря, плохое и глупое требование, потому что ниоткуда не следует, что по этому пути уже нет файла, который мог остаться с прошлого ребута или по любой другой причине. И тогда выйдет обломчикус. То есть ты предлагаешь заменить надежную схему на ненадежную. Eugene -- Поэты - страшные люди. У них все святое. --- slrn/1.0.3 (FreeBSD) |
#4
|
|||
|
|||
SSН_AUTН_SOCK
Sergey Zabolotny написал(а) к Alexey Vissarionov в Jun 19 22:37:32 по местному времени:
Нello Alexey. Thursday 06 June 2019 21:00, Alexey Vissarionov wrote to Sergey Zabolotny: SZ>> в $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid>. хочу, чтоб он лежал, SZ>> например, где-то тут $TMPDIR/SSНAUTНSOCK/agent.<ppid>. AV> Эээээ... А зачем? В него всегда указывает $SSНAUTНSOCK - этого AV> вполне достаточно. смотря для чего. мне этого показалось недостаточно. SZ>> как такое можно сделать не трогая клиентскую сторону? в SZ>> интернетах пишут, что это прям боль и ничего не получится. но SZ>> вдруг есть какие-то обходные пути? AV> Уж извини, но пока я не прочитаю внятное объяснение, на кой ляд оно AV> тебе вперлось именно в таком виде - хренушки тебе, а не рецепт. спасибо, что не отказал. решение я уже нашел и даже не знаю, надо ли рассказывать зачем мне оно такое было надо. вообще не понятно, зачем писать если не собираешься помочь решить вопрос? похоже только для того, чтоб в очередной раз показать, что ты все знаешь, но хрен кому поможешь. --- GoldED+ 1.1.5-031023 (WinNT 5.1.2600-ServicePack3 i1586) |
#5
|
|||
|
|||
SSН_AUTН_SOCK
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) |
#6
|
|||
|
|||
Re: SSН_AUTН_SOCK
Eugene Grosbein написал(а) к Sergey Zabolotny в Jun 19 03:00:29 по местному времени:
08 июня 2019, суббота, в 21:59 NOVT, Sergey Zabolotny написал(а): EG>> Но зачем? Это, вообще говоря, плохое и глупое требование, SZ> есть система в которую могут логиниться множество разных пользователей. у SZ> каждого есть свои ссх ключи. пользователь после логина стартует некий скрипт SZ> который поднимает набор докер контейнеров, в один из которых нужно прокинуть SZ> пользовательские ключи. Ничего не понял. Которые именно ключи? Речь про пары ssh-ключей, приватные части которых расположены на клиентских хостах, с которых они подключаются? Или про пары ssh-ключей, приватные части которых лежат в их домашних каталогах непосредственно на системе, о которой идёт речь и в которую они логинятся? Или о каких-то ещё ключах? EG>> потому что ниоткуда не следует, что по этому пути уже нет файла, EG>> который мог остаться с прошлого ребута или по любой другой причине. SZ> так же как и нет гарантии, что с прошлого ребута мог остаться файл SZ> $TMPDIR/ssh-XXXXXXXXXX/agent.<ppid> Есть гарантия. Её даёт XXXXXXXXXX - каждый раз генерируется уникальная последовательность именно для такой гарантии. Eugene -- Господа Действительного Положения Вещей предохраняют себя от голода своим богатством, от общественного мнения - тайной и анонимностью, от частной критики - законами против клеветы и тем, что средства связи находятся в их распоряжении. (Норберт Винер) --- slrn/1.0.3 (FreeBSD) |
#7
|
|||
|
|||
SSН_AUTН_SOCK
Sergey Zabolotny написал(а) к Eugene Grosbein в Jun 19 10:43:40 по местному времени:
Нello Eugene. Monday 10 June 2019 03:00, Eugene Grosbein wrote to Sergey Zabolotny: EG>>> Но зачем? Это, вообще говоря, плохое и глупое требование, SZ>> есть система в которую могут логиниться множество разных SZ>> пользователей. у каждого есть свои ссх ключи. пользователь после SZ>> логина стартует некий скрипт который поднимает набор докер SZ>> контейнеров, в один из которых нужно прокинуть пользовательские SZ>> ключи. EG> Ничего не понял. Которые именно ключи? Речь про пары ssh-ключей, EG> приватные части которых расположены на клиентских хостах, EG> с которых они подключаются? да --- GoldED+ 1.1.5-031023 (WinNT 5.1.2600-ServicePack3 i1586) |