Comments 39
Под Windows для файлового обмена по протоколу SCP и SFTP удобно использовать графическую утилиту WinSCP или WinSCP-плагин для файловых менеджеров FAR Manager или Total Commander.
Для файлового обмена замечательно работает FileZilla. Умеет SFTP, притом крайне качественно и кроссплатформенно =)
А ещё удобней монтировать сервер по sftp прямо себе в файловую систему.
Тогда можно открывать файлы на удалённой прямо в редакторе как локальные.
И не нужно заморачиваться со всякими [s]ftp-клиентами, копировать по сто раз файлы на сервер и проч.
Для этого можно воспользоваться консольной утилитой вроде sshfs, либо гуёвыми типа gigolo.
Ещё у гнома есть какой-то встроенный функционал для этого, и у kde вроде тоже.
Тогда можно открывать файлы на удалённой прямо в редакторе как локальные.
И не нужно заморачиваться со всякими [s]ftp-клиентами, копировать по сто раз файлы на сервер и проч.
Для этого можно воспользоваться консольной утилитой вроде sshfs, либо гуёвыми типа gigolo.
Ещё у гнома есть какой-то встроенный функционал для этого, и у kde вроде тоже.
А вообще статья ни о чём. Такое впечатление, что статья просто ради публикации на хабре.
И про screen, и про работу с SSH по ключам тут были отдельные и более информативные статьи.
И про screen, и про работу с SSH по ключам тут были отдельные и более информативные статьи.
А теперь вопрос: в чём разница между фразой к ключу и парольной авторизацией? Я не про техническую часть, я про практическое применение.
1 раз ввел — дальше без пароля.
А так каждый раз пароль.
Я вообще несекурно ключи делаю беспарольные :)
А так каждый раз пароль.
Я вообще несекурно ключи делаю беспарольные :)
Парольная фраза одна на ключ, который может быть на множестве серверов (одинаковый пароль на всех серверах это не самое лучшее решение) — легче запомнить и можно сделать достаточно сложной, остальное сказал ниже RainFall
А как лучше поступить, если есть 3 сервера, и с каждого на каждый хочется заходить без пароля?
Сгенерить три приватных в .ssh ключа для каждого сервера, и 3 .pub также раскидать на каждый из серверов?
Сгенерить три приватных в .ssh ключа для каждого сервера, и 3 .pub также раскидать на каждый из серверов?
Для еще большего удобства можно создать файл ~/.ssh/config, поместить в него пару строк:
И коннектиться:
Host ex HostName ssh.example.com User user_name Port 2002
И коннектиться:
ssh ex
Работа с ssh-agent и ssh-add на самом деле не столь проста и прозрачна.
Во-первых, есть проблема перехвата доступа к вашим ключам. Дело в том, что ssh для доступа к ssh-agent использует UNIX-socket в /tmp/ssh-XXX/, доступ к которому ограничен файловыми правами доступа. А это значит, что не только вы, но и root этой системы получает доступ везде, где есть доступ по ssh у вас. Допустим, дома вы работаете один, и root это тоже вы. Следующая проблема возникает при включённой (в /etc/ssh/ssh_config или ~/.ssh/config) опции ForwardAgent yes. Эта опция позволяет после подключения к удалённой машине по ssh сохранить доступ с той машины к вашему ssh-agent, т.е. можно без ввода пароля с той машины открыть ssh доступ к любой другой машине где у вас есть доступ. Соответственно, root того сервера (которым вы уже, как правило, не являетесь) опять же может перехватить доступ к вашим ключам. Сейчас ForwardAgent по умолчанию обычно выключен, но, насколько я помню, в старых версиях openssh он мог быть включён по умолчанию.
Во-вторых, есть несколько разных утилит ssh-askpass, через которые ssh может запрашивать пароль пользователя. Например, в портаж Gentoo есть net-misc/ssh-askpass-fullscreen и net-misc/x11-ssh-askpass. При этом первая не поддерживает некоторые спец.символы в пароле (например, табуляцию :)).
В-третьих, в некоторых системах (включая как минимум мой Gentoo) чтобы ssh-add запросил пароль через графическую askpass-утилиту, а не в текстовом режиме, необходимо запускать
Ещё, если вы используете ForwardAgent yes, а от перехвата ваших ключей пытаетесь защититься с помощью опции ssh-add -c (запрос подтверждения при каждом доступе к ключу), и некоторые из ваших ключей не запаролены (для использования из скриптов без ssh-agent), то в ssh-add эти ключи добавлять нельзя, иначе на не запароленные ключи тоже будет требоваться подтверждение.
Во-первых, есть проблема перехвата доступа к вашим ключам. Дело в том, что ssh для доступа к ssh-agent использует UNIX-socket в /tmp/ssh-XXX/, доступ к которому ограничен файловыми правами доступа. А это значит, что не только вы, но и root этой системы получает доступ везде, где есть доступ по ssh у вас. Допустим, дома вы работаете один, и root это тоже вы. Следующая проблема возникает при включённой (в /etc/ssh/ssh_config или ~/.ssh/config) опции ForwardAgent yes. Эта опция позволяет после подключения к удалённой машине по ssh сохранить доступ с той машины к вашему ssh-agent, т.е. можно без ввода пароля с той машины открыть ssh доступ к любой другой машине где у вас есть доступ. Соответственно, root того сервера (которым вы уже, как правило, не являетесь) опять же может перехватить доступ к вашим ключам. Сейчас ForwardAgent по умолчанию обычно выключен, но, насколько я помню, в старых версиях openssh он мог быть включён по умолчанию.
Во-вторых, есть несколько разных утилит ssh-askpass, через которые ssh может запрашивать пароль пользователя. Например, в портаж Gentoo есть net-misc/ssh-askpass-fullscreen и net-misc/x11-ssh-askpass. При этом первая не поддерживает некоторые спец.символы в пароле (например, табуляцию :)).
В-третьих, в некоторых системах (включая как минимум мой Gentoo) чтобы ssh-add запросил пароль через графическую askpass-утилиту, а не в текстовом режиме, необходимо запускать
ssh-add </dev/null.Ещё, если вы используете ForwardAgent yes, а от перехвата ваших ключей пытаетесь защититься с помощью опции ssh-add -c (запрос подтверждения при каждом доступе к ключу), и некоторые из ваших ключей не запаролены (для использования из скриптов без ssh-agent), то в ssh-add эти ключи добавлять нельзя, иначе на не запароленные ключи тоже будет требоваться подтверждение.
Если вы работаете со своей машины, вы там и root, если со стороннего сервака и положили там свой закрытый ключ, то причём тут tmp файлы — рут и ключ ваш заберёт и ввод парольной фразы перехватит
Это не совсем так. Если относится к безопасности с позиции юношеского максимализма, и воспринимать сторонний сервер как шарообразную лошадь в вакууме — тогда Вы правы. Но с этой позиции что-либо защищать и шифровать вообще не имеет смысла, т.к. взломать рано или поздно можно что угодно.
Во-первых, ваш приватный ключ на стороннем сервере зашифрован паролем, так что несмотря на то, что root того сервера может считать этот ключ, при выборе надёжного пароля ему это не поможет — ломать перебором он его будет вечно.
Во-вторых, со сторонним сервером Вы работаете по ssh, так что для перехвата вашего пароля root-у потребуется заменить /usr/sbin/sshd на пропатченную им версию — а это совсем не такая тривиальная задача как доступ к чужому unix-сокету в /tmp/ssh-XXX/. Вся защита и безопасность по сути строятся как раз на усложнении, замедлении и удорожании взлома, а не гарантии невозможности взлома.
Ну и в-третьих, таким образом root того сервера может получить доступ только к тем Вашим приватным ключам, которые лежат на его сервере, и только тогда, когда Вы этими ключами воспользуетесь. А в случае с «ForwardAgent yes» он получит доступ ко всем ключам лежащим на Вашей рабочей станции, причём сразу, не дожидаясь пока Вы ими воспользуетесь.
Во-первых, ваш приватный ключ на стороннем сервере зашифрован паролем, так что несмотря на то, что root того сервера может считать этот ключ, при выборе надёжного пароля ему это не поможет — ломать перебором он его будет вечно.
Во-вторых, со сторонним сервером Вы работаете по ssh, так что для перехвата вашего пароля root-у потребуется заменить /usr/sbin/sshd на пропатченную им версию — а это совсем не такая тривиальная задача как доступ к чужому unix-сокету в /tmp/ssh-XXX/. Вся защита и безопасность по сути строятся как раз на усложнении, замедлении и удорожании взлома, а не гарантии невозможности взлома.
Ну и в-третьих, таким образом root того сервера может получить доступ только к тем Вашим приватным ключам, которые лежат на его сервере, и только тогда, когда Вы этими ключами воспользуетесь. А в случае с «ForwardAgent yes» он получит доступ ко всем ключам лежащим на Вашей рабочей станции, причём сразу, не дожидаясь пока Вы ими воспользуетесь.
UFO just landed and posted this here
«в ~/.kde/Autostart» Фу! А писать в .xinitrc не пробовали? Или вообще пользоваться нормальным ssh-agent`ом, и записать в .bashrc (.zshrc и т.п.)
Про ssh-agent я конечно проффтыкал, но вот в WM`овский автостарт что-то писать это извращение.
1. .xinitrc не пробовал, надо разбираться, если есть пример поделись
2. А чем лучше писать в .bashrc?
2. А чем лучше писать в .bashrc?
.xinitrc — автоматически запускает разные приложения при старте иксов (т.е. независимо от того kde вы используете или гном). Вообще-то разницы особо нет, но для гайдов лучше писать универсальный вариант. Правда не знаю наверняка… Т.е. если KDE стартует через startx, то ~/.xinitrc наверняка исполняется. А вот если через KDM, то я не уверен.
Просто надо написать что запускать, ну и не забыть послать процессы в фон.
Например:
xrdb -merge .Xdefaults &
xsetroot -solid midnightblue &
feh --bg-scale /home/imp/atoplevel/BGs/mossy-16-8.jpg &
stalonetray &
Ну а в вашем случае надо ssh-add запускать
numlockx &
Просто надо написать что запускать, ну и не забыть послать процессы в фон.
Например:
xrdb -merge .Xdefaults &
xsetroot -solid midnightblue &
feh --bg-scale /home/imp/atoplevel/BGs/mossy-16-8.jpg &
stalonetray &
Ну а в вашем случае надо ssh-add запускать
numlockx &
А для тех у кого нестабильный коннект есть утилита autossh
Аналоги yakuake для Gnome — guake и tilda
Если ключей становится много, то есть вероятность напороться на ошибку «Too many authentication failures», как написано тут это связано с тем что по умолчанию на сервер шлются все ключи, а некоторые сервера банят после нескольких попыток, поэтому нужно добавить в конфиг строчку
т.е. для такого сервака в .ssh/config будет примерно так:
IdentitiesOnly yesт.е. для такого сервака в .ssh/config будет примерно так:
Host ex
HostName example.com
IdentityFile ~/.ssh/work
IdentitiesOnly yes
User username
Port 22Sign up to leave a comment.
Удобная и безопасная работа с серверами по ssh