Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
SSH authorized_keys USG, UniFi Network
 
Есть ли способ сохранить authorized_keys на USG? В инструкциях по ссылке https://help.ubnt.com/hc/en-us/articles/235247068-UniFi-Add-Custom-SSH-Keys-to-Your-UniFi-Devices сказано, что это применимо только к оборудованию UAP и USW — и *НЕ* к USG. Я обновил config.properties — и он сохраняется на моих UAP/USW... но интересно, где задаются аналогичные настройки для USG. Может, это где-то в config.gateway.json?
 
Я не понимаю, какое отношение ваша конфигурация имеет к авторизованным ключам SSH, но у вас в конце строки с режимом PPTP стоит лишняя «,». Чтобы проверить, используйте валидатор JSON, например этот: https://jsonformatter.curiousconcept.com/.
 
Честно говоря, я не доверяю напрямую выставлять логин от роутера в интернете, и не пробовал проверять, работает ли удалённый вход по паролю 😀 Мой ssh-порт проброшен на внутренний сервер (который, кстати, позволяет проксировать намного быстрее, чем сам USG, когда мне нужно использовать SOCKS-порт).
 
Я хотел бы включить вход по SSH через ключ и настроить это напрямую через конфигурацию. Ошибка в JSON возникла из-за того, что я редактировал и вырезал части отдельно от файла. Если я добавляю упомянутый раздел в свою конфигурацию, то USG фактически застревает на этапе настройки и не проходит её.
 
Но USG основан на файрволе Vyatta, который имеет странный способ работы с конфигурацией, связанной с SSH.

configure
echo установить SSH-ключ
jimbo@UniFiSecurityGateway# load
load
loadkey  
[edit]
jimbo@UniFiSecurityGateway# loadkey jimbo

Возможные варианты:
 <file>                     Загрузить из файла на локальной машине
 scp://<user>@<host>/<file> Загрузить из файла на удалённой машине
 sftp://<user>:<passwd>@<host>/<file> Загрузить из файла на удалённой машине
 ftp://<user>@<host>/<file> Загрузить из файла на удалённой машине
 http://<host>/<file>        Загрузить из файла на удалённой машине
 tftp://<host>/<file>        Загрузить из файла на удалённой машине

echo отключить аутентификацию по паролю
[edit]
jimbo@UniFiSecurityGateway# set service ssh

Возможные варианты:
 allow-root                  Включить вход под root через SSH
 disable                    Отключить SSH-сервис
 disable-host-validation    Не проверять имя удалённого хоста через DNS
 disable-password-authentication Запретить вход неизвестным пользователям по паролю
 listen-address             Локальные адреса, на которых SSH-сервис должен слушать
 port                       Порт для SSH-сервиса
 protocol-version           Версия SSH-протокола

[edit]
jimbo@UniFiSecurityGateway# set service ssh dis
disable                          disable-host-validation          disable-password-authentication
[edit]
jimbo@UniFiSecurityGateway# set service ssh disable-password-authentication
 
PsychoWood, десятилетиями ssh-демон на ПК позволял подключаться по ssh ключам через сеть, а пароли — только при работы непосредственно на консоли. То есть у имени пользователя может быть пароль, но opensshd его никогда не использует. Пароль всё ещё применим, когда хочешь воспользоваться sudo.

Это хорошие новости насчёт следующего релиза, ведь открывать порт 22 на нашем интернет-шлюзе и разрешать вход по паролю по умолчанию — просто ужасно. Обычно «PasswordAuthentication» выключен.

user@ubnt:~$ cat /etc/ssh/sshd_config | egrep -i '(pass)'
PermitEmptyPasswords no
PasswordAuthentication yes
 
Не думаю, что это возможно, по крайней мере не через контроллер (пустой пароль не принимается). Кстати, контроллер версии 5.7.3 (сейчас в альфе) позволяет устанавливать SSH-ключ прямо из интерфейса.
 
Можно ли полностью отключить доступ по паролю и разрешить только по SSH-ключу? Особенно важно это сделать хотя бы на стороне WAN. Спасибо!
 
Имя было с заглавной буквы — ошибка. С маленькой буквы — работает. Успех!
 
Спасибо — позже сегодня вечером поищу причины сбоев... Без сомнений, проблема в provisioning, надеюсь найти участок, который её вызывает. Я сопоставил свой pub — удалил начальный ssh-rsa и конечный user@host из pub-файла, чтобы остался только ключ. Надеюсь, журнал сервера укажет на ошибку.
 
Можешь проверить server.log в контроллере? Там должно быть указано, почему не удаётся выполнить provisioning. В моём случае добавленная конфигурация (до твоих последних и предпоследних закрывающих скобок) выглядит так:

"system": {
   "login": {
       "user": {
           "USERNAME": {
               "authentication": {
                   "public-keys": {
                       "mykey": {
                           "key": "AAAA.....aP",
                           "type": "ssh-rsa"
                       }
                   }
               },
               "level": "admin"
           }
       }
   }
}

Обрати внимание, что USERNAME совпадает с тем, что настроен в Site Settings / Device Authentication в контроллере. У меня нет узла "password" в json, вероятно, из-за этого же момента. Может быть, ключ в неправильном формате или ты включаешь лишние символы? Вот мой id_rsa.pub: ssh-rsa AAAA.....aP user@host
 
Просто не могу заставить это работать ни за что. В моем config.gateway.json нет записи system json... и когда я пытаюсь добавить этот раздел [и добавляю его правильно как JSON-объект], USG застревает в режиме настройки, когда пытается загрузиться... Я пробовал вставлять код с необходимой завершающей запятой — в начале файла [после открывающей скобки], но не получилось.

{
   "firewall": {
       "name": {
           "WAN_LOCAL": {
               "rule": {
                   "4": {
                       "action": "accept",
                       "description": "SSH to WAN",
                       "destination": {
                           "address": "*redacted*",
                           "port": "22"
                       },
                       "protocol": "tcp"
                   },
                   "50": {
                       "action": "accept",
                       "description": "Allow L2TP",
                       "destination": {
                           "port": "500,1701,4500"
                       },
                       "protocol": "udp"
                   },
                   "51": {
                       "action": "accept",
                       "description": "Allow ESP",
                       "protocol": "esp"
                   }
               }
           }
       }
   },
   "vpn": {
       "pptp": {
           "remote-access": {
               "authentication": {
                   "local-users": {
                       "username": {
                           "user1": {
                               "password": "*redacted*"
                           }
                       }
                   },
                   "mode": "local"
               }
           }
       },
       "ipsec": {
           "auto-firewall-nat-exclude": "disable",
           "ipsec-interfaces": {
               "interface": [
                   "eth0"
               ]
           },
           "nat-networks": {
               "allowed-network": {
                   "0.0.0.0/0": "''"
               }
           },
           "nat-traversal": "enable"
       },
       "l2tp": {
           "remote-access": {
               "authentication": {
                   "local-users": {
                       "username": {
                           "user1": {
                               "password": "*redacted*"
                           }
                       }
                   },
                   "mode": "local"
               },
               "client-ip-pool": {
                   "start": "192.168.1.200",
                   "stop": "192.168.1.254"
               },
               "dhcp-interface": "eth0",
               "dns-servers": {
                   "server-1": "8.8.8.8",
                   "server-2": "8.8.4.4"
               },
               "ipsec-settings": {
                   "authentication": {
                       "mode": "pre-shared-secret",
                       "pre-shared-secret": "*redacted*"
                   },
                   "ike-lifetime": "3600"
               },
               "mtu": "1492"
           }
       }
   }
}
 
Спасибо, у меня тоже работает. Кстати, пользователь «root» тоже не работает (создаётся корректно, но молча даёт сбой, и даже войти с паролем невозможно).
 
Это меня мучило целую вечность, я пытался заставить это работать, но по какой-то причине ничего не срабатывало (хотя ошибок не было). В конце концов я сдался и решил создать нового пользователя, чтобы протестировать. Теперь не уверен, связано ли это с тем, что у моего «admin» аккаунта не получалось, но сборка жаловалась, что пароль не задан (я не хотел ставить пароль, но пришлось). Моя итоговая конфигурация выглядит так:

{
   "system": {
       "login": {
           "user": {
               "bill": {
                   "authentication": {
                       "public-keys": {
                           "billkey": {
                               "key": "blah...",
                               "type": "ssh-rsa"
                           }
                       },
                       "encrypted-password": "blah..."
                   },
                   "level": "admin"
               }
           }
       }
   }
}

На всякий случай, если кто-то ещё столкнётся с такой проблемой...
Страницы: 1
Читают тему (гостей: 1)