Невозможно подключиться по ssh к серверу: нет поддерживаемых методов аутентификации

1723
Soufiaane

Попробовав несколько советов из разных блогов о том, как защитить ssh-соединения с сервером, я не могу получить доступ к своему серверу. Я получаю это сообщение об ошибке:

(Отключено: нет поддерживаемых методов аутентификации (сервер отправлен: publickey, gssapi-keyex, gssapi-with-mic)))

Это мой конфигурационный файл для sshd:

# $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $  # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information.  # This sshd was compiled with PATH=/usr/local/bin:/usr/bin  # 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.  # If you want to change the port on a SELinux system, you have to tell # SELinux about this change. # semanage port -a -t ssh_port_t -p tcp #PORTNUMBER # Port 7777 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress ::  # The default requires explicit activation of protocol 1 Protocol 2  # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key HostKey /etc/ssh/ssh_host_ed25519_key  # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 1024  # Ciphers and keying #RekeyLimit default none  # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH SyslogFacility AUTHPRIV #LogLevel INFO  # Authentication:  #LoginGraceTime 2m PermitRootLogin no #StrictModes yes #MaxAuthTries 6 #MaxSessions 10  RSAAuthentication yes 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  #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody  # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and 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 PasswordAuthentication no StrictModes no  # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes ChallengeResponseAuthentication no  # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no #KerberosUseKuserok yes  # GSSAPI options GSSAPIAuthentication yes GSSAPICleanupCredentials no #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no #GSSAPIEnablek5users 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'. # WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several # problems. UsePAM yes  #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no UsePrivilegeSeparation sandbox # Default for new installations. #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #ShowPatchLevel no #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none  # no default banner path #Banner none  # Accept locale-related environment variables AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS  # override default of no subsystems Subsystem sftp /usr/libexec/openssh/sftp-server  # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server 

Я не думаю, что это как-то связано с SELinux.

Это вывод для моего списка папок .ssh:

ls -laZ ~/.ssh/  drwx------. smghanen apache unconfined_u:object_r:ssh_home_t:s0 . drwx------. smghanen apache unconfined_u:object_r:user_home_dir_t:s0 .. -rw-------. smghanen apache unconfined_u:object_r:user_home_t:s0 authorized_keys 

Как я могу решить это? И какие советы помогут сделать его еще более безопасным?

1
Вы сгенерировали ключ и передали его на сервер перед отключением аутентификации по паролю? Вы пытаетесь войти в систему как пользователь без полномочий root, и у этого пользователя есть соответствующий ключ? А вы запускали команду semanage в комментариях вверху sshd_config? Mella 7 лет назад 1
1) да, я сгенерировал ключ и передал его на сервер перед отключением аутентификации по паролю 2) да, я пытаюсь войти в систему как пользователь без полномочий root, и да, это пользователь, имеющий соответствующий ключ 3) и да, я запустил приведенная выше команда semanage, я не думаю, что это проблема с портом, потому что, если я попробую другой порт, я получу сообщение «Ошибка сети, соединение отказано» и для ключа я смог войти в систему с пользователем без полномочий root, прежде чем это произошло, когда я отключена аутентификация по паролю и изменен номер порта по умолчанию Soufiaane 7 лет назад 0

2 ответа на вопрос

0
Vitalii Nesterenko

С CentOS7 вы используете firewallcmd. Лучший способ - отключить службу firewallcmd, попытаться подключиться и, если подключение установлено успешно, создать правило в firewallcmd.

firewall-cmd - список всех открытых (по умолчанию, активных) интерфейсов: eth0 источники: службы: dhcpv6-client ssh порты: 7431 / tcp 25672 / tcp 4369 / tcp 8089 / tcp 7432 / tcp 5671-5672 / tcp 7777 / tcp 8883 / tcp 61613-61614 / tcp 15672 / tcp маскарад: нет форвард-портов: icmp-blocks: богатые правила: порт sudoage-sudo -l | grep ssh_port_t ssh_port_t tcp 7777, 22 Я не думаю, что это проблема порта Soufiaane 7 лет назад 0
"Какую операционную систему вы используете?" - Это комментарий и не принадлежит вашему ответу. В будущем вам следует обратиться за разъяснениями, отправив комментарий на вопрос автора, а после получения разъяснения отправьте свой ответ. Ramhound 7 лет назад 0
"Какую операционную систему вы используете?" Не нужно быть в ответе, потому что исходный вопрос помечен `centos-7`, поэтому второй и третий абзацы действительно отвечают на исходный вопрос. karel 7 лет назад 0
0
Soufiaane

Плохо, я изменил расположение закрытого ключа на моем клиенте и не заметил, что он не был загружен Pageant