Подпишите кто является клиентом а кто сервером

Как подписать POST/GET запросы на сервер с приложения андроид?

В общем вопрос в следующем как возможно подписать запросы с приложения которые сохраняют что-то в бд на сервере. Чтобы кто угодно не мог слать запросы ко мне на сервер и сохранять что либо в бд. Мб как то проверять сами запросы. Может быть от гугла какое то решение есть. Посоветуйте что то.

Отслеживать
задан 31 июл 2019 в 7:27
153 7 7 бронзовых знаков

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Вариантов много. Можете отправлять токены. Все зависит от задач. Если у вас разные пользователи с разными правами:

1. Пользователь вводит логин и пароль. Все это отправляется на сервер. Он в свою очередь проверяет данные. Потом создает токен для этого пользователя, записывает его в бд и возвращает в ответе.
2. Клиент(ваше приложение) сохраняет этот токен у себя. И при обращении на сервер подставляет этот токен в запрос.
3. Сервер при любом запросе проверяет отправленный токен.

Это минимум, для работы. Почитайте про авторизацию с помощью токенов.

Отслеживать
ответ дан 31 июл 2019 в 8:24
1,349 1 1 золотой знак 10 10 серебряных знаков 28 28 бронзовых знаков
Вариант хороший а если нет авторизации в приложении?
31 июл 2019 в 8:28
У вас будет один токен. Пропускаете пункт 1.
31 июл 2019 в 8:29

Допустим юзер регистрируется в приложении через еmail, и его email уже шлется на сервер, т.е. в этот момент надо чтоб сервер как то определял что это юзер зарегестрировался именно с приложения а не какой то там чел просто отправил запрос на сервер и добавил юзера или еще что то в бд.

31 июл 2019 в 8:34
Отправляете токен, проверяете на сервере.
31 июл 2019 в 8:40

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

Грейлистинг

Грейлистинг (англ. greylisting) — это способ защиты email пользователей от спама. Email серверы, которые используют его, блокируют подозрительные письма и выдают ошибку «временно отклонено». В такой ситуации надежный SMTP сервер повторно отправляет отложенное сообщение до тех пор, пока оно не будет принято. А вот серверы, которые массово рассылают спам, обычно такими возможностями не обладают.

Содержание

Как работает грейлистинг

Протокол SMTP предусматривает фильтрацию неизвестных email серверов с помощью грейлистинга и возврат писем отправителю с ошибкой «временно отклонено». Авторитетные SMTP серверы повторяют отправку по умолчанию каждые 15 минут снова и снова.

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

Еще один положительный аспект грейлистинга заключается в том, что для email серверов отправка временной ошибки — это экономически эффективный метод. Для его выполнения не требуется много ресурсов центрального процессора и памяти, в отличие от большинства других программ фильтрации спама.

Если сервер отправителя плохо настроен, время задержки может составить больше 15 минут, что раздражает получателей, ведь они привыкли к мгновенному обмену письмами. Другим недостатком является то, что спаммеры приспосабливаются к грейлистингу и просто ставят сообщения в очередь для повторной доставки. В любом случае, задержка позволяет другим системам идентифицировать подозрительный сервер, как спам.

Как избежать попадания в грейлистинг

1. Позаботьтесь о репутации отправителя
2. Используйте надежный домен
3. Подпишите свой email реальным именем
4. Добавьте ссылку отписки
5. Правильно отформатируйте заголовки и сообщение
6. Избегайте стоп-слов

• Позаботьтесь о репутации отправителя. SendPulse обеспечивает хорошую репутацию IP адреса и сводит к минимуму шансы попасть в «серый список».
• Используйте надежный домен. В email адресе домен следует за символом «@», например, hello@linguatrip.com. Для того, чтобы заработать хорошую репутацию домена, требуется время.
• Подпишите свой email реальным именем. Настоящее имя, вместо набора символов наподобие noreply@example.com, помогает завоевать доверие аудитории и повысить открываемость. Это напрямую влияет на репутацию компании в глазах подписчиков и спам-фильтров. Вот пример привлекательного имени отправителя: Антон, WebPromoExperts.
• Добавьте ссылку отписки. Пользователи могут захотеть отписаться от рассылки по разным причинам — дайте им такую возможность. Если подписчик не сможет сделать это, то отметит письмо как спам. Когда количество жалоб достигнет критического уровня — пострадает репутация IP адреса, а фильтры грейлистинга будут считать рассылки компании подозрительными.
• Правильно отформатируйте заголовки и сообщение. Заголовки и само сообщение должны быть отформатированы в соответствии со стандартами RFC 5322 (формат интернет-сообщений) и HTML.
• Избегайте стоп-слов. Такие слова как «Купить», «Заказать», «Бесплатно», «Дешево» могут послужить плохим сигналом для фильтров грейлистинга и те посчитают, что письмо не заслуживает доверия. Поэтому, будьте предельно осторожны с сообщениями, которые должны быть доставлены мгновенно. Например, письмо-подтверждение, приветственное письмо, транзакционное и так далее.

Также искали с «Грейлистинг»

• Приветственные письма
• Письмо-анонс
• Реактивационное письмо
• Поведенческое письмо
• Жалоба на спам
• Репутация
• Прехедер письма
• Транзакционное письмо
• Email сервис
• Аналитика

Авторизация на базе ключей SSH

SSH-ключи для авторизации — это простой и надежный способ получения доступа к удаленному узлу. В статье мы рассмотрим процесс настройки SSH-авторизации по ключу, а также покажем способы устранения некоторых известных ошибок.

Что такое SSH-ключ

Аббревиатура SSH означает Secure Shell, что дословно переводится как «безопасная оболочка». Если говорить точнее, SSH — это защищенный сетевой протокол с проверкой подлинности и шифрованием. Он используется для передачи файлов, управления сетью и удаленного доступа к операционной системе. Аббревиатура SSH также используется для описания набора инструментов, используемых для взаимодействия с одноименным протоколом.

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

Так как SSH работает по системе «клиент-сервер», обязательное условие для работы этого протокола — наличие на удаленном узле демона SSH. Демон SSH — это ПО, которое прослушивает определенный сетевой порт и при прохождении аутентификации другим узлом создает необходимую среду для работы с ним.

В свою очередь на локальной машине должно быть установлено соответствующее ПО — SSH-клиент. Он взаимодействует с удаленным хостом и передает ему необходимые данные, которые нужны для прохождения аутентификации.

Пользователи Linux могут установить OpenSSH с помощью команды:

sudo apt-get install ssh

В некоторых ОС компоненты OpenSSH можно установить отдельно для клиента openssh-client и отдельно для сервера openssh-server.

Структура ключа

Можно сказать, что определение «SSH-ключ» составное, так как на самом деле это два ключа — открытый и закрытый. На узле A создаются и хранятся оба ключа, а на узел B передается только копия публичного SSH-ключа, что позволяет подключаться к узлу B с узла A.

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

• id_rsa — закрытый ключ,
• id_rsa.pub — публичный (открытый) ключ.

В чем же разница открытого и закрытого ключа?

Открытые и закрытые SSH-ключи

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

Закрытый (приватный) SSH-ключ — это ключ к данным. Он расшифровывает сами сообщения. Хранится он на устройстве, которое будет подключаться к удаленному узлу (на котором находится открытый ключ). Приватный ключ ни в коем случае нельзя передавать в чужие руки, в том числе через мессенджеры или файлообменники, во избежание утечки информации и персональных данных. Также рекомендуем сразу установить пароль на закрытый ключ, чтобы обеспечить ему дополнительную защиту.

Как работает SSH-авторизация?

Давайте представим, что Selectel — это сервер, а вы — клиент. Вы хотите подключиться к нам с использованием SSH-ключа. Предварительно вы уже создали пару ключей и передали публичный ключ нам. Алгоритм взаимодействия будет следующим:

1. Вы должны изъявить свое желание подключиться к нам, то есть отправить запрос на подключение по TCP-порту.
2. В случае установки TCP-соединения мы бмениваемся информацией о версиях наших SSH-протоколов. С помощью этой информации можно понять, какую именно конфигурацию (версию протоколов и алгоритмы работы) использовать. Самостоятельно узнать версию OpenSSH можно с помощью команды ssh -V.
3. После согласования мы (сервер) направляем вам (клиенту) открытый ключ. Теперь уже вы решаете, доверять такому ключу или нет. В случае положительного ответа мы с вами генерируем сеансовый ключ, который будет использоваться для симметричного шифрования канала. Этот ключ существует, только пока существует канал (текущая сессия).
4. Теперь следует аутентифицировать вас. Для этого вы отсылаете нам свой открытый ключ. Мы в свою очередь проверяем его со своим списком открытых SSH-ключей. Если совпадение найдено, мы генерируем случайное число, шифруем его открытым ключом и отправляем обратно. Вы как клиент расшифровываете сообщение закрытым ключом и отправляете полученные данные нам. В случае совпадения присланного числа с первоначальным аутентификация признается успешной.

Поздравляем! Теперь вам открыт доступ на сервер.

Типы ключей SSH

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

Если мы введем в терминал команду ssh-keygen ?, то увидим справку, где у параметра -t указаны алгоритмы, которые можно использовать в данной системе:

~# ssh-keygen ? … [-t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa]

RSA — по умолчанию ssh-keygen использует в качестве параметра -t именно RSA, так как этот алгоритм обеспечивает наилучшую совместимость из всех, но требует большего размера ключа для обеспечения достаточной безопасности. Длина ключа по умолчанию составляет 3072 бит, но вы можете самостоятельно задать его размер от 1024 до 16384 бит с помощью опции -b команды ssh-keygen.

Имейте в виду, что, чем больше ключ, тем больше вычислительных мощностей и трафика будут задействовать устройства. Поэтому если вам нужна усиленная защита и для этого вы хотите увеличить длину ключа RSA, возможно, вам стоит рассмотреть алгоритмы на основе эллиптических кривых. При таких условиях они будут работать быстрее.

DSA — криптографический алгоритм с использованием открытого ключа для создания электронной подписи, но не для шифрования. Это значит, что только один узел сможет подписать сообщение, а другие смогут только проверить ее на корректность. Алгоритм основан на вычислительной сложности взятия логарифмов в конечных полях. Алгоритм DSA в сравнении с RSA показывает лучшие показатели при генерации подписи, но уступает по времени при ее проверке. Также отметим, что максимальная длина ключа данного типа — 1024 бит. Это не самый безопасный показатель в защите от взлома.

ECDSA — это реализация схемы цифровой подписи, основанная на использовании эллиптических кривых и модульной арифметики. Производительность данного алгоритма быстрее, чем у алгоритма RSA, так как для обеспечения шифрования требуются ключи гораздо меньшего размера. Однако у него есть минус: он более уязвим перед взломом с помощью квантовых вычислений, чем RSA.

ED25519 — это схема подписи на эллиптической кривой, которая обеспечивает лучшую безопасность, чем ECDSA и DSA, и хорошую производительность. Его главными преимуществами являются скорость. Однако данный алгоритм поддерживается только в версиях от OpenSSH 6.5.

ECDSA-SK и ED25519-SK — это те же ECDSA и ED25519, но поддерживающие аппаратный аутентификатор. Данные алгоритмы появились не так давно в версии OpenSSH 8.2. Они позволяют реализовать двухфакторную аутентификацию с помощью устройств, которые поддерживают протокол FIDO/U2F. Существует множество разновидностей физической аутентификации, например USB-токен, или другие виды устройств, подключаемые к оборудованию с помощью Bluetooth или NFC.

Храните публичный ключ в панели управления Selectel

Добавить публичный ключ можно сразу при заказе сервера. Все добавленные ключи хранятся в разделе Серверы и оборудование → SSH-ключи.

Создание SSH-ключа

Параметры утилиты ssh-keygen

В Linux для создания SSH-ключей используется команда ssh-keygen. Далее приведены наиболее популярные параметры для этой команды и их описание.

-C comment

Создание нового комментария. Например, одной из самых известных команд является добавление комментария с информацией о том, кто, на какой машине и когда создал ключ:

ssh-keygen -C "$(whoami)@$(uname -n)-$(date -I)"

—p

Если указать данный параметр при вводе ssh-keygen, то вам будет предложено изменить старую секретную фразу на новую. Ввод команды будет выглядеть следующим образом:

ssh-keygen -p

Также вы можете задать все параметры для изменения секретной фразы сразу:

ssh-keygen -p [-P old_passphrase] [-N new_passphrase] [-f keyfile]

—t type

Задает тип создаваемого ключа. Чтобы узнать какие типы доступны для вашей версии, введите:

ssh-keygen -t ?

Подробный режим. ssh-keygen будет печатать отладочные сообщения о ходе выполнения. Несколько опций -v увеличивают степень подробности информации (максимум 3).

Генерация SSH-ключей в Linux

Процесс создания SSH-ключей на базе Linux предельно прост. Вам необходимо лишь указать некоторые параметры, которые мы опишем далее.

Мы будем создавать ключ RSA. При вводе команды ssh-keygen опцию -t RSA можно не указывать явно, так как RSA является алгоритмом по умолчанию.

~# ssh-keygen Generating public/private RSA key pair. Enter file in which to save the key (/root/.ssh/id_rsa):

В последней строке вам предлагается выбрать путь, куда будут сохранены ключи. Если оставить поле пустым, будут созданы файлы с именами id_rsa.pub и id_rsa.

Enter passphrase (empty for no passphrase):

В данной строке предлагается создать кодовую фразу. Оставив строку пустой, дополнительной защиты не будет.

С одной стороны, не вводить кодовую фразу опасно. Если закрытый ключ попадет в руки злоумышленников, то у них может появиться доступ к серверу. В то же время, если вы введете кодовую фразу, в будущем это может доставить вам неудобства. Пароль придется вводить каждый раз при использовании SSH-подключения с этим ключом. Поэтому использование кодовой фразы остается на ваше усмотрение.

Как мы упоминали ранее, кодовую фразу можно будет установить (или заменить) самостоятельно, введя ssh-keygen -p, когда ключ уже будет создан.

Your identification has been saved in /root/.ssh/id_rsa Your public key has been saved in /root/.ssh/id_rsa.pub The key fingerprint is: SHA256:Uh6CVy4Voz0/70Am8j+hXOLBV21l4rMmiMLG5BTz3cE root@trexclient The key's randomart image is: +---[RSA 3072]----+ | =. . | | .o* . E . o| | . =+*. . + + | | .o=.+. o = | | *o.S.=o . o | | *+=+=o. o | | . +.*. o | | +..o | | . | +----[SHA256]-----+

Созданные файлы хранятся в директории /home/*SystemName*/.ssh/.

Генерация SSH-ключей в Windows с помощью Putty

Если вы хотите создать SSH-ключи на базе ОС Windows, самым популярным решением для этого будет использование программного обеспечения Putty. Скачать его можно с официального сайта по ссылке (актуальная версия на момент написания статьи — Putty 0.78). После установки программы вам будет доступно несколько .exe файлов.

Для создания SSH-ключей откройте puttygen.exe, выберите необходимый тип ключа и задайте его размер. Мы будем использовать RSA с длиной 3072.

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

После генерации ключа вы можете вписать комментарий и кодовую фразу.

Далее необходимо сохранить на диск открытый и закрытый SSH-ключи, для этого нажмите на соответствующие кнопки в окне программы. Вы можете самостоятельно выбрать путь, куда сохранять данные ключи.

Putty сохраняет закрытые ключи с разрешением .ppk, что означает, что такой ключ можно будет использовать только с Putty. Чтобы сохранить секретный ключ в формате, пригодном для OpenSSH, нужно во вкладке Конвертация выбрать пункт «Экспортировать ключ в формате OpenSSH (новый формат)» и указать расположение нового файла (старый формат при конвертации из .pkk в OpenSSH сохраняет не все поля — например, комментарий).

Генерация SSH-ключей в Windows с помощью OpenSSH

Не так давно в ОС Windows добавили возможность использования инструментов OpenSSH. Пакет добавлен в ОС, начиная с Windows 10 и Windows Server 2019.

Установить клиент OpenSSH можно с помощью следующей команды в PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Client

Или же с помощью графического интерфейса: Параметры → Приложения → Дополнительные возможности → Добавить компонент. В списке предложенных компонентов необходимо найти Клиент OpenSSH и нажать кнопку Установить.

Проверить статус компонента можно командой:

Get-WindowsCapability -Online | ? Name -like 'OpenSSH.Client*'

Если в ответе команды статус Installed, то загрузка выполнена успешно.

Генерация SSH-ключей происходит таким же образом, как и в ОС Linux, с помощью ssh-keygen:

PS C:\Users\Administrator> ssh-keygen -t ed25519 Generating public/private ed25519 key pair. Enter file in which to save the key (C:\Users\Administrator/.ssh/id_ed25519): Created directory 'C:\Users\Administrator/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in C:\Users\Administrator/.ssh/id_ed25519. Your public key has been saved in C:\Users\Administrator/.ssh/id_ed25519.pub. The key fingerprint is: SHA256:1qBO0MIgYM+A80G1zZgUzW4QCYHKNuLgwaIR77sY2/U administrator@winselectel The key's randomart image is: +--[ED25519 256]--+ |===+=* | |*.=+oBo | |+= +Bo+ . | |**o oo. o | |Ooo .o S . | |.o. o . | |. .. . | | =.. . | |o o. E | +----[SHA256]-----+

Созданные ключи можно найти в папке C:\Users\Administrator\.ssh, если она не была изменена при генерации.

Копирование открытого ключа на сервер

В данном разделе мы рассмотрим общий вариант копирования открытого SSH-ключа на сервер.

Копирование при помощи SSH-Copy-ID

Данный метод подойдет тем, чья ОС поддерживает команду SSH-Copy-ID, и удаленный сервер имеет доступ по SSH без ключа. Если это не так, попробуйте использовать второй или третий способ.

Синтаксис команды выглядит следующим образом:

-# ssh-copy-id username@remote_host

Обратите внимание на последние строки вывода:

-# ssh-copy-id root@5.159.102.80 /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub" The authenticity of host '5.159.102.80 (5.159.102.80)' can't be established. ED25519 key fingerprint is SHA256:KSvVyjbijk+LQ7n3cEQd94qcyIcTDfaED+jRFzBBPGM. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])?

Наш клиент запрашивает разрешение на продолжение подключения к удаленному узлу, так как встречает его впервые. Необходимо ввести yes. После успешного подключения ключи будут добавлены и мы увидим соответствующий вывод:

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys root@5.159.102.80's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'root@5.159.102.80'" and check to make sure that only the key(s) you wanted were added.

Чтобы проверить, действительно ли скопировался открытый ключ, найдем искомый файл authorized_keys на удаленном узле и посмотрим его содержимое, так как именно в него добавляются открытые SSH-ключи.

~# cat /root/.ssh/authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCoQ/EcDWqYKTKCLkd3gZcz98+wRSCTNVNmLUUF6HqWsl105sBX6vep4/xe6cc6zcYSCgFgcKGEK8h2QNIzw+DmdH2Ujxn6AaEkaNBS0b4AGMJSYREqCh6tRpTwBF1VVV5usLMQLz9/eh7HVhorCsHB6bdxk+M2sJOHxX1ikynnwc2cRs12uY/mWMfdLi6S1Q76NmgcfR/ICjyxXUcM3FlmUUsyzQJVyq7+pPr5ahodJw0LRKe3hRNPdQIiXOlNXn1tX7oIxcN9wZ5VR4ZwMORwNBZymZA3oS2Kr27cHvvIhwtEC92ouxd3ue1H8mBmexzbwW6S9Qom0pLiEclK4zRrKmmAWLgHV/2I7nzH6n3V+RFGttW3EOTKTI6n48tnKx7RKaM0qBpzqSAxanNaW3NRvrs++NSjb2LnZoLFoSf9YPLB6YrI6cO08vkWbesc/DWHic3BYPPEaj0rekj5dLJip+acdJw0AiG3dzwfw4ppmcv7zuQpanJYntpmLHoQV4E= root@trexclient

Как мы видим, публичный SSH-ключ клиента был успешно добавлен на сервер.

Примечание. Если на удаленном узле вы используете не стандартный порт в качестве порта для подключения по SSH, а любой другой, то необходимо при вводе команды ssh-copy-id указать дополнительные параметры:

ssh-copy-id ‘-p *port* username@remote_host’

После внесенных изменений необходимо перезапустить службы SSH.

sudo service ssh restart (для Ubuntu / Debian / Mint Linux) sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

Копирование ключа при помощи SSH

Данный метод подойдет тем, чья клиентская машина не поддерживает команду SSH-Copy-ID, но сервер имеет доступ по SSH.

В таком случае вы можете воспользоваться командой:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

• cat ~/.ssh/id_rsa.pub — вывод содержимого файла id_rsa.pub,
• ssh username@remote_host — подключение к удаленному серверу,
• «mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys» — проверка наличия директории /.ssh и перенаправление вывода первой команды в файл authorized_keys.

Чтобы проверить, действительно ли скопировался открытый ключ, точно так же, как в первом варианте, найдем искомый файл authorized_keys на удаленном узле и посмотрим его содержимое.

~# cat /root/.ssh/authorized_keys

После внесенных изменений необходимо перезапустить службы SSH.

sudo service ssh restart (для Ubuntu / Debian / Mint Linux) sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

Копирование пользователем вручную

Данный метод следует использовать тем, у кого нет SSH-доступа на удаленный сервер. Вам необходимо найти файл id_rsa.pub (при использовании Linux) или public (при использовании Windows) на клиентской машине, открыть его и скопировать все содержимое. Через консоль Linux это можно сделать, используя команду cat:

cat ~/.ssh/id_rsa.pub

Затем следует любым доступным вам способом подключиться к удаленному серверу, куда необходимо скопировать открытый SSH-ключ. В нашем случае это будет консольный доступ к облачному (виртуальному) серверу через панель my.selectel.ru.

Найдя все тот же файл authorized_keys, необходимо просто вставить в него то, что мы скопировали из файла id_rsa.pub на клиентской машине ранее. В случае, если вы генерировали SSH-ключи в ОС Windows с помощью Putty, необходимо так же скопировать публичный ключ в файл authorized_keys. Либо вы можете открыть консоль и использовать команду для загрузки ключа:

echo *Text* >> ~/.ssh/authorized_keys

Где *Text* — это скопированные вами данные из id_rsa.pub.

После внесенных изменений необходимо перезапустить службы SSH.

sudo service ssh restart (для Ubuntu / Debian / Mint Linux) sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

Использование SSH-ключей

Настройка аутентификации на сервере с помощью SSH-ключей из ОС Linux

Чтобы воспользоваться подключением по SSH с помощью ключей, необходимо из-под клиентской машины, на которой мы создавали ключи, ввести команду:

~# ssh username@remote_host root@trexclient:~# ssh root@5.159.102.80 Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-60-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage * Introducing Expanded Security Maintenance for Applications. Receive updates to over 25,000 software packages with your Ubuntu Pro subscription. Free for personal use. https://ubuntu.com/pro Expanded Security Maintenance for Applications is not enabled. 0 updates can be applied immediately. Enable ESM Apps to receive additional future security updates. See https://ubuntu.com/esm or run: sudo pro status Last login: Sun Mar 5 12:31:34 2023 from 152.89.133.14 root@selectelserv:~#

Если имя пользователя на локальной машине и удаленном узле совпадают, можно сократить вводимую команду до:

~# ssh remote_host

Настройка аутентификации на сервере с помощью SSH-ключей из ОС Windows

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

Для этого откройте putty.exe и введите IP-адрес удаленного узла и порт для подключения, а также проверьте, что в качестве типа подключения выбран SSH.

Далее пройдите по пути, указанному на скриншоте (Connection → SSH → Auth → Credentials):

В поле Private key file for authentication вставьте ссылку на приватный ключ, который необходимо использовать в данном подключении, и нажмите Open.

Перед вами откроется окно, в котором нужно ввести логин пользователя удаленного узла. В нашем случае — учетная запись root.

Подключение из ОС Windows с помощью OpenSSH аналогично подключению по SSH на сервере Linux:

C:\Users\Administrator> ssh hostname@remote_host 

Если при генерации SSH-ключей была создана секретная фраза, то удаленный хост запросит ее подтверждение:

Enter passphrase for key 'C:\Users\Administrator/.ssh/id_ed25519':

Выполнение одной команды на удаленном узле

Если вам необходимо ввести лишь одну команду, можно не создавать целый сеанс, а ввести нужную команду после ssh hostname@remote_host.

ssh hostname@remote_host command

Технически сессия все-таки создается, и происходит аутентификация на основе введенных данных. Затем передается нужная команда command, и сеанс сразу же закрывается. Поэтому визуально кажется, что мы просто передали команду на удаленный узел.

Отпечаток SSH-ключа

Каждая пара SSH-ключей использует один криптографический отпечаток. Его можно использовать для идентификации ключей.

~# ssh-keygen -l Enter file in which the key is (/root/.ssh/id_rsa):

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

3072 SHA256:UxyIzKj93YXoldmfyP5K4/uKkHTu9UoG0nK9e93q57g root@trexclient (RSA)

Смена порта SSH

Дополнительной защитой доступа к вашему серверу может быть смена стандартного порта, на котором работает SSH. Перед сменой порта подключения необходимо открыть данный порт в файерволе с помощью команды:

sudo ufw allow *port*

Теперь приступим к изменению порта. В первую очередь, находясь на удаленном узле, необходимо открыть файл sshd_config:

sudo nano /etc/ssh/sshd_confog

Внутри этого файла найдите строку Port и укажите там свое значение, например, 4312.

Port 4312

После этого необходимо перезагрузить демон SSH:

sudo service ssh restart (для Ubuntu / Debian / Mint Linux) sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

Теперь при подключении к этому удаленному узлу необходимо указывать новый порт для подключения по SSH с помощью ключа -p:

ssh -p 4312 hostname@remote_host

Если вы хотите, чтобы -p 4312 не нужно было вводить каждый раз, можно изменить файл конфигурации SSH на локальной машине следующим образом:

nano ~/.ssh/config Host *alias_name* HostName *remote_host* Port *port* User *username*

Теперь при подключении к удаленному узлу с помощью команды ssh *AliasName* порт будет выбран автоматически согласно соответствующей записи в /config.

Проброс авторизации

Проброс авторизации — это аутентификация на другом сервере через сервер, к которому вы подключены, используя ключ на вашем локальном компьютере. Иными словами, мы с узла A подключаемся к узлу B, а узел B, используя данные узла A, присоединяется с их помощью к узлу C.

На первом узле мы ввели команду подключения с ключом -A, тем самым подключились к узлу host_B.

ssh -A root@*host_B*

На узле host_B мы ввели следующую команду и присоединились к узлу host_C под учетными данными первого узла.

root@host_B:~# ssh root@*host_C*

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

Увеличение времени простоя

Время ожидания подключения может истечь — придется подключаться к системе заново. Чтобы этого избежать, можно настроить конфигурацию так, чтобы удаленный узел проверял активное SSH-соединение, отправляя клиенту echo-запросы каждые ServerAliveInterval секунд. Если клиент не ответит на запрос ServerAliveCountMax раз, то соединение будет разорвано.

Данные изменения нужно внести в конфигурацию файла /etc/ssh/sshd_config на сервере.

ServerAliveInterval *count* ServerAliveCountMax *count*

Отключение проверки пароля

Ранее мы с вами настроили доступ по SSH с использованием SSH-ключей, но альтернативный вход по паролю по-прежнему включен. Чтобы обезопасить себя от возможного брутфорса (взлома пароля простым перебором), необходимо отключить возможность такого входа. Для этого на сервере нам необходимо открыть на редактирование файл конфигурации SSH под названием sshd_config:

sudo nano /etc/ssh/sshd_config

В нем найдем строку PasswordAuthentication, изменим ее значение с yes на no и сохраним изменения.

PasswordAuthentication no

Для того, чтобы изменения вступили в силу, следует перезагрузить службу SSH:

sudo service ssh restart (для Ubuntu / Debian / Mint Linux) sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

Теперь ваш сервер не будет рассматривать в качестве возможного варианта подключения по SSH использование пароля.

Устранение неполадок

Ключ игнорируется сервером

В редких случаях можно столкнуться с проблемой, что вы настроили все корректно, но не можете подключиться к серверу с использованием SSH-ключей. Видя следующий вывод, можно подумать, что сервер не видит ключ:

Permission denied (publickey).

Вероятнее всего, сервер SSH считает, что установлены неподходящие разрешения к некоторым каталогам. Для решения этой проблемы следует изменить права доступа.

Настройка удаленного узла

Полный доступ к папке .ssh только владельцу, остальным — полный запрет:

chmod rwx------ ~/.ssh

Права на запись и чтение для файла authorized_keys только владельцу, остальным — полный запрет:

chmod rw------- ~/.ssh/authorized_keys

Отмена записи группой и остальными пользователями:

chmod go-w ~/

Настройка локальной машины

Полный доступ к папке .ssh только владельцу, остальным — полный запрет:

chmod rwx------ ~/.ssh

Права на запись и чтение для файла ключа только владельцу, остальным — полный запрет:

chmod rw------- ~/.ssh/*key*

После применения этих политик ошибка должна исчезнуть.

Зашифрованный домашний каталог

Если у вас есть зашифрованный домашний каталог, то SSH не сможет получить доступ к файлу authorized_keys, пока вы не пройдете аутентификацию. Поэтому SSH по умолчанию будет использовать вход по паролю. Чтобы решить эту проблему, создайте папку вне домашнего каталога с именем /etc/ssh/*username*. Этот каталог должен иметь права доступа rwxr-xr-x и принадлежать пользователю. Переместите в него файл authorized_keys (authorized_keys должен иметь права доступа rw-r—r— и принадлежать пользователю).

Затем отредактируйте файл /etc/ssh/sshd_config и добавьте в него запись:

AuthorizedKeysFile /etc/ssh/%u/authorized_keys

Перезагрузите службу SSH.

sudo service ssh restart (для Ubuntu / Debian / Mint Linux) sudo service sshd restart (для CentOS / RHEL / Fedora Linux)

При следующем подключении по SSH вам не нужно будет вводить пароль.

Анализ логов подключения

При возникновении ошибок во время подключения вы можете проанализировать файл /var/log/auth.log, в котором будут указаны все попытки подключения к системе, а также механизмы, использованные для аутентификации.

Также детальную информацию о подключении можно получить с помощью опций -v, -vv или -vvv. Чем больше ключей -v (но не более 3), тем подробнее будет лог.

ssh -vvv hostname@remote_host

Вызов справки

Подробное описание команды (ее параметров, значений и дрю.) вы можете найти в документации, которая вызывается командой man, например:

man ssh man sshd

Заключение

В тексте мы рассмотрели создание и авторизацию с помощью SSH-ключей на базе ОС Linux и Windows, а также разобрали некоторые ошибки, которые могут возникать при использовании такого способа авторизации. Использование SSH-ключей не только упрощает способ авторизации, но и увеличивает степень защиты вашего сервера.

Подпись на сервере 1С

Помощь экспертов ЭДО по любым вопросам работы ЭДО в 1С. Гарантия на услуги до 12 мес.

Разберем основные каноны к получению электронной подписи. Что такое экспортируемый и неэкспортируемый ключ сертификата электронной подписи. Что включает в себя настройка ЭП (ЭЦП) в 1С-решениях и как подать заявление на сертификат электронной подписи из 1С.

В программах «1С:Предприятие» возможна работа только с отсоединенной электронной подписью в формате PKCS#7. Ее создают в системе 1С при помощи сертифицированных криптографических программ, и она отвечает всем требованиям 63-ФЗ «Об электронной подписи»

Основные требования к КЭП

Взаимодействия в области использования квалифицированных электронных подписей (КЭП) при заключении юридически значимых сделок, оказании различного рода услуг (муниципальных или государственных), функций, действий, а также в случаях, установленных другими федеральными законами, регламентируются 63-ФЗ «Об электронной подписи».

На основании вышеуказанного закона электронная подпись является информацией в электронной форме, которая прикрепляется к электронному подписываемому документу или иному файлу, используемому для определения лица, подписывающего данную информацию.

Чтобы пользоваться электронной подписью и шифрованием, нужно установить специальную программу, так называемый криптопровайдер. Программа дает возможность выполнять такие операции, как:

• подписывать содержимое хранимых файлов;
• шифровать содержимое хранимых файлов.

Перед тем, как начать использование ЭП и шифрования, необходимо произвести:

1. Общую настройку программы.
2. Персональную настройку программы.

Руководители компаний как юрлиц, так и ИП с 1 января 2022 года получают электронные подписи только в УЦ ФНС России или в доверенных ей аккредитованных УЦ. Такие электронные подписи должны быть неэкспортируемыми в целях усиления безопасности работы с ними.

Доверенное лицо УЦ ФНС России – выбранная ФНС компания, где можно приобрести КЭП УЦ ФНС, соответствующую требованиям 63-ФЗ. Правила к таким фирмам обозначены постановлением Правительства РФ № 2409. Также необходимо выполнить требования технического характера согласно приказу ФСБ №171. У аналитических центров есть свои партнеры и точки, которые помогают в сборе документов для выпуска квалифицированной ЭП.

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

1. Необходима аккредитация Минцифры по новым правилам.
2. При создании ключей ЭП применять средства ЭП классов КВ2.
3. Выездная идентификация не предусмотрена требованиями п.25 Порядка УЦ ФНС.
4. Первичная идентификация только личная, нет сценариев дистанционной идентификации.
5. Сложность реализации решения.

Что необходимо иметь при себе для выпуска квалифицированной электронной подписи указано на рисунке 3.

Экспортируемый и неэкспортируемый ключи

ФНС обозначила ряд рекомендаций, относящихся к использованию носителей с ключами ЭП и выделила пару видов закрытых ключей: Пассивные и Активные.

Пассивный закрытый ключ защищается только ПИН-кодом. Активный закрытый ключ защищен встроенными функциями СКЗИ (средства криптографической защиты информации)

Возможность и невозможность копирования закрытой части ключа – наиболее значимое в безопасности его свойство. Для сохранения конфедициальности данных и невозможности передачи КЭП третьим лицам рекомендуется использовать неэкспортируемые ключи.

Также существует понятие извлекаемый и неизвлекаемый закрытый ключ.

Если закрытый ключ неизвлекаемый – это указывает на то, что он никогда не оставляет носитель, на котором был сгенерирован

Такие ключи записываются на активные носители с поддерживаемыми функциями СКЗИ.

Извлекаемые ключи – все иные, а также экспортируемые и неэкспортируемые.

Вопросы – ответы

Можно ли установить подпись директора на компьютер, а не пользоваться флешкой каждый раз при отправке отчетов и электронных документов?

Если ключ ЭП записан на токен с признаком неизвлекаемости, перенести такой ключ с токена на компьютер нельзя! ОДНАКО документы может подписывать не только директор организации, но и сотрудник по доверенности. Можно получить в АУЦ сертификат, например, на замдиректора или бухгалтера, установить его на ПК и использовать для подписания электронных документов и отчетности.

Что делать при уходе сотрудника из компании, владеющего ЭП?

Обязательно отменить доверенность этого сотрудника! Необходимо:

• Сообщить контрагентам об отмене им об аннулировании/отмене доверенности в соответствии со ст. 188 ГК РФ;
• При помощи функционала отмены МЧД в программе 1С – отменить электронную доверенность.

Если сотрудник пользуется КЭПом на юридическое лицо или ИП, нужно обратиться в УЦ, где выпускалась подпись, с заявлением на аннулирование сертификата.

Как бухгалтера аутсорсинговой компании уполномочить на сдачу отчетности клиента доверителя?

Есть 2 варианта передачи бухгалтеру аутсорсинговой компании полномочия от имени доверителя:

1. Клиент, доверитель выдает МЧД на имя фирмы аутсорсера (самый надежный способ). Директор аутсорсера либо сдает отчетность со своей КЭП, либо в порядке передоверения выдает МЧД на имя сотрудника, который ведет отчетность клиента.
2. Клиент выдает МЧД непосредственно на имя сотрудника аутсорсера. Доверитель должен проверить, что этот сотрудник приказом и/или доверенностью от директора аутсорсера уполномочен вести отчетность фирмы клиента, и что эта внутренняя доверенность не была отменена.

Примечание: важно принимать во внимание то, что ЭП может подтвердить авторство и обеспечить целостность подписанных данных, но подпись не отвечает за конфиденциальность передаваемых данных. Эту задачу решает шифрование. Поэтому рекомендуется использовать электронную подпись совместно с шифрованием.

Поддержка работы ЭДО в 1С

Консультации и поддержка работы ЭДО в любых программах 1С. Приступим к вашему вопросу в течение 15 минут

1С-ЭДО — встроенный сервис в 1С

Подходит малому бизнесу для типовых 1С. Оперативное подключение и настройка от экспертов ЭДО

от 250 руб./мес.

Работа с КЭП в программе 1С

В программах «1С:Предприятие» возможна работа только с отсоединенной электронной подписью. Работа с присоединенными подписями и подписями внутри документа в программе невозможна.

Отсоединенная электронная подпись в формате PKCS#7, которую создали в программе 1С при помощи сертифицированных криптографических сервисов, отвечает всем требованиям 63-ФЗ. Такая подпись формируется в отдельном файле от подписываемого объекта. В файл подписи безусловно должен быть добавлен сертификат, которым выполнена подпись. В противном случае будет констатирована ошибка при проверке корректности подписи и при добавлении из файла. Название файла подписи такое же, как подписанный документ с расширением .p7s.

Подписи таких файлов хранятся в информационной базе 1С, в отличие от подписываемых файлов, которые могут храниться в томах на различных сетевых дисках. При необходимости хранения и пересылки понадобятся оба файла. Нельзя их и переименовывать!

Сам подписываемый файл будет доступен для чтения без программ ЭП. Такие программы нужны только для того, чтобы проверить корректность подписи. Для проверки подписи достаточно загрузить в программу 2 файла: подписанный и с электронной подписью.

Настройка использования КЭП в 1С

Чтобы настроить 1С для работы с электронными подписями, необходимо открыть раздел Администрирование – Электронная подпись и шифрование.

Функция подписания данных активируется включением флажка Электронная подпись. Вместе с ним необходимо активировать и шифрование соответствующим флажком.

Далее будут доступны и другие настройки электронной подписи этого раздела.

Программы электронной подписи в 1С

Чтобы создать электронную подпись и шифрование нужно воспользоваться криптопровайдером. Для настройки необходимо открыть вкладку Программы в разделе настройки электронной подписи и шифрования.

Вкладка Программы включает в себя перечень программ криптографии, которые могут быть использованы 1С, а также в числе всех узлов распределенной информационной базы. При первичном открытии вкладки осуществляется поиск программ, которые установлены на ПК. Занимает это обычно непродолжительное время – менее минуты. Результаты проверки каждого указанного/добавленного криптопровайдера можно увидеть в одноименной колонке (Рис. 6).

Настройка в 1С другой программы электронной подписи вручную

Если юридически значимая ЭП не нужна (предположим, для работы с ЭП внутри компании), можно использовать любой криптопровайдер. Например, от Microsoft. Такой криптопровайдер необходимо добавить вручную через кнопку Добавить.

Поле Представление необходимо заполнить при помощи кнопки ❌ и выбрать из выпадающего списка предлагаемый криптопровайдер или Другая программа, заполнив вручную характеристики формы.

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

Чтобы не устанавливать СКЗИ на каждом ПК каждого сотрудника организации, кто работает с КЭП, используется сервер 1С:Предприятия в клиент-серверном варианте работы программы или web-сервер в файловом варианте. Для этого на компьютере, где работает сервер «1С:Предприятия» или web-сервер, устанавливают криптопровайдер (желательно один, во избежании конфликтов между ними).

На следующем этапе необходимо открыть раздел Администрирование – Общие настройки – Электронная подпись и шифрование включить флажок Проверять электронные подписи и сертификаты на сервере. Если включить флажок Подписывать и шифровать на сервере, то потребуется также установить на сервере секретные ключи пользователей.

Если один из флажков Проверять подписи и сертификаты на сервере или Подписывать и шифровать на сервере включен, то в панели навигации становится доступной ссылка Пути к программе на серверах Linux.

Дополнительные настройки программы

На закладке Дополнительно доступны следующие настройки:

• расширение для зашифрованных файлов по умолчанию указано .p7m;
• расширение для файлов подписи по умолчанию .p7s.

С помощью переключателя можно задать поведение программы При сохранении данных в файл вместе с ЭП.

Использование облачной электронной подписи по технологии КриптоПро DSS

В программе есть возможность использовать облачную подпись по технологии КриптоПро DSS. Она работает в тестовом режиме и будет развиваться в следующих версиях программы.

Использование сервиса облачной подписи включается в общих настройках программы.

Для использования сертификатов, хранящихся на сервере, необходимо завести карточку сервера подписи, прописав в ней пути различных сервисов сервера DSS.

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

На закладках разных видов аутентификации есть возможность указать способы авторизации для использования на сервере при создании КЭП.

После этого можно будет добавить сертификаты, расположенные на сервере КриптоПро DSS.

Во время сеанса при первом обращении 1С обратится к сервису с просьбой пройти первичную аутентификацию и выбрать способ вторичной аутентификации при создании подписи.

При повторном обращении к сервису программа запомнит выбранные первичную и вторичную авторизации. На рисунке ниже изображен пример, когда вторичная аутентификация на сервере не настроена, необходимо ввести только ПИН-код от сертификата на сервере.

Настройка клиент-серверного подписания электронных документов

Многие пользователи задумываются о том, как реализовать подписание документов на сервере, где лежит база 1С и находятся ключи (все в одном месте). Иными словами, как добиться того, чтобы программа смотрела и искала сертификат только там, где сама установлена, а не с компьютера, откуда пользователи заходят в базу.

Настройки и установки сертификатов и криптопровайдера должны быть выполнены от имени того пользователя, под которым запускается служба Агент сервера 1С:Предприятия

Для проверки от имени какого пользователя запущена служба необходимо: Запустить Диспетчер задач → Службы → открыть службы → найти необходимую в списке Агент сервера 1С:Предприятия 8.3 или Агент сервера 1С:Предприятия 8.3 (x86-64) → правой кнопкой мыши открыть Свойства → Вход в систему

После того, как был выбран оптимальный пользователь для запуска 1С , можно приступать к дальнейшим настройкам. На сервере надо авторизоваться под выбранным пользователем и установить:

1. Криптопровайдер.
2. Сертификаты.

Поддержка работы ЭДО в 1С

Консультации и поддержка работы ЭДО в любых программах 1С. Приступим к вашему вопросу в течение 15 минут

1С-ЭДО — встроенный сервис в 1С

Подходит малому бизнесу для типовых 1С. Оперативное подключение и настройка от экспертов ЭДО

от 250 руб./мес.

Особенности работы в веб-клиенте

Для работы с ЭП и шифрованием в web-клиенте нужно установить расширение.

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

Установка расширения работы с СКЗИ проходит аналогичным образом. После выполнения всех манипуляций список настроек электронной подписи и шифрования станет доступным для работы.

Хранение электронной подписи в облачной программе 1cfresh.com. Преимуществами такого хранения может выступать:

• гибкость – работа при помощи любого браузера, который поддерживает платформа 1С и под любой ОС;
• мобильность – работа с ЭДО и Отчетностью с любого ПК, который имеет доступ к сети Интернет;
• безопасность – минимальный риск компрометации КЭП в случае потери его носителя;
• легкий старт работы – нет необходимости устанавливать дополнительные ПО (криптопровайдеры и т.д.).

Хранение КЭП

Хранение облачных ключей происходит в специальном защищенном пространстве, которое называется Аппаратное хранилище. Оно сертифицировано ФСБ России.

Операции с КЭП проводятся через подтверждение одноразовым паролем пользователя.

Заявление на сертификат электронной подписи из 1С

ВАЖНО: в соответствии с ФЗ от 06.04.2011 № 63 выпуск сертификатов для директоров в коммерческих УЦ недоступен! Выпуск осуществляется только для сотрудников, которые работают по доверенности.

1С проверяет имеющиеся сертификаты электронной подписи и предупреждает о необходимости их продления, также сообщает о состоянии заявления, например, на начальной странице в разделе Текущие дела. При подписании документа КЭП менее чем за 30 дней до окончания срока действия, 1С выведет информационное сообщение о необходимости продлить сертификат.

В программных продуктах линейки 1С имеется возможность подготовки заявления на выпуск новой или продление старой КЭП в Удостоверяющем центре 1С. Но для выпуска КЭП необходимо предоставить комплект документов в обслуживающую организацию в бумажном виде. Продлить ранее полученный в программе действующий сертификат можно, подписав им заявление, оформленное в электронном виде (безбумажное продление сертификата).

Заявление на выпуск КЭП в бумажном виде

В списке Настройки электронной подписи и шифрования (вкладка Сертификаты) нажмите кнопку Добавить, выберите Заявление на выпуск сертификата. В поле Оформить выберите В бумажном виде.

Подать заявление можно также из списка физических лиц с помощью кнопки Заявление на сертификат. В данном случае необходимо заполнить только данные обслуживающей организации, остальные поля заполняются автоматически. Также можно подать заявление из карточки сертификата, который нуждается в продлении, с помощью кнопки копирования или F9.

Данные физлица выбираются из соответствующего списка и обязаны быть заполнены. Когда будет готовиться заявление 1С проверяет корректность заполнения данных и оповещает об ошибках. Для того, чтобы заявление было отправлено нужно корректно заполнить все данные, проверить, внести при необходимости корректировки.

Многие данные заполнятся автоматически. Если не все поля заполнены, можно проверить данные с помощью кнопки.

ВАЖНО: выпускать заявление на сервере, где установлена 1С под пользователем, под которым запущена служба Агента сервера 1С.

Заявление сохраняется автоматически на стадии подготовки и хранится в списке сертификатов. В любой момент к нему можно вернуться и продолжить работу.

Заявление на выпуск КЭП в электронном виде

Данный вид используется для возможности перевыпуска сертификата, у которого заканчивается срок действия.

Создать заявление возможно из перечня сертификатов или из карточки сертификата. Если нажать на кнопку Перевыпустить… (Копировать, F9), запустится проверка выбранного сертификата на возможность безбумажного продления. Если такая возможность будет найдена, установится автоматически способ оформления равный В электронном виде.

Поле Сертификат для продления является обязательным к заполнению.

После подтверждения сведений заявления происходит генерация закрытого ключа, создание, подписание и отправка заявления.

Программа уведомит, когда сертификат будет получен. Если продлеваемый сертификат действует, необходимо при получении подписать им новый сертификат. После этого происходит установка и открывается карточка нового сертификата.

Если срок действия сертификата окончен, подтверждение необходимо произвести по «бумажному» сценарию.

Перед установкой сертификата требуется подтвердить информацию об отправке расписки.