Удаленный доступ из Windows на FreeBSD для начинающих

Однажды надо было наладить удаленный ssh-доступ на рабочей машине под Win ХР к удаленному компьютеру под управлением FreeBSD.
Отдельных мануалов работе во Фрюшке, генерации ключей в OpenSSL и т.д очень много, но подходящего для данной ситуации не нашлось, поэтому я решила свести отдельные инструкции воедино.
Далее — описание всего процесса от подготовки платцдарма до проверки работоспособности.

Часть 1, подготовительная. Создание пользователя и наделение его необходимыми правами.

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

% sudo adduser
далее пойдут вопросы, на которые можно ответить примерно так:
Username: shurchik
Full name: (на него можно не отвечать, это инфа для профиля пользователя),
UID (Leave empty for default): (разрешаем системе самой выбрать свободный идентификатор, пропускаем это),
Login group [shurchik]: wheel (сюда вписываем основную группу пользователя, по умолчанию она равна имени пользователя, но для создания системного администратора лучше поместить его в группу wheel),
Login group is wheel. Invite shurchik into other groups?: (Запрос тоже можно пропустить, поскольку не надо включать этого пользователя в другие группы. Потом тоже можно обавить его в группы),
Login class [default]: (Его тоже пропускаю, но теоретически можно задать локаль – раскладку и язык пользователя, сказав russian.),
Shell (sh csh tcsh bash nologin) [sh]: bash (Это запрос о командной оболочке, можно оставить и shell, который идет по умолчанию, но более удобный bash или zsh),
Home directory [/home/shurchik/]: (Если эта домашняя директория устраивает, то нажимаю Enter, если нет – пишу другую, например, /home/test/),
Home directory permissions (Leave empty for default): (можно принудительно задать права доступа, но я оставляю все как есть по умолчании),
Use password-based authentication? [yes]: (тоже оставляю по умолчанию, поскольку иначе войти обычным способом в систему не смогу),
Use an empty password? (yes/no) [no]: (тоже оставляю по умолчанию, поскольку вход без пароля не имеет смысла),
Enter password: (ввести пароль для пользователя, но учитывать, что пароль при вводе никак не обозначается, даже звездочками),
Enter password again: (тут тоже все понятно, повторить пароль),
Lock out the account after creation [no]:

После всего в терминале появится профиль пользователя с вопросом, согласны с ним или нет:
Username: shurchik
Password:******
Full name:
UID: 1010
Class:
Groups: wheel
Home directory: /home/shurchik/
Home mode:
Shell: /bin/bash
Locked: no
OK? (yes/no):

Набираю yes

Adduser: INFO: Successfully added (shurchik) to user database.
На новый запрос о создания еще одного пользователя ответить no:
Add another user? (yes/no): no
Goodbye!


Для того, чтобы свежесозданный user имел право на sudo надо либо всю группу wheel прописать в файле sudoers, либо только самого пользователя.
Это делается так:
В файле /PCBSD/local/etc/sudoers раскомментировать строку
% wheel ALL=(ALL) NOPASSWD: ALL
(Это означает, что теперь доступ к sudo (superuser do) открыт для всех членов группы wheel без пароля),
! Изменения в файле sudoers вступают в силу сразу же после его сохранения. Необходимо поставить на него права 440.

Теперь войдем в систему под новым пользователем:
% su shurchik
password:


Можно узнать, какие команды доступны этому пользователю
% sudo –l
Можно вывести список всех групп и их членов:
% less /etc/group

Часть 2, основная. Настройка работы демона sshd.
Генерация private и public key.

Работать я буду с программой Openssh.

1. Настройка программы ssh
Открыть 22 порт на шлюзе.

Сначала проверим, запущен ли демон на сервере. (Демона ssh зовут sshd)
Способы:
% ps auwx | grep sshd

Или
% sockstat -4l | grep :22
Если выведет:
sshd …tcp4 :22
значит, 22 порт слушается (по умолчанию. ssh идет через этот порт)
Если порт не слушается, значит, демон ssh не запущен.
Или же можно просто дать команду:
% sudo /etc/rc.d/sshd start
Если выругается, значит, надо изменить конфигурационный файл.

Тогда идем в конфигурационный файл rc.conf.local (Расположен в /etc). Если его еще нет, то создаем его и прописываем там sshd_enable = ”YES”. (Можно вместо этого такую же строку написать просто в rc.conf.)
Это нужно для того, чтобы можно было запускать демон ssh командой start. Изменения вступают в силу сразу же.

Теперь снова дадим команду запуска ssh:
% sudo /etc/rc.d/sshd start должен запуститься.
Теперь снова проверить его работу, слушается ли 22 порт:
% sockstat -4l | grep :22
Должен вывести:
sshd …tcp4 :22
Кроме того, можно дать команду, например, соединиться с локалхостом:
% ssh localhost
Если идет ..connection refused, значит, ssh не запущен. И надо снова смотреть конфиг.

2. Генерация ключей
Даем команду сгенерировать ключи:
% ssh-keygen
По умолчанию способ шифрования rsa. Чтобы сгенерировать, например, методом шифрования dsa, надо сказать % ssh-keygen –t dsa
Начнется генерация пары ключей private key/public key.
Скажет:
Enter passphrase: (лучше длинную и сложную)
Генерируются ключи в директории ~/.ssh (/home/shurchik/.ssh).

Теперь проверим, что там лежит:
% ls –l ~/.ssh
id_rsa – это private key (может называться, например, просто rsa),
id_rsa.pub – это public key (может называться, например, rsa.pub).

Далее надо положить публичный ключ на сервер в понятном тому виде. Для этого делаем следующее:
Добавляем содержимое файла id_rsa.pub к содержимому файла authorized_keys.
Это делается командой:
% cat id_rsa.pub >> authorized_keys
Она добавляет содержимое id_rsa.pub в конец файла authorized_keys. А если его нет, то создает. cat – сокращение от слова concatenate.

Если файла authorized_keys вообще нет, то можно его создать копированием id_rsa.pub:
% cp id_rsa.pub authorized_keys

Проверим еще раз содержимое папки .ssh:
% ls –l ~/.ssh
(Должно быть примерно следующее)
id_rsa
id_rsa.pub
authorized_keys


Файл authorized_keys оставляем на удаленном компьютере, а id_rsa и id_rsa.pub сохраняем куда-нибудь в другое место и удаляем из папки ~/.ssh. Важно не потерять публичный ключ, потому что в противном случае придется все генерировать заново.
И, напоследок, узнаем название хоста на удаленной машине (он нужен при подключении через ssh), после чего перейдем к рабочему компьютеру и будем мучать уже его.
% hostname
testhost


Теперь узнаем ip-адрес компа:
% host testhost

!Note: FreeBsd7 использует способ шифрования des-, который совместим с программой Putty. А вот FreeBsd9 уже использует другой способ шифрования, который данная программа не распознает. Поэтому в такой случае придется генерировать ключи уже в самой программе putty-gen, а потом их конвертировать в вид, понятный Юниксу.

3. Преобразование закрытого ключа в формат, понятный программе Putty.
(На Windows)
Скачать программу Putty, установить ее. Принести свежесгенерированный ключ на машинку с Windows. Putty понимает ключи только одного формата (своего=) .ppk

Запустить программу Putty-gen (устанавливается одновременно с основной или по отдельности).
а. File-load private key (поскольку у меня Putty установлена именно на рабочей машинке, которой требуется именно закрытый ключ, то конвертируем его.)
б. Save private key (например, id_rsa.ppk)

Часть 3, торжественная. Настройка Putty и установление шифрованного удаленного соединения.

1. Запустить Putty.
Настройки следующие:

Session: hostname testhost (или ip)

Logging: какие-нибудь логи, по желанию + отметить always overwrite it (или append to the end of it), чтоб не спрашивал каждый раз, перезаписывать ли логи;

Window: translation utf-8

Connection: auto-login username shurchik

SSH: browse… указать путь к файлу id_rsa.ppk (может лежать где угодно, putty абсолютно безразлично., откуда его брать.)

И теперь все сохраним:
Session: Saved sessions: new (задать имя этой сессии), нажать Save, сессия new появится в списке.
Чтобы потом ее вызвать, не настраивая все заново, после запуска Putty просто выбрать new из списка и нажать Load.
Теперь нажать Open и откроется терминал с просьбой ввести pass-фразу.
Если что-то с ключами пойдет не так, то программа, ругнувшись, запросит логин и пароль (shurchik и пароль к нему).

2. В конце можно запретить обращаться по шифрованному соединению на удаленный компьютер по логину-паролю (оставив только возможно подключения по пассфразе.)
На удаленном компьютере заходим в конфигурационный файл ssh:
/etc/ssh/sshd_config.
Там надо дописать (или раскомментировать) строку:
UsePAM no.

После чего надо перезапустить ssh:
% sudo /etc/rc.d/sshd stop
% sudo /etc/rc.d/sshd start


Всё!
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 22

    +1
    Это, видимо, самый подробный пост про настройку ssh и putty. Вы девушка? Удивлен.
      0
      Да, девушка:)

      Хм, интересно, с этим связан минус в карму?
        –2
        Если что, я приятно удивлен.
        Когда моя карма спустилась ниже нуля, меня стали воспринимать с плохой стороны.
          0
          Вопрос про карму был мыслью вслух!
          Не обижайтесь, я совсем не Вас имела в виду.
      +5
      Я, возможно, буду занудой, но не проще ли запустить (если речь идет о FreeBSD) /usr/sbin/sysinstall, поставить галочку в Configure -> Networking напротив sshd при установке (или позже; в последнем случае запустить sshd командой /etc/rc.d/sshd start), при первом старте будут созданы ключи; далее там же (в sysinstall) создаем пользователей, если еще не сделали, запускаем putty на виндовой машинке, указываем адрес машины с FreeBSD, после чего путти интересуется, не хотим ли мы добавить новый ключ и после согласия выдает строку с приглашением ввести имя пользователя\пароль?..

      Или я чего-то не понимаю? :-[
        +3
        У вашего варианта есть серьезный недостаток. В нем отсутствует торжественная часть.
          +2
          Пост из 3 строк не поможет попасть на хабр.
            –2
            Про путти я примерно то же самое и имела в виду, просто описала чуть подробнее.

            А про sysinstall надо подумать, спасибо!
              –4
              Если я правильно поняла, то sysinstall — лишь графическая оболочка, а суть та же, так что это дело вкуса.
                0
                За самоотверженность и терпение поставил вам плюс в карму, но… начал писать и решил, что незачем это тут делать, если интересно подискутировать — пишите в личку. :)
              +8
              Раньше было: установил Linux — отпишись на Хабр.
              Теперь: настроил SSH-подключение — отпишись на Хабр.
              Что ж, похоже, Хабр выходит на принципиально новый уровень!
                +1
                Ну кстати смотря какой Linux. Помню как-то лишь с пятого раза по инструкции смог установить Gentoo, потому что не понимал, где в #make menuconfig включить поддержку контроллера моего винчестера. А еще как-то помнится Linuxcenter продавал диск коллекционный, который назывался SexLinux и содержал наиболее нестабильный на тот момент код ядра Linux и сопутствующего ПО. Там вообще в аннотации было написано, что, если вы сможете установить его с первого раза, то вам памятник нужно ставить.
                0
                Когда нужно было сделать удаленный доступ на фряшку, сделал это за пару минут. При том, что видел линуховую ось второй день. Даже написать неочем:(
                0
                Пару замечаний:
                По дефолту у FreeBSD кодировка — koi8, и в putty надо выставлять именно ее, а не utf8
                По дефолту ssh у многих дистрибутивов слушает все порты
                Также в путти надо не забыть установить режим для функциональных клавиш — Xterm R6, иначе не будут работать F1-F12
                Перегружать sshd можно проще —
                service sshd reload
                  0
                  >По дефолту ssh у многих дистрибутивов слушает все порты

                  Серьезно? Что за дистрибутивы?
                    0
                    Извините, очепятка.
                    По дефолту ssh у многих дистрибутивов слушает все сетевые интерфейсы.
                  0
                  По дефолту ssh у многих дистрибутивов слушает все сетевые интерфейсы.
                    0
                    Cтавить основной группой пользователя «wheel», не рекомендуется.
                    Лучше вписывать его в приглашении «Login group is %username%. Invite %username% into other groups?»
                    Это касается и остальных *nix-like ОС.
                      0
                      А на что влияет, дефолтной группой пользователя ставить wheel или дополнительной?
                        +1
                        На удобство управления политиками доступа. Ну, например, вы передумаете давать этому пользователю судиться (sudo) и/или сушиться (su). В большинстве *nix-like OS это можно только пользователям группы wheel.
                        +
                        У пользователя, хоть он и админ, должна быть СВОЯ группа. Для хоть какой-то приватности данных. А так, все его файлы будут принадлежать юзеру и группе wheel.
                        Иначе, если вы его решите ограничить, вам придётся создать отдельную группу и изменить владельца для ВСЕХ файлов которые он создал (если нет наследования владельца от директорий).

                        P.S. Админы приходят и уходят, а сервера остаются.
                    • НЛО прилетело и опубликовало эту надпись здесь

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

                      Самое читаемое