Re: Problems with ssh-keygen

On Tue, Feb 04, 2003 at 08:25:24AM -0500, Steve Perron wrote:

> as some of you suggested I used ssh-keygen to automate my sftp connection

Permissions.

> I will give you the steps I did for the ssh-keygen installation.
>
> 1. ssh-keygen -t dsa (on the openssh client side)
> 2. put the .ssh/id_dsa.pub into .ssh/authorized_keys (on the openssh server
> side)

Check the permissions on $HOME and $HOME/.ssh and $HOME/.ssh/authorized_keys. Then check the permissions on every directory leading up to $HOME. I've seen cases where someone had $HOME = /foo/bar/u/username and one of the directories (e.g. /foo/bar) had group write permission.

> Someone suggested me that the server side and client side had to have the
> same username/password. Is it a reality?

No, it's not.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

> Also, is there a possible miscommunication between two server that are not
> the same, one HP and one Sun?

The operating system should not matter. I've used passwordless authentication between HP-UX, Linux and OpenBSD. The version of SSH, however, might matter, as there is an interoperability issue with the key formats used by OpenSSH and commercial SSH.

Also, if you're using OpenSSH 2.x, you've placed the public key in the wrong file (you need to use authorized_keys2 in that version).

If all else fails, get root on the server, and run

   /path/to/sshd -p 2222 -d

then connect to the server on port 2222. The server will emit debugging information which might help tell you why your authorized_keys file isn't being honored. (Client-side debugging, with "ssh -v", tends not to be useful in this kind of problem.) Received on Thu Feb 6 11:50:43 2003