Сегодня ради забавы рассмотрим, как можно подключить удаленный каталог SSHFS на фряхе. Недавно наткнулся на неплохой сервис онлайн хранилища, который предоставляет доступ с использоватением SSHFS, и где можно зарегать бесплатный аккаунт на 1G места. Самое оно для экспериментов. Рассмотрим по шагам, как можно подрубить к своей фряхе аккаунт стронгспейса в деталях.

Будем исходить из того, что у нас установлена чистая FreeBSD 8.2 без пакетов и исходников. Подготовка для работы с портами фряхи (загрузка портов, установка утилиты управления портами portmaster):

# portsnap fetch extract
 # cd /usr/ports/ports-mgmt/portmaster/ && make install clean

Для того, чтобы можно было монтировать файловую систему SSHFS, нам нужно поставить FUSE. Для сборки FUSE необходимы исходники пространства ядра и пользователя. Ставятся они так sysinstall -> configure -> distributions -> src -> all. Теперь можно собрать утилиту для работы с SSHFS:

# portmaster sysutils/fusefs-sshfs

Произведем тюнинг, чтобы можно было монтировать файловую систему из под обычного пользователя. Для разрешения пользователям монтирования файловых систем выполняем:

# sysctl vfs.usermount=1

Для перманентного действия этой шутки редактируем /etc/sysctl.conf, добавляя туда строку «vfs.usermount=1». Для того, чтобы пользователю было разрешено работать с девайсом FUSE, необходимо изменить права:

# devfs ruleset 10
 # devfs rule add path 'fuse*' mode 666

Создаем папку, куда будем монтировать нашу удаленную файловую систему (из под нужного пользователя), подключаем удаленную папку:

$ mkdir /home/kavolorn/sshfs
 $ sshfs -o uid=1003 -o gid=1003 -o allow_other
 [email protected]:/strongspace/kavolorn/home
 /home/kavolorn/sshfs/

Стронгспейс запросит ваш пароль, после введения которого смонтируется файловая система. Собственно все. Единственное неудобство — запрос пароля. Для того, чтобы его не было, можно через веб интерфейс в аккаунте стронгспейса добавить ваш публичный ключ, который можно сгенерировать следующим образом:

$ ssh-keygen

Автоматическое монтирование при загрузке фряхи оставим на домашнее задание 🙂
Оригинал: kavolorn.ru/post/show/postId/124

Положим, что нам необходимо периодически переносить данные с сервера источника (Server1) на сервер приемник (Server2). Обычно это может потребоваться для сохранения бекапов или синхронизации каких-то данных. Для этой цели предлагается использовать команду rsync и соединяться с удаленным сервером через SSH. В обычном режиме при соединении через SSH второй сервер будет запрашивать пароль, то есть требовать дополнительные действия от пользователя. Это не подходит для автоматизированного переноса данных. Поэтому процедура слегка усложняется.

Дано:

Server1 (источник)
 User: user1
 Password: pass1
 Папка для переноса: /backup/arch/

Server2 (приемник)

 User: user2
 Password: pass2
 Папка для приема информации: /hdd2/get/

1) Логинимся через SSH на Server1.
2) Server1: cd ~/
3) Server1: mkdir .ssh

Замечение: иногда из под текущего юзера это сделать невозможно (например при работе из под Plesk), в этом случае папку необходимо создавать из под root.
4) Server1: ssh-keygen -t rsa
Наберите в качестве пути ./.ssh/id_rsa
Затем два раза Enter
5) Переносим любым способом ~/.ssh/id_rsa.pub на Server2. Предположим, что мы положили его в папку /hdd2/
6) Server2: cd ~/
7) Server2: mkdir .ssh
8) Server2: cat /hdd2/id_rsa.pub >> ./.ssh/authorized_keys
Если файл не существует, то он автоматически будет создан
9) Server2: chmod 700 ./.ssh/authorized_keys
Необходимо в целях безопасности
10) Далее используем команду rsync с первого сервера. Для начала рекомендуется проделать это один раз вручную, во-первых, что бы проверить, как все работает, во-вторых, иногда требуется создать автоматический batch-файл, который для своего создания в первый раз требует выбрать yes или no вручную:

Server1: nice -n +17 rsync -avz /backup/arch/ user2@Server2_IP:/hdd2/get/

Замечание: рекомендуется использовать nice что бы процесс копирования шел в фоновом режиме.
11) Теперь можно приступить к автоматизации через cron. Запишите эту команду в файл “rsync.sh”.

Внимание зачастую для корректной работы требуется прописать полные пути до nice и rsync. В моем случае пути такие:

 /bin/nice -n +17 /usr/bin/rsync -avz /backup/arch/ user2@Server2_IP:/hdd2/get/

12) Создаем файл cron.txt со следующим содержимым (что бы не мучиться в редакторе vi)

 30 5 * * * /bin/sh /backup/rsync.sh

Эта команда означает, что бэкап будет выполняться каждый день в 5-30 утра.

Далее записываем cron для текущего юзера:
Server1: crontab /backup/cron.txt

Заключение: для более гибкого управления переносом данных смотрите документацию по cron и rsync.

Оригинал: zcontest.ru/data/005_rsync_ssh_backup.php

Беспарольный ssh достаточно частое явление в жизни системного администратора unix. Я бы даже сказал, что такое соединение в какой-то степени более надежное чем вход по паролю. Ведь пароль можно подсмотреть или просто подобрать. А при беспарольном соединении на сервере должен находиться публичный ключ, а на клиенте секретный ключ. Вход без ключа отключить. И тогда если у тебя нет ключика на сервер и не попасть по ssh
А еще можно связку ключ-публичный ключ обезопасить парольной фразой, тогда точно авторизация ssh будет криптостойкой.

Генерируем пару ключей для такого ssh соединения. Выполнять команду будем на клиенте (на той машине откуда будем выполнять ssh соединение), ведь именно тут будет храниться наш секретный ключ. Убедимся что директория .ssh создана в вашем домашнем каталоге и имеет права 600. Теперь выполняем

mik@m1k:~$ ssh-keygen -t dsa -b 1024 -f /home/user/.ssh/id_dsa
Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
95:e8:94:83:74:5c:63:0a:e1:4d:6d:77:30:86:aa:7b mik@m1k
The key's randomart image is:
+--[ DSA 1024]----+
|      +ooo+.+.   |
|     o *.=++...  |
|      o Boo. .   |
|       o.o       |
|       .S        |
|      .          |
|       .         |
|      . E        |
|       .         |
+-----------------+

Парольную фразу не указываем, нажимаем Enter.

• -t dsa — тип ключа. Есть rsa и dsa. Dsa это для второй версии ssh, которая сейчас везде по умолчанию. Rsa  — первая версия ssh.
• -b 1024 длина ключа
• -f /home/user/.ssh/id_dsa — каталог где будет сохранен ключ id_dsa и его публичный ключ id_dsa.pub

Получаем два файла id_dsa и id_dsa.pub. PUB ключ — это публичный, а id_dsa секретный. Переносим файл id_dsa.pub на сервер, куда мы будем подключаться в директорию /home/user/.ssh/ того пользователя под которым мы будем соединяться по ssh.

Теперь надо изменить конфигурацию ssh сервера (файл /etc/ssh/sshd_config) той машины куда мы перенесли публичный ключ. Раскомментируем строки по которым мы разрешим использовать ключи, запретим логиниться по ssh пользователю root.

PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PermitRootLogin no

Обязательно после изменения конфига ssh перезапускаем сервер ssh. Для linux и freebsd можно использовать команду

#killall -HUP /usr/sbin/sshd

Возвращаемся к нашему публичному ключу. Переименовываем ключ id_dsa.pub в файл authorized_keys, назначаем файлу правами 600 и оставляем файл в папке /home/user/.ssh.

Пробуем соединиться с нашей машины

mik@m1k:~# ssh -i /home/user/.ssh/id_dsa [email protected]
The authenticity of host '[192.168.0.1]:22 ([192.168.0.1]:22)' 
can't be established.
RSA key fingerprint is be:68:fe:64:bb:62:d6:d8:a9:62:3e:76:17:85:76:94.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[192.168.0.1]:22,[192.168.0.1]:22'
 (RSA) to the list of known hosts.
Last login: Thu Jul 29 11:12:22 2010 from mik.localhost
Linux 2.6.29.6-gw-smp.
mik@gw:~$

Первый раз спросит подтверждение на соединение. После ответа yes мы должны попасть на удаленную машины безо всякого пароля.
Кстати, в вышепреведенном случае местоположение нашего секретного ключа «-i /home/user/.ssh/id_dsa» можем не указывать. Я специально назвал его id_dsa, что является названием по умолчанию. При указании другого файла, например для соединения со второй машиной по ключу, получится что название по умолчанию id_dsa уже занято. Так что будьте готовы что для конкретного соединения надо будет указывать свой ключ.

Если в конфиге sshd_config на удаленной машине, где мы уже правили конфиг, выставить

UsePAM no

Тогда уже, кроме как по ключу, попасть на эту машину и не сможем.

Наверное вы уже поняли, что если при создании ключа набрать парольную фразу, тогда при соединении с машиной от вас будет требоваться парольная фраза. Остальные действия с ключами аналогичные.
И теперь помните, если хотите заходить на сервер с разных компьютеров, то на каждый компьютер надо переносить id_dsa секретный ключ. Я бы рекомендовал носить его на флешке, а флешку не терять

Оригинал: ruunix.ru/642-ssh-bez-paroly-ili-po-kluchu.html