diff options
Diffstat (limited to 'LINUX/SSH.md')
| -rw-r--r-- | LINUX/SSH.md | 302 |
1 files changed, 302 insertions, 0 deletions
diff --git a/LINUX/SSH.md b/LINUX/SSH.md new file mode 100644 index 0000000..a169457 --- /dev/null +++ b/LINUX/SSH.md @@ -0,0 +1,302 @@ +#### SSH alias !!! #### +```sh +ssh-keygen --help # -h + +vim ~/.ssh/config + +UseRoaming no + +Host <newHostName> +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 +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` для новых идей.
\ No newline at end of file |