bash & ssh.pub в переменную

но не через файлик, а переменную

динамически генерируемый ~/.ssh/config не устроит?

Через переменную среды даже хуже - ключ будет светиться в списке процессов.

Если коннект продразумевается local → remote, то имхо лучше задействовать ssh-copy и не мучаться — пусть себе паб-кей там валяется, никому он не мешает. Если же наоборот, то правильней было бы генерить для каждого remote свою пару ключей.

Можешь немного по-подробнее описать проблему? Насколько мне известно identity ни через переменную, ни через stdin передать нельзя, но может я и ошибаюсь.

динамически генерируемый ~/.ssh/config не устроит?

Ну, тут хотелось бы конкретно ключик спрятать, а опции отдаю просто при подключении (по типу -o «LogLevel error» -o «ConnectTimeout 5» -o «StrictHostKeyChecking no» -o «UserKnownHostsFile=/dev/null»).

Через переменную среды даже хуже - ключ будет светиться в списке процессов.

Что-то я всё спрятал с СП, всегда помня об этом, а тут о такой банальности забыл.
Спасибо. Это моя глупость.

Да тут немного другая, более печальная ситуация.
Уже на существующую конструкцию нужно докрутить эту фичу.
На пальцах: есть сервак, клиент получает, скажем, какую-то инфу через ssh -i /foo.bar host -c './get_data.sh'.
Это всё что он должен иметь право делать. Логично просто ограничить всё на серваке - но увы, это невозможно. Потому принято решение зашить ключик в бинарник, что бы клиент его выполнял, получал инфу, но при этом не мог использовать паб, для доступа на этого юзера.
Такая вот печаль.

но увы, это невозможно

Чем мотивируют? Так, для статистики.

А по сабжу — пабкей спрячешь, только если саму функцию коннекта будешь вызывать из своей программы, я имею ввиду бинарник, в котором зашита часть сш. И то ещё с областями видимости памяти мудрить. Не страдай ты этим.

Just for Info: в authorized_keys можно польностью анально оградить клиента.

command="get_data.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAA…

Помоему это именно то, что тебе надо.

Чем мотивируют? Так, для статистики.

Пока тот сарвер-маста на месяц не доступен.
Нагорожен этот бок, клиенты начали вытаскивать и юзать паб-кей (нынче он открыто лежал). Ну и на это время - нужно принять меры, в виде подобного костыля.

функцию коннекта будешь вызывать из своей программы

Кстати да, можно хукнуть всю функцию. Логично.

Прости моё невеждовство, но я немного не понял.
Данное действие на каком этапе ограничит?
Если это опции для коннекта, что буду пользовать в бинарнике - то это не совсем то, ибо если краб забирает сам паб ключик, что никак не ограничен на стороне сервера, то просто ssh -i /ssh.pub и получает свою консольку.
У меня проблема, как именно не слить этот паб, ибо он беспарольно пускает на сервак (ведь ничего не помешает переписать эти опции, даже если они будут прописаны в этом файлике).
Или я таки не верно понял?

Моё предложение следующее: как я понял, клиенты коннектятся на сервер и запускают “get_data.sh”, верно?

В таком случае у каждого клиента своя пара pub/private. Pub-ключи клиентов прописаны на сервере в “authorized_keys” так, как описанно выше. С такой записью они не могут получить терминал на сервере или пробросить порт, а могут только запустить “get_data.sh”. Из дополнительных плюшек — что-то вроде ACL.

Можно конечно использовать и одну пару ключей на все клиенты, но в таком случае ACL не будет.

К тому же, мне кажится, что ты путаешь pub и private key. Из пары ключей private — там от куда коннектятся, public — там куда коннектятся (в authorized_keys).

Вот оно что, я слепо зациклился на клиенте.
Да, если это будет работать - это очень даже шикарный вариант.
Осталось помахать плетью и попробовать.
Большое спасибо.

К тому же, мне кажится, что ты путаешь pub и private key. Из пары ключей private — там от куда коннектятся, public — там куда коннектятся (в authorized_keys).

Абсолютно верное наблюдение.
Спешка, в раскуривании вопроса, под пулемётными очередями...