 |
Проброс доступа к SSH через HTTPS (доп. ссылка 1) |
[комментарии]
|
| | Для организации подключения к SSH-серверу из окружений, в которых заблокирован любой трафик, кроме HTTP/HTTPS, можно настроить проброс к SSH на основе внешнего HTTP-прокси.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
 |
|
|
Использование SSH поверх UNIX-сокета вместо sudo (доп. ссылка 1) |
[комментарии]
|
| | Тимоти Равье (Timothee Ravier) из компании Red Hat, мэйнтейнер проектов Fedora Silverblue и Fedora Kinoite, [[https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket/ предложил]] заслуживающий внимания способ ухода от применения утилиты sudo, использующей suid-бит для повышения привилегий. Вместо sudo для выполнения обычным пользователем команд с правами root предлагается задействовать утилиту ssh с локальным соединением к той же системе через UNIX-сокет.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Преобразование закрытого ключа PuTTY для использования в OpenSSH (доп. ссылка 1) |
[комментарии]
|
| | Для преобразования можно использовать утилиту puttygen из пакета putty-tools или putty.
Debian/Ubuntu:
sudo apt-get install putty-tools
Fedora:
sudo yum install putty
puttygen putty.ppk -O private-openssh -o ~/.ssh/id_putty
puttygen putty.ppk -O public-openssh -o ~/.ssh/id_putty.pub
chmod 0600 ~/.ssh/id_putty
chmod 0644 ~/.ssh/id_putty.pub
Для подключения к хосту с закрытым ключом, преобразованным из ключа PuTTY:
ssh user@host -i ~/.ssh/id_putty
|
| |
|
|
|
Использование SSH-ключей в Gitlab CI |
Автор: Ilya
[комментарии]
|
| | Многие хотят использовать ssh ключи в своих CI/CD (не одобряю), но давайте делать это правильно:
before_script:
- '[[ ! -d /root/.ssh ]] && mkdir /root/.ssh && chmod 700 /root/.ssh'
- '[[ -f /.dockerenv ]] && echo -e "Host *\\n\\tStrictHostKeyChecking no\\n\\n" > ~/.ssh/config'
- 'which ssh-agent || (yum install openssh-clients -y; yum clean all -y )'
- eval $(ssh-agent -s)
- ssh-add <(echo "$SSH_PRIVATE_KEY")
- mkdir -p ~/.ssh
В $SSH_PRIVATE_KEY устанавливаем "protected" переменную в интерфейсе самого
Gitlab (repo->settings->ci/cd-> vars )
Данный сниппет рассчитан на CentOS, но легко адаптируется по любую ОС, работает
в докер окружении (см. строку #2). При таком подходе больше нет нужды помещать
id_rsa в репозитории (ему там и не место).
|
| |
|
|
|
Генерация конфигурации клиента OpenSSH из inventory.ini в Ansible |
Автор: Ilya
[комментарии]
|
| | Часто на работе приходится разыскивать серверы, грепать из inventory.ini. Но почему бы Ansible не позаботится о нас. Настраиваем генерацию ~/.ssh/config из inventory.ini:
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Еscape-последовательности в сеансе OpenSSH |
[комментарии]
|
| | В сеансе удалённого входа через OpenSSH можно использовать
escape-последовательность "~" (действует только в начале новой строки, в
которой не было ввода, поэтому перед "~" лучше нажать Enter) для запуска ряда
полезных команд. Например, можно набрать "~C", а затем ввести "-D 1080" для
запуска SOCKS-прокси или "-L 80:localhost:8000" для проброса сетевого порта без
запуска отдельного сеанса.
Поддерживаемые управляющие последовательности:
~. - принудительное завершение сеанса (например, при зависании соединения);
~B - отправка команды BREAK;
~C - открытие командной строки для динамической установки некоторых опций командной строки.
Поддерживается установка опций "-L", "-R", "-D" (разные виды проброса) и "-KR" (отмена проброса);
~R - инициирование обновления ключей;
~ Ctrl+Z - приостановка сеанса с возвращением в shell, для возврата следует выполнить команду fg;
~# - вывод списка перенаправленных соединений;
~& - завершить работу в фоне (при ожидании завершения соединений);
~? - вывод подсказки по командам;
~~ - отображение escape-символа.
|
| |
|
|
|
Настройка SSH для использования наиболее защищённых алгоритмов шифрования (доп. ссылка 1) |
[комментарии]
|
| | В свете [[https://www.opennet.ru/opennews/art.shtml?num=41356 появления]] сведений об организации АНБ атак, направленных на получение контроля над SSH-соединениями, [[https://stribika.github.io/2015/01/04/secure-secure-shell.html подготовлено]] руководство с рекомендациями по усилению защищённости SSH. АНБ может получить контроль за SSH-соединением в случае использования уязвимых методов шифрования или в результате захвата приватных ключей. Ниже представлены советы по отключению потенциально проблемных алгоритмов и усилению защиты.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Применение двухфакторной аутентификации для SSH и GDM средствами Google Authenticator (доп. ссылка 1) (доп. ссылка 2) (доп. ссылка 3) |
[комментарии]
|
| | При применении двухфакторной аутентификации, кроме традиционного логина/пароля или ключа требуется ввести код подтверждения, получаемый с устройства, заведомо принадлежащего владельцу аккаунта. Наиболее простым способом является использование открытого проекта [[https://code.google.com/p/google-authenticator/ Google Authenticator]], который предоставляет мобильное приложение для генерации одноразовых паролей (TOTP) и PAM-модуль для установки на стороне сервера.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Двухфакторная аутентификация SSH с использованием YubiKey (доп. ссылка 1) |
Автор: Dvenum
[комментарии]
|
| | Все началось с того, что я приобрел YubiKey и захотел использовать его для двухфакторной аутентификации SSH. Я также хотел иметь возможность восстановить доступ к серверу на случай, если потеряю ключ. Информация о том, как это сделать, слишком разрознена, поэтому я написал собственное руководство.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Автоматизация запуска PuTTY и XMing |
Автор: Igor Garkusha
[комментарии]
|
| | [[B]]Задача:[[/B]] Организовать автоматизированное подключение Windows-клиента
к Linux-серверу терминалов через программу [[http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY]] (по ssh-протоколу) в связке с [[http://sourceforge.net/projects/xming/ XMing]]. Windows-клиент имеет в домене гостевой профиль (все настройки после выхода из системы сбрасываются). Имена пользователей из домена Windows и на сервере терминалов совпадают(!).
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Как удержать SSH-соединение от обрыва при использовании Socks |
[комментарии]
|
| | При выходе в сеть через Socks-прокси ssh-соединение часто разрывается после
небольшого интервала неактивности (иногда достаточно несколько секунд).
Чтобы этого не произошло необходимо использовать опцию ServerAliveInterval=N,
которая заставляет ssh через N секунд отправлять alive-пакеты, не дающие
автоматически оборвать соединение из-за истечения таймаута.
Пример:
tsocks ssh -o ServerAliveInterval=3 myhost.test.ru
|
| |
|
|
|
Создание HTTP-туннеля для удаленного доступа к Linux-хосту в обход Microsoft ISA (доп. ссылка 1) |
[комментарии]
|
| | Для организации управления внешней рабочей станцией из корпоративной сети, защищенной Microsoft ISA, можно поднять HTTP-туннель, при помощи которого можно установить TCP-соединение, несмотря на использование HTTP-прокси и жестких политик ограничения доступа на межсетевом экране.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Escape-последовательность для ssh (доп. ссылка 1) |
Автор: Аноним
[комментарии]
|
| | Многим известна escape-последовательность ^], используемая клиентом telnet для
перехода в командный режим. Однако, не все знают о существовании
escape-последовательности в ssh-клиенте.
Если в вашем дистрибутиве она не включена по умолчанию, то это можно сделать
добавив в файл конфигурации ssh_config следующую опцию:
EscapeChar ~
Теперь вы можете:
~? получить список всех команд клиента
~. оборвать подвисшую сессию
|
| |
|
|
|
Автодополнение ssh-хостов в командной строке (доп. ссылка 1) |
Автор: bthemad
[комментарии]
|
| | Простейшим способом упрощения набора параметров для частоиспользуемых хостов является задание псевдонимов в ~/.ssh/config:
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Защищаем SSH при помощи технологии "Port Knocking" (доп. ссылка 1) (доп. ссылка 2) |
Автор: Дмитрий
[комментарии]
|
| | Реализация идеи динамического открытия доступа к 22 порту, при предварительном обращении telnet-ом на определенный сетевой порт (в примере 333 - открыть доступ и 334 - закрыть). Идея реализована средствами iptables, без привлечения дополнительных утилит и анализаторов логов.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Сопоставление логинов и хостов для упрощения входа по SSH (доп. ссылка 1) |
[комментарии]
|
| | При использовании разных имен пользователей на разных хостах часто приходится
долго перебирать их и вспоминать,
какой из аккаунтов заведен для данной машины. OpenSSH позволяет определить,
какое из имен использовать
для данного хоста по умолчанию.
Пример настроек .ssh/config:
Host *.test1.ru
ServerAliveInterval 60
User user1
Host *.test2.ru
Compression yes
ForwardX11 yes
IdentityFile ~/.ssh/id_dsa_ext
User user2
Теперь при входе "ssh test.test1.ru" будет использовано имя user1, а при "ssh
host.test2.ru" - имя user2.
|
| |
|
|
|
Поддержание SSH-туннеля в активном состоянии при помощи AutoSSH (доп. ссылка 1) (доп. ссылка 2) |
Автор: Roman Sozinov
[комментарии]
|
| | Иногда необходимо иметь возможность удалённо управлять какими-то системами, которые находятся за firewall'ами,
которые Вы не контролируете. В таких случаях помогают ssh-тунели с использованием перенаправления
(forwarding) портов. Например, допустим имеется удалённая машина trick, которая находится за маршрутизатором
в удалённой локальной сети, и вторая машина rose имеющая внешний ip-адрес. Для того, чтобы иметь
возможность с rose заходить на trick (либо использовать какой-то сервис на trick), необходимо поднять
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Помещение OpenSSH пользователей в изолированное sftp окружение (доп. ссылка 1) |
[комментарии]
|
| | Начиная с релиза 4.9 в OpenSSH появилась возможность помещать отдельных пользователей в изолированное окружение.
Помещение в chroot управляется через директиву ChrootDirectory, задаваемую в конфигурационном файле sshd_config.
При задействовании sftp-server интегрированного в sshd, при этом не требуется формирование специального chroot окружения.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Организация подключения по SSH через HTTP прокси |
[комментарии]
|
| | Устанавливаем ПО corkscrew (http://www.agroman.net/corkscrew/), позволяющее создавать туннели поверх HTTP прокси.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
Повторное использование открытых OpenSSH соединений и кеширование ключей (доп. ссылка 1) |
[комментарии]
|
| | В OpenSSH предусмотрена возможность использования существующих соединений, при повторном коннекте к хосту.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
|
|
Безопасный способ копировать бэкапы через ssh (доп. ссылка 1) |
Автор: mahoro
[комментарии]
|
| | Опция "command" файла authorized_keys позволяет указать команду, которая будет выполняться при каждом подключении пользователя по ssh.
...
[Слишком большой объем текста. Скрыт. Для просмотра см. продолжение]
|
| |
|
|
|
|
|
Как скрыть отображаемую версию OpenSSH |
Автор: Вотинцев Сергей А,
[комментарии]
|
| | Для OpenSSH из FreeBSD, в /usr/src/crypto/openssh/version.h меняем, например, на это:
#define SSH_VERSION_BASE "OpenSSH"
#define SSH_VERSION_ADDENDUM "Beastie"
пересобираем:
cd /usr/src/secure/usr.sbin/sshd
make obj && make depend && make all install
и имеем SSH-2.0-OpenSSH Beastie вместо SSH-2.0-OpenSSH_3.6.1p1 FreeBSD-200xxxxx.
Некоторые пакеты с OpenSSH (например в AltLinux) включают в себя патч от http://openwall.com,
добавляющий директиву SshVersion:
SshVersion OpenSSH-1.2.3
|
| |
|
|
|
Как создать шифрованный туннель используя SSH (доп. ссылка 1) |
[комментарии]
|
| | ssh dmzserver -R 9999:mirrorserver:80
ssh -R 9999:localhost:80 dmzserver
ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
|
| |
|
|
|
Как включить доступ на Cisco через ssh (доп. ссылка 1) |
[комментарии]
|
| | hostname имя_хоста
ip domain-name доменное_имя
crypto key generate rsa
ip ssh time-out 120
ip ssh authentication-retries 3
line vty 0 4
transport input telnet ssh
!
show crypto key mypubkey rsa
|
| |
|
|
|
Как настроить доступ по SSH на базе секретных ключей без ввода пароля. |
[комментарии]
|
| | В /etc/ssh/sshd_config проверяем активна ли опция "PubkeyAuthentication yes".
Запускаем на локальной машине программу ssh-keygen (ssh-keygen -t rsa),
на все задаваемые вопросы принимаем значения по умолчанию (поле passphrase оставляем пустым).
Далее, запускаем программу ssh-copy-id -i ~/.ssh/id_rsa.pub user@remotehost, где
user - пользователь удаленной машины
remotehost - адрес удаленной машины,
( или вручную, на удаленной машине в директории ~/.ssh, создаем файл authorized_keys,
куда копируем содержимое файла identity.pub (id_rsa.pub) с локальной машины).
Для увеличения безопасности в файл ~/.ssh/authorized_keys на удаленной машине
добавляем перед ключом (разделив пробелом) строку:
from="localhost", где localhost - адрес локальной машины (from="localhost" 1024 23 1343.....).
|
| |
|
|
|
Какие ограничения лучше включить для SSHD ? |
[обсудить]
|
| | В /etc/ssh/sshd_config:
AllowUsers user1 user2 user3@host.ru
ChallengeResponseAuthentication no
PermitEmptyPasswords no
PermitRootLogin no
Protocol 2
UseLogin no
X11Forwarding no
UsePrivilegeSeparation yes
# убрать все Subsystem
Ограничить вход только с определенных IP через /etc/hosts.allow
|
| |
|
|
|
Как скопировать группу файлов на удаленную машину. |
[комментарии]
|
| | С локальной на удаленную:
tar czvf - список_файлов_и_директорий | ssh remote.test.ru tar xzf - -C /home/user/куда_копировать
Скопировать группу файлов с удаленной машины на локальную.
ssh remote.test.ru tar czf - -C стартовая_директория какие_файлы_копировать
|tar xzf - -C директория_куда_копировать.
|
| |
|
|
