0

I have a remote CentOS server to which I had SSH access to. Today when I try to log in via SSH I just get Access Denied even though I am using the correct credentials. I have plesk 9 access and so have reset the admin password and tried to SSH using that password but to no avail. I even created a new user with SSH access rights and tried to log in as them but again failed with the same access denied. I have rebooted.

Can anyone offer any advice? There is no file manager in plesk other than for the web domains so I can't get at any system files to see what is going on.

Any advice appreciated.

EDIT-------------Output asked for by Iain

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
John Gardeniers
  • 27,458
  • 12
  • 55
  • 109
columbo
  • 219
  • 2
  • 12
  • I've realised I can set root commands as scheduled tasks a couple of minutes off. I've tried restrating SSH but it doesn't help. – columbo Feb 16 '11 at 14:57
  • I'm not familiar with Plesk. Can you view the /etc/ssh/sshd_config file with it? If so, check the AllowUsers directive. – quanta Feb 16 '11 at 15:08
  • Can you post the output (perhaps via a link to pastbin) of the output of ssh -vvv user@servername please. – user9517 Feb 16 '11 at 15:51
  • FYI - the plesk admin password is not the same as the plesk admin user. I don't actually know of a way to change the root password via plesk, but you can retrieve the admin password in /etc/psa/.psa.shadow – Coops Feb 16 '11 at 15:55
  • Hi Iain and Coops. Iain, op edited into my original question. Coops, how do you go about retrieval via .psa.shadow? – columbo Feb 16 '11 at 16:09
  • By the way, since I can make root commands as scheduled tasks, is there a way to change the root password without it prompting for the new password? I don't suppose there is because it wants you to enter it twice to verify it. – columbo Feb 16 '11 at 16:11
  • Can be issue of tcp wrapper also also check /etc/hosts.deny – vnix27 Feb 16 '11 at 16:34
  • What OS are you using and is your SSH Client/service running locally? – Chadddada Feb 16 '11 at 15:00
  • Hi, OS is CentOS 5 with Plesk 9 (64-bit), I am trying to connect via my local windows PC via Putty and have also tried SSHing from the command line of another remote server but it gives the same result (access denied). – columbo Feb 16 '11 at 15:05

4 Answers4

1

There is a very good chance that your sshd_config has the following setting:

PermitRootLogin without-password

This means, Root can only authenticate with a key. If you've never supplied one, there's a good chance that you'll need to ask your data center to take the box down to single user mode and edit that file to allow you to get in.

After that, make a private / public key pair and get your public key on the server, so that you can authenticate more securely.

Tim Post
  • 1,525
  • 13
  • 25
1

This almost reminds me of a situation I have seen where you are out of space and a process cant be forked, etc. If space is not the issue then you will want to see if your account is locked.

If you can run remote commands but cant see the output, you should try piping the output to a mail program to send you the details. For example:cat /etc/ssh/sshd_config | mail -s ssh_config email@example.com

cwebber
  • 491
  • 3
  • 7
  • Good idea, it shows there is no AllowUsers in the config and PermitRootLogin without-password is not present. it feels like I've got the wrong password but I am convinced I haven't changed it. – columbo Feb 16 '11 at 16:40
  • This mailing idea allowed meto get info I needed, I'm going to rebbot the server in resue mode and reset the root password that way. – columbo Feb 18 '11 at 10:06
0

Check AllowUsers into /etc/ssh/sshd_config.

lg.
  • 4,649
  • 3
  • 21
  • 20
0

In addition to the answers already given, especially Tim's suggestion about the root account specific settings, let me add a few lines about the basics of a general way to quickly diagnose ssh connection problems.

On the client add the verbose options

ssh -vvv me@node

One v means verbose, 2 v means more verbose etc...

If this is not enough, on the server, if you're the only user (or at 3 o'clock in the morning ;-) stop sshd daemon and run it with full debug flags.

sshd -ddd

Same thing one d stands for debug (terse), 2 for more debug, etc... When public keys have been exchanged, this often points to file/folder permission issues.

Alain Pannetier
  • 142
  • 2
  • 9