Re: [gentoo-user] [perhaps OT] ssh from Gentoo into a RedHat server

[Mauro Faccenda]

On Thursday 31 May 2007 07:42, Mick wrote:
> On Wednesday 30 May 2007 21:42, Mauro Faccenda wrote:
> > On Wednesday 30 May 2007 16:57, Mick wrote:
> > > I find it confusing.  First of all I do not have a id_rsa.
> >
> > it tries the default keys (id_rsa or id_dsa), if exists.
>
> id_rsa does not exist in my local /home/michael/.ssh/ only id_dsa is there
> and the public key that I have saved in /home/mic/.ssh/authorized_keys on
> the server is my corresponding id_dsa.pub.
>
> > if you don't want
> > it to try it, you can use the -i parameter to ssh pointing to your
> > private key (ssh -i ~/.ssh/id_dsa <user>@<server>),
>
> Trying with the -i option also fails:
> ======================================
>  $ ssh -v -p 22 -i /home/michael/.ssh/id_dsa mick@<blah-blah>
> [snip]
> debug1: Found key in /home/michael/.ssh/known_hosts:18
> debug1: ssh_rsa_verify: signature correct
> debug1: Enabling compression at level 6.
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue:
> publickey,gssapi-with-mic,password debug1: Next authentication method:
> publickey
> debug1: Offering public key: /home/michael/.ssh/id_dsa
> debug1: Authentications that can continue:
> publickey,gssapi-with-mic,password debug1: Next authentication method:
> password
> ======================================

that's strange.

which version of openssh do you use in the server and the client?
mine:
client: OpenSSH_4.5p1
server: OpenSSH_4.4p1

here mine output doing ssh to a server with only key authentication enabled:

i don't have the id_dsa.pub in my local machine too.

=======================================
debug1: Found key in /home/faccenda/.ssh/known_hosts:8
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: id_dsa
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key 'id_dsa':
=======================================

the failed part was because my key is password protected, so it asks me.

> That's right, so why does it:
> ======================================
> debug1: Trying private key: /home/michael/.ssh/id_rsa <--this doesn't exist
> debug1: Offering public key: /home/michael/.ssh/id_dsa <--this is my
> private key
> ======================================

i didn't noticed this line... really strange.

how your id_dsa was created? is it corrupted or does it has a public key on it 
instead?

you should try creating your key pair again with:

$ ssh-keygen -t dsa

i would like to see the content of this file (or, at least the "headers"), but 
its a PRIVATE key. ;)

the "headers" of mine:

-----BEGIN DSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,933FEB2C1C691496


> > > PS. Not sure if this is relevant but although my user name on the
> > > server is mick, for reasons better known to him the sysadmin has
> > > created my home directory as /home/mic - could it be that sshd is
> > > looking for /home/mick?
> >
> > that messages isn't from the server, is from client running locally. but
> > it doesnt matter for what you want.
>
> It matters if the server is trying to find id_dsa.pub in a non-existing
> directory.

but as i said, that message isn't from the server. being a redhat, i suppose 
that it uses redhat with more less the default configuration, that tries to 
read your public key on your user home in the server (~/.ssh/authorized_users 
or ~/.ssh/authorized_users2). and openssh knows where to look at. even when 
the home of the user isn't the default which is your case, right?

hope it helps,
	.m
-- 
gentoo-user@g.o mailing list