Удобная и безопасная работа с серверами по ssh

    Так как по работе приходится много удалённо работать с unix серверами, то пришлось разобраться как это делать комфортно и безопасно и со временем возникло желание поделиться. Данная заметка не претендует на новизну информации, но мне показалось что нигде нет цельного руководства, нечто похожее есть только на английском.
    Описание тестировалось под Debian GNU/Linux с KDE, но должно подходить под основную массу unix систем/дистрибутивов/оконных менеджеров и графических сред.

    Терминал



    я использую yakuake — очень удобно быстро вызывать консоль по клавише (по умолчанию F12)

    Авторизация



    Важный принцип систем безопасности заключается в том, что они должны быть удобными, иначе ими не будут пользоваться, касательно ssh это означает, что для безопасности нужно пользоваться авторизацией по ключам с парольной фразой, а для удобства нужно хранить парольную фразу от ключа в памяти компьютера до перезагрузки (т.е. вводить её нужно один раз при запуске машины, и до следующей перезагрузки ничего вводить не придётся).
    Исходное положение:
    1. Подразумевается что удалённый ssh сервер уже настроен для авторизации по ключу (это обычно так и есть)
    2. Подразумевается что ssh-agent запускается автоматом (обычно это так и есть, проверить можно командой ps aux | grep 'ssh')
    3. Установлен пакет ssh-askpass (поставить можно командой sudo aptitude install ssh-askpass)

    Алгоритм
    1. генерим ключ
    ssh-keygen -b 4096 -t rsa
    обязательно вводим парольную фразу, иначе потеря ключа будет означать выдачу злоумышленнику всех ваши
    доступов

    2. Копируем ключ на сервер
    ssh-copy-id -i ~/.ssh/id_rsa.pub server.tld
    если юзеры на локальной машине и удалённом сервер разные, то необходимо указать и имя юзера — ssh-copy-id user@server.tld

    3. Пользователям KDE для добавления ключей при логине в папку ~/.kde/Autostart добавляем скрипт add-keys.sh со следующим содержимым
    #!/bin/bash
    /usr/bin/ssh-add


    Для пользователей GNOME есть описание.
    Также для хранения ключей в памяти можно использовать keychain.

    Завершаем сессию, входим и видим окно запроса парольной фразы, вводим её и пробуем зайти на сервер
    ssh user@server.tld
    или выполнить команду
    ssh user@server.tld uname -a

    Работа при неустойчивой связи



    При обычном интернет броузинге или скачивании файлов соответствующим софтом обрывов связи можно и не заметить, однако при работе с удалённым сервером по ssh при разрыве связи вы потеряете соединение, будут остановлены все выполняемые программы, например оборвётся запущенный скрипт, пропадут несохранённые изменения в текстовом редакторе и т.п.
    Для решения этой проблемы существует программа screen, она остаётся запущенной даже при обрыве связи и сохраняет открытыми/запущенными все приложения которые запускались в ней.

    Алгоритм
    1. запускаем screen, с виду может ничего не поменяться, но echo $TERM скажет что мы в скрине
    2. с помощью клавиатурных команд
    Ctrl+A затем «c» – создать окно screen
    Ctrl+A затем «K» – закрыть окно screen
    Ctrl+A затем «p» – переключиться к предыдущему окну screen
    Ctrl+A затем «n» – переключиться к следующему окну screen
    Ctrl+A затем «"» – выводит меню со списком окон
    Ctrl+A затем «number» – переходит на окно с нужным номером, нумерация с 0

    создаём нужно число окон, запускаем в них нужные программы, логично выработать единую систему назначения окон на всех сервера (например в окне номер 1 иметь подключение к базе, в окне номер 2 логи и т.д.).
    3. По каким-то причинам обрывается коннект
    4. Заходим на сервер, выполняем:
    screen -d -RR
    и мы снова в том же скрине со всем приложениями в том же состоянии.

    Дополнительно про screen читаем:
    man screen
    и много статей в сети, например эту.

    Обмен файлами



    Для копирования файлов на/с/между машинами существует утилита scp, утилита простая всё должно быть понятно по примеру копирования с текущей машины на удалённый сервер
    scp backdoor.sh user@server.tld:/home/user/
    с удалённого сервера на текущую (в текущую папку)
    scp user@server.tld:/etc/passwd .

    Для страдающих на MS Windows ®

    есть PuTTY:
    • PuTTY (ssh клиент)
    • PSCP (SCP клиент)
    • Pageant (аналог ssh-agent)
    • PuTTYgen (генератор ключей)

    аналог GNU screen видимо тут.

    Надеюсь кому-то будет полезным.
    Поделиться публикацией
    Никаких подозрительных скриптов, только релевантные баннеры. Не релевантные? Пиши на: adv@tmtm.ru с темой «Полундра»

    Зачем оно вам?
    Реклама
    Комментарии 38
    • 0
      Под Windows для файлового обмена по протоколу SCP и SFTP удобно использовать графическую утилиту WinSCP или WinSCP-плагин для файловых менеджеров FAR Manager или Total Commander.
      • +3
        Для файлового обмена замечательно работает FileZilla. Умеет SFTP, притом крайне качественно и кроссплатформенно =)
        • 0
          А ещё удобней монтировать сервер по sftp прямо себе в файловую систему.
          Тогда можно открывать файлы на удалённой прямо в редакторе как локальные.
          И не нужно заморачиваться со всякими [s]ftp-клиентами, копировать по сто раз файлы на сервер и проч.

          Для этого можно воспользоваться консольной утилитой вроде sshfs, либо гуёвыми типа gigolo.
          Ещё у гнома есть какой-то встроенный функционал для этого, и у kde вроде тоже.
          • 0
            У гнома есть VFS для sftp: ALT+F2, sftp://user@server:/folder — и вот смонтированная директория. Единственный минус перед sshfs — невозможность попасть туда из окна выбора файла (для открытия или сохранения)
            • 0
              На сколько я понимаю, для того, чтобы директория реально появилась в файловой системе, но поставить пакет fuse-gvfs или gvfs-fuse, как-то так.
      • +6
        А вообще статья ни о чём. Такое впечатление, что статья просто ради публикации на хабре.
        И про screen, и про работу с SSH по ключам тут были отдельные и более информативные статьи.
        • 0
          Хотелось сделать обзор всех полезных технологий для активно работающих с ssh, естественно по каждой теме есть более подробные статьи, возможно и на хабре
          • +1
            Вы действительно думаете, что активно работающие по SSH этого не знают?
            • 0
              Всё происходит постепенно, когда у тебя всего пару серваков, хватает парольной авторизации и даже не задумываешься о других вариантах, а когда их число растёт начинаешь искать более оптимальные варианты, для тех кто ещё не начал искать этот обзор будет полезен
            • 0
              Статья скорее — краткое описание основных методов работы с ssh. Очень удобно, кстати, что они все здесь собраны. Цель статьи — осветить методы работы и расставить ориентиры «куда копать дальше».
          • 0
            А теперь вопрос: в чём разница между фразой к ключу и парольной авторизацией? Я не про техническую часть, я про практическое применение.
            • 0
              1 раз ввел — дальше без пароля.
              А так каждый раз пароль.

              Я вообще несекурно ключи делаю беспарольные :)
              • +2
                Я тоже. Только у меня с каждой машины свой ключ (т.е. если я подключаюсь из дома к серверу, это не то же самое, что подключение снаружи). В случае компрометации машины нужно отозвать только один ключ, а не переделывать всё и вся.
                • 0
                  Буду считать это ответом на мой вопрос ниже. Спасибо.
              • 0
                Парольная фраза одна на ключ, который может быть на множестве серверов (одинаковый пароль на всех серверах это не самое лучшее решение) — легче запомнить и можно сделать достаточно сложной, остальное сказал ниже RainFall
              • 0
                А как лучше поступить, если есть 3 сервера, и с каждого на каждый хочется заходить без пароля?

                Сгенерить три приватных в .ssh ключа для каждого сервера, и 3 .pub также раскидать на каждый из серверов?
                • 0
                  именно так. или путем тунелирования — выбрать один главный сервер, с которого будет доступ на все сервера и на который будет доступ с любого.
                • +1
                  Для еще большего удобства можно создать файл ~/.ssh/config, поместить в него пару строк:
                  Host ex
                  HostName ssh.example.com
                  User user_name
                  Port 2002
                  

                  И коннектиться:
                  ssh ex
                  
                  • 0
                    отличное предложение: туда же можно положить и ключ
                    Host ex
                      HostName ssh.example.com
                      IdentityFile ~/.ssh/key_for_example_com
                      User user_name
                      Port 2002
                    


                    и вообще, сколько вижу этих статей про безпарольную авторизацию в ssh по ключам — очень редко кто использует ключ -f для ssh-keygen.
                    все используют дефолтную пару:
                    ~/.ssh/id_rsa{,.pub}


                    можно ведь
                    ssh-keygen -b 4096 -t rsa -f ~/.ssh/key_for_work
                    ssh-keygen -b 4096 -t rsa -f ~/.ssh/myvps
                    

                    и их использовать для разных серверов.
                    вот статейка статейка (англ, вот перевод на линсовете)
                    • 0
                      Да, весьма удобно, бывает что и юзер и порт отличаются от дефолтных
                    • +1
                      Для ОС Windows, есть еще Kitty
                      (KiTTY — это модифицированная версия программы PuTTY)
                      • +1
                        китти рулез. сам им пользуюсь.
                        • 0
                          У меня вопрос, у вас было такое, что Kitty не может отрезолвить домен? Приходится вручную писать, после этого коннект идет… но это не всегда так бывает, а временами.
                          • +1
                            домены не использую, поэтому сказать не могу. извините.
                      • +3
                        Работа с 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 эти ключи добавлять нельзя, иначе на не запароленные ключи тоже будет требоваться подтверждение.
                        • 0
                          Если вы работаете со своей машины, вы там и root, если со стороннего сервака и положили там свой закрытый ключ, то причём тут tmp файлы — рут и ключ ваш заберёт и ввод парольной фразы перехватит
                          • 0
                            Это не совсем так. Если относится к безопасности с позиции юношеского максимализма, и воспринимать сторонний сервер как шарообразную лошадь в вакууме — тогда Вы правы. Но с этой позиции что-либо защищать и шифровать вообще не имеет смысла, т.к. взломать рано или поздно можно что угодно.

                            Во-первых, ваш приватный ключ на стороннем сервере зашифрован паролем, так что несмотря на то, что root того сервера может считать этот ключ, при выборе надёжного пароля ему это не поможет — ломать перебором он его будет вечно.

                            Во-вторых, со сторонним сервером Вы работаете по ssh, так что для перехвата вашего пароля root-у потребуется заменить /usr/sbin/sshd на пропатченную им версию — а это совсем не такая тривиальная задача как доступ к чужому unix-сокету в /tmp/ssh-XXX/. Вся защита и безопасность по сути строятся как раз на усложнении, замедлении и удорожании взлома, а не гарантии невозможности взлома.

                            Ну и в-третьих, таким образом root того сервера может получить доступ только к тем Вашим приватным ключам, которые лежат на его сервере, и только тогда, когда Вы этими ключами воспользуетесь. А в случае с «ForwardAgent yes» он получит доступ ко всем ключам лежащим на Вашей рабочей станции, причём сразу, не дожидаясь пока Вы ими воспользуетесь.
                          • 0
                            для конкретного ключа, на стороне сервера, в authorized_keys можно добавить опцию
                            no-agent-forwarding ssh-rsa AAAAB3NzaC1yc2EAAAABI...(pubkey) 


                            опции для ключа, хоть и не серьезная преграда, но одно from= может отлично ограничить ценность украденного private-ключа.
                            from="192.168.0.1,192.168.0.2"  ssh-rsa AAAAB3NzaC1yc2EAAAABI...(pubkey) 


                            по опциям ~/.ssh/authorized_keys хороший конспект тут лежит.
                          • 0
                            «в ~/.kde/Autostart» Фу! А писать в .xinitrc не пробовали? Или вообще пользоваться нормальным ssh-agent`ом, и записать в .bashrc (.zshrc и т.п.)
                            • 0
                              Про ssh-agent я конечно проффтыкал, но вот в WM`овский автостарт что-то писать это извращение.
                              • 0
                                1. .xinitrc не пробовал, надо разбираться, если есть пример поделись
                                2. А чем лучше писать в .bashrc?
                                • 0
                                  .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 &
                                  • 0
                                    > Вообще-то разницы особо нет, но для гайдов лучше писать универсальный вариант.

                                    согласен, но тогда придётся сюда интегрировать гайд по .xinitrc, что наверно излишне когда есть более простой вариант
                                    • 0
                                      гайд по .xinitrc быдет выглядеть так:
                                      echo «your_command &» >> ~/.xinitrc
                                      (=
                                      • 0
                                        эксперимент с .xinitrc пока не удался
                              • 0
                                А для тех у кого нестабильный коннект есть утилита autossh
                                • 0
                                  Аналоги yakuake для Gnome — guake и tilda
                                  • 0
                                    Если ключей становится много, то есть вероятность напороться на ошибку «Too many authentication failures», как написано тут это связано с тем что по умолчанию на сервер шлются все ключи, а некоторые сервера банят после нескольких попыток, поэтому нужно добавить в конфиг строчку
                                    IdentitiesOnly yes
                                    т.е. для такого сервака в .ssh/config будет примерно так:
                                    Host ex
                                    HostName example.com
                                    IdentityFile ~/.ssh/work
                                    IdentitiesOnly yes
                                    User username
                                    Port 22

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.