Я пытаюсь подключиться к серверу CentOS, который я не могу контролировать. Администратор добавил мой открытый ключ к серверу и настаивает на том, что вина лежит на мне, но я не могу понять, в чем дело.
Конфиг в .ssh:
tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa
Разрешения на мои ключевые файлы:
tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim 746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub
Журнал подключений, который я не могу понять:
tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key:
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
ssh tim@10.0.12.28
в качестве журнала упомянуть Kerberos, что сервер CentOS может быть интегрирован в домен (AD, IPA, ...). Вы должны выяснить, какого пользователя вы должны использовать. Спросите администратора. Например, мы используем IPA, поэтому мы разрешаем пользователям подключаться к определенным серверам с помощью учетной записи домена IPA и пары ключей, и при необходимости они могут выполнять sudo. Нет root-доступа :)Ответы:
Это обычно решает большинство проблем с разрешениями авторизованного ключа SSH на стороне сервера , при условии, что кто-то не внес дополнительных изменений в разрешения.
Если ваш администратор создал файл .ssh / directory или .ssh / authorized_keys в качестве пользователя root (как это обычно делается), то владение файлом, принадлежащим другому пользователю (даже если root!), Не допускается.
Userify (отказ от ответственности: соучредитель) автоматически делает это точно так же. Https://github.com/userify/shim/blob/master/shim.py#L285
источник
sudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -R
что сэкономит время при наборе текста, но новичку будет труднее понятьУ меня была точно такая же проблема на двух серверах: в Linux, работающем под управлением Debian Stretch, и на NAS (Synology DS715)
оказалось, что в обоих случаях права на домашний каталог на сервере были неправильными
auth.log на сервере был очень полезным
в Linux он имел бит записи / группы (drwxrwxr - x), поэтому мне пришлось удалить хотя бы группу записи (chmod gw ~ /), и тогда это сработало
на Synology, по какой-то причине, было немного
Я должен был изменить это с
и я мог бы тогда подключиться без пароля
источник
chmod -t
... Я закончил с:admin@SYN:~$ ls -ald . .ssh .ssh/* drwxr-xr-x 6 admin users 4096 Jan 10 15:54 . drwx------ 2 admin users 4096 Jan 10 15:54 .ssh -rwx------ 1 admin users 401 Jan 10 15:54 .ssh/authorized_keys -rw------- 1 admin users 1679 Jan 10 15:49 .ssh/id_rsa -rwxr--r-- 1 admin users 396 Jan 10 15:49 .ssh/id_rsa.pub -rwx------ 1 admin users 396 Jan 10 10:04 .ssh/known_hosts
Когда я использую CentOS 7, я уверен, что он применим и к другим ОС Linux, использующим sshd. С помощью корневого доступа вы можете больше узнать, почему аутентификация может быть неудачной. Сделать это:
vi /etc/ssh/sshd_config
SyslogFacility AUTH LogLevel INFO
systemctl restart sshd
tail -l /var/log/messages
Например, я испытывал некоторые из тех же проблем, что и упомянутые выше.
Используя эти шаги, я смог подтвердить, что проблема заключалась в разрешениях для файла authorized_keys. Установив chmod на 644 в файле авторизованных ключей моего пользователя, проблема была исправлена.
источник
Похоже, что права доступа к вашей
.ssh
папке не скопированы + вставлены правильно. Не могли бы вы добавить это снова?Если строгий режим включен, то мы должны убедиться, что
.ssh
имеет правильные разрешения:.ssh/
должны иметь завивки0700/rwx------
.ssh/*.pub
файлы должны быть644/rw-r--r--
.ssh/*
(другие файлы в формате .ssh)0600/rw-------
Как все выглядит для вас с разрешения?
источник
На всякий случай, если кто-то наткнется на этот ответ - ни одна из рекомендаций не сработала в моем сценарии. В итоге проблема заключалась в том, что я создал учетную запись без пароля. Как только я установил пароль с помощью,
usermod -p "my password" username
а затем принудительно разблокировал учетную запись,usermod -U username
все было замечательно.источник
У меня была похожая проблема , когда ssh-соединение пробует ключ,
~/.ssh/id_rsa
прежде чем неожиданно остановиться:В моем случае это было связано со старым файлом открытого ключа, лежащим в
.ssh
каталоге:Перемещение / удаление
id_rsa.pub
из.ssh
каталога решило проблему.Из того, что я понимаю: когда на стороне клиента присутствует открытый ключ, SSH 1st проверяет закрытый ключ на его соответствие. Если это не удается, он не будет пытаться использовать закрытый ключ для удаленного подключения.
Я отправил электронное письмо в список рассылки openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .
источник
openssh-8.0p1-5.fc30.x86_64
Кстати. У меня был открытый ключ от более раннего сервера с тем же именем, что и у нового сервераfedora@(baloo).sshkey.pub
, которыйfedora@(baloo).sshkey
передается в командной строке вместе с-i
опцией. Ошибка аутентификации с новым ключом сервера, найденным в новомfedora@(baloo).sshkey
- ключ RSA.Мы столкнулись с этой проблемой. Права доступа и права доступа к файлам .ssh были правильными. В / var / log / messages мы нашли:
Итак, решение для разработчика VM, где мы не заботимся о безопасности, это отключить selinux. Отредактируйте / etc / sysconfig / selinux и измените SELINUX = отключено и перезагрузите компьютер.
источник
На всякий случай это тоже кого-то спасает. Я пытался скопировать ключ с моей машины Ubuntu 18.04 на 2 сервера CentOS 7. Я имел обыкновение
ssh-copy-id
передавать их. Один работал, другой нет. Так что я прошел все отладки разрешений и ничего не нашел. Итак, наконец, я поднял файл/etc/ssh/sshd_config
на обоих серверах и построчно прошел через них. Наконец я нашел это, вероятно, кое-что, что кто-то изменил задолго до того, как я приступил к работе.Один читал:
AuthorizedKeysFile .ssh/authorized_keys
И еще одно чтение:
AuthorizedKeysFile ~/.ssh/authorized_keys
на сервере, который не принимал мои ключи. Очевидно, что поиск между двумя файлами и замечание комментария, в котором говорится, что шаблоны поиска по умолчанию не включают в себя ведущий,~/
я удалил его и перезапустил sshd. Проблема решена.источник
Также столкнулся с этой проблемой. setroubleshoot не работает в моей среде, поэтому в / var / log / messages такой записи журнала не было. Отключение SELinux не было для меня вариантом, поэтому я сделал
После этого логин по ключу rsa работал нормально.
источник
Причиной в моем случае была опция, заданная пользователем
AuthorizedKeysFile
в файле/etc/ssh/sshd_config
. Для него был задан home dir (/home/webmaster/.ssh/authorized_keys
) другого пользователя , поэтому пользователь, которому я пытался войти, не имел доступа к этому файлу / каталогу.После его изменения и перезапуска ssh-server (
service ssh restart
) все пришло в норму. Я могу войти через свой закрытый ключ сейчас.источник
В нашем случае проблемы были связаны с тем, что наши правила брандмауэра и NAT не были правильно настроены.
порт 22, был направлен на неправильный сервер, где наши ключи и пользователь не был распознан.
Если кто-то доберется до этой точки. tcpdump и telnet могут быть вашими друзьями
Вы заметите, что эти два сервера имеют разные версии openssh. Это помогло мне определить проблему довольно быстро. Если ваши хосты используют одни и те же версии ssh, вам нужно будет выполнить упакованную трассировку в месте назначения, чтобы увидеть, действительно ли трафик поступает в пункт назначения.
Ssh может генерировать много трафика, что затрудняет поиск tcpdump, что вы ищете.
Это помогло мне
Попробуйте подключиться к телнету с 3 разных серверов, а не с вашего текущего компьютера @ [mylocalip]. Вы хотите увидеть, какой трафик фактически достигает вашего сервера.
источник
Журнал ошибок на стороне клиента заканчивается следующим образом:
может быть вызвано серверным (удаленным) ограничением на вход в систему root, когда sshd файл конфигурации содержит:
Предложение JonCav включить ведение журнала было полезно при устранении такой проблемы. В то время как на стороне клиента отладки изрыгать был удивительно бесполезным, помещая следующее в Sshd сервера sshd_config файл:
закончил производить полезные сообщения журнала:
В случае, если не удается выполнить вход только с правами root , и если ваша политика безопасности допускает использование только аутентификации на основе ключей для учетной записи с правами root, может помочь изменение файла sshd_config :
Ваш пробег может отличаться, хотя это часто помогает, некоторые другие конфигурации могут все еще вмешиваться в соответствии с комментарием, найденным в некоторых файлах sshd_config :
Даже если вы не можете легко изменить конфигурацию удаленного сервера для отладки таким способом, можно до некоторой степени проверить конфигурацию на стороне клиента, используя те же файлы идентификации для ssh для учетной записи без полномочий root на том же удаленном сервере.
источник
Я понимаю, почему безопасность может беспокоить людей. У меня просто
ssh won't use my key
снова возникла проблема. Я решил это, войдя в удаленный сервер и запустива затем с моего рабочего стола, (пытается SSH к серверу)
На сервер я попал
Authentication refused: bad ownership or modes for directory /
Какой-то новый системный администратор испортил разрешение и права собственности, которые я исправил:
(Я привык к необходимости,
chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pub
но sshd проверка / поиск прав root является для меня новым.) Теперь я собираюсь проверить наличие руткита, а затем уничтожить и переустановить.источник
В моем случае проблемы были с неправильной оболочкой exec.
Изменен файл / etc / passwd для этого пользователя
источник
У меня была эта проблема в CentOS 7. Я обычный пользователь Linux на основе Debian, поэтому я был рыбой из воды. Я заметил, что на некоторых серверах это работало, а на одном - нет. Audit.log не сказал ничего полезного, и secure.log тоже ничего не дал. Я обнаружил, что единственной реальной разницей были некоторые различия в контексте безопасности файлов и каталогов между теми, которые работали, и теми, которые не работали. Получить безопасность с
sudo ls -laZ <user-home>/.ssh
каталога (я предполагаю много значений по умолчанию для sshd_config).
Вы должны увидеть некоторые
ssh_home_t
иuser_home_t
атрибуты. Если вы этого не сделаете, используйтеchcon
команду, чтобы добавить недостающие атрибуты.Например
В моем случае я подозреваю, что пользователь был создан нестандартным способом. Его дом был каталогом
/var/lib
.Больше информации в: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/
источник