help! ssh password being denied for ALL acccounts (hacked?)

JustinHoMi · 05-16-2002, 07:34 PM

Hi. I've been trying to ssh into my remote server for the last several minutes, and my password is coming back denied. I've tried a couple of accounts, but am having no luck logging in. The accounts DO work for ftp though. I have not tried the root account b/c I don't to risk revealing the password to a hacker. Any ideas as to what could be going on, and how to get around it?

THanks!
Justin

unSpawn · 05-17-2002, 04:38 PM

Hmm. Any hunch *why* you think it might be a cracked box?
Since you haven't stated you got access any other way to a remote account, have you tried using ssh with "-v -v -v" for extra detailed output? Can you retrace any modifications you did on the box lately?

JustinHoMi · 05-17-2002, 05:03 PM

Well, first of all I'm a little paranoid b/c I work on a lot of sensitive data, and hackers know it's on that server. I was surprised that my password was denied, so it worried me that someone had changed it.

Here's the output of "ssh -v user@hostname". It didn't look particularly out of the ordinary:

Quote:

[nuttin@david nuttin]$ ssh -v user@hostname
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /usr/local/openssh-3.1p1/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 60033 geteuid 0 anon 1
debug1: Connecting to hostname [x.x.x.x] port 22.
debug1: temporarily_use_uid: 60033/100 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 60033/100 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/httpd/business/nuttin/.ssh/identity type -1
debug1: identity file /home/httpd/business/nuttin/.ssh/id_rsa type -1
debug1: identity file /home/httpd/business/nuttin/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.1p1
debug1: match: OpenSSH_3.1p1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.1p1
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 sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 140/256
debug1: bits set: 1579/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hostname' is known and matches the RSA host key.
debug1: Found key in /home/httpd/business/nuttin/.ssh/known_hosts2:1
debug1: bits set: 1602/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: next auth method to try is publickey
debug1: try privkey: /home/httpd/business/nuttin/.ssh/identity
debug1: try privkey: /home/httpd/business/nuttin/.ssh/id_rsa
debug1: try privkey: /home/httpd/business/nuttin/.ssh/id_dsa
debug1: next auth method to try is keyboard-interactive
debug1: authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: next auth method to try is password
justin@hostname's password:
debug1: packet_send2: adding 64 (len 58 padlen 6 extra_pad 64)
debug1: authentications that can continue: publickey,password,keyboard-interacti
ve
Permission denied, please try again.
user@hostname's password:

The only thing that I did was upgrade to the new redhat 7.3 glibc package (2.2.5 i think?) and gcc and the dev package. Could that be the culprit? It wasn't an immediate effect... maybe a couple hours later that this started happening.

Justin

myutopia · 05-24-2002, 10:31 AM

for a few pointers look here

The short off it is log in to the machine and start sshd on some other port with debugging ie
sshd -d -d -d -p 2000

the last part being the port you want to connect on then from your client machine ssh -p 2000 <sshserver>

obviously the nothing else can be using the port you choose. and hopefully this should give you something.

Usually i make the mistake of having the .ssh folder in my home directory world readable when I set it up.

Noerr · 05-26-2002, 05:57 AM

Also check sshd2_config if allowed users aren't altered ( if you play with this feature- you can get same results)