Веселье в гитхабе

На том удалённом сервере, с которого нужен доступ к другому удалённому серверу, нужно же.

Нет.

что-что?

Как и пароль, ты должен хранить свой приватный ключ в надёжном месте

пароли надо запоминать. Даже самая надежная бумажка с паролем небезопасна

у меня своих ключей целые папки.

папки

мдэ...

Сеанс работы, это типа промежуток времени между login/logout?

Можно это расценивать и так. А вообще я имел ввиду промежуток работы ssh-agent-а(который как правило запускается при логине и выгружается при logout)

А не логичнее ли для настоящих параноиков просто вводить пароль каждый раз, без всяких ключей?

Ключ под паролем дает больше защиты чем просто пароль. Потому что сбрутить ключ на целевом сервере сложнее ;-).

ССЗБ же.
Гитхаб (как и сам гит) это только инструмент. То, что некоторые не умеют им пользоваться, не говорит, что инструмент плох

девственницы

с разрезами до живота

перед парнями

Ты точно не из параллельной вселенной/альтернативной реальности?

А так да, адокЪ и содомия.

А если у меня есть в хомяке папка git, и с git работаю только там, - мой ключ тоже туда попал?

Уже второй модератор лора, который порет какую-то глухую чушь про девственниц, ага. У одного трахаются за макароны, у другого какое-то гуро:/

А ты бекапишь хомяк на гите? Заведи уже дропбокс, ну!

А что, если админ сдаст?

А что, если флуктцация поля и они сами собой разошлются? И еще прон-реклама вылезет на рабстол. Сама собой.

А ты бекапишь хомяк на гите? Заведи уже дропбокс, ну!

Зачем хомяк? Так, пару быдлоскриптов пилил, решил заодно научиться с git работать. Так и ниасилил ничего, кроме git clone.

Просто идиоты грубо как-то, бэ.

зато по существу. я сначала тоже подумал про дыру в гитхабе

Ну если у тебя папка git в ~ лежит, а ключ - в ней, то попасть он может, если ты бэкапил в гитхаб эту папку. Самая сцуть тут в том, что простым удалением и коммитом тут дело не решается, надо репозиторий удалять, потому что в истории коммитов все равно все останется.

Самая сцуть тут в том, что простым удалением и коммитом тут дело не решается, надо репозиторий удалять, потому что в истории коммитов все равно все останется.

Это я в курсе.

а ключ - в ней

Так ведь ключ в ~/.ssh, или я что-то путаю? Или нашлись идиоты, у которых рабочий каталог - хомяк, со всеми вытекающими?

ключ может быть где попало. просто головой думать надо, но это очевидно настолько, что, кроме как ССЗБ, сказать больше нечего.

Ну так, модераторы то в девочках ничего не понимают :}

Вовремя я стал на bitbucket переезжать.

Как это поможет идиоту, который коммитит в репозиторий приватные ключи?

Нахира держать файл ключей в репе? Это каким мозгом надо думать?

В ~/.ssh/config:

Host очень_удалённый_сервер
    ProxyCommand ssh удалённый_сервер 'nc ip_куда_надо 22'

На том удалённом сервере, с которого нужен доступ к другому удалённому сервер

Но к этому удалённому серверу нет же доступа у всех через вебформу.

А еще есть ssh agent forwarding.

Возможность закрыть репозитарий от посторонних глаз?

А еще есть ssh agent forwarding.

Это небезопасно.

Это небезопасно.

Это так же небезопасно как и хранить ключи на промежуточном сервере.

Это так же небезопасно как и хранить ключи на промежуточном сервере.

Именно. Тогда какой от этого смысл?

Тогда какой от этого смысл?

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

Сходил бы по ссылке, не нёс бы такого бреда.

Он его несет независимо от хождения по ссылкам.

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

ProxyCommand уменьшает гимор практически до нуля и при этом совершенно безопасно.

Они удалили ключи и сделали коммит :D

Что ж ты делаешь? Ахаха, прекрати!

Гм, может я чего-то не понимаю, но как ProxyCommand поможет, когда на промежуточном сервере нужен доступ к стороннему.

Например:

localhost -----------> GIT repo
    |                      ^
    |                      |
    +-----> Deploy host ---+

Понятия не имею, как они работают. Всегда думал, что если секурити специалисты, например в моей компании, дают доступ по ssh извне, они понимают что делают.

есть простое правило: секретный ключ НИКОГДА не должен покидать компьютер, на котором он создан.

онечно, нужно знать, куда этот ключ подходит, или пробовать методом тыка

дык там же лежит known_hosts

Зачем тыкать? Заходи на здоровье.

Отлично:) Только тут не гитхаб, а сами пользователи виноваты.

Гм, может я чего-то не понимаю, но как ProxyCommand поможет, когда на промежуточном сервере нужен доступ к стороннему.

Или я чего-то не понял.

Комментарий yvv я понял примерно так: есть сервер X, на котором пользователь хочет получить шелл, есть сервер Y, который является шлюзом для сети, в которой находится X, и есть localhost, за которым сидит пользователь. Напрямую сервер X через интернет никак не доступен, а сервер Y доступен (по ssh), то есть подключаться нужно так:

localhost -> Y -> X

В этом случае ProxyCommand как раз и помогает.

А вот смысл твоей схемы я не понял.

В панике побежал проверять, везде drwx------.

смысл? эти юзеры САМИ залили туда свои ключи.

Всё, сообразил. Если нужен «туннель», тады да.

А вот смысл твоей схемы я не понял.

Часто бывает нужен доступ к репам с серверов на которые производится выкатка кода.

Сеанс работы, это типа промежуток времени между login/logout?

это как настроишь ssh-agent.

пароли надо запоминать.

дык к трём своим локалхостам я помню(6 штук). А остальное?

Часто бывает нужен доступ к репам с серверов на которые производится выкатка кода.

В этом случае нужно для серверов сгенерировать собственные ключи.

Вообще, у любого средства аутентификации, будь то пароль, ssh-ключ, или бумажный паспорт, должен быть ровно один владелец. Хотя у одного владельца может быть несколько разных паролей, например.

В этом случае нужно для серверов сгенерировать собственные ключи.

Вот это и напрягает.

id_dsa тоже немало :)

Languages
Perl......7
PHP.......1

Теперь окончательно выяснили, какие программисты самые неумные.

Возможность закрыть репозитарий от посторонних глаз?

Идиоту это не поможет. Он найдет способ сделать приватные ключи публичными.

Есть даже рабочие: http://d.pr/i/oGRS :)

Оставил сообщение им в 2 часа ночи, сегодня уже сменили authorized_keys.

А ты думаешь, что пароли на ключи запоминаются проще?

Комментарий yvv я понял примерно так: есть сервер X, на котором пользователь хочет получить шелл, есть сервер Y, который является шлюзом для сети, в которой находится X, и есть localhost, за которым сидит пользователь. Напрямую сервер X через интернет никак не доступен, а сервер Y доступен (по ssh), то есть подключаться нужно так:

Нет, не так. Работать приходится на нескольких разных кластерах. Есть необходимость перекидывать между ними данные. Для некоторых операций беспарольный login с одного кластера на другой обязателен.

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

Несколько ключей спасут бацку демократии.

На том удалённом сервере, с которого нужен доступ к другому удалённому серверу, нужно же. Например, в моём случае это вычислительный кластер, и cvs репозиторий.

Не нужно. Освой проброс ключей.