no password ssh not working as it used to

I backup stuff on my home machine by rsyncing with my work machine. I have to pull from work because I can't see my work machine externally.

The process is usually as follows:
1) logon to visible machine at work
2) login to my machine
3) switch to root (i have a external HD that only root can see)
4) run rsync script

Since there are several rsync commands I set up no password ssh by copying the root@work public key in to my authorised keys. THen out of the blue this stopped working.

I cannot get it to work again, even by starting all over from scratch. On my home network public keys work.

I allow access via ssh to my home network using a non standar port and my hostname is set via ddclient, although my ISP tends to give me the same IP address at all times anyway.

How can I trouble shoot this?

Many thanks,

Dave

Originally Posted by robotronic I backup stuff on my home machine by rsyncing with my work machine. I have to pull from work because I can't see my work machine externally. The process is usually as follows: 1) logon to visible machine at work 2) login to my machine 3) switch to root (i have a external HD that only root can see) 4) run rsync script Since there are several rsync commands I set up no password ssh by copying the root@work public key in to my authorised keys. THen out of the blue this stopped working. I cannot get it to work again, even by starting all over from scratch. On my home network public keys work. I allow access via ssh to my home network using a non standar port and my hostname is set via ddclient, although my ISP tends to give me the same IP address at all times anyway. How can I trouble shoot this? Many thanks, Dave

start with manual ssh connection using verbose flag and tail -f logs at remote side at the same time

ssh -vv user@host

[/code]

Also, are you watching /var/log/auth.log? I presume since you say "my work machine" that you are in control of that machine? So another sysadmin would not have blocked root logins?

If I were the sysadmin, I would have blocked it. That's a standard security practice. I use a restricted user account for backups and use sudo when needed. The keys are also restricted so that the connections can only do what I originally intended. It works just fine for doing backups, and root is not allowed to login remotely.

By the way, if you aren't familiar with it already, http://sial.org/howto/openssh/publickey-auth/ is a pretty standard reference for setting up keys. It also has some debugging notes.

Originally Posted by robotronic THen out of the blue this stopped working.

My WAG is that you have sshd's StrictModes enabled, and that you changed your user's home directory permissions on the server side. e.g. /home/foo can not be group writable or world writable, or pubkey authentication will not work.

A quick -

$ chmod go-w /home/foo

- will correct that.

While you're reviewing and fixing that, also confirm that /home/foo/.ssh and /home/foo/.ssh/authorized_keys is readable by only foo.

Hi,

@choogendyk So I have full root access to my work machine. I'm an academic and things are a little more relaxed. root logins over ssh are not allowed though. I'm backing up as root for some reason that I can't remember. I think I wanted to mount the drive as read only for my user account.

Here is the verbose output of ssh. I think the lines at the end are telling what is going wrong, but I don't understand it.

Is it trying to access as root on my home machine even though the ssh command is user@homemachine?:

debug2: key: /root/.ssh/authorized_keys ((nil)) debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/authorized_keys debug2: we did not send a packet, disable method

ssh -vv user@homemachine -p XXXXX OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to homemachine [XX.XX.XXX.XX] port XXXXX. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/authorized_keys type -1 debug1: loaded 1 keys debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-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,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,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-sha256,diffie-hellman-group-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,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,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 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_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: 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: 126/256 debug2: bits set: 489/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'lobster.parishouse.mine.nu' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:3 debug2: bits set: 552/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/authorized_keys ((nil)) debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/authorized_keys debug2: we did not send a packet, disable method debug1: Next authentication method: password

This is the tail of /var/log/auth.log on my home machine

Aug 20 09:09:01 homemachine CRON[6129]: pam_unix(cron:session): session opened for user root by (uid=0) Aug 20 09:09:01 homemachine dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.26" (uid=1000 pid=4733 comm="/usr/lib/indicator-applet/indicator-applet --oaf-a") interface="org.freedesktop.DBus.Properties" member="Get" error name="(unset)" requested_reply=0 destination=":1.41" (uid=0 pid=6129 comm="/USR/SBIN/CRON ")) Aug 20 09:09:01 homemachine CRON[6129]: pam_unix(cron:session): session closed for user root Aug 20 09:10:01 homemachine CRON[6209]: pam_unix(cron:session): session opened for user root by (uid=0) Aug 20 09:10:01 homemachine dbus-daemon: Rejected send message, 1 matched rules; type="method_call", sender=":1.26" (uid=1000 pid=4733 comm="/usr/lib/indicator-applet/indicator-applet --oaf-a") interface="org.freedesktop.DBus.Properties" member="Get" error name="(unset)" requested_reply=0 destination=":1.42" (uid=0 pid=6209 comm="/USR/SBIN/CRON ")) Aug 20 09:10:02 homemachine CRON[6209]: pam_unix(cron:session): session closed for user root

Thanks,

Dave

Originally Posted by robotronic Hi, @choogendyk So I have full root access to my work machine. I'm an academic and things are a little more relaxed. root logins over ssh are not allowed though. I'm backing up as root for some reason that I can't remember. I think I wanted to mount the drive as read only for my user account. Here is the verbose output of ssh. I think the lines at the end are telling what is going wrong, but I don't understand it. Is it trying to access as root on my home machine even though the ssh command is user@homemachine?: This is the tail of /var/log/auth.log on my home machine Thanks, Dave

looks like a key pair mismatch
i say this because

debug2: key: /root/.ssh/authorized_keys ((nil))
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/authorized_keys
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

should have been more like

[code]
debug1: Trying private key: /home/root/.ssh/identity
debug1: Trying private key: /home/root/.ssh/id_rsa
debug1: Offering public key: /home/root/.ssh/id_dsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 433




you may get some more info from

/var/log/secure

but i doubt you will need that.
points to keypair mismatch

I don't really understand. I generated a fresh pair in .ssh as root on my work machine:

ssh-keygen -t dsa -f id_dsa -P ''

I then cat id_dsa.pub into .ssh authorized_keys2 on my home machine.

Which keys are mismatched?

Many thanks,

Dave

authorized_keys2? I thought more recent versions of OpenSSH had dropped that distinction. Try authorized_keys, and see if that does something. Also, do look at

Originally Posted by choogendyk ... http://sial.org/howto/openssh/publickey-auth/ is a pretty standard reference for setting up keys. It also has some debugging notes.

Originally Posted by choogendyk authorized_keys2? I thought more recent versions of OpenSSH had dropped that distinction. Try authorized_keys, and see if that does something. Also, do look at

the sshd_config file will tell you if ssh looks for authorized_keys or authorized_keys2.


the key isnt being found......according to the verbose output

Originally Posted by robotronic I don't really understand. I generated a fresh pair in .ssh as root on my work machine: I then cat id_dsa.pub into .ssh authorized_keys2 on my home machine. Which keys are mismatched? Many thanks, Dave

my bad

looks like authorized_keys is being checked.

debug2: key: /root/.ssh/authorized_keys ((nil))
debug1: Authentications that can continue: publickey,password

so append the key there./....

@robotronic: Have you explored my suggestion yet?

@anomie Yes thanks.

I should point out that I can log in with public keys from two other machines: 1) the a laptop on my home network 2) a work machine visible to the outside world.

This implies to me that I have things set up correctly at this end. The machine I am rsyncing from is not visible externally (which is why I am pulling to it). This is the one that is not working, (Although it used to!!!!).

Now, here is what I don't get:

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/authorized_keys ((nil))
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/authorized_keys
debug2: we did not send a packet, disable method

Why is it looking at /root/ssh/authorized_keys?

Okay so the work user is root, but it is logging on as myname:

root@workdt:# ssh myname@home -p xxxxx

Shouldn't it be looking in /home/myname/.ssh/authorized_keys?????

Many thanks for all your help so far!

Dave