Comments 66
Расскажите как настроить iTerm под маком, что не пробовал — не комфортно.
UFO just landed and posted this here
UFO just landed and posted this here
С клавишами там беда, но не совсем — во всех MC замечательно работает замена F1-F9 через альт.
Например, вместо F10 нажимаем Alt+0, F5 = Alt +5 b n/g/
Например, вместо 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 везде работала.
Немного непонятно, зачем вы в следующем комменте F5 вводите как Alt+Esc+5 — достаточно вводить как Esc, 5 (с отпусканием Esc перед нажатием пятёрки). Или это специфика iTerm? В попадавшихся мне gnome-terminal, konsole, PuTTY и xterm Esc как Meta везде работала.
Для iTerm2, чтобы он вел себя так же, как линуксовый терминал, с хоткеями в mc, нужно зайти в настройки iTerm2 -> Profiles -> вкладка Keys и внизу отметить +Esc
В основе лежат две статьи о том как показывать на фоне картинку с именем сервера, на котором работаем и поставить приятные для глаза цвета. Кроме того автор предоставил свои файлы настроек для терминала, которые я себе поставил и практически не кастомизировал — и так все очень удобно.
Поставить iTerm2, zsh и oh-my-zsh.
А что не так?
Я пользуюсь вполне успешно. Некоторые хоткеи mc не работают, но из меню вполне доступны.
Я пользуюсь вполне успешно. Некоторые хоткеи mc не работают, но из меню вполне доступны.
В последнее время предпочитаю iTerm 2 — производит намного лучшее впечатление.
Да, и ещё пускай автор расскажет, как пропатчить KDE под FreeBSD.
А чем плох стандартный терминал?
Поставить iTerm2?
попробуй iVisor
Спасибо, открыл для себя много нового, особенно про .ssh/config.
От себя лишь добавлю совет: отключайте в конфигах на серверах вход по паролю, оставляйте только ключи (естественно перед отключением входа по паролю надо себе дать права sudo и закинуть свой ключ). Ключи только с passphrase (на всякий случай).
И еще.
Passphrase — не пароль к учетной записи на сервере, а «пароль» к ключю rsa. Он используется для получения доступа к private сертификату (как-то сумбурно, но в общем так — поправьте если заблуждаюсь).
От себя лишь добавлю совет: отключайте в конфигах на серверах вход по паролю, оставляйте только ключи (естественно перед отключением входа по паролю надо себе дать права sudo и закинуть свой ключ). Ключи только с passphrase (на всякий случай).
И еще.
Вводим (или не вводим) passphrase. Лучше все-таки вводить: система будет помнить ваш пароль от логина до логаута, то есть вводить постоянно этот пароль не нужно. Зато на порядок возрастет безопасность.
Passphrase — не пароль к учетной записи на сервере, а «пароль» к ключю rsa. Он используется для получения доступа к private сертификату (как-то сумбурно, но в общем так — поправьте если заблуждаюсь).
Блин, неужели всё-таки придётся когда-то начать обучаться линуксу?..
Наиболее простой способ перенести ключ на сервер это выполнить у себя в консоли вот эту команду
man ssh-copy-idДа, но к сожалению работает не везде: под маком приходится делать вот такой вот трюк.
Не знал. Но по крайней мере те, у кого она работает, узнают о ней.
А у меня под маком работает ssh-copy-id. А почему может не работать?
Потому что ее нет. И нужно отдельно поставить. Например так phildawson.tumblr.com/post/484798267/ssh-copy-id-in-mac-os-x
тогда стоит использовать 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
> $ ssh user@hostname «umask 077; cat >> .ssh/authorized_keys» < ~/.ssh/id_dsa.pub
Сегодня на одном сервере столкнулся с тем, что подобный финт не сработал. А всё потому, что в настройках sshd был указан другой путь к файлу с ключами:
Ну а также необходимо убедиться, что авторизация по ключам вообще работает:
Сегодня на одном сервере столкнулся с тем, что подобный финт не сработал. А всё потому, что в настройках sshd был указан другой путь к файлу с ключами:
AuthorizedKeysFile .ssh_authorized/keys
Ну а также необходимо убедиться, что авторизация по ключам вообще работает:
PubkeyAuthentication yesUFO just landed and posted this here
ssh-copy-id для копирования ключей лучше всего подходит.
>Лучше все-таки вводить: система будет помнить ваш пароль от логина до логаута, то есть вводить постоянно этот пароль не нужно.
чиво? это о чем написано?
чиво? это о чем написано?
Касательно ssh-ключей, ситуация, на мой взглят, двоякая. Существует вероятность в какой–то момент просто остаться без доступа к серверам.
Была у нас как–то ситуация: админ компании сначала ушёл в отпуск, а после отпуска просто исчез. Дозвониться или как–то ещё выйти на контакт не удавалось. Все доступы к серверам на площадках были у него, а авторизовывался он там через ключи (грубо говоря, запускал в консоли скрипт типа connect some_server), чтобы не вводить постоянно пароли.
И вот исключительно благодаря этим ключам, отыскав пароль к его рабочей машине мы смогли от его имени войти на сервера и получить к ним полный доступ. С одной стороны, это, конечно, было хорошо для нас, а вот с другой — огромная дыра в безопасности.
Я за хранение паролей в зашифрованном менеджере паролей и за ввод их каждый раз при авторизации.
Была у нас как–то ситуация: админ компании сначала ушёл в отпуск, а после отпуска просто исчез. Дозвониться или как–то ещё выйти на контакт не удавалось. Все доступы к серверам на площадках были у него, а авторизовывался он там через ключи (грубо говоря, запускал в консоли скрипт типа connect some_server), чтобы не вводить постоянно пароли.
И вот исключительно благодаря этим ключам, отыскав пароль к его рабочей машине мы смогли от его имени войти на сервера и получить к ним полный доступ. С одной стороны, это, конечно, было хорошо для нас, а вот с другой — огромная дыра в безопасности.
Я за хранение паролей в зашифрованном менеджере паролей и за ввод их каждый раз при авторизации.
ссш-ключ можно защитить парольной фразой и вводить её один раз в начале сеанса — это достаточно разумный компромисс, на мой взгляд.
Вот для этого и нужно вводить passphrase — если вы включите компьютер и попробуете зайти на удаленный сервер у вас спросят этот пароль. После того как пароль будет дан компьютер вас запомнит… до тех пор пока вы не выйдете из системы. Та же идеология что и с менеджером паролей, только пароли к серверам вы не вытаскиваете, не храните и меньше шанс что потеряете/покажете где не надо.
а вот если бы вы не смогли получить доступ к его машине?
Ещё иногда удобно «пробросить порт» через ssh:
# ssh user@remoute_host -L<local_port>:<local_host>:<remoute_port>
# ssh user@remoute_host -L<local_port>:<local_host>:<remoute_port>
Точнее сказать
В той части, где Вы указали local_host указывается к какому хосту и порту будет привязан проброшенный туннель на удаленной стороне.
Ещё полезна обратная фича
которая даст доступ с <remote_host>:<remote_port> к <local_host>:<local_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. Первый указывает, что на удаленной стороне не нужно ничего выполнять, второй отправляет в бэкграунд. Удобна их комбинация, если надо только пробросить порт.
Да, статья отличная. Очень хочется продолжения в том же духе…
Хотел вот это (и еще ряд фиксов) прислать личным сообщением:
… но форма почему-то не валидируется, якобы не указан получатель (хотя он указан). Так что придется чуть-чуть запакостить тред.
(Вообще, жаль, что на хабре до сих пор нет вики-режима, как на StackOverflow и К°. Было бы несравнимо проще и читать, и помогать другим в подготовке более читабельного текста.)
Как правило, автодополнение парсит файлы ssh-конфига, достаточно начать писать хостнейм и нажать таб, чтобы имя хоста было дописано автоматически. Если этого не происходит, нужно баш этому научить.
… но форма почему-то не валидируется, якобы не указан получатель (хотя он указан). Так что придется чуть-чуть запакостить тред.
(Вообще, жаль, что на хабре до сих пор нет вики-режима, как на StackOverflow и К°. Было бы несравнимо проще и читать, и помогать другим в подготовке более читабельного текста.)
а вообще много неплохих советов. Сам я до большинства сам дошёл разными путями с одним отличием — у меня tcsh, а не bash :)
Кстати, автодополнение хостов полезно настроить не только для команды ssh, но также для sftp и scp.
Отдельно хотелось бы запросить рассказ про ssh-agent. Сам я настроил такое в XFCE, однако в Гноме было прикольнее, там парольная фраза хранилась в брелке сеанса, то есть её вообще надо было сохранить всего один раз.
Кстати, автодополнение хостов полезно настроить не только для команды ssh, но также для sftp и scp.
Отдельно хотелось бы запросить рассказ про ssh-agent. Сам я настроил такое в XFCE, однако в Гноме было прикольнее, там парольная фраза хранилась в брелке сеанса, то есть её вообще надо было сохранить всего один раз.
Еще классная штука — forced commands. Прописываем в ключах текст вроде: command="/home/remoteuser/cron/validate-rsync" (перед ключом, напр перед текстом ssh-dss .....) и удаленный пользователь автоматически будет делать эту команду.
Например, простенький веб-интерфейс (даже на другой машине) сможет коннектится на нужный сервер и добавлять-удалять правило на файрволе или ребутить машину или рестартовать апач итд, в общем — делать некоторые нужные операции, которые требуют рута. Но даже если эту машинку поломают и ключик уведут — зайти с ним на систему и сделать rm -rf не получится — только /etc/init.d/apache restart.
Например, простенький веб-интерфейс (даже на другой машине) сможет коннектится на нужный сервер и добавлять-удалять правило на файрволе или ребутить машину или рестартовать апач итд, в общем — делать некоторые нужные операции, которые требуют рута. Но даже если эту машинку поломают и ключик уведут — зайти с ним на систему и сделать rm -rf не получится — только /etc/init.d/apache restart.
Если компьютеров за NAT'ом огромное количество и каждый день подключаешься к разным, редко когда два дня подключаешься к одному и тому же — можно ли как-то пробросить в ProxyCommand и пароль к target computer?
Sign up to leave a comment.
Полезные мелочи в работе веб-разработчика или «Как я мог без этого жить»