Android ssh port forwarding

Запускаем SSH сервер на Android устройстве с использованием Termux

У меня часто бывают ситуации, когда мне приходится исправлять или дополнять свой код с чужого ПК. Однако, не на всех рабочих станциях есть мое рабочее окружение. Также, установка нужных компонентов, а потом их удаление занимает лишнее время. Поэтому мне в голову пришла идея — сделать удаленное рабочее окружение, которое всегда будет рядом.

С этим мне решил помочь Termux.

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

Итак, приступим.

Нам понадобится сам эмулятор терминала Linux — Termux. Это отличное мобильное приложение, которое подходит не только для сервера, но и для других целей.

Изначально нужно установить OpenSSH пакет.

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

В директории .ssh создалось два файла — id_rsa и id_rsa.pub . Копируем содержимое файла id_rsa.pub в файл authorized_keys .

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

Если вам надо посмотреть включен сервер или выключен.

Подключение к серверу с помощью PuTTY.

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

Далее, копируем ключ в память.

После этого, копируем файл на машину.

Теперь нам понадобится PuTTYgen.
Запускаем программу и загружаем файл, нажимая на кнопку Load. После этого сохраняем приватный ключ (save private key) в формате *.ppk.

Отлично, теперь у нас есть ключ. Осталось только подключиться.

Скачаем сам PuTTY.
Запускаем его. В поле IP адреса вводим локальный адрес нашего Android устройства. Чтобы посмотреть локальный адрес, нужно зайти в Termux и ввести команду.

В разделе wlan0 будет написан локальный IP адрес.

В поле порта вводим стандартный порт для ssh сервера — 8022. Далее, переходим в SSH → Auth и нажимаем кнопку Browse.

Находим тот файл, который сохранили в формате *.ppk, и нажимаем Open. После запуска нажимаем Enter.

Все, мы подключились.

Далее вы можете настроить ваше окружение и подключаться к нему в любое время.

Источник

Android ssh port forwarding

Для функционирования программы необходимы права root пользователя.

Краткое описание:
Создание SSH-туннелей

Описание:
SSH предоставляет безопасное шифрованное соединение с сервером, которое используется приложением для создания SSH-туннелей. Идея SSH-туннелей в том, что бы безопасно передавать трафик в незащищённой среде (например, мобильные сети или публичные WiFi точки) на доверенный сервер, а с него уже на необходимый интернет-ресурс.

Требуется Android: 2.1
Русский интерфейс: Нет
Лицензия: GPLv3

Скачать: версия: 1.5.6
sshtunnel 1.5.6.apk ( 1.1 МБ )

Сообщение отредактировал gim0 — 29.04.14, 06:34

Инструкции по разным вопросам

Q: Зачем это мне?
A: Мы все пользуемся интернет-ресурсами и постоянно передаём/получаем разного рода конфиденциальную информацию из интернета, но не каждый знает, что не всегда эта информация достаточно защищена от злоумышленников. Дело в том, что чаще всего пароли и прочая информация передаётся в незашифрованном виде. Во время подключения через мобильные сети (например 3G) есть серьёзный потенциальный риск того, что в данный момент злоумышленники перехватывают весь трафик, передающийся по воздуху. В случае же публичных или любых других незнакомых вам WiFi точек, администратор точки может получить доступ к любой незашифрованной информации, которая проходит через эту точку. С помощью данного приложения и SSH технологии, вы можете обезопасить себя от подобных угроз. Более того, с помощью этой технологии вы можете обойти любые фильтры трафика на любом уровне.

Q: В чём преимущество по отношению к VPN-туннелю?
A: В действительности, преимуществ нету, даже наоборот. Если у вас есть возможность использовать VPN, то советую использовать именно его в связи с его универсальностью и поддержкой многими программами по стандарту. Используйте SSH-туннели только если нету других вариантов.
Подробнее про Android и VPN можно узнать тут — Подключение к виртуальным частным сетям (VPN)

Q: Что если у меня нет возможности держать SSH-сервер?
A: В таком случае вы всегда можете арендовать сервер за отдельную плату у любого хостинга, предоставляющего такую возможность.

Q: Туннель создается, но на сайты не зайти. Что делать?
A: Есть вероятность что проблема с соединении с DNS. Попробуйте отключить опцию в приложении «Enable DNS Proxy».

DD-WRT — это свободная продвинутая прошивка для многих беспроводных маршрутизаторов (роутеров). См. Википедию и Официальный сайт. С некоторых пор настройка и запуск SSH-сервера осуществим очень быстро и легко с помощью панели управления.
Преимущество SSH-сервера, работающего на роутере, в том, что роутер, как правило, работает круглосуточно. Таким образом можно в любое время и в любом месте использовать SSH-туннель, без необходимости оставлять включенным ваш ПК или аренды отдельных серверов. Предположим, что на вашем роутере установлена прошивка DD-WRT. Обратите внимание, что все нижеуказанные действия осуществляются только когда вы в данный момент подключены к интернету через ваш роутер.

1. Заходим в панель управления. Обычно она находится по адресу http://192.168.1.1/, вводим логин и пароль.
2. Первым делом нужно активировать SSHd сервис. Заходим во вкладку Services.
3. Находим блок «Secure Shell» и включаем его. Появятся следующие опции:
   

4. Включаем опцию «Password Login»
5. В самом низу страницы жмём «Save»
6. Далее нам нужно позволить удалённое подключение к SSH. Переходим во вкладку «Administration».
7. Находим блок «Remote Access» и включаем опцию «SSH Management» и «Allow Any Remote IP»:
   

8. Порт по стандарту 22, если нет необходимости то оставляем как есть.
9. В самом низу страницы нажимаем «Apply Settings».
10. Ждём перезагрузки роутера.

Готово! Теперь на вашем роутере работает SSH-сервер, к которому можно в любой момент подключиться и использовать для создания туннеля.
Параметры вашего SSH-сервера:

• IP-адрес: Можно узнать зайдя на сайт WhatIsMyIP.
• Порт: 22 — по стандарту если он не был изменён.
• Логин: тот же логин, который вы использовали для входа в панель управления (по стандарту обычно root).
• Пароль: тот же пароль, который вы использовали для входа в панель управления.

Полезные ссылки:

• SSH-туннель домой без необходимости оставлять включённым домашний ПК

Хотелось бы добавить:

• Инструкция по установке и настройке SSH-сервера в GNU/Linux
• Инструкция по установке и настройке SSH-сервера в Windows
• Инструкция по созданию и использованию OpenSSH ключей

Сообщение отредактировал gim0 — 22.05.16, 12:28

Оно (было) с рекламой? Натравил на него LBE Security сразу как поставил, рекламы ни разу не видел.

Заметил, что с ним инет гораздо отзывчивее работает. Может, какое-то сжатие в туннеле присутствует?

Нет, никогда там нету и небыло реклам. Важно отметить что это свободное программное обеспечение :yes2:

Источник

Android ssh port forwarding

Automatically exported from code.google.com/p/sshtunnel

SSH Tunnel for Android System

SSHTunnel is a SSH tunnel app for Android System, based on Connectbot and Dropbear / OpenSSH (Beta Branch). With this app and a configured server (typically configured with sshd and nginx / squid), you can easily browse internet through a SSH tunnel on your android devices.

SSHTunnel is using redsocks (http://darkk.net.ru/redsocks/) to redirect all traffic on Android. You can check out its source codes from: https://github.com/darkk/redsocks

Currently, the latest sshtunnel source codes can be found here: https://bitbucket.org/madeye/sshtunnel and the latest sshtunnel-beta can be found here: https://github.com/madeye/sshtunnel-beta

Notice If you want to set up your own VPS to work with this app, please install and configure HTTP PROXY on your VPS first (typically squid or nginx). To support HTTPS (SSL), you must configure your http proxy to allow CONNECT Method on 443 port

Considering the poor performance of dynamic port forwarding on most android devices, we suggest you to use a transparent proxy set up in the SSH server and use local port forward to proxy data through SSH tunnel.

To work with your private/public key, please store your key (only OpenSSH format, not putty) as the file /sdcard/sshtunnel/key

If you run into application problems Please, please send us relevant logcat dumps when you have a crash. Here’s how to get a logcat dump:

Enable USB debugging. Go into Settings, Applications, Development, and enable the «USB debugging» option.

Install the Android SDK. You’ll need a desktop tool called adb that will help you get error logs.

Make sure your phone can connect. Follow the instructions here to make sure that adb can talk with your device:

1. Dump logcat data. From your desktop console, type ./adb -d logcat | grep -i SSHTunnel. Make sure it’s showing some data, then copy everything into a text file and attach to your bugreport here on this site. CAREFULLY read over the logs for any sensitive information BEFORE posting. You might need to Ctrl+C to quit adb once it stops printing data.

Источник

Магия SSH

С SSH многие знакомы давно, но, как и я, не все подозревают о том, какие возможности таятся за этими магическими тремя буквами. Хотел бы поделиться своим небольшим опытом использования SSH для решения различных административных задач.

1) Local TCP forwarding

Начнем с простого — local TCP forwarding:

Имеем удаленный сервер «host2» с неким приложением, допустим, PostgreSQL server, которое принимает TCP-соединения на порту 5432. При этом вполне логично, что на этом сервере стоит файрвол, который прямых соединений извне на порт 5432 не разрешает, но при этом есть доступ по SSH (по-умолчанию порт 22, рекомендую его изменить). Требуется подключиться с нашего рабочего места «host1» клиентским приложением к серверу PostgreSQL на «host2».

Для этого на «host1» в консоли набираем:

host1# ssh -L 9999:localhost:5432 host2

Теперь на «host1» мы можем соединяться с PostgreSQL сервером через локальный порт 9999:

host1# psql -h localhost -p 9999 -U postgres

Мы также можем соединяться с приложением не на самом «host2», а на любой доступной ему машине:

Для этого при пробросе портов вместо «localhost» указываем имя хоста, например «host3»:

host1# ssh -L 9999:host3:5432 host2

Тут важно заметить, что «host3» должен быть известен (если это имя, а не IP-адрес) и доступен для машины «host2».

Также можно через «host1» предоставить доступ любому другому узлу (назовем его «host1A») к сервису на «host3»:

Для этого нужно вставить в команду соединения ssh IP-адрес интерфейса, на котором будет поднят локальный порт 9999:

ssh -L 0.0.0.0:9999:host3:5432 host2

В данном примере порт 9999 будет открыт на всех доступных на «host1» IPv4 интерфейсах.

2) Remote TCP forwarding

Но что делать, если, например, «host2» не имеет белого IP-адреса, находится за NAT или вообще все входящие соединения к нему закрыты? Или, например, на «host2» стоит Windows и нет возможности поставить SSH-сервер?

Для этого случая есть Remote TCP forwarding:

Теперь нужно устанавливать ssh-соединение в обратном направлении — от «host2» к «host1». Т.е. наша административная рабочая станция будет SSH-сервером и будет доступна по SSH с «host2», а на «host2» нужно будет выполнить подключение SSH-клиентом:

ssh -R 9999:localhost:5432 host1

Например, в PuTTy это делается так:
Идем по дереву настроек: Connection → SSH → Tunnels.
Далее в поле «Source port» вбиваем 9999, в «Destination» — localhost:5432, а ниже выбираем «Remote», и нажимаем Add.
Не забываем после этого сохранить настройки сессии, если требуется.

Также у вас возникнут дополнительные сложности с обеспечением безопасности на «host1», если вы не доверяете узлу «host2». Однако это выходит за рамки данной статьи.

И, конечно, вы каким-то образом (сами или с посторонней помощью) должны инициировать ssh-соединение со стороны «host2» вводом приведенной выше команды, а «host1» должен иметь белый IP-адрес и открытый порт SSH.

После установки ssh-соединения все работает аналогично предыдущей главе.

3) TCP forwarding chain через несколько узлов

В закрытых сетях часто бывает, что нужный нам узел напрямую недоступен. Т.е. мы можем зайти на нужный хост только по цепочке, например host1 → host2 → host3 → host4:
host1# ssh host2
host2# ssh host3
host3# ssh host4
host4# echo hello host4

Это может происходить например если эти узлы являются шлюзами, либо если на них доступны шлюзы только в соседние подсети.

В таком случае мы также можем делать TCP forwarding по цепочке:

Здесь порты 9991, 9992, 9993 выбраны для наглядности, на практике можно использовать один и тот же порт (например, 9999), если он свободен на всех узлах.

Итого нужно выполнить следующую цепочку команд:

host1# ssh -L 9991:localhost:9992 host2
host2# ssh -L 9992:localhost:9993 host3
host3# ssh -L 9993:localhost:5432 host4

После успешного выполнения перечисленных выше команд, на узлах выполняется следующее:

• на «host1»: открывается порт 9991, при подключении к которому данные перенаправляются по ssh-соединению на порт 9992 на «host2»;
• на «host2»: открывается порт 9992, при подключении к которому данные перенаправляются по ssh-соединению на порт 9993 на «host3»;
• на «host3»: открывается порт 9993, при подключении к которому данные перенаправляются по ssh-соединению на порт 5432 на «host4»;

Таким образом, при соединении на порт 9991 на «host1», данные перенаправляются по цепочке на «host4» на порт 5432.

ВАЖНО! Все указанные на схемах стрелками соединения являются отдельными TCP-соединениями (сессиями).

4) TCP forwarding ssh-соединения

Иногда бывает нужно соединиться по ssh с сервером, который напрямую недоступен, а доступ возможен только по цепочке ssh-серверов (см. предыдущую главу). Теперь мы обладаем нужными знаниями чтобы сделать следующее:

host1# ssh -L 2222:localhost:2222 host2
host2# ssh -L 2222:host4:22 host3

Таким образом, на порту 2222 на «host1» у нас теперь есть форвардинг на порт SSH (22) на «host4». Можем соединиться:

host1# ssh -p 2222 localhost
host4# echo hello host4

Казалось бы, зачем это нужно? Например, вот зачем:

# копируем файл на host4
host1# scp -P 2222 /local/path/to/some/file localhost:/path/on/host4
# копируем файл с host4
host1# scp -P 2222 localhost:/path/on/host4 /local/path/to/some/file
# делаем еще один замечательный TCP forwarding на host4
host1# ssh -p 2222 -L 9999:localhost:5432 localhost
host1# psql -h localhost -p 9999 -U postgres
# обратите внимание, что порт для команды ssh задается ключем -p в нижнем регистре,
# а для команды scp -P в верхнем регистре

Ну и вообще, здорово что теперь «host4» так близко 🙂

Вывод: можно делать TCP forwarding большого уровня вложенности.

В некоторых случаях scp не отработает, пока не зайдете сначала через ssh -p 2222 localhost и не примете RSA fingerprint удаленного сервера.

Если пользуетесь одним и тем же портом (2222) для доступа к разным удаленным серверам, то будут ошибки RSA fingerprint, который остался от предыдущего сервера. Его нужно будет удалить из

5) SSH VPN Tunnel

TCP port forwarding — это отличная возможность. Но что если нам нужно больше? Доступ по UDP, доступ к множеству портов и хостов, доступ к динамическим портам? Ответ очевиден — VPN. И всемогущий SSH начиная с версии 4.3 и здесь придет нам на помощь.

Забегая вперед скажу: этот функционал SSH хорошо работает если вам нужно временное решение для каких-то административных задач. Для построения постоянных VPN этот вариант далеко не самый подходящий, т. к. он предполагает TCP-over-TCP, что плохо скажется на скорости соединения.

Настройка SSH-сервера:
PermitTunnel в настройках sshd по-умолчанию выключен, его нужно включить в /etc/ssh/sshd_config:
PermitTunnel yes
или
PermitTunnel point-to-point

ВАЖНО: для поднятия нового сетевого интерфейса туннеля и на ssh-клиенте, и на ssh-сервере необходимы права суперпользователя. Можно долго спорить о том, насколько это небезопасно, но в большинстве случаев на ssh-сервере достаточно настройки:

Таким образом вы запрещаете вход root по паролю, а разрешаете только другими средствами, например, по ключу RSA, что гораздо безопаснее.

Перезапускаем sshd:
sudo service sshd restart # centos
или
/etc/init.d/ssh restart # (debian/ubuntu)

Туннель поднимается при использовании магического ключа -w:

host1# sudo ssh -w 5:5 root@host2

Где 5:5 — номер интерфейса на локальной машине и на удаленной соответственно. Здесь вас может смутить, что ifconfig не выдаст в списке интерфейса «tun5». Это потому что он в состоянии «down», а вот если вызвать «ifconfig -a» или «ifconfig tun5», то интерфейс будет виден:

host1# ifconfig tun5
tun5 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Назначаем интерфейсам IP-адреса и поднимаем их:

host1# sudo ifconfig tun5 192.168.150.101/24 pointopoint 192.168.150.102
host2# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101

Если есть файрвол, не забываем разрешить соединения с интерфейса tun5:

host1# # сохраняем исходные правила файрвола
host1# sudo iptables-save > /tmp/iptables.rules.orig
host1# sudo iptables -I INPUT 1 -i tun5 -j ACCEPT
host2# # сохраняем исходные правила файрвола
host2# sudo iptables-save > /tmp/iptables.rules.orig
host2# sudo iptables -I INPUT 1 -i tun5 -j ACCEPT

На host1 это делать необязательно, здесь это сделано лишь для того чтобы ping работал в обе стороны.

host1# ping 192.168.150.102
host2# ping 192.168.150.101

Если рассмотреть более ранний пример с PostgreSQL, то теперь схема будет такая:

А команда для подключения к серверу PostgreSQL будет выглядеть так:

host1# psql -h 192.168.150.102 -U postgres

Ну а далее можно делать какой-либо из этих узлов шлюзом, если нужно обеспечить доступ не к одному узлу, а к сети. Например:

host2# # разрешаем IP forwarding
host2# sudo sysctl -w net.ipv4.ip_forward=1
host2# # разрешаем IP forwarding с host1
host2# sudo iptables -I FORWARD 1 -s 192.168.150.101 -j ACCEPT
host2# # разрешаем IP forwarding на host1
host2# sudo iptables -I FORWARD 1 -d 192.168.150.101 -j ACCEPT
host2# # маскируем IP адрес host1
host2# sudo iptables -t nat -A POSTROUTING -s 192.168.150.101 -j MASQUERADE

host1# # Предположим, у host2 есть доступ к сети 192.168.2.x, куда нам нужно попасть с host1
host1# # Прописываем host2 как шлюз в сеть 192.168.2.x
host1# sudo ip route add 192.168.2.0/24 via 192.168.150.2
host1# # Наслаждаемся доступом в сеть с host1
host1# ping 192.168.2.1

После окончания работы не забываем вернуть net.ipv4.ip_forward и файрвол в исходное состояние.

host1# sudo iptables-restore

Допустим, нужно настроить сервер в закрытой сети, где доступ в Интернет запрещен, но тем не менее у вас туда есть лазейка — доступ через один ssh-сервер или цепочку ssh-серверов. Предположим, для настройки сервера вам нужен на нем доступ в Интернет. Тогда проще самостоятельно настроить временный доступ в Интернет на требующем настройки сервере, чем просить это сделать обслуживающий персонал.

Допустим, есть доступ по ssh с вашей рабочей машины host1 на сервер host2, с него — на host3, а уже оттуда — на нужный вам host4. Тогда делаем TCP forwarding для ssh (если с host1 вы сразу можете соединиться с host4, пропустите этот шаг):

host1# ssh -L 2222:localhost:2222 host2
host2# ssh -L 2222:host4:22 host3

Далее, соединяемся с host4 и поднимаем интерфейс tun5:

host1# sudo ssh -p 2222 -w 5:5 root@localhost
host1# # или если host4 доступен сразу: sudo ssh -w 5:5 root@host4
host1# sudo ifconfig tun5 192.168.150.101/24 pointopoint 192.168.150.102
host4# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101

Смотрим таблицу маршрутизации на host4, допустим видим следующее:

host4# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 tun5
192.168.56.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
0.0.0.0 192.168.56.254 0.0.0.0 UG 0 0 0 eth0

ВАЖНО! Далее нам скорее всего захочется сделать маршрутом по-умолчанию интерфейс tun5 со шлюзом 192.168.150.101, через который будет доступен Интернет. Поэтому на данном этапе важно точно знать, какие маршруты нужно дописать, чтобы заменить маршрут по-умолчанию. Это важно, поскольку довольно часто маршруты на отдельные сети не прописывают отдельно, а просто задают маршрут по-умолчанию (0.0.0.0/0) со шлюзом, через который и идет весь межсетевой трафик. Более того, вполне вероятно что ваше ssh-соединение с сервером также использует исходный шлюз по-умолчанию.

Для простоты в данном примере предположим, что никаких маршрутов кроме 192.168.56.0/24 серверу для нормального функционирования не нужно и что предыдущий ssh-хост host3 имеет IP-адрес из этой же сети.

Запоминаем и записываем куда-нибудь исходную маршрутную таблицу со шлюзом по-умолчанию:
host4# route -n > routes.orig

Настраиваем наш host1 для работы в качестве шлюза в Интернет для host4:

host1# # разрешаем IP forwarding
host1# sudo sysctl -w net.ipv4.ip_forward=1
host1# # сохраняем исходные правила файрвола
host1# sudo iptables-save > /tmp/iptables.rules.orig
host1# # разрешаем IP forwarding с host4
host1# sudo iptables -I FORWARD 1 -s 192.168.150.102 -j ACCEPT
host1# # разрешаем IP forwarding на host4
host1# sudo iptables -I FORWARD 1 -d 192.168.150.102 -j ACCEPT
host1# # маскируем IP адрес host4
host1# sudo iptables -t nat -A POSTROUTING -s 192.168.150.102 -j MASQUERADE

Изменяем маршрут по-умолчанию на host4 (ОСТОРОЖНО, см. предупреждение выше!):

host4# sudo ip route replace default via 192.168.150.101
host4# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 tun5
192.168.56.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
0.0.0.0 192.168.150.101 0.0.0.0 UG 0 0 0 tun5

Если весь Интернет нам не нужен, а только конкретные IP-адреса/маски, то можно маршрут по-умолчанию не менять, а дописать только нужные нам адреса через шлюз на tun5.

Проверяем, что есть Интернет:

host4# ping 8.8.8.8

Отлично. Осталось настроить DNS. Есть множество способов это сделать, проще всего отредактировать файл /etc/resolv.conf и добавить туда строчки:

nameserver 8.8.8.8
nameserver 8.8.4.4

После этого Интернет должен быть полностью доступен:

host4# ping ya.ru

После окончания работы не забываем вернуть все в исходное состояние:

host1# # восстанавливаем правила файрвола на host1
host1# sudo iptables-restore

host2# # восстановите маршрут по-умолчанию на host4:
host2# sudo ip route replace default via 192.168.56.254
host2# # и уберите добавленные ранее DNS-сервера из /etc/resolv.conf

6) Коротко о беспарольном доступе

Думаю, все уже знают что авторизация по паролю это не про нас. Но на всякий случай впихну сюда краткую инструкцию по настройке аутентификации по ключу RSA:

1. На клиентских машинах генерируем пользователю свой ключ RSA:

client1# ssh-keygen -t rsa

По-умолчанию приватный ключ сохраняется в

/.ssh/id_rsa, а открытый — в

/.ssh/id_rsa.pub. Приватный ключ храните как зеницу ока и никому не давайте, никуда не копируйте.
При создании ключа можно задать пароль (passphrase), которым ключ будет зашифрован.

2. Клиентские открытые ключи нужно сохранить на ssh-сервере в файле

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

Где user — имя пользователя на сервере, sshserver — имя или IP-адрес ssh-сервера.

/.ssh/authorized_keys на ssh-сервере необходимо задать следующие права:
chmod 0700

3. Проверьте, что можете зайти на сервер по ключу, без ввода пароля (не путать с passphrase):
ssh user@sshserver
Рекомендую не закрывать хотя бы одну активную ssh-сессию с сервером до тех пор, пока окончательно не закончите настройку и не убедитесь что все работает.

4. Отключите на SSH-сервере возможность входа по паролю в файле /etc/ssh/sshd_config:

Возможность входа по открытому ключу обычно уже включена по-умолчанию:

Я обычно также отключаю две следующие опции:

GSSAPIAuthentication no
UseDNS no

В некоторых случаях это позволяет ускорить процесс соединения (например, когда на сервере нет доступа в Интернет).

5. Перезапустите sshd:
service sshd restart
или
/etc/init.d/ssh restart

В случае ошибок полезно бывает смотреть лог /var/log/secure либо использовать опции -v, -vv или -vvv для вывода детального лога соединения:
ssh -vvv user@sshserver

Источник