2016-02-03 7 views
0

Я пытаюсь использовать SSH-аутентификацию через открытый ключ, который работает для нескольких машин, но одна отдельная машина не принимает его.Вход OpenSSH через открытый ключ не работает

Прежде всего, созвездие: Машина, которая пытается подключиться: OpenSSH_5.1p1, OpenSSL 0.9.8h 28 мая 2008 Сервер: OpenSSH_5.3p1, OpenSSL 1.0.1e-ФИПС 11 февраля 2013

Это то, что происходит:

[email protected]:/root> ssh -v server 
OpenSSH_5.1p1, OpenSSL 0.9.8h 28 May 2008 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: Applying options for * 
debug1: Connecting to server [x.x.x.x] port 22. 
debug1: Connection established. 
debug1: identity file /home/user/.ssh/id_rsa type -1 
debug1: identity file /home/user/.ssh/id_dsa type 2 
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 
debug1: match: OpenSSH_5.3 pat OpenSSH* 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_5.1 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: server->client aes128-cbc hmac-md5 none 
debug1: kex: client->server aes128-cbc hmac-md5 none 
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent 
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP 
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent 
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY 
debug1: Host 'server' is known and matches the RSA host key. 
debug1: Found key in /home/user/.ssh/known_hosts:1 
debug1: ssh_rsa_verify: signature correct 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug1: SSH2_MSG_NEWKEYS received 
debug1: SSH2_MSG_SERVICE_REQUEST sent 
debug1: SSH2_MSG_SERVICE_ACCEPT received 
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password 
debug1: Next authentication method: publickey 
debug1: Trying private key: /home/nagios/.ssh/id_rsa 
debug1: Offering public key: /home/nagios/.ssh/id_dsa 
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password 
debug1: Next authentication method: password 
[email protected]'s password: 

sshd_config сервера:

#  $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 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:/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 change a 
# default value. 

#Port 22 
#AddressFamily any 
#ListenAddress 0.0.0.0 
#ListenAddress :: 

# Disable legacy (protocol version 1) support in the server for new 
# installations. In future the default will change to require 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 

# Lifetime and size of ephemeral version 1 server key 
#KeyRegenerationInterval 1h 
#ServerKeyBits 1024 

# Logging 
# obsoletes QuietMode and FascistLogging 
#SyslogFacility AUTH 
SyslogFacility AUTHPRIV 
#LogLevel INFO 

# Authentication: 

#LoginGraceTime 2m 
#PermitRootLogin yes 
#StrictModes yes 
#MaxAuthTries 6 
#MaxSessions 10 

RSAAuthentication yes 
PubkeyAuthentication yes 
AuthorizedKeysFile  .ssh/authorized_keys 
#AuthorizedKeysCommand none 
#AuthorizedKeysCommandRunAs 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 yes 

# 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 no 
GSSAPIAuthentication yes 
#GSSAPICleanupCredentials yes 
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 no 
UsePAM yes 

# 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 

#AllowAgentForwarding yes 
#AllowTcpForwarding yes 
#GatewayPorts no 
#X11Forwarding no 
X11Forwarding yes 
#X11DisplayOffset 10 
#X11UseLocalhost yes 
#PrintMotd yes 
#PrintLastLog yes 
#TCPKeepAlive yes 
#UseLogin no 
#UsePrivilegeSeparation yes 
#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 

# no default banner path 
#Banner none 

# 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 
#  ForceCommand cvs server 

ssh_config клиента:

#  $OpenBSD: ssh_config,v 1.23 2007/06/08 04:40:40 pvalchev Exp $ 

# This is the ssh client system-wide configuration file. See 
# ssh_config(5) for more information. This file provides defaults for 
# users, and the values can be changed in per-user configuration files 
# or on the command line. 

# Configuration data is parsed as follows: 
# 1. command line options 
# 2. user-specific file 
# 3. system-wide file 
# Any configuration value is only changed the first time it is set. 
# Thus, host-specific definitions should be at the beginning of the 
# configuration file, and defaults at the end. 

# Site-wide defaults for some commonly used options. For a comprehensive 
# list of available options, their meanings and defaults, please see the 
# ssh_config(5) man page. 

Host * 
# ForwardAgent no 
# ForwardX11 no 

# If you do not trust your remote host (or its administrator), you 
# should not forward X11 connections to your local X11-display for 
# security reasons: Someone stealing the authentification data on the 
# remote side (the "spoofed" X-server by the remote sshd) can read your 
# keystrokes as you type, just like any other X11 client could do. 
# Set this to "no" here for global effect or in your own ~/.ssh/config 
# file if you want to have the remote X11 authentification data to 
# expire after two minutes after remote login. 
ForwardX11Trusted yes 

# RhostsRSAAuthentication no 
# RSAAuthentication yes 
# PasswordAuthentication yes 
# HostbasedAuthentication no 
# GSSAPIAuthentication no 
# GSSAPIDelegateCredentials no 
# BatchMode no 
# CheckHostIP yes 
# AddressFamily any 
# ConnectTimeout 0 
# StrictHostKeyChecking ask 
# IdentityFile ~/.ssh/identity 
# IdentityFile ~/.ssh/id_rsa 
# IdentityFile ~/.ssh/id_dsa 
# Port 22 
    Protocol 2 
# Cipher 3des 
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc 
# MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160 
# EscapeChar ~ 
# Tunnel no 
# TunnelDevice any:any 
# PermitLocalCommand no 
# GSSAPIAuthentication no 
# GSSAPIDelegateCredentials no 

# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication 
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included 
# in this release. The use of 'gssapi' is deprecated due to the presence of 
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to. 
# GSSAPIEnableMITMAttack no 

# This enables sending locale enviroment variables LC_* LANG, see ssh_config(5). 
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
SendEnv LC_IDENTIFICATION LC_ALL 

Я также проверил права доступа к дому, .ssh папок и файлов. Клиент:

[email protected]:/home> ls -l | grep user 
drwx------ 11 user user 4096 Feb 2 13:48 user 
[email protected]:/home> cd user 
[email protected]:~> ls -al | grep '.ssh' 
drwx------ 2 user user 4096 Feb 2 13:48 .ssh 
[email protected]:~> cd .ssh 
[email protected]:~/.ssh> ls -al 
total 32 
drwx------ 2 user user 4096 Feb 2 13:48 . 
drwx------ 11 user user 4096 Feb 2 13:48 .. 
-rw------- 1 user user 672 May 10 2010 id_dsa 
-rw------- 1 user user 609 May 10 2010 id_dsa.pub 
-rw------- 1 user user 12823 Feb 2 17:06 known_hosts 

Сервер:

[[email protected] home]# ls -l |grep user 
drwx------. 4 user user 4096 May 27 2013 user 
[[email protected] home]# cd user 
[[email protected] user]# ls -al |grep '.ssh' 
drwx------. 2 user user 4096 Feb 3 13:09 .ssh 
[[email protected] user]# cd .ssh 
[[email protected] .ssh]# ls -al 
total 12 
drwx------. 2 user user 4096 Feb 3 13:09 . 
drwx------. 4 user user 4096 May 27 2013 .. 
-rw-------. 1 user user 609 Feb 3 13:09 authorized_keys 

Так что я совершенно не знаю, почему сервер продолжает спрашивать меня пароль. Я также установил пароль, и этот работает. Но мне нужен auth без пароля.

У вас есть идеи? Интересно, действительно ли это несовместимость ...

Заранее спасибо.

+0

проверить журналы сервера, проверить, используете ли вы правильный ключ, запустить сервер в режиме отладки ('LogLevel DEBUG3') и следить за журналами. Он расскажет вам причину отказа от ключа. – Jakuje

+0

Можете ли вы сказать мне, какие файлы журналов я должен проверить для таких записей? Может быть, они уже там. Я бы хотел предотвратить перезагрузку, так как это операционный сервер. Thasnks. – Nico

ответ

0

Полная версия OpenSSL 0.9.8 не поддерживается на openssl.org, как и вся версия 1.0.0!

Кроме того, 0.9.8h, в частности, является древним - даже ваш собственный журнал показывает, что он с 2008 года. Последний 0.9.8 был 0.9.8zh за github's OpenSSL release page.

СЛЕДУЕТ ДОПОЛНИТЕЛЬНУЮ версию 1.0.1 или 1.0.2 или последнюю версию LibreSSL или PolarSSL.

Вам НУЖНО на минимальном обновлении до 0,9,8 года, чтобы получить 8 years of vulnerability fixes.

Вам также необходимо просмотреть настройки sshd_config; за openbsd documentation RSAAuthentication - это только вариант протокола 1, и вы настроили его только на своем сервере с протоколом 2. Я только заметил это; у вас могут быть другие странные конфигурации в обеих конфигурациях - внимательно их просмотрите и сравните клиента ssh_config с обновлением после обновления с рабочими файлами ssh_config на других клиентах.

+0

Спасибо, что до сих пор. Просто уточнить: существует много серверов, на которых работает функция pubkey auth. Только этот единственный сервер не принимает. И файл authorized_keys верен. Существует еще один сервер с теми же версиями, и я могу использовать pubkey для auth просто отлично. Даже sshd_config - то же самое (я прокомментировал три строки: RSA, PubKey и один после). Достаточно сбивать с толку, это даже та же операционная система. Кстати, я пробовал обновлять, но я не знаком с YaST. YaST online-updater обнаружил несколько патчей, даже для OpenSSL. Но строка версии не изменилась даже после перезапуска. – Nico

+0

Является ли ssh_config одинаковым между рабочим и нерабочим клиентом с той же версией строки? Вам нужно будет обновить OpenSSH, а не только OpenSSL, чтобы изменить строку версии - это может быть статическое связывание (то есть версия OpenSSL, запеченная в OpenSSH). Похоже, вам нужно перейти на новый сервер или проверить брандмауэры и доступ к сети. –

+0

Ну, клиент является единственным, кто используется для этого. Это машина Nagios и предназначена для подключения через SSH для запуска команд проверки. Вот почему на самом деле существует паблик. Поэтому у меня нет другого клиента, с которым можно сравнить. И поскольку один сервер совершенно идентичен другому, но один не работает, мне интересно, где я мог бы взглянуть дальше. Я попытаюсь найти другую машину и проверить pubkey оттуда, чтобы проверить, не поддерживает ли этот сервер публичный ключ вообще. Но если у вас есть идея, где я могу взглянуть, пожалуйста, дайте мне знать. Благодаря! – Nico