У меня есть удаленный сервер CentOS, к которому у меня был доступ по SSH. Сегодня, когда я пытаюсь войти в систему через SSH, я просто получаю отказ в доступе, хотя я использую правильные учетные данные. У меня есть доступ к plesk 9, поэтому я сбросил пароль администратора и попытался подключиться к SSH, используя этот пароль, но безрезультатно. Я даже создал нового пользователя с правами доступа SSH и попытался войти под ним, но снова потерпел неудачу с тем же отказом в доступе. Я перезагрузился.
Кто-нибудь может дать совет? В plesk нет файлового менеджера, кроме веб-доменов, поэтому я не могу получить доступ к системным файлам, чтобы увидеть, что происходит.
Любые советы приветствуются.
РЕДАКТИРОВАТЬ ------------- Вывод, запрошенный Ианом
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXXXX [XXXXX] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-g roup-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160 ,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160 ,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-gro up14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1 28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 122/256
debug2: bits set: 507/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 0 for host XXXXX
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts2
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug2: no key of type 2 for host XXXXX
The authenticity of host 'XXXXX (XXXXX)' can 't be established.
RSA key fingerprint is da:23:25:e5:e7:11:7f:73:f3:d2:be:a4:f8:b9:a7:21.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'XXXXX' (RSA) to the list of known hosts.
debug2: bits set: 491/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa ((nil))
debug2: key: /root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interac tive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password
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 credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found
debug1: Unspecified GSS failure. Minor code may provide more information
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@XXXXX's password:
debug3: packet_send2: adding 48 (len 62 padlen 18 extra_pad 64)
debug2: we sent a password packet, wait for reply
Connection closed by XXXXX
Eсть очень хороший шанс, что ваш sshd_config имеет следующие настройки:
PermitRootLogin without-password
Это означает, что Root может аутентифицироваться только с помощью ключа. Если вы никогда его не поставляли, есть большая вероятность, что вам придется попросить свой центр обработки данных перевести коробку в однопользовательский режим и отредактировать этот файл, чтобы вы могли войти.
После этого создайте пару закрытого / открытого ключей и получите свой открытый ключ на сервере, чтобы вы могли аутентифицироваться более безопасно.
Это почти напоминает мне ситуацию, которую я видел, когда у вас не хватает места, и процесс не может быть разветвлен и т. Д. Если проблема не в пространстве, вы захотите увидеть, заблокирована ли ваша учетная запись.
Если вы можете запускать удаленные команды, но не видите вывод, вам следует попробовать передать вывод в почтовую программу, чтобы отправить вам подробности. Например:cat /etc/ssh/sshd_config | mail -s ssh_config email@example.com
Отметьте AllowUsers в / etc / ssh / sshd_config.
В дополнение к уже приведенным ответам, особенно к предложению Тима о конкретных настройках учетной записи root, позвольте мне добавить несколько строк об основах общего способа быстрой диагностики проблем с ssh-соединением.
На клиенте добавьте подробные параметры
ssh -vvv me@node
Один v означает подробный, 2 v означает более подробный и т. Д.
Если этого недостаточно, на сервере, если вы единственный пользователь (или в 3 часа ночи ;-) остановите демон sshd и запустите его с полными флагами отладки.
sshd -ddd
То же самое: один d означает отладку (кратко), 2 - дополнительную отладку и т. Д. Обмен открытыми ключами часто указывает на проблемы с правами доступа к файлам / папкам.