LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This 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

Reply
 
Search this Thread
Old 09-01-2005, 01:28 PM   #1
guideweb
Member
 
Registered: Mar 2004
Location: /planet/earth
Posts: 110

Rep: Reputation: 15
CVS & SSH & Public/private keys


Hello,

I am trying to get my public/ private keys auth working but it only work for user root(local and remote)


Trying to connect to remote user 'admin' from local user 'admin'
$ ssh domain.com
Code:
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to domain.com 11.22.33.44 port 22.
debug1: Connection established.
debug1: identity file /home/admin/.ssh/identity type -1
debug1: identity file /home/admin/.ssh/id_rsa type -1
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
debug1: identity file /home/admin/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1
debug1: match: OpenSSH_3.5p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.9p1
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,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,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
debug2: kex_parse_kexinit: none,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-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se
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
debug2: kex_parse_kexinit: none,zlib
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: 123/256
debug2: bits set: 475/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host "domain.com" is known and matches the RSA host key.
debug1: Found key in /home/admin/.ssh/known_hosts:2
debug2: bits set: 507/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/admin/.ssh/identity ((nil))
debug2: key: /home/admin/.ssh/id_rsa ((nil))
debug2: key: /home/admin/.ssh/id_dsa (0x987af30)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/admin/.ssh/identity
debug1: Trying private key: /home/admin/.ssh/id_rsa
debug1: Offering public key: /home/admin/.ssh/id_dsa
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
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
admin@domain.com's password:

I haved read many howto but i cant get it to work.

My local system is FC3
$ ssh -V
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003

and my remote is RH8
$ ssh -V
OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

EDIT On 05-09-08 i have upgraded openssh on my remote to version
[root@remote root]$ ssh -V
OpenSSH_4.2p1, OpenSSL 0.9.7a Feb 19 2003
END EDIT

Thanks for any input,

Last edited by guideweb; 09-08-2005 at 05:08 PM.
 
Old 09-02-2005, 11:23 PM   #2
guideweb
Member
 
Registered: Mar 2004
Location: /planet/earth
Posts: 110

Original Poster
Rep: Reputation: 15
Or does anyone know how to connect to a remote cvs server (ext) without password ?


Thanks
 
Old 09-03-2005, 07:59 AM   #3
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,785
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
For the SSH bit, the best how-to I've read is here .

From your post, it looks like at least one of the keys in the authorized_keys files has extra text that is goofing things up:

Quote:
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug2: key_type_from_name: unknown key type '-----END'
For the authorized_keys file you need to make sure that the ENTIRE key is on a single line and there there isn't a bunch of extra text. On my box the file looks something like this:

ssh-dss FIRSTKEY
ssh-dss SECONDKEY


As for the CVS server, there are likely to be instructions on the site as to how to log in anonymously.
 
Old 09-03-2005, 11:26 AM   #4
guideweb
Member
 
Registered: Mar 2004
Location: /planet/earth
Posts: 110

Original Poster
Rep: Reputation: 15
Hello,


I have done this howto many times but without any results.
(local user) admin (remote user) admin
Code:
 debug1: Next authentication method: publickey
debug1: Trying private key: /home/admin/.ssh/identity
debug3: no such identity: /home/admin/.ssh/identity
debug1: Trying private key: /home/admin/.ssh/id_rsa
debug3: no such identity: /home/admin/.ssh/id_rsa
debug1: Offering public key: /home/admin/.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

And when i do the same howto with 'root' user evrything work fine

Code:
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: Offering public key: /root/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-dss blen 433
debug2: input_userauth_pk_ok: fp cd:1b:ae:03:ad:07:aa:a4:ae:b0:24:5d:2c:12:11:63
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
This look like a configuration problem. Do you know where in config files the pub/private login could be restricted to 'root'

EDIT :
For info, here is the file ownship for admin and root users.

::::LOCAL :::
/home/admin/
drwxr-xr-x 2 admin admin 4096 Sep 3 12:14 .ssh
/home/admin/.ssh/
-rw------- 1 admin admin 668 Sep 3 12:13 id_dsa
-rw-r--r-- 1 admin admin 618 Sep 3 12:13 id_dsa.pub
-rw-r--r-- 1 admin admin 464 Sep 3 12:21 known_hosts

/root/
drwxr-xr-x 2 root root 4096 Jul 21 21:19 .ssh
/root/.ssh/
rw------- 1 root root 668 Jul 21 00:33 id_dsa
-rw-r--r-- 1 root root 617 Jul 21 00:33 id_dsa.pub
-rw-r--r-- 1 root root 470 Jul 21 00:33 known_hosts

::: REMOTE :::
/home/admin/
drwx------ 2 admin admin 4096 Sep 3 12:15 .ssh
/home/admin/.ssh
-rwx------ 1 admin admin 618 Sep 3 12:14 authorized_keys
-rw-r--r-- 1 admin admin 242 Sep 3 12:15 known_hosts

/root
drwx------ 2 root root 4096 Sep 1 13:46 .ssh
/root/.ssh/
-rwx------ 1 root root 618 Jul 21 21:18 authorized_keys
-rw-r--r-- 1 root root 242 Jul 21 00:31 known_hosts

Note that root's autorized_keys file have one byte more that id_dsa.pub.
END EDIT



Thanks in advance,

Last edited by guideweb; 09-03-2005 at 11:37 AM.
 
Old 09-03-2005, 12:55 PM   #5
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,785
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Well, the config file should be in /etc/ssh and is called sshd_config. You should look and see if there is an AllowUsers directive (which may prevent admin from logging on). You also should have a look at the system logs. SSH usually leaves a lot in /var/logs/messages and it may give us a clue. By any chance can admin log in with a username and password instead of a key? If you can, that suggests a key problem, not an ssh config problem. Of course there is also regenerating a key pair for admin an see if something strange happened when the public key was installed on the remote system.
 
Old 09-07-2005, 08:06 AM   #6
guideweb
Member
 
Registered: Mar 2004
Location: /planet/earth
Posts: 110

Original Poster
Rep: Reputation: 15
Hello,

Yes admin can login with password,


/var/log/messages
Sep 7 08:51:23 domain sshd(pam_unix)[19248]: session opened for user root by (uid=0)
Sep 7 08:52:00 domain sshd(pam_unix)[19309]: session opened for user admin by (uid=502)
Note : root login using key pair and admin login with password

I look in the /etc/ssh/sshd_config and i dont have an AllowUsers directive.


I generated many times the keys for admin and i never get anything that go wrong.



Thanks
 
Old 09-07-2005, 05:18 PM   #7
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,785
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Yes admin can login with password,
OK, that and the lack of AllowUsers rules out the brutally obvious problems. I guess I'm back to thinking that there may be a problem with the format of the /home/admin/.ssh/authorized_keys file. As I said before, the key has to be on a single line. It might be worth a double check on this.
 
Old 09-07-2005, 09:31 PM   #8
guideweb
Member
 
Registered: Mar 2004
Location: /planet/earth
Posts: 110

Original Poster
Rep: Reputation: 15
Quote:
s I said before, the key has to be on a single line. It might be worth a double check on this. [/B]
I did that so many times with all kind of method (cp, ftp , manual copy/paste) the only think i didint try is to copy the key manualy

Is it possible that Openssh v3_5 and 3_9 are incompatibles ?

Just in case ....
[root@remote root]# cat /etc/passwd | grep admin
admin:x:502:502::/home/admin:/bin/bash


/// EDIT
Could you try to use public/private keys on my server if i create a test account ? With this we could know if the problem come from my server or local.
/// END EDIT


Thanks

Last edited by guideweb; 09-07-2005 at 09:33 PM.
 
Old 09-08-2005, 07:33 AM   #9
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,785
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Quote:
Is it possible that Openssh v3_5 and 3_9 are incompatibles ?
Sorry, I should have caught this earlier.....I suppose its possible that you have some version incompatibility, but more to the point, you really should upgrade the 3.5 box. There were a lot of serious security bugs in OpenSSH not too long ago and I would defintely upgrade all my systems before doing anything else. I can tell you from my own logs that every single day somebody tries to crack my ssh server and I wouldn't want to be using anything other than the latest version. There are known ssh exploits out there and you need to upgrade.

Last edited by Hangdog42; 09-08-2005 at 07:36 AM.
 
Old 09-08-2005, 05:02 PM   #10
guideweb
Member
 
Registered: Mar 2004
Location: /planet/earth
Posts: 110

Original Poster
Rep: Reputation: 15
Ok,
I have upgraded my remote but it still dosent work

[root@remote root]$ ssh -V
OpenSSH_4.2p1, OpenSSL 0.9.7a Feb 19 2003
 
Old 09-09-2005, 07:15 AM   #11
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,785
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Well, at least you now have a more secure system!

I'm about out of ideas, but I do have one more. The /home/admin/.ssh directory should have 755 permissions. The files in the directory can be 644, but I think the directory itself should be 755.
 
Old 09-09-2005, 09:15 AM   #12
guideweb
Member
 
Registered: Mar 2004
Location: /planet/earth
Posts: 110

Original Poster
Rep: Reputation: 15
Hi,
I have read somwhere(lost source) that the private key must be 600 because if perms are something else the server could maybe reject the key.

Can you send me your public key by email or the forum so i could see if my problem come from my server or local ?


Thanks
 
Old 09-09-2005, 09:48 AM   #13
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,785
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Well on my system the ~/.ssh directory is 755 and the files in that directory are 644. If you really are using 600, that may very well be the problem since that restricts reading to the user only and the ssh daemon isn't going to be able to read the files. I'm using OpenSSH 3.9, so the idea that the permissions must be 600 isn't correct.

Click on the email link below to contact me and I'll send you a public key I know works.

Last edited by Hangdog42; 09-09-2005 at 09:50 AM.
 
Old 09-09-2005, 11:39 AM   #14
guideweb
Member
 
Registered: Mar 2004
Location: /planet/earth
Posts: 110

Original Poster
Rep: Reputation: 15
I have found the problem !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

This look like it not documented anywhere but when i change my admin home directory permisions(on remote) (/home/admin) from 770 to 700 the keys start to work !!

It dosent work with 770 and 760 but it work with 750 and any other permision that only owner can write

Thanks for your help Hangdog,
 
Old 09-09-2005, 12:20 PM   #15
Hangdog42
LQ Veteran
 
Registered: Feb 2003
Location: Maryland
Distribution: Slackware
Posts: 7,785
Blog Entries: 1

Rep: Reputation: 414Reputation: 414Reputation: 414Reputation: 414Reputation: 414
Well, congratulations on figuring that one out. I've never heard of that sort of a restriction on the home directory, but I suppose it is possible. On my server the home directories are 755 (which must be the default because I don't think I've ever messed with them) so that does fit into what you've found.

Now that you've got it working, I would take some additional security steps and not allow root access via SSH. If you get into your /etc/ssh/sshd_config file there is a directive you can change to turn off root access. I'd also turn off username and password access, particularly with a login name as obvious as admin. Restricting access to those with keys is a good thing since the dictionary attacks that will happen to your ssh server do cover a LOT of common usernames. And you can descend further into paranoia by using the AllowUsers directive, which restricts access to only those users listed on the AllowUsers line. But in the case of SSH, paranoia is a good thing because they are out to get you.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ssh public/private keys lord_darkhelmet Linux - Newbie 8 10-29-2005 03:14 PM
SSH public / private keys problem guideweb Linux - Software 7 08-27-2005 09:49 PM
How to delete public & private keys for SSH? TrulyTessa Linux - Security 2 11-18-2004 12:27 PM
CVS - SSH Keys & Cervisia vi0lat0r Linux - General 2 05-30-2004 09:46 PM
Help with SSH and public/private keys stodge Linux - Security 5 05-14-2003 01:22 PM


All times are GMT -5. The time now is 09:57 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration