SSH из вне

17 сообщений / 0 новое

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

Последнее сообщение

пн, 02/08/2016 - 15:43

Иван

SSH из вне

Добрый день.
Имею настроенный доступ по SSH на маршрутизаторы 1811 из локальной сети с определённых ip:

ip access-list standard MANAGED
permit 10.10.20....
permit 10.10.20....

line vty 0 4
access-class MANAGED in
password 7 что-то там...
login local
transport input ssh

Из глобально во внутреннюю сеть смотрят только пара протоколов через NAT. Вопрос: как настроить доступ по SSH из интернета к самой железке, желательно по нестандартному порту? Второй вопрос: возможна ли авторизация по ключу? Можно ли его экспортировать, как в той же убунте, например?

Заранее спасибо.

вт, 02/09/2016 - 11:01

bacek

Есть ли на маршрутизаторе публичный адрес? Если да - то коннектиться надо прямо к нему спокойно, только добавить в ACL публичный адрес, с которого вы собираетесь подключаться.
Если адреса нет, то значит нат на каком-то другом устройстве? Тогда на нём надо настроить проброс портов. То есть паралельно с существующими правилами ната надо добавит ьчто-то вроде этого: ip nat inside source static tcp внутренний адрес 22 внешний адрес секретный-порт Например, ip nat inside source static tcp 192.168.1.1 22 212.192.212.192 2222

вт, 02/09/2016 - 11:37

Прохожий

По поводу ключей: надо скопировать содержимое id_rsa.pub
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#ip ssh pubkey-chain
R2(conf-ssh-pubkey)#username myname
R2(conf-ssh-pubkey-user)#key-string
R2(conf-ssh-pubkey-data)#$AAQEA6jYlf9MBskhkWov+ZOUDKun0ExQIRj1zfWA/YciO02VS
R2(conf-ssh-pubkey-data)#$XsxM7SqNkRSQOR7y7HBMoxTHV7o+R/uS6A8/mF0A3P/ScRjct
R2(conf-ssh-pubkey-data)#$JrNGACGaFy1njD9PrrvrU4o4hx6XDr6xVXF4sP4OCSXIn+Cp8
R2(conf-ssh-pubkey-data)#$bCnZLmv908AeDb1Ac4nPdsn1OhCPIg6fxZjB7DvAMB8Dbr+7Y
R2(conf-ssh-pubkey-data)#$apEbGE94luIqnBc61HsMd6JCWbQ== myname@mydomain.ru
R2(conf-ssh-pubkey-data)#exit
R2(conf-ssh-pubkey-user)#^Z
Дальше надо чтобы роутер сконвертировал ключ в хэш:
R2#show run | section ssh
ip ssh rsa keypair-name SSH
ip ssh version 2
ip ssh pubkey-chain
username myname
key-hash ssh-rsa C20B739F2645D6850C591C6A11780CB5 myname@mydomain.ru

Вообще, было бы неплохо на этом сайте увидеть что-то вроде цикла статей с best practice по базовой безопасности и SSH.

ср, 02/10/2016 - 10:25

Иван

Публичный адрес есть, но, видимо, я что-то делал не так, ибо при конекте на глобальный адрес меня не пускало, хотя этот адрес был явно указан в ACL MANAGED. Пробовал и второй вариант, тоже не завелось.

Пока использую костыль в виде проброса портов на прокси под дебианом, а уже он разрешён в нужном ACL для подключения к маршрутизатору. Знаю, извращение, но ума пока не дал.

ср, 02/10/2016 - 11:39

(Ответ на #4) #5

bacek

Кстати, интересный момент. На счёт этой ситуации. Возможно, трансляция происходит до обращения к роутеру? Ты не смотрел, появляется трансляция в sh ip nat translations когда ты пытаешься подключиться по ssh? Вообще, если хочешь коллективно поразбираться - скинь сюда обезличенный конфиг.

ср, 02/10/2016 - 11:51

Иван

Конфиг доступен по ссылке - https://yadi.sk/i/Tq25hkMJobKvY

Мне вот тут подумалось, а если пробросить порт на loopback, он же вроде всегда включен, а уже его добавить в ACL, разрешающий доступ к железке. Или это колхоз?

ср, 02/10/2016 - 12:13

(Ответ на #6) #7

bacek

А вот эти пробросы портов нормально отрабатывают?
ip nat inside source static tcp 10.10.20.9 3389 interface Dialer1 5555
ip nat inside source static tcp 192.168.0.20 8080 interface Dialer1 8080
ip nat inside source static tcp 10.10.20.2 3389 interface Dialer1 3389
ip nat inside source static tcp 10.10.20.2 21 interface Dialer1 21

ср, 02/10/2016 - 12:18

Иван

Да, исключительно без проблем. Беда в том, что буквально только что создал такое правило: ip nat inside source static tcp 1.1.1.1 22 interface Dialer1 2222.

1.1.1.1 здесь loopback. И ожидаемо ничего не заработало. Циска не пускает на себя со своих же интерфейсов. Если пытаться войти с любого другого, разрешённого в MANAGED, находящегося в локальной сети, то без проблем. Я уже всю голову сломал.

ср, 02/10/2016 - 12:58

(Ответ на #8) #9

bacek

То есть проблема получается 100% в том что обратный адрес не совпадает с MANAGED? Если вообще убрать ip access class, чтобы отовсюду подключаться — типа заработает всё?

ср, 02/10/2016 - 13:53

#10

Иван

Хм, да, ты прав. Проблема именно в access-class MANAGED. Без него пускает всех и ото всюду. Другой вопрос тогда - как защититься от любопытствующих без использования этого ACLа?

А если сказать этим vty 0 4, что теперь к нему применяется access-class MANAGED out, а уже в него добавить все интерфейсы самой циски, чтобы она могла с них осуществлять подключения? В этом есть смысл?

пт, 02/12/2016 - 11:32

#11

bacek

А ты проверял, какой адрес отображается? Попробуй убрать ACL, подключись извне и посмотри командой who, какой будет стоять Peer Address - такой ли как ты ожидал увидеть?

пн, 02/15/2016 - 16:03

#12

Иван

Хм, теперь всё усложнилось немного больше. Адрес, с которого я подключаюсь, - белый айпи моего маршрутизатора. Вполне логично его там видеть, но! Задача состоит в том, что статические адреса у меня только в двух местах, из которых доступ организовать оказалось совсем не проблема, а в остальном - динамические. Встаёт вопрос, как организовать доступ так, что у меня отрабатывал access-class на vti 0 4, и чтобы я мог из вне иметь доступ. Фокус с пробросом портов на loopback не помог. :-\

Может, поднять на маршрутизаторе саб в совершенно отстранённой подсети, включить его в acl MANAGED и уже на него пробрасывать порт? Умеет ли циска натить на саму себя?

ср, 02/24/2016 - 10:48

#13

bacek

Если адреса динамические, и тем более, может меняться их список и количество, то я бы организовал подключение при помощи VPN для начала - для всех администраторов изо всех мест, а потом уже в этом впн-е выдавал бы адреса.
Чтобы первоначальная аутентификация была бы не по IP адресу, а по паролю или сертификату.

ср, 02/24/2016 - 21:45

#14

Прохожий

Есть на сайте внятная статья по настройке VPN?

чт, 02/25/2016 - 15:35

(Ответ на #14) #15

bacek

Смотря по какому. Есть общая статья по VPN и статья о GRE тонелях, но в данном случае надо как минимум PPTP настраивать.

пт, 02/26/2016 - 09:54

(Ответ на #15) #16

Иван

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

пт, 02/26/2016 - 10:01

#17

Иван

Кстати, GRE вполне себе решение, особенно если не нужно ничего шифровать. Настраивается быстро, легко. Только вопрос защиты передаваемых данных меня беспокоит.

Форма поиска

Вы здесь

SSH из вне

Реклама