1 |
Hi, |
2 |
|
3 |
On Thu, 31 May 2007 11:42:48 +0100 Mick <michaelkintzios@×××××.com> |
4 |
wrote: |
5 |
|
6 |
> > > Second, my id_dsa is my private key not my public key. My public |
7 |
> > > key is id_dsa.pub |
8 |
> > |
9 |
> > but you will need your private key to be authenticated. that's why |
10 |
> > it is *private*. |
11 |
> |
12 |
> That's right, so why does it: |
13 |
> ====================================== |
14 |
> debug1: Trying private key: /home/michael/.ssh/id_rsa <--this doesn't exist |
15 |
> debug1: Offering public key: /home/michael/.ssh/id_dsa <--this is my private key |
16 |
> ====================================== |
17 |
|
18 |
What is wrong with that? It just says it is trying to access id_rsa, |
19 |
not that there is one. So it fails, of course. So not existing key |
20 |
isn't a matter here. It's _debugging_ output, so not necessarily |
21 |
important information. |
22 |
|
23 |
Using the private key is absolutely normal. A test message is encrypted |
24 |
using it and is then being sent to the server, hence the term "offering". |
25 |
|
26 |
I don't see what you are wondering about here. |
27 |
|
28 |
> > > PS. Not sure if this is relevant but although my user name on the |
29 |
> > > server is mick, for reasons better known to him the sysadmin has |
30 |
> > > created my home directory as /home/mic - could it be that sshd is |
31 |
> > > looking for /home/mick? |
32 |
> > |
33 |
> > that messages isn't from the server, is from client running |
34 |
> > locally. but it doesnt matter for what you want. |
35 |
> |
36 |
> It matters if the server is trying to find id_dsa.pub in a |
37 |
> non-existing directory. |
38 |
|
39 |
But it _is_ a client message. It doesn't tell you where the server is |
40 |
searching. So yes, the server might be off track and searching in the |
41 |
wrong place. You could tell by monitoring the server's logs. |
42 |
|
43 |
sshd will always search in the home directory as specified |
44 |
in /etc/passwd (in the normal case) or more sophisticated solutions |
45 |
like LDAP or NSS. So make sure it really *is* configured as the home |
46 |
directory. |
47 |
|
48 |
If the target server is ancient, it might also be searching in |
49 |
".ssh/authorized_keys2". Maybe DSA auth is disabled. Why don't you |
50 |
check server side logs (or let your sysadmin do that)? |
51 |
|
52 |
-hwh |
53 |
-- |
54 |
gentoo-user@g.o mailing list |