По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
SSH расшифровывается как Secure Shell и представляет собой метод, используемый для установления безопасного соединения между двумя компьютерами.
SSH работает путем аутентификации на основе пары ключей, причем закрытый ключ находится на удаленном сервере, а соответствующий открытый ключ - на локальной машине. Когда ключи совпадают, доступ предоставляется удаленному пользователю.
Это руководство покажет вам, как сгенерировать пару ключей SSH в Windows 10, используя OpenSSH или PuTTY.
Генерация ключа SSH в Windows 10 с помощью OpenSSH Client
Шаг 1. Проверьте, установлен ли клиент OpenSSH
Во-первых, проверьте, установлен ли у вас клиент OpenSSH:
1. Войдите в меню Параметры, и затем нажмите Приложения.
2. Во вкладке Приложения и возможности выберите Дополнительные компоненты.
3. Прокрутите список вниз, чтобы увидеть, есть ли в списке клиент OpenSSH.
Если клиента нет, нажмите знак плюс рядом с Добавить компонент
Прокрутите список, чтобы найти и выбрать OpenSSH Client.
Нажмите Установить.
Шаг 2. Откройте командную строку
Нажмите клавишу Windows, в строке поиска введите cmd, в результатах нажните правой кнопкой на значок командной строки и выберите Запуск от имени администратора.
Шаг 3. Использование OpenSSH для генерации пары ключей SSH
1. В командной строке введите следующее:
ssh-keygen
2. По умолчанию система сохранит ключи в C:Usersyour_username.sshid_rsa. Вы можете использовать имя по умолчанию, или вы можете выбрать более осмысленные имена. Это может помочь различать ключи, если вы используете несколько пар ключей. Чтобы придерживаться опции по умолчанию, нажмите Enter. Если файл с таким именем уже существует, вам будет предложено перезаписать файл.
3. Вас попросят ввести кодовую фразу. Нажмите Enter, чтобы пропустить этот шаг.
4. Система сгенерирует пару ключей и отобразит отпечаток ключа и изображение randomart.
5. Откройте проводник
6. Перейдите к C:Usersyour_username.ssh.
7. Вы должны увидеть два файла. Идентификация сохраняется в файле id_rsa, а открытый ключ помечается как id_rsa.pub. Это ваша пара ключей SSH.
Обычно открытый ключ идентифицируется расширением .pub. Вы можете использовать Блокнот, чтобы просмотреть содержимое как закрытого, так и открытого ключа.
Генерация ключей SSH с помощью PuTTY
До того, как OpenSSH был включен в Windows, инструмент PuTTY был золотым стандартом для генерации ключей SSH.
Шаг 1: Установите PuTTY
Скачайте PuTTY с оффициального сайта, затем дважды щелкните загруженный файл и следуйте указаниям мастера установки, чтобы завершить установку. Тут все просто, но если что, у нас есть подробное описание как скачать и установить PuTTY
Шаг 2: Запустите генератор ключей PuTTY SSH
1. Откройте меню Пуск
2. Введите puttygen.
3. В результатах щелкните правой кнопкой мыши на PuTTYgen и нажмите Запуск от имени администратора.
Шаг 3: Используйте PuTTY для создания пары ключей SSH
Процесс, описанный ниже, сгенерирует ключи RSA, классический и широко используемый тип алгоритма шифрования. Инструмент PuTTY keygen предлагает несколько других алгоритмов - DSA, ECDSA, Ed25519 и SSH-1 (RSA).
Если вам требуется другой алгоритм шифрования, выберите нужную опцию в разделе Parameters перед созданием пары ключей.
1. В окне PuTTY Key Generator нажмите Generate.
2. Переместите курсор в серое поле, чтобы заполнить зеленую полосу.
3. Сохраните открытый ключ:
Нажмите кнопку Save public key.
Выберите место для сохранения ключа.
Дайте ключу имя (например, putty_key.pub)
4. Сохраните закрытый ключ:
Откройте меню Conversions наверху.
Нажмите Export OpenSSH key.
Вас спросят, хотите ли вы сохранить ключ без ключевой фразы. Нажмите Да.
Выберите место для сохранения ключа (обычно это та же папка, что и открытый ключ).
Дайте ключу имя (например, putty_key).
Использование ваших ключей SSH
Чтобы использовать ваши ключи SSH, скопируйте ваш открытый ключ SSH в систему, к которой вы хотите подключиться. Используйте свой личный ключ SSH в своей системе. Ваш закрытый ключ будет соответствовать открытому ключу и предоставит доступ.
Привет! Сегодня в статье мы расскажем, как обновить прошивку на IP-телефоне Cisco через Cisco Unified Communications Manager (CUCM) .
Обновимся?
Сначала нужно скачать необходимую версию прошивки для нашего телефона на сайте Cisco.com в разделе Support → Downloads.
Далее скачанный файл нужно перенести в директорию SFTP или FTP сервера
По-умолчанию нельзя обновить прошивку для отдельного телефона. После того, как вы установите файл прошивки обновления в CUCM, все телефоны с такой же моделью автоматически начнут обновление при их перезапуске.
Чтобы избежать этой проблемы, нужно сохранить существующее имя прошивки телефона. Для этого в разделе Cisco Unified CM Administration переходим во вкладку Device → Device Settings → Device Defaults, ищем необходимый нам телефон, и копируем название его прошивки.
Также это можно посмотреть на странице телефона в разделе Device → Phone, в строке Active Load ID.
Далее переходим в раздел Cisco Unified OS Administration во вкладку Software Upgrades → Install/Upgrade. Здесь указываем следующие данные:
Source – указываем Remote Filesystem;
Directory – директория, где находятся файлы прошивки (если они находятся в корне, то указываем “”);
Server – указываем адрес сервера, на котором мы разместили файлы прошивок;
User Name и User Password – логин и пароль для подключения к серверу с файлами;
Transfer Protocol – протокол сервера – FTP или STFP;
После этого в Software Location выбираем файл прошивки и нажимаем Next
После этого CUCM покажет контрольную сумму MD5 файла прошивки, которую можно сравнить с той, которая указана на сайте Cisco.
Проверив, нажимаем Next для начала установки. Установка будет завершена, когда в строке Status будет написано Complete.
Следующим шагом нужно будет перезапустить сервис Cisco TFTP. Для этого переходим в раздел Cisco Unified Serviceability во вкладку Tools → Control Center → Feature Services. Выбираем наш сервер, находим Cisco TFTP и нажимаем Restart.
После этого дефолтная прошивка для данного типа телефонов изменится на загруженную нами. Пока эта прошивка указана в меню Device → Device Settings → Device Defaults у конкретной модели телефона, перезапуск любого телефона этой модели приведет к установки на него новой прошивки. Поэтому нужно скопировать из поля Load Information название новой прошивки и заменяем его на старое, скопированное ранее.
Старая и новая версии прошивки находятся на TFTP, но старая остается стандартной для всех устройств данной модели.
Теперь обновим прошивку на одном конкретном телефоне. Переходим в меню Device → Phone, находим желаемый телефон и в строку Phone Load Name вставляем название новой прошивки.
После этого сохраняем конфигурацию и перезагружаем телефон. В результате на нем будет установлена новая версия прошивки. Проверить это можно на самом телефоне, нажав кнопку Settings и перейдя в меню Model Information – версия прошивки будет написана в пункте Load File.
Всем привет! В сегодняшней статье мы расскажем, как победить очень надоедливый “баг” во FreePBX, который кочует из версии в версию и сильно мешает пользователям, которые используют кириллицу, то есть русские буквы, в именах внутренних номеров своей IP-АТС. Точно можно сказать, что данная проблема присутствовала в FreePBX 13 и перебралась в 14 релиз.
/p>
Как многие могли догадаться, речь пойдёт о неправильном отображении русской кодировки в модуле CDR, в простонародье – кракозябры в CDR.
Предыстория
Итак, вот вы установили самый последний актуальный FreePBX Distro SNG7-FPBX-64bit-1707-1, долго ждали когда же наконец закончится загрузка 571 пакета (если устанавливаете на VM)
Небольшой оффтоп для тех, кто устанавливает FreePBX 14 на VM и подумал, что процесс установки завис на 571 пакете и надо его прервать – НЕТ, он не завис, наберитесь терпения, правда. Да, это долго, мы, например, ждали полтора часа. Отдохните, попейте кофе, почитайте о нововведениях в FreePBX 14
И, наконец, дождались - всё готово, пора регистрировать абонентов. Вы добавили два внутренних номера с русскими именами, пусть будет Алексей Добронравов и Сергей Злонамеров
Зарегистрировали для каждого по софтфону и провели тестовый звонок – успех. А что же в CDR? Открываете Reports → CDR Reports и видите те самые “кракозябры”, которые мало чем напоминают имена наших внутренних абонентов.
Знакомо? Тогда читай дальше!
Быстро проверим таблицу cdr в базе asteriskcdrdb и убедимся, что там такая же картина:
Решение
Внимание! Прежде чем повторять дальнейшие инструкции – сделайте полный бэкап системы или снэпшот виртуальной машины. Компания Мерион Нетворкс не несёт ответственности за потенциальные проблемы, которые могут возникнуть на вашей IP-АТС. Неправильное выполнение нижеизложенных действий может привести к полной неработоспособности FreePBX и Asterisk!
В интернете можно найти много советов по устранению данной проблемы, начиная от выставления значения charset = utf8 в файле /etc/asterisk/cdr_mysql.conf и выполнения core reload, когда записи опять слетают и заканчивая написанием скрипта, который будет время от времени производить принудительную перекодировку записей. Но всё это либо “костыль”, либо не помогает вовсе.
На сайте разработчика freepbx.org по данной проблеме даже заведён официальный Bug FREEPBX-15268, который по сегодняшний день имеет статус (11.10.2017) DEV TESTING: Unresolved, то есть – не решён.
Более менее действенным способом решения этой проблемы является снос старого MySQL коннектора и установка mysql-connector-odbc-5.3.9 (ANSI Driver), а затем внесение изменений в файл /etc/odbc.ini следующего вида:
[MySQL-asteriskcdrdb]
driver=MySQL ODBC 5.3 ANSI Driver
После этого записи в CDR, конечно, будут отображаться корректно, однако, все логи будут завалены предупреждениями типа:
[2017-10-13 22:31:16] WARNING[8933] cel_odbc.c: Insert failed on 'asteriskcdrdb:cel'. CEL failed: INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,extra) VALUES ('CHAN_START',{ts '2017-10-13 22:31:16.974567'},'Алексей Добронравов','175','','','','s','from-internal','SIP/175-00000001','','',3,'','1507923076.1','1507923076.0','','','')
[2017-10-13 22:31:18] WARNING[8933] cel_odbc.c: Insert failed on 'asteriskcdrdb:cel'. CEL failed: INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,extra) VALUES ('ANSWER',{ts '2017-10-13 22:31:18.631244'},'Алексей Добронравов','175','175','','','175','from-internal','SIP/175-00000001','AppDial','(Outgoing Line)',3,'','1507923076.1','1507923076.0','','','')
При этом в самой таблице cel, на которую ругается сервер, всё будет нормально:
Вроде решение, CDR корректен, но лог будет буквально забит этими предупреждениями, а мы этого не хотим.
Итак, сейчас мы опишем способ решения, после которого и логи будут чистыми и никаких “кракозябр” в CDR вы не увидите.
Для начала, нужно удалить текущий mysql-connector-odbc, однако, в силу того, что он связан зависимостями, вместе с ним удалится и сам Asterisk. Поэтому, сначала нужно узнать, какой именно коннектор установлен на сервере, и удалить его отдельно. Для этого пишем команду:
rpm -qa | grep mysql-connector-odbc
Ну и после предыдущих манипуляций видим, что у нас установлен mysql-connector-odbc-5.3.9-1.el7.x86_64, вероятнее всего у вас будет mysql-connector-odbc-5.3.6. Теперь его нужно удалить, но не учитывая при этом его зависимости. Нам нужно удалить только коннектор, для этого пишем следующую команду:
rpm -e --nodeps "mysql-connector-odbc-5.3.9-1.el7.x86_64"
Теперь нужно установить новый коннектор, но только не от MySQL, а от MariaDB, для этого пишем:
Внимание! Ввод следующей команды без предварительного сноса прежнего коннектора может привести к полному отказу Asterisk!
yum install mariadb-connector-odbc
Теперь проверьте файл /etc/odbcinst.ini в нём обязательно должна быть запись:
[MariaDB]
Description=ODBC for MariaDB
Driver=/usr/lib64/libmaodbc.so
Setup=/usr/lib64/libodbcmyS.so
UsageCount=1
Теперь сделаем перезагрузку fwconsole restart и всё готово. Проводим ещё пару тестовых звноков, смотрим в модуль CDR во FreePBX и проверяем таблицу cdr в asteriskcdrbd:
И логи тоже проверьте, они будут чистыми, никаких предупреждений :)
На этом – всё. Надеемся, что наша статься будет вам полезна и поставит, наконец, точку в истории этого надоевшего всем бага. Выражаем благодарность нашим читателям, которые активно обсуждали данную проблему в комментариях и подсказали правильное направление для её решения.