crower | scp без пароля

Наконец-то победил scp на предмет передачи файлов без пароля.

Да, в итоге всё оказалось более чем просто, но предыдущие две попытки были неуспешными. То получал запрос пароля на расшифровку ключа, то аутентификация ничерта не работает и опять пароль запрашивается по старой схеме... В третий раз ~~забросил я невод~~ спросил я у гугля, но на этот раз заглянул в четвёртую ссылку. Найденный хинт выглядел довольно лаконичным и по существу.
В общем, приступив к процедуре реализации в третий раз, достиг-таки желаемого. А дабы не искать процедуду в следующий раз (если вдруг понадобится и забуду) оставляю инструкцию тут:

1. Начальные условия: с хоста1 необходимо передавать/принимать файлы на хост2. То есть scp запускается на хосте1 и идёт на хост2 вне зависимости от направления передачи файлов. Само собой разумеется, что и там, и там используются некоторые существующие экаунты, которые не обязательно должны быть синонимичны.

2. Генерим на хосте1 пару ключей:

ssh-keygen -t rsa

Генератор ключей спросит где будем сохранять ключ. По-умолчанию это ~/ssh/id_rsa. Там и оставим. Также будет запрошена фраза (passphrase) для разлочивания ключа. Поскольку мы собираемся заняться передачей файлов без ввода пароля, то тут нужно просто жамкнуть Enter. Два раза. В результате получаем в означенном месте секретный ключ id_rsa и публичный ключ id_rsa.pub.

3. На хост2 передаём файл id_rsa.pub и импортируем его в файл ~/.ssh/authorized_keys.

cat id_rsa.pub >> ~/.ssh/authorized_keys

Снять права с этого файла на чтение/запись/запуск для всех кроме владельца. ssh за этим следит, так что если забыть, то где-то, кажется в логах, об этом будет предупреждение и авторизация не будет работать.

Кстати, в authorized_keys имя хоста генерится на хост1, а проверяться будет на хост2. Поэтому хост1 должен быть прописан в таком виде, в каком он ресолвится на хосте2. В случае чего можно просто поправить в файле имя хоста1. Хм. Можно продублировать запись для разных вариантов ресолвинга (и без).

Рестартовать мне ничего не понадобилось даже.

На некоторых старых системах (как у меня на одном из хостов с trustix 2.2) вместо authorized_keys используется authorized_keys2 (для SSH2). В остальном всё так же.

Бонус: обычный ssh с хоста1 на хост2 тоже стал работать без ввода пароля.

Если надо чтобы работал аналогичный доступ с хоста2 на хост1 нужно точно также сгенерить пару ключей на хосте2 и затолкать публичный ключ с хоста2 в authorized_keys на хосте1.

Получается, что можно с логин@хост1 ходить под разные логины хоста2, для чего надо в каждому из нужных логинов хоста2 подкинуть публичный ключ логина1 с хоста1.

А вот что будет если попытаться подключиться с хоста1, находящегося в приватном сегменте, через фаервол, к хосту2, находящемуся вне фаервола - не знаю. Если запрос идёт по ssh, то всё ОК, а если на хосте2 входящим соединением будет ресолвится фаервол, то тогда "опаньки". :( - только через пароль. Нужно будет эксперимент поставить.

Бонус2: с одного из хоста через фаервол проброшена была из корпоративки (где приватные адреса) в закрытый выделенный сегмент (где ещё более приватные адреса) пара ssh-туннелей, дабы ходить телнетом до станции:
```
ssh -i file.ppk -N -L ip1:port1:ip3:port3 login2@host2
```
Запускается через autossh чтобы автоматически поднимались туннели при падении.
```
autossh -M 0 login2@host2 -i file.ppk -N -L ip1:port1:ip3:port3
```
Но при первом запуске (а иногда и при поднятии после падения) приходилось ручками вбивать пароль. Так вот после того как на хосте1 у юзера, из под которого запускается autossh/ssh для поднятия туннеля была сгенерена пара ключей и публичный ключ был импортирован на хосте2 в соответствующий authorized_keys2, то туннель стал подниматься без запроса пароля. Что очень и очень приятно.