Cannot passwordlessly ssh using root

[Michele Albertone]

Hi,

know this is a commonly posted issue but could not make it work.

Have an 11.31 box where I need to be able to ssh using root without prompting the password.

to make it simple I was ssh to myself using root, and got a password prompt.

I tried to

1) regenerate the local keys public and private via  ssh-keygen -t dsa

2) copied the id_dsa.pub to authorized_keys and chmod 600

3) tried to ssh to myself and got the password prompt

On the same box another user is able to connect to itself but not to root, so that think the issue may be in some root specific configuration preventing that.

Running

ssh -vvvv <hostname>:

ebug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: REQUESTED ENC.NAME is 'aes128-cbc'
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: 134/256
debug2: bits set: 538/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host 'tbsms1a' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:1
debug2: bits set: 490/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: /.ssh/id_rsa (0)
debug2: key: /.ssh/id_dsa (40038a20)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/id_rsa
debug3: no such identity: /.ssh/id_rsa
debug1: Offering public key: /.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:

Thanks in advance!

Cheers,

Mike

[Patrick Wallek]

Check the /var/adm/syslog/syslog.log file for SSH errors. 

If public keys are set up correctly, the problem is almost always related to permissions somewhere.

[Michele Albertone]

Thanks Patrick,

checked in syslog before but no information logged  before the passowrd prompt is displayed

I did the same steps on a similar box, same SW level and it worked as expected.

Cheers,

Mike

[Michele Albertone · Accepted solution]

Got it,

my "/" was 777 instead of 755. After changint it worked fine.

Thanks!

Mike

[Steven Schweda]

> checked in syslog before but no information logged [...]

> my "/" was 777 instead of 755. After changint it worked fine.

   And there was nothing helpful in the system log file on the server
system?  Really?

   You do need to look at the log file on the _server_, not on the
client.  What, exactly, did "in syslog" mean to you?

[Michele Albertone]

Hi,

in this case I was ssh'ng to the same server I was alraedy logged on so that client and server were the same. I checked on /var/adm/syslog/syslog.log and could not find anything during my ssh attempt. Similarly the verbose info on ssh did not point me to the right direction, not sure if this deals with security/privacy reasons.

Thanks,

Mike