#### SSH alias !!! #### ```sh ssh-keygen --help # -h vim ~/.ssh/config UseRoaming no Host Hostname 178.20.46.157 # или vlapa.ru User vlapa Port 22 ##########################: # заходим на сервер ssh newHostName ``` #### Проброс портов SSH: #### ```sh ssh -L 9000:localhost:8000 server2 ssh -L [локальный_адрес:]порт:удалённый_адрес:порт [user@]hostname # Если не указывать [локальный_адрес:], соединение по умолчанию будет привязано к интерфейсу localhost. ``` #### SSH #### ```sh ssh-keygen -t rsa -b 4096 -C "backup-vlapa" ssh-keygen -t rsa cat ~/.ssh/id_rsa.pub ssh-keygen -t ed25519 ssh-keygen -t ed25519 -f ~/.ssh/key2 -C "new key" # -сменить пароль на ключ ssh-keygen -p # -открытый ключ. копируют на сервера ~/.ssh/id_rsa.pub # -закрытый ключ (у нас) ~/.ssh/id_rsa ~/.ssh/authorized_keys chown -R vlapa:vlapa /home/vlapa/.ssh # Права обязательно !!! chmod 700 ~/.ssh chmod 644 ~/.ssh/* chmod 600 authorized_keys ssh -i ~/.ssh/key2 vlapa@192.168.88.2 cd /etc/ssh ll vim /etc/sshd_config Port 22 PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no systemctl restart sshd systemctl status sshd ssh -i ~/.ssh/key2 vlapa@192.168.88.2 vim .ssh/config Host \*.com StrictHostKeyChecking no User etoosamoe ForwardAgent yes IdentityFile /Users/username/.ssh/id_rsa IdentitiesOnly yes UserKnownHostsFile=/dev/null UseKeychain yes AddKeysToAgent yes ServerAliveInterval 60 ServerAliveCountMax 1200 Host std-\* StrictHostKeyChecking no User ci-user ForwardAgent yes IdentityFile /Users/username/.ssh/id_rsa_second IdentitiesOnly yes UserKnownHostsFile=/dev/null UseKeychain yes AddKeysToAgent yes ServerAliveInterval 60 ServerAliveCountMax 1200 ``` ```sh # В каталоге пользователя, под которым вы хотите зайти, если создать файл и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям (и группам !!!), иначе ssh его не примет. В ключе последнее поле — user@machine Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа. ssh-copy-id user@server # позволяет скопировать ключ не редактируя файлы вручную. # Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id '-p 443 user@server' # внимание на кавычки ! # Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts Узнать, где какой ключ нельзя (ибо несекьюрно). # Удалить известный ключ сервера можно командой: ssh-keygen -R server # При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1 # Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub # Их можно: # а) скопировать со старого сервера на новый. # б) сгенерировать с помощью ssh-keygen Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет. # Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать. # Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key sudo ssh service restart sudo sshd service restart # Чтобы удаленно выполнить команду с локального компьютера, добавьте инструкцию к команде SSH. Например, чтобы удалить файл, введите: ssh test.server.com rm ~/Desktop/Dir1/sample4 # Введите пароль, и файл на удаленном сервере будет удален без создания новой оболочки. sudo systemctl restart ssh vim /etc/ssh/sshd_config - PasswordAuthentication no - PermitRootLogin no - AllowUsers www root sudo service ssh restart # Ключ игнорируется сервером # В редких случаях можно столкнуться с проблемой, что вы настроили все корректно, но не можете подключиться к серверу с использованием 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* ( 600) # После применения этих политик ошибка должна исчезнуть. ``` =========================================== ### Как общаться с удаленным сервером через SSH `ssh-keygen -t rsa -b 4096 -f host_ca -C host_ca Файл `host_ca` является закрытым ключом центра сертификации хоста и должен храниться в защищенном месте. Не выдавайте его никому, не копируйте куда-либо и убедитесь, что как можно меньше людей имеют к нему доступ. В идеале он «живет» на машине, которая не допускает прямого доступа, и все сертификаты выдаются автоматически. Рекомендуется использовать два отдельных CA – один для подписания сертификатов хостов, другой для пользователей. Одни и те же процессы не будут добавлять и хосты, и юзеров. А если закрытый ключ скомпрометируют, нужно будет лишь пересоздать сертификаты для хостов или пользователей, а не оба сразу. Вот так создается `user_ca`: `$ ssh-keygen -t rsa -b 4096 -f user_ca -C user_ca` Файл `user_ca` – закрытый ключ пользователя, который должен быть защищен, как и закрытый ключ хоста. ### Выдача сертификатов хостам Создадим новый ключ и подпишем с помощью центра сертификации. ssh_host_rsa_key-cert.pub содержит подписанный сертификат хоста. ```sh $ ssh-keygen -f ssh_host_rsa_key -N '' -b 4096 -t rsa $ ls -l -rw------- 1 palpatine palpatine 3247 Mar 17 14:49 ssh_host_rsa_key -rw-r--r-- 1 palpatine palpatine 764 Mar 17 14:49 ssh_host_rsa_key.pub $ ssh-keygen -s host_ca -I host.example.com -h -n host.example.com -V +52w ssh_host_rsa_key.pub Enter passphrase: # the passphrase used for the host CA Signed host key ssh_host_rsa_key-cert.pub: id "host.example.com" serial 0 for host.example.com valid from 2020-03-16T15:00:00 to 2021-03-15T15:01:37 $ ls -l -rw------- 1 palpatine palpatine 3247 Mar 17 14:49 ssh_host_rsa_key -rw-r--r-- 1 palpatine palpatine 2369 Mar 17 14:50 ssh_host_rsa_key-cert.pub -rw-r--r-- 1 palpatine palpatine 764 Mar 17 14:49 ssh_host_rsa_key.pub ``` Вот описание используемых флагов: - **-s host_ca**: указывает имя файла закрытого CA-ключа, используемого для подписи. - **-I host.example.com**: буквенно-цифровая строка, идентифицирующая сервер. При необходимости значение можно использовать для отзыва сертификата. - **-h**: указывает, что сертификат выдается хосту, а не юзеру. - **-n host.example.com**: указывает разделенный запятыми список участников, для проверки подлинности которых будет действителен сертификат. - **-V +52w**: срок действия сертификата. В данном случае 52 недели (один год). По умолчанию сертификаты действительны вечно. Указание периода истечения срока действия сертификатов хоста настоятельно рекомендуется для ротации и замены сертификатов. ## Настройка SSH для использования сертификатов Нужно указать серверу, чтобы он использовал новый сертификат. Скопируйте три сгенерированных файла на сервер в каталог `/etc/ssh`, установите разрешения и добавьте в файл `/etc/ssh/sshd_config` следующую строку: `HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub` Перезагрузите **sshd** с помощью `systemctl restart sshd`. Теперь сервер настроен на выдачу сертификата. Чтобы локальный ssh-клиент мог автоматически доверять хосту на основе удостоверения сертификата, нужно добавить открытый ключ CA в `known_hosts`. Вы можете сделать это, добавив в начало файла `host_ca.pub` следующее: `@cert-authority *.example.com`, а затем и в `~/.ssh/known_hosts`: `@cert-authority *.example.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDwiOso0Q4W+KKQ4OrZZ1o1X7g3yWcmAJtySILZSwo1GXBKgurV4jmmBN5RsHetl98QiJq64e8oKX1vGR251afalWu0w/iW9jL0isZrPrmDg/p6Cb6yKnreFEaDFocDhoiIcbUiImIWcp9PJXFOK1Lu8afdeKWJA2f6cC4lnAEq4sA/Phg4xfKMQZUFG5sQ/Gj1StjIXi2RYCQBHFDzzNm0Q5uB4hUsAYNqbnaiTI/pRtuknsgl97xK9P+rQiNfBfPQhsGeyJzT6Tup/KKlxarjkMOlFX2MUMaAj/cDrBSzvSrfOwzkqyzYGHzQhST/lWQZr4OddRszGPO4W5bRQzddUG8iC7M6U4llUxrb/H5QOkVyvnx4Dw76MA97tiZItSGzRPblU4S6HMmCVpZTwva4LLmMEEIk1lW5HcbB6AWAc0dFE0KBuusgJp9MlFkt7mZkSqnim8wdQApal+E3p13d0QZSH3b6eB3cbBcbpNmYqnmBFrNSKkEpQ8OwBnFvjjdYB7AXqQqrcqHUqfwkX8B27chDn2dwyWb3AdPMg1+j3wtVrwVqO9caeeQ1310CNHIFhIRTqnp2ECFGCCy+EDSFNZM+JStQoNO5rMOvZmecbp35XH/UJ5IHOkh9wE5TBYIeFRUYoc2jHNAuP2FM4LbEagGtP8L5gSCTXNRM1EX2gQ== host_ca` Значение `*.example.com` указывает на то, что этому сертификату следует доверять для идентификации любого хоста, к которому вы подключаетесь и который имеет домен `*.example.com`. Это разделенный запятыми список имен хостов для сертификата: **host1**, **host2**, **host3** или **1.2.3.4**, **1.2.3.5** в зависимости от обстоятельств. Как только закончите настройку, удалите все старые записи для `host.example.com` в `~/.ssh/known_hosts` и запустите подключение. Правильность создания сертификата проверяется так: `$ ssh -vv host.example.com 2>&1 | grep "Server host certificate" debug1: Server host certificate: ssh-rsa-cert-v01@openssh.com SHA256:dWi6L8k3Jvf7NAtyzd9LmFuEkygWR69tZC1NaZJ3iF4, serial 0 ID "host.example.com" CA ssh-rsa SHA256:8gVhYAAW9r2BWBwh7uXsx2yHSCjY5OPo/X3erqQi6jg valid from 2020-03-17T11:49:00 to 2021-03-16T11:50:21 debug2: Server host certificate hostname: host.example.com` На этом этапе вы можете продолжить выдачу сертификатов всех хостов, используя центр сертификации. Польза от этого следующая: вам больше не нужно полагаться на небезопасную модель **Trust On First Use (TOFU)** для новых хостов, и если вы когда-нибудь повторно развернете сервер и, следовательно, измените ключ хоста, новый хост автоматически представит подписанный сертификат без ужасного предупреждения: **WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!** ## Выдача сертификатов пользователям (для аутентификации пользователей на хостах) В этом примере мы создадим новый ключ пользователя и подпишем с помощью центра сертификации. `$ ssh-keygen -f user-key -b 4096 -t rsa $ ls -l -rw-r--r--. 1 tatooine tatooine 737 Mar 19 16:33 user-key.pub -rw-------. 1 tatooine tatooine 3369 Mar 19 16:33 user-key $ ssh-keygen -s user_ca -I gus@gravitational.com -n ec2-user,gus -V +1d user-key.pub Enter passphrase: # the passphrase used for the user CA Signed user key user-key-cert.pub: id "gus@gravitational.com" serial 0 for ec2-user,gus valid from 2020-03-19T16:33:00 to 2020-03-20T16:34:54 $ ls -l -rw-------. 1 tatooine tatooine 3369 Mar 19 16:33 user-key -rw-r--r--. 1 tatooine tatooine 2534 Mar 19 16:34 user-key-cert.pub -rw-r--r--. 1 tatooine tatooine 737 Mar 19 16:33 user-key.pub` `user-key-cert.pub` содержит подписанный сертификат пользователя. Для входа в систему понадобится как этот, так и приватный ключ. Вот описание используемых флагов: - **-s user_ca**: указывает приватный ключ CA, используемый для подписи. - **-I tatooine@proglib.io**: буквенно-цифровая строка, которая будет видна в логе SSH. Для точной идентификации пользователя рекомендуем использовать адрес электронной почты или логин. - **-n palpatine, tatooine**: указывает разделенный запятыми список участников, для проверки подлинности которых будет действителен сертификат. В примере мы предоставляем сертификат доступа как для `palpatine`, так и для `tatooine`. - **-V +1d**: указывает срок действия сертификата, в данном случае +1d означает 1 день. Если нужно увидеть параметры подписи сертификата, используйте`ssh-keygen -L`: `$ ssh-keygen -L -f user-key-cert.pub user-key-cert.pub: Type: ssh-rsa-cert-v01@openssh.com user certificate Public key: RSA-CERT SHA256:egWNu5cUZaqwm76zoyTtktac2jxKktj30Oi/ydrOqZ8 Signing CA: RSA SHA256:tltbnMalWg+skhm+VlGLd2xHiVPozyuOPl34WypdEO0 (using ssh-rsa) Key ID: "palpatine@proglib.io" Serial: 0 Valid: from 2020-03-19T16:33:00 to 2020-03-20T16:34:54 Principals: tatooine palpatine Critical Options: (none) Extensions: permit-X11-forwarding permit-agent-forwarding permit-port-forwarding permit-pty permit-user-rc` ## Настройка SSH для проверки подлинности После того как сертификат подписан, нужно сообщить серверу, что можно доверять пользователским сертификатам. Копируем `user_ca.pub` в директорию `/etc/ssh`, поправляем права и добавляем в конфиг `/etc/ssh/sshd_config` строку: `TrustedUserCAKeys /etc/ssh/user_ca.pub` Как раньше, перезагружаем **sshd** с помощью `systemctl restart sshd`. Теперь сервер настроен на пропуск всех, кто представляет сертификат, выданный центром сертификации при подключении. Если сертификат хранится в том же каталоге, что и ваш приватый ключ (указанный с флагом `-i`, например `ssh -i /home/tatooine/user-key` `palpatine @proglib.io`), он будет автоматически использоваться при подключении к серверам. ## Проcмотр логов Если вы посмотрите в журнал sshd сервера, запустив `journalctl -u sshd`, то увидите имя используемого для аутентификации сертификата, а также данные центра сертификации: `sshd[14543]: Accepted publickey for tatooine from 1.2.3.4 port 53734 ssh2: RSA-CERT ID palpatine@proglib.io (serial 0) CA RSA SHA256:tltbnMalWg+skhm+VlGLd2xHiVPozyuOPl34WypdEO0` Если пользователь попытается войти в систему под логином, у которого нет доступа, в логе вы увидите такую ошибку: `sshd[14612]: error: key_cert_check_authority: invalid certificate sshd[14612]: error: Certificate invalid: name is not a listed principal` Если срок действия сертификата истек, вы увидите следующую ошибку: `sshd[14240]: error: key_cert_check_authority: invalid certificate sshd[14240]: error: Certificate invalid: expired` В качестве домашнего задания напишите скрипт, который будет использовать центр сертификации для выдачи сертификатов, действительных в течение следующих двух часов. Каждое использование этого скрипта должно журналировать того, кто запросил сертификат и его почту, а потом встраивать этот email в сертификат. Это поможет в мониторинге. Взгляните на `man ssh-keygen` для новых идей.