Hi, On Thu, 31 May 2007 11:42:48 +0100 Mick <[EMAIL PROTECTED]> wrote:
> > > Second, my id_dsa is my private key not my public key. My public > > > key is id_dsa.pub > > > > but you will need your private key to be authenticated. that's why > > it is *private*. > > 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 > ====================================== What is wrong with that? It just says it is trying to access id_rsa, not that there is one. So it fails, of course. So not existing key isn't a matter here. It's _debugging_ output, so not necessarily important information. Using the private key is absolutely normal. A test message is encrypted using it and is then being sent to the server, hence the term "offering". I don't see what you are wondering about here. > > > 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 it _is_ a client message. It doesn't tell you where the server is searching. So yes, the server might be off track and searching in the wrong place. You could tell by monitoring the server's logs. sshd will always search in the home directory as specified in /etc/passwd (in the normal case) or more sophisticated solutions like LDAP or NSS. So make sure it really *is* configured as the home directory. If the target server is ancient, it might also be searching in ".ssh/authorized_keys2". Maybe DSA auth is disabled. Why don't you check server side logs (or let your sysadmin do that)? -hwh -- [EMAIL PROTECTED] mailing list
