Pull to refresh

Comments 66

Расскажите как настроить iTerm под маком, что не пробовал — не комфортно.
Присоединяюсь к вопросу.
UFO landed and left these words here
С клавишами там беда, но не совсем — во всех MC замечательно работает замена F1-F9 через альт.
Например, вместо F10 нажимаем Alt+0, F5 = Alt +5 b n/g/
К сожалению немного хуже: Alt + Esc + 5, Alt + Esc + 9 и т.д.
Сейчас работаю за линуксом, а тут немного не так.
Не Alt, а Meta. А уж как Meta настроена конкретно на вашей системе — другой вопрос. Последовательный вариант с клавишей Esc или параллельный с клавишей Alt — наиболее распространённые варианты.

Немного непонятно, зачем вы в следующем комменте F5 вводите как Alt+Esc+5 — достаточно вводить как Esc, 5 (с отпусканием Esc перед нажатием пятёрки). Или это специфика iTerm? В попадавшихся мне gnome-terminal, konsole, PuTTY и xterm Esc как Meta везде работала.
я же говорю, учусь от случая к случаю. (: Спасибо, буду знать
Для iTerm2, чтобы он вел себя так же, как линуксовый терминал, с хоткеями в mc, нужно зайти в настройки iTerm2 -> Profiles -> вкладка Keys и внизу отметить +Esc
В основе лежат две статьи о том как показывать на фоне картинку с именем сервера, на котором работаем и поставить приятные для глаза цвета. Кроме того автор предоставил свои файлы настроек для терминала, которые я себе поставил и практически не кастомизировал — и так все очень удобно.

А что не так?
Я пользуюсь вполне успешно. Некоторые хоткеи mc не работают, но из меню вполне доступны.
В последнее время предпочитаю iTerm 2 — производит намного лучшее впечатление.
Был на маке — пользовался Guake.
славная рифма получилась
Да, и ещё пускай автор расскажет, как пропатчить KDE под FreeBSD.
А чем плох стандартный терминал?
Спасибо, открыл для себя много нового, особенно про .ssh/config.

От себя лишь добавлю совет: отключайте в конфигах на серверах вход по паролю, оставляйте только ключи (естественно перед отключением входа по паролю надо себе дать права sudo и закинуть свой ключ). Ключи только с passphrase (на всякий случай).

И еще.

Вводим (или не вводим) passphrase. Лучше все-таки вводить: система будет помнить ваш пароль от логина до логаута, то есть вводить постоянно этот пароль не нужно. Зато на порядок возрастет безопасность.

Passphrase — не пароль к учетной записи на сервере, а «пароль» к ключю rsa. Он используется для получения доступа к private сертификату (как-то сумбурно, но в общем так — поправьте если заблуждаюсь).
> private сертификату

нет, таки к приватному ключу. В openssh сертификаты не применяются.
Прошу прощения, конечно ключ — я тут просто сертификат параллельно генерирую для https, вот и проскочило ненароком.
Блин, неужели всё-таки придётся когда-то начать обучаться линуксу?..
давно уже пора было обучиться
Графический интерфейс суть от тебя глубинную скрывает. В bash-консоли силу истиную найдешь ты.
Наиболее простой способ перенести ключ на сервер это выполнить у себя в консоли вот эту команду

man ssh-copy-id
Да, но к сожалению работает не везде: под маком приходится делать вот такой вот трюк.
Не знал. Но по крайней мере те, у кого она работает, узнают о ней.
А у меня под маком работает ssh-copy-id. А почему может не работать?
У меня она есть. Я просто думал у автора именно «не работает» и спросил почему она может не работать. Но ниже увидел его коммент, что он не знает как ее поставить и даже отписал более простой способ установки — через homebrew.
тогда стоит использовать scp
А если в ~/.ssh/authorized_keys уже есть чей-то ключ? scp его же заменит?
Для переноса ключа на сервер можно использовать команду ssh-copy-id.
А ещё стоит поставить zsh + oh-my-zsh, это если не охота разбираться в настройках. Работа в консоли станет гораздо удобнее. Ну и полазить по commandlinefu.com бывает полезно.
Наиболее простой способ перенести ключ на сервер это выполнить у себя в консоли вот эту команду:
$ ssh user@hostname «umask 077; cat >> .ssh/authorized_keys» < ~/.ssh/id_dsa.pub


Для этого существует команда ssh-copy-id:
$ssh-copy-id -i id_rsa.pub user@host
Мешать брю с портами (если они стоят, что есть частое явление) — это не самое true решение. А в портах этого пакета нет.
Она есть только в Linux, на маке ее нет, например.
Можно поставить через homebrew.
> $ ssh user@hostname «umask 077; cat >> .ssh/authorized_keys» < ~/.ssh/id_dsa.pub

Сегодня на одном сервере столкнулся с тем, что подобный финт не сработал. А всё потому, что в настройках sshd был указан другой путь к файлу с ключами:
AuthorizedKeysFile .ssh_authorized/keys

Ну а также необходимо убедиться, что авторизация по ключам вообще работает:
PubkeyAuthentication yes
UFO landed and left these words here
ssh-copy-id для копирования ключей лучше всего подходит.
>Лучше все-таки вводить: система будет помнить ваш пароль от логина до логаута, то есть вводить постоянно этот пароль не нужно.

чиво? это о чем написано?
автор забыл написать об ssh-add, а только намекнул на это :) Зря вообще-то, это был бы хороший совет, мне очень удобно.
Поделитесь, в чем плюсы ssh-agent? я так и не понял чем это может быть полезно
а куда вы будете ваши ключи совать через ssh-add? в вакуум? :)
Касательно ssh-ключей, ситуация, на мой взглят, двоякая. Существует вероятность в какой–то момент просто остаться без доступа к серверам.

Была у нас как–то ситуация: админ компании сначала ушёл в отпуск, а после отпуска просто исчез. Дозвониться или как–то ещё выйти на контакт не удавалось. Все доступы к серверам на площадках были у него, а авторизовывался он там через ключи (грубо говоря, запускал в консоли скрипт типа connect some_server), чтобы не вводить постоянно пароли.

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

Я за хранение паролей в зашифрованном менеджере паролей и за ввод их каждый раз при авторизации.
ссш-ключ можно защитить парольной фразой и вводить её один раз в начале сеанса — это достаточно разумный компромисс, на мой взгляд.
Вот для этого и нужно вводить passphrase — если вы включите компьютер и попробуете зайти на удаленный сервер у вас спросят этот пароль. После того как пароль будет дан компьютер вас запомнит… до тех пор пока вы не выйдете из системы. Та же идеология что и с менеджером паролей, только пароли к серверам вы не вытаскиваете, не храните и меньше шанс что потеряете/покажете где не надо.
Т.е. один пароль меняем на другой, только называем его passphrase? :)
нет: вместо кучи чужих паролей (к хостингам, которые нельзя сменить, к серверам которыми пользуются многие люди) мы используем ключи. Что бы защитить этот ключ генерируем свой пароль, его-то и нужно запомнить. Это ваш универсальный пароль для доступа к любому серверу, удобно же!
а вот если бы вы не смогли получить доступ к его машине?
Ну, при физическом доступе к серверу, вроде как, можно получить над ним управление (точно сказать не могу, не моя епархия), так что отправили бы свеженанятого админа в датацентр разбираться в ситуации и решать проблемы. :)
необязательно отправлять админа куда-то. Админу достаточно попросить об этом у службы поддержки датацентра. Но в целом мысль верная :)
Ещё иногда удобно «пробросить порт» через ssh:
# ssh user@remoute_host -L<local_port>:<local_host>:<remoute_port>
Точнее сказать
ssh user@remote -L [<local_host>:]<local_port>:<remote_host>:<remote_port>

В той части, где Вы указали local_host указывается к какому хосту и порту будет привязан проброшенный туннель на удаленной стороне.

Ещё полезна обратная фича
ssh user@remote -R [<local_host>:]<local_port>:<remote_host>:<remote_port>

которая даст доступ с <remote_host>:<remote_port> к <local_host>:<local_port>.

Следует также упомянуть полезные ключи -N и -f. Первый указывает, что на удаленной стороне не нужно ничего выполнять, второй отправляет в бэкграунд. Удобна их комбинация, если надо только пробросить порт.
Да, статья отличная. Очень хочется продолжения в том же духе…
Хотел вот это (и еще ряд фиксов) прислать личным сообщением:
Как правило, автодополнение парсит файлы ssh-конфига, достаточно начать писать хостнейм и нажать таб, чтобы имя хоста было дописано автоматически. Если этого не происходит, нужно баш этому научить.

… но форма почему-то не валидируется, якобы не указан получатель (хотя он указан). Так что придется чуть-чуть запакостить тред.

(Вообще, жаль, что на хабре до сих пор нет вики-режима, как на StackOverflow и К°. Было бы несравнимо проще и читать, и помогать другим в подготовке более читабельного текста.)
а вообще много неплохих советов. Сам я до большинства сам дошёл разными путями с одним отличием — у меня tcsh, а не bash :)
Кстати, автодополнение хостов полезно настроить не только для команды ssh, но также для sftp и scp.
Отдельно хотелось бы запросить рассказ про ssh-agent. Сам я настроил такое в XFCE, однако в Гноме было прикольнее, там парольная фраза хранилась в брелке сеанса, то есть её вообще надо было сохранить всего один раз.
Еще классная штука — forced commands. Прописываем в ключах текст вроде: command="/home/remoteuser/cron/validate-rsync" (перед ключом, напр перед текстом ssh-dss .....) и удаленный пользователь автоматически будет делать эту команду.

Например, простенький веб-интерфейс (даже на другой машине) сможет коннектится на нужный сервер и добавлять-удалять правило на файрволе или ребутить машину или рестартовать апач итд, в общем — делать некоторые нужные операции, которые требуют рута. Но даже если эту машинку поломают и ключик уведут — зайти с ним на систему и сделать rm -rf не получится — только /etc/init.d/apache restart.
Если компьютеров за NAT'ом огромное количество и каждый день подключаешься к разным, редко когда два дня подключаешься к одному и тому же — можно ли как-то пробросить в ProxyCommand и пароль к target computer?
Only those users with full accounts are able to leave comments. Log in, please.