Пара хитростей ssh

[@dimks]

Спасибо. Пригодится

[@Roxis]

man ssh_config
man ssh

[@ocnk]

Туннели решают, особенно за корп проксей %)

[@dzmitryc]

От корпоративных проксей спасает socks:
ssh [e-mail] -N -D 127.0.0.1:1080
;)

[@ocnk]

в винде это замечательно делается через putty :)

[@yuretsz]

Здесь решает не столько клиент, сколько sshd

[@stolen]

Опции -p22 -2 -C во втором примере абсолютно лишние. Точнее, -C может пригодиться, но к форвардингу портов это отношения не имеет.
За controlmaster и controlpath спасибо.

[@fenidik]

-p у меня просто другой порт: о) и я когда выкладывал я порт поправил на 22. а оставил для наглядности чтоб кто невнимательно читает маны видел что и порт поменять можно. -2 и -С тоже примерно по таким же соображениям оставил

[@Alien]

Спасибо, что поделились такой удобной хитростью! Действительно пригодится :)

[@Urevic]

А авторизация с private/public keys не удобнее для того, чтобы не вводить пароль каждый раз? Причем даже не зависимо от того открыто ли уже соединение с хостом в каком-то другом окне или нет.

[@dei34]

удобнее, но иногда вход бывает разрешён только по паролям (вот такие бывают админы).

[@NickyX3]

Ну это бывает нужно — Zend Studio 5.5, к примеру, не умеет по SSH ходить с ключами. Только с паролями

[@Urevic]

Обычно одно другому не мешает, можно разрешить авторизацию и по паролю и по ключам.

[@NickyX3]

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

[@ugenk]

Странно, вообще считается, что вход по ключам безопаснее

[@dei34]

я поразмыслил, и согласен решением нашего админа разрешить доступ по ключу на «точку входа» и запретить вход по ключу на рабочие станции (которые извне не видны, и с друг-другом по ssh тоже соединяться не могут, на них только с «точки входа» зайти можно). Домашние директории там везде общие, и если бы был разрешён вход на рабочие станции по ключу, многие стали бы хранить в ~/.ssh/ как public так private ключи. Тогда достаточно какого-нибудь неаккуратного пользователя, или нового локального эксплойта чтобы получить кучу залогиненых внешних хакеров.

[@ugenk]

Да, закономерно. У нас как-то был похожий случай — взломали аккаунт одного пользователя, имевшего sudo NOPASSWD на сервере, и через ключ другого поимели доступ на несколько серверов.

[@Urevic]

Все это так просто только в том случае, если private ключи не зашифрованы мастер паролем. Нет?

[@0x62ash]

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

[@fenidik]

Аутсорсерам полезно. Нет смысла заводить ключи там куда возможно один раз в жизни прийдётся зайти поглядеть, но в то же время понадобится иметь 2 окна на этом хосте.

[@0x62ash]

Честно говоря, не так часто удается сделать все в один заход )
А 2 окна я стараюсь screen'ом делать )

[@dei34]

напоминание про тоннели полезно, но почему не сказано самое главное:

после
ssh -N -f -L 6632:192.168.100.72:66320 tunnel@88.88.88.88

для подсоединения (например, тем же ssh-ем) к порту 66320 на машине 192.168.100.72 надо сказать
ssh -p 6632 localhost

[@fenidik]

Ну я приводил пример с базой поэтому в веб приложении надо указать что база находится на локалхост и порту 6632 и вперёт. Спасибо за замечание.

[@tony]

спасибо! так лень самому читать man ssh...))