Pull to refresh

Comments 25

Туннели решают, особенно за корп проксей %)
От корпоративных проксей спасает socks:
ssh user@host.outside.com -N -D 127.0.0.1:1080
;)
в винде это замечательно делается через putty :)
Здесь решает не столько клиент, сколько sshd
Опции -p22 -2 -C во втором примере абсолютно лишние. Точнее, -C может пригодиться, но к форвардингу портов это отношения не имеет.
За controlmaster и controlpath спасибо.
-p у меня просто другой порт: о) и я когда выкладывал я порт поправил на 22. а оставил для наглядности чтоб кто невнимательно читает маны видел что и порт поменять можно. -2 и -С тоже примерно по таким же соображениям оставил
UFO just landed and posted this here
Спасибо, что поделились такой удобной хитростью! Действительно пригодится :)
А авторизация с private/public keys не удобнее для того, чтобы не вводить пароль каждый раз? Причем даже не зависимо от того открыто ли уже соединение с хостом в каком-то другом окне или нет.
удобнее, но иногда вход бывает разрешён только по паролям (вот такие бывают админы).
Ну это бывает нужно — Zend Studio 5.5, к примеру, не умеет по SSH ходить с ключами. Только с паролями
Обычно одно другому не мешает, можно разрешить авторизацию и по паролю и по ключам.
Я разве спорю? А вот некоторые особо извращенные параноидальные коллеги мне говорят что пассворд базед надо отключить
Странно, вообще считается, что вход по ключам безопаснее
я поразмыслил, и согласен решением нашего админа разрешить доступ по ключу на «точку входа» и запретить вход по ключу на рабочие станции (которые извне не видны, и с друг-другом по ssh тоже соединяться не могут, на них только с «точки входа» зайти можно). Домашние директории там везде общие, и если бы был разрешён вход на рабочие станции по ключу, многие стали бы хранить в ~/.ssh/ как public так private ключи. Тогда достаточно какого-нибудь неаккуратного пользователя, или нового локального эксплойта чтобы получить кучу залогиненых внешних хакеров.
Да, закономерно. У нас как-то был похожий случай — взломали аккаунт одного пользователя, имевшего sudo NOPASSWD на сервере, и через ключ другого поимели доступ на несколько серверов.
Все это так просто только в том случае, если private ключи не зашифрованы мастер паролем. Нет?
Первый совет не актуален, у меня везде авторизация по ключам. А второй это уже классика.
Но это здорово, что вы это написали, думаю, многим будет полезно.
Аутсорсерам полезно. Нет смысла заводить ключи там куда возможно один раз в жизни прийдётся зайти поглядеть, но в то же время понадобится иметь 2 окна на этом хосте.
Честно говоря, не так часто удается сделать все в один заход )
А 2 окна я стараюсь screen'ом делать )
напоминание про тоннели полезно, но почему не сказано самое главное:

после
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
Ну я приводил пример с базой поэтому в веб приложении надо указать что база находится на локалхост и порту 6632 и вперёт. Спасибо за замечание.
спасибо! так лень самому читать man ssh...))
Sign up to leave a comment.

Articles