[SOLVED] ssh-keygen for auto ssh login not working
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I followed the information provided on this page to use ssh-keygen to generate ssh keys to allow me to login to some machines on the local network that would not require me to login (because I'm writing a script that needs to ssh into these machines and execute various commands). These machines are running different versions of Linux, including one WindowsXP machine running cygwin.
It worked great for every machine except for one embedded system that is running a minimal version of debian. I copied over the key to it exactly the same as I did for the other machines, but it still requires me to enter a password. I checked permissions and also tried to save the key to .ssh/authorized_keys2 as the webpage suggests, but nothing changed. I don't see any messages at all regarding ssh so I'm unable to really figure out what I should do, and a general web search didn't help me either. Does anyone have an idea of what might be wrong or what I could be missing?
One important distinction is on this machine, when I ssh into it I have to login as root. So I stored my ssh key in /root/.ssh/authorized_keys instead of in a user's local home .ssh folder. I'm wondering if there's something special or different I need to do for ssh'ing in as root as opposed to a normal user.
Also I checked the permissions of .ssh and authorized_keys and they are both correct as far as I know (again, according to the site I linked to in my original post).
/home/militho is on the machine I'm ssh-ing from (that user doesn't exist on the machine I'm ssh-ing to). At a quick glance I don't see it trying to reference any .ssh/authorized_keys file. But just having this information helps a lot, thanks.
But it looks like it’s not honored in the server side. Is there any note in /var/log/messages or similar file on the server side about bad permissions?
Last edited by Reuti; 02-14-2012 at 04:21 PM.
Reason: Network problem prohibits finishing of the original post
The most likely cause of this is that you are generating the keys on an ssh-2 machine but your target machine is installed with ssh-1 protocol and never the twain shall meet .....
debug1: Connection established.
debug1: identity file /home/militho/.ssh/identity type -1
debug3: Not a RSA1 key file /home/militho/.ssh/id_rsa. <-----------
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
I have the output about the failed RSA1 detection all the time I use -vvv and it doesn’t mean the server expect only RSA1, nor prohibits it to log in using RSA2 keys AFAICS, for me it works despite the debug message.
Distribution: Ubuntu, Debian, Fedora, Oracle Linux
Posts: 109
Rep:
Does that SSH server accept root login?
You can simply verify that in your sshd_config (usually located in /etc/ssh/).
Do you have the parameter "PermitRootLogin yes"?
Sorry I've been absent here the past couple of days. I got tied up with some other work.
Yes, the sshd server permits root login. If it didn't I shouldn't be able to login as root as all, right? And I can ssh as root into that machine, just not without requiring a password.
After reading everyone's feedback and going through the ssh-keygen man page, I tried a couple of things and still have the same problem.
$ ssh -vvv -oPreferredAuthentications=publickey root@192.168.1.4
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 192.168.1.4 [192.168.1.4] port 22.
debug1: Connection established.
debug1: identity file /home/militho/.ssh/identity type 0
debug3: Not a RSA1 key file /home/militho/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/militho/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /home/militho/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/militho/.ssh/id_dsa type 2
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 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: 137/256
debug2: bits set: 535/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/militho/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 10
debug1: Host '192.168.1.4' is known and matches the RSA host key.
debug1: Found key in /home/militho/.ssh/known_hosts:10
debug2: bits set: 515/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: /home/militho/.ssh/id_rsa (0x9c4adf8)
debug2: key: /home/militho/.ssh/id_dsa (0x9c4ae10)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred:
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/militho/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/militho/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password).
So reading through this it seems that it first tried the RSA2 key, which failed like it did last time. Then it tried to do the DSA key, but for some reason doesn't send the packet. and the RSA1 key I generated doesn't seem to be used at all. I'm going to go read through ssh man pages some more to try to figure this out, but in the mean time if anyone has any ideas for what could be going on, I'd appreciate it. Thanks all.
Oops, sorry I skipped over that. There is nothing in /var/log/messages; its simply a blank file. A different company setup this embedded system (it runs some version of Debian) and I have no idea how they have it configured. I didn't see anything else in /var/log that looked like it would contain any useful information.
Ok, then it’s not used. But usually the default is written in this form and so I assume that the home directory of root is /root on this machine where you put the keys?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.