Можно и мне озвучить, как это делается? Нужно именно для шифрования, т.к. authen делается с использованием RADIUS, а в чистом виде работать СБ не дает.

Как вариант могу предложить пользоваться SecureCRT (либо еще каким-либо софтом, который умеет сохранять логины и пароли для хостов). Правда сам таким давно не пользуюсь, но когда-то давно такая фишка, как запоминание паролей, прикалывало.

_________________
не важно, из какого места растут золотые руки

Хожу с Linux хоста, софт нужно поискать... Но хотелось бы не софтом решать проблему, а средствами коммутаторов.

_________________
o2.uz.ua

В таком случае думаю Вам будет удобнее управлять коммутаторами по SNMP.
2 trumann: Выслал Вам пример.

Мы управляем по SNMP, но телнета(командной строки) это не заменит...

_________________
o2.uz.ua

Укажите пожалуйста в личку Ваш телефон.

Спасибо.
Только я немного еще поработал с устройством, и стало непонятно, зачем нужны все эти танцы вокруг публичных ключей в этой реализации, если все равно ssh-сервер в коммутаторе аутентификацию по ним не проводит, и достаточно просто подключиться по ssh без аутентификации.
(т.е., если используется putty - пункт "Bypass authentication entirely")

Извините за вопрос: а вы технический консультант? Если да -- какое отношение имеет ключ авторизации к шифрации трафика?

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

Ну вот видел я эту доку, дока ни о чём совершенно и не соответствует действительности, тем более в свете топика: вы говорите, что "авторизации по открытому ключу нет", а дока как раз по тому, как её реализовать. Более того, в доке на DES-35xx есть такая команда, свич не ругается на config ssh user admin authmode publickey -- почему? И последнее -- в доке, которую вы прислали, нет ответа на основной вопрос: как загрузить публичный ключ на свич?

Перечитайте, пожалуйста, еще раз внимательно эту тему и высланный Вам документ. Загрузить открытый ключ на коммутатор невозможно, а то зачем нужна команда: и что под ней понимается указано в документе.

Я изучил её вдоль и поперёк. Совершенно очевидно, что это только часть документации. Кстати, она много где лежит в сети, я ожидал чего-то более вменяемого.

Давайте-ка всё же разберёмся.

В этом документе (присланном) абсолютно правильно прописана процедура генерации пары ключей. И на месте процедуры "upload key to server" указана процедура логина на свич, и... На этом мысль останавливается. В результате чего совершенно непонятно, зачем нужна команда и зачем нужны эти ключи. То есть без продолжения это абсолютно бессмысленный, точнее, бессвязный, набор телодвижений. Вполне очевидно, что далее должна была бы быть процедура загрузки ключа на свич. Но... её нет.

Итак. Пойдём по шагам.

1. В официальной доке, взятой здесь: ftp://ftp.dlink.com/Switch/des3526/Manual/ (это же официальная дока, верно?) версия 5.1, самая свежая (в 5.0, забегая вперёд, то же самое), и в описании вебфэйса, и в описании командной строки есть функция "указать режим аутентикации" с возможностью выбрать Public Key (des3526_manual_510.pdf стр. 185-186, des3526_CLI_manual_510.pdf стр. 253-257). И по описанию под public key понимается именно то, что понимается везде -- аутентикация публичным ключом. А вовсе не шифрация трафика ssh -- вообще, как Вас угораздило сказать такое? Трафик ssh, если Вы не в курсе, шифруется симметричным ключом из случайных чисел, генерирующимся в начале сессии и меняющимся периодически (раз в час про умолчальным настройкам). Public key используется только для аутентикации, period.

2. Повторение указанных в мануале действий с выбором authmode publickey и соответственное движение в вебфэйсе не вызывает ошибки типа unknown command, function not implemented -- то есть любой ошибки, которая бы означала отсутствие данного режима. В итоге вполне очевидно, что функция реализована, или я неправ?

3. В свиче реализован tftp server для загрузки файлов, в частности firmware, значит, в теории можно залить произвольный файл (я знаю ограничения протокола tftp). Есть процедура заливки файлов сертификатов (des3526_manual_510.pdf стр. 180), и нет процедуры заливки файла публичного ключа. В конце концов стандартные форматы публичного ключа текстовые, вполне заливабельные копипэйстом.

4. В присланной Вами документации, как я и писал выше, вполне валидно описана процедура генерации пары ключей для авторизации методом ssh Public key. Что "какбэ намекает", если, конечно, не подозревать ДЛинк в природной тупости (пока прецедентов не было, кстати, даже я при своём скептическом отношении к ДЛинку не попру против истины).

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

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

Вот ответ штаб-квартиры по этому вопросу относительно DES-3028, на DES-3526 поведение точно такое же:

P.S. Я понимаю чего хочел топикстартер и чего хотите Вы, но, к сожалению, на DES-3526 это невозможно реализовать.

Я бы всё-таки попросил уточнить это, и имнно в отношении 3526 - поскольку в процитированном кусочке чушь. Повторюсь -- Public key никакого отношения к штфрации не имеет, а необходимость ввода пароля при авторизации публичным ключом может быть следствием установки пароля на приватный ключ.

Мы это уточним именно для DES-3526 и я сообщу Вам по результатам.