Permittty ssh что это

ssh по ключу на оффтопик

Хочу настроить это https://code.visualstudio.com/docs/remote/ssh-tutorial Поставил в виртуалку десятку, запустил sshd. В C:\Users\user\.ssh\authorized_keys добавил свой ключ из ~/.ssh/id_rsa.pub . В C:\Users\user\.ssh\sshd_config отключил доступ с паролем PasswordAuthentication no . Рестартнул сервис и пытаюсь подключиться

$ ssh 'user@192.168.89.136' user@192.168.89.136: Permission denied (publickey,keyboard-interactive).

Авторизация по ключу в виндоус вообще доступна?

# This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key #HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key #HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key #HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH LogLevel ERROR # Authentication: #LoginGraceTime 2m #PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys AuthorizedKeysFile .ssh/authorized_keys #AuthorizedPrincipalsFile none # For this to work you will also need host keys in %programData%/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no #PermitEmptyPasswords no #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #PermitTTY yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #PermitUserEnvironment no #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # override default of no subsystems Subsystem sftp sftp-server.exe # Example of overriding settings on a per-user basis #Match User anoncvs # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server Match Group administrators AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

dnb ★★★★
16.04.22 13:56:20 MSK

Ответить на это сообщение
Ссылка

не получается соединиться с компьютером по ssh

В общем надо соединиться с компьютером по ssh . НО так и не понял что я делаю не так. На машине к которой хочу подключиться делаю перезагрузку ssh . И запускаю ssh .

root@R2CPU:~# service ssh restart root@R2CPU:~# service ssh start root@R2CPU:~# ifconfig eth0: flags=4163 mtu 1500 inet 192.168.1.111 netmask 255.255.255.0 broadcast 192.168.1.255 ether 00:1f:f2:00:00:00 txqueuelen 1000 (Ethernet) RX packets 4066 bytes 422817 (412.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 883 bytes 37086 (36.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1 (Local Loopback) RX packets 1589 bytes 139429 (136.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1589 bytes 139429 (136.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

На другой машине пытаюсь присоединиться :

comp@comp0:~$ ssh 192.168.1.111 ssh: connect to host 192.168.1.111 port 22: Connection timed out

В общем не подключилось 🙁 В общем так и не понял, что я не так делаю . В конфигурационный файл /etc/ssh/sshd_config не лез (всё стандартное). Вот «он»:

# $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #PubkeyAuthentication yes # Expect .ssh/authorized_keys2 to be disregarded by default in future. #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for# HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no #GSSAPIAuthentication no #GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes PrintMotd no #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation sandbox #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # Allow client to pass locale environment variables AcceptEnv LANG LC_* # override default of no subsystems Subsystem sftp /usr/lib/openssh/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options

Попробовал nmap

comp@comp0:~$ nmap -p22 192.168.1.111 Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-01 12:46 MSK Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.05 seconds comp@comp0:~$ nmap 192.168.1.111 Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-01 12:46 MSK Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.05 seconds comp@comp0:~$ ssh 192.168.1.111 ssh: connect to host 192.168.1.111 port 22: Connection timed out comp@comp0:~$ nmap -Pn -p22 192.168.1.111 Starting Nmap 7.60 ( https://nmap.org ) at 2019-10-01 12:55 MSK Nmap scan report for 192.168.1.111 Host is up. PORT STATE SERVICE 22/tcp filtered ssh Nmap done: 1 IP address (1 host up) scanned in 2.40 seconds

ifconfig на клиенской машине :

comp@comp0:~$ ifconfig enp2s0: flags=4163 mtu 1500 inet 172.16.8.106 netmask 255.255.255.0 broadcast 172.16.8.255 inet6 fe80::433e:3621:7ea4:caa4 prefixlen 64 scopeid 0x20 ether bc:ae:c5:d8:4e:ff txqueuelen 1000 (Ethernet) RX packets 39312 bytes 29092453 (29.0 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 24969 bytes 4286043 (4.2 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Локальная петля (Loopback)) RX packets 2598 bytes 266475 (266.4 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2598 bytes 266475 (266.4 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Решил попробывать от атвратного , вспомнил что отвратный это я :3 и посему решил наоборот попробывать, сейчас debian 9 сервер, Ubuntu 18 клиент а будет debian 9 клиент, Ubuntu 18 сервер вот сервер на Убунте

 comp@comp0:~$ ifconfig enp2s0: flags=4163 mtu 1500 inet 172.16.8.106 netmask 255.255.255.0 broadcast 172.16.8.255 inet6 fe80::433e:3621:7ea4:caa4 prefixlen 64 scopeid 0x20 ether bc:ae:c5:d8:4e:ff txqueuelen 1000 (Ethernet) RX packets 45932 bytes 41114861 (41.1 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 34976 bytes 8223651 (8.2 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Локальная петля (Loopback)) RX packets 3028 bytes 312797 (312.7 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3028 bytes 312797 (312.7 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 comp@comp0:~$ service ssh start comp@comp0:~$

А вот клиент Дебиан

root@R2CPU:/# service ssh stop root@R2CPU:/# ifconfig eth0: flags=4163 mtu 1500 inet 172.16.8.169 netmask 255.255.255.0 broadcast 172.16.8.255 ether 00:1f:f2:00:00:00 txqueuelen 1000 (Ethernet) RX packets 21301 bytes 2143902 (2.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 4176 bytes 180772 (176.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1 (Local Loopback) RX packets 1368 bytes 129809 (126.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1368 bytes 129809 (126.7 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 root@R2CPU:/# ssh 172.16.8.106 The authenticity of host '172.16.8.106 (172.16.8.106)' can't be established. ECDSA key fingerprint is SHA256:TxUTkjjnCo87SUjePlU/h76UnyeL/8CzG+5sd8bZa5A. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '172.16.8.106' (ECDSA) to the list of known hosts. [email protected]'s password: Permission denied, please try again. [email protected]'s password: Permission denied, please try again. [email protected]'s password: Permission denied (publickey,password). root@R2CPU:/# ssh 172.16.8.106 [email protected]'s password: Permission denied, please try again. [email protected]'s password: Permission denied, please try again. [email protected]'s password: Permission denied (publickey,password). root@R2CPU:/#

Требует какойто код , которого у меня нету 🙁 Пытался использовать имя и пароль от компа сервера (именно пользовательский ) но как то не вышло (( В файле /etc/ssh/sshd_config на сервере изменил строку :

 PermitRootLogin no

Но всё равно просит ввести какой-то пароль (единственный плюс он хотябы начал отвечать (именно сервер дебиан :3 )).

comp@comp0:/$ ssh 172.16.8.169 [email protected]'s password: Permission denied, please try again. [email protected]'s password: Permission denied, please try again. [email protected]'s password: [email protected]: Permission denied (publickey,password). comp@comp0:/$

При подключенини одноразовый пароль нигде не создаётся и не выводится Где «добыть» этот чертов пароль .

Как настроить SSH-Jump Server

Для работы с облачной инфраструктурой рекомендуется создавать SSH Jumpstation. Это позволяет повысить безопасность и удобство администрирования серверов. В этой статье мы расскажем, как настроить единую точку входа для подключений по ssh – SSH Jump Server. Для реализации выбраны два проекта с открытым исходным кодом.

Традиционный подход с использованием OpenSSH. Преимущество в том, что на ваших Linux-серверах уже предустановлены необходимые пакеты OpenSSH
Использование альтернативного opensource-проекта Teleport

Оба этих сервера просты в установке и настройке, бесплатны, имеют открытый исходный код и представляют собой демоны Linux с одним бинарником.

Что такое SSH Jump Server?

SSH Jump Server — это обычный сервер Linux, доступный из интернета, который используется в качестве шлюза для доступа к другим машинам Linux в частной сети с использованием протокола SSH. Иногда SSH Jump Server также называют jump host или bastion host. Назначение SSH Jump Server — быть единственным шлюзом для доступа к вашей инфраструктуре, уменьшая размер потенциальной поверхности атаки. Наличие выделенной точки доступа SSH также упрощает ведение сводного журнала аудита всех SSH подключений.

Почему бы не использовать термин SSH-proxy? Отчасти по историческим причинам. В первые дни использования SSH пользователям приходилось подключаться по SSH к Jump Server, а оттуда им приходилось снова вводить ssh, чтобы «перейти» к хосту назначения. Сегодня это делается автоматически, и Teleport фактически использует термин SSH-proxy для описания этой функции.

Настройка SSH Jump Server

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

Чтобы предотвратить непреднамеренное обновление конфигурации jump-сервера
Чтобы исключить возможность использования jump-сервера для других задач

Также неплохо изменить порт TCP по умолчанию на сервере перехода SSH с 22 на другой.

Давайте рассмотрим настройку сервера перехода SSH с использованием двух проектов с открытым исходным кодом. Начнём с OpenSSH, самого распространённого варианта.

Но сначала давайте введём некоторые имена, которые будут использоваться в примерах ниже:

Домен организации: example.com
DNS-имя jump-сервера организации будет proxy.example.com

Также предполагается, что proxy.example.com — это единственная машина в локальной сети организации, доступная из Интернета.

OpenSSH

Этот пакет SSH-сервера по умолчанию входит в состав большинства дистрибутивов Linux, и есть почти 100% вероятность, что он у вас уже установлен. Если у вас есть доступ к jump-серверу proxy.example.com, вы можете получить доступ к другим серверам в локальной сети за этим NAT с помощью -J флага в командной строке:

$ ssh -J proxy.example.com 10.3.3.1

В приведённом примере 10.3.3.1 – это адрес конечной станции в локальной сети, к которой вы подключаетесь. Выглядит довольно просто.

Чтобы не печатать в командной строке параметры -J proxy.example.com , вы можете обновить конфигурацию SSH на вашем клиенте в файле ~/.ssh/config следующим образом:

Host 10.3.3.* ProxyJump proxy.example.com

Теперь, когда пользователь вводит ssh 10.3.3.1 , SSH-клиент даже не пытается разрешить адрес 10.3.3.1 локально, а вместо этого устанавливает соединение c proxy.example.com , которое перенаправляет его на 10.3.3.1 в своем локальном сегменте.

Теперь нужно немного усилить конфигурацию безопасности jump-сервера, отключив интерактивные сеансы SSH на jump-сервере для обычных пользователей, но оставив их включёнными для администраторов. Для этого необходимо обновить конфигурацию sshd , обычно она лежит в файле /etc/ssh/sshd_config :

# Do not let SSH clients do anything except be forwarded to the destination: PermitTTY no X11Forwarding no PermitTunnel no GatewayPorts no ForceCommand /sbin/nologin

Приведённый выше пример будет работать для Debian и его производных, советуем проверить наличие файла /sbin/nologin .

Это конфигурация будет работать, если на jump-сервере есть учётные записи для всех пользователей SSH, что не очень удобно. Вместо этого рассмотрите возможность создания отдельной учётной записи на jump-сервере, предназначенной для перенаправляемых пользователей ssh. Назовём эту учётную запись jumpuser и обновим конфигурацию ssh-сервера:

Match User jumpuser PermitTTY no X11Forwarding no PermitTunnel no GatewayPorts no ForceCommand /usr/sbin/nologin

И пользователям нужно будет обновить конфигурацию своего клиента SSH в файле ~/.ssh/config :

Host 10.2.2.* ProxyJump jumpuser@proxy.example.com

Для получения дополнительной информации по конфигурированию SSH для вашей конкретной ситуации, обратитесь к man ssh_config и man sshd_config .

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

Teleport

Teleport — это SSH-сервер и клиент, который был выпущен в 2016 году. Teleport ориентирован на работу с кластерами и большим количеством узлов.

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

Помимо современных функций прокси, Teleport предлагает несколько преимуществ по сравнению с традиционным SSH:

Teleport не использует SSH-ключи и вместо этого по умолчанию использует более безопасные и гибкие сертификаты SSH. Это устраняет необходимость в управлении ключами и сильно упрощает настройку SSH-серверов.
Teleport поддерживает другие протоколы в дополнение к SSH, поэтому тот же jump-сервер можно использовать для доступа к другим ресурсам за NAT, таким как кластеры Kubernetes или даже внутренние приложения через HTTP(s).
Teleport не полагается на пользователей Linux для аутентификации. Вместо этого он поддерживает отдельную базу данных пользователей или может интегрироваться с помощью единого входа с другими поставщиками аутентификации, такими как Github, Google Apps, или корпоративными опциями, такими как Okta и Active Directory.

Teleport всегда поставляется с прокси (то есть то же самое, что и jump-сервер), и нет необходимости в специальных инструкциях по его настройке. Скачать его можно здесь.

Другие особенности Teleport:

Помимо традиционного интерфейса командной строки имеется возможность входа через HTTPS с эмуляцией терминала в web-браузере
Поддержка функций аудита и повторения типовых операций. Содержимое SSH-сеансов может записываться и при необходимости воспроизводиться на других хостах
Режим совместного решения проблем, при котором несколько человек могут совместно использовать один сеанс SSH
Автоматическое определение доступных рабочих серверов и контейнеров Docker в кластерах с динамическим присвоением имён хостам
Поддержка обратного туннелирования для подключения к кластерам, ограждённым межсетевым экраном
Возможность определения меток для наглядного разделения узлов кластера
Поддержка блокировки доступа после нескольких неудачных попыток входа
Сопоставление пользователей с логинами на конечных узлах осуществляется через специальные списки маппинга
Для подсоединения к хосту требуется указать два имени — имя кластера и имя узла в кластере. Teleport ориентирован на управление кластерами, а не отдельными серверами. Для каждого пользователя и хоста определяется принадлежность к кластеру
Узлы подключаются к кластеру через определение статичестких или генерацию динамических токенов, которые при желании можно отозвать для запрета входа на данный узел
Для подсоединения к серверам Teleport внутри кластера можно использовать обычный клиент OpenSSH (требуется копирование ключей)
Успешно пройден аудит безопасности кода, заказанный в независимой проверяющей компании

Заключение

Итак, мы рассказали, как настроить SSH-jump сервер с помощью двух проектов с открытым исходным кодом: OpenSSH и Teleport. Но какой же выбрать?

Используйте OpenSSH, если:

Количество серверов и/или пользователей в вашей организации невелико
Вам нужна быстрая настройка jump-сервера, и у вас не так много времени, чтобы изучить новые технологии

Используйте Teleport, если:

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

Что ещё интересного есть в блоге Cloud4Y

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Кстати, у нас сейчас действует акция: -65% на IaaS-инфраструктуру. Условия актуальны до 6 декабря, поспешите!

Блог компании Cloud4Y
Информационная безопасность
Системное администрирование
IT-инфраструктура
Серверное администрирование

Доступ по SSH

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

Примечание: Проверено на Starterkit P10 Mate (весенний) 25.07.2022

С помощью SSH-сервера можно удаленно управлять сервером через консоль (ssh://-соединение) и передавать файлы (sftp-сервер).

В данной статье будут рассмотрены настройка доступа к терминалу (TODO: надо описать. В данный момент настройка терминального доступа не описана) и файлам через SSH.

1 Предварительный бэкап
2 Доступ по SSH через сеть
- 2.1 Обмен файлами
Предварительный бэкап

На сервере переключаемся в режим суперпользователя:

Делаем на всякий случай бэкап конфига:
```
# cd /etc/openssh # cp -a sshd_config sshd_config.bak
```
И правим конфиг файл:
```
# cd /etc/openssh # mcedit sshd_config
```
Потом, если что-то пошло не так, удаляем измененный и восстанавливаем исходный:
```
# cd /etc/openssh # rm sshd_config # cp -a sshd_config.bak sshd_config # service sshd reload
```
В любом случае при изменениях этого файла стоит обязательно:
1. держать уже открытую рутовую сессию через достаточно надёжное соединение;
2. перезапустить sshd;
3. попытаться подключиться ещё одной рутовой сессией по ключу (либо пользовательской с поднятием привилегий, что несколько менее предпочтительно),
чтобы убедиться в том, что удалённый доступ к системе всё ещё функционирует.

Доступ по SSH через сеть

Редактируем следующие значения:
```
Port 22 //раскоментируем строчку MaxSessions 10 //раскомментируем строчку PubkeyAuthentication yes //раскомментируем строчку PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa-cert-v01@openssh.com,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256 //раскомментируем строчку PasswordAuthentication yes //раскомментируем строчку PermitEmptyPasswords no //раскомментируем строчку ChallengeResponseAuthentication yes //раскомментируем строчку ClientAliveInterval 300 //раскомментируем строчку и меняем значение ClientAliveCountMax 3 //раскомментируем строчку Subsystem sftp /usr/lib/openssh/sftp-server //раскомментируем строчку Match User petr //тут пишем пользователя, под которым будем заходить X11Forwarding yes //раскомментируем строчку AllowTcpForwarding yes //раскомментируем строчку PermitTTY yes //раскомментируем строчку
```
Сохраняем файл и перезапускаем сервис:
```
# service sshd reload
```
Вводим в консоли ssh user@ip:
```
$ ssh petr@10.0.2.6
```
Система запросит разрешение на принятие SSH-ключа и ввод пароля. После этого у Вас будет консоль подключенного сервера.

Обмен файлами

Обмен файлами с сервером будет происходить по протоколу SSH.
```
# mkdir /home/files
```
Этот же каталог прописываем в ChrootDirectory.
```
ChrootDirectory /home/files
```
Даем себе полные права:
```
# chown petr:petr /home/files # chmod -R u+rwx /home/files
```
Подключаем его на Workstation:
- Открываем Caja
- Файл > Соединиться с сервером:
  - IP
  - Тип: SSH
  - Папка: /home/files
  - Имя пользователя: petr (учетка на сервере, которой мы дали права)
  - Пароль: (соответствующий)
  - Можно поставить галочку «Добавить закладку»
  Похожие публикации: