sftp without password

[swaggart]

Hi all,

I'm trying to set up sftp from a Linux (Ubuntu) box to HP-UX 11.31 server.
What I have done so far:

On HPUX:
rsa-keygen -t RSA

Copied the ~/.ssh/id_rsa.pub to Linux box and renamed to ~.ssh/authorized_keys

But sftp still asks for the password. Is there something I have missed out ?

-Tommy

[Jupinder Bedi]

my dear friend , you need to give following command

ssh-keygen -t rsa

not rsa-keygen -t RSA


Good luck

[swaggart]

I am very sorry. That was a typo.

I actually typed ssh-keygen -t rsa.

[johnsonpk]

Hi Tommy,

Are you able to doe ssh with out password??

post ssh -vvv and post the messages

Johnson

[swaggart]

No login without password with ssh either.

Se attached output from ssh -vvv

-Tommy

[Jupinder Bedi]

have you check the permission of .ssh/authorized_keys

it should be

chmod 600 /.ssh/authorized_keys

[swaggart]

Yes, file permissions are correct

-rw-------

[johnsonpk]

On remote server

it seems public key authentication is disabled
check for "PubkeyAuthentication" entry in /etc/opt/ssh/sshd_config

make it as "yes" and restart ssh service

/sbin/init.d/secsh stop
/sbin/init.d/secsh start

Thanks!
Johnson

[swaggart]

That was the first thing I changed:

RSAAuthentication yes
PubkeyAuthentication yes

[Rita C Workman]

I'm no ssh guru, but here are some thoughts..

First, when you transferred the file over to your remote server ?How did you tranfer it?
>>I find it helps to do file exchange via ftp and set it to binary. Sometimes the file can become corrupted if transfer is done via ascii.

I'm sort of a vanilla kind of person, so I tend to leave the public file name as the default name. Since that is what it sftp will default to and look for. Just a thought.

Last, you don't mention populating known_host. So either populate that, or maybe for the first connection put in the password and except the remote host. Once your connected, then logout and see if you can reconnect passwordless.

Regards,
Rita

[swaggart]

Haven't done anything with known_hosts, but have tried to log in 'manually' and used the password the first time.
Logged out again, but no success.

[Steven Schweda]

> debug1: Host 'hpux_host' is known and matches the RSA host key.
> debug1: Found key in /home/XXXXX/.ssh/known_hosts:49
> debug2: bits set: 500/1024
> debug1: ssh_rsa_verify: signature correct

Stop worrying about "known_hosts".

> debug1: Trying private key: /home/XXXXX/.ssh/identity
> debug3: no such identity: /home/XXXXX/.ssh/identity

I'd probably do:

ln -s id_rsa /home/XXXXX/.ssh/identity

> debug1: Offering public key: /home/XXXXX/.ssh/id_rsa

but it seems to try the thing eventually.

> debug2: we sent a publickey packet, wait for reply
> debug1: Authentications that can continue: publickey,password,keyboard-interactive
> debug1: Trying private key: /home/XXXXX/.ssh/id_dsa

Apparently the server did not like that key.

Have you looked at the system log file(s) on
the HP-UX (server) system?


> On HPUX:
> rsa-keygen -t RSA
>
> Copied the ~/.ssh/id_rsa.pub to Linux box
> and renamed to ~.ssh/authorized_keys

> OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007

But you seem to be running ssh on the Linux
system. Don't you want the public key file
on the _server_ system, and the private key
on the _client_? Or do _I_ have everything
backward?

[swaggart]

I might have confused you here.

My goal is to sftp from my Linux box (or from another UX-server later) to the HP-UX server.

>I'd probably do:
>
> ln -s id_rsa /home/XXXXX/.ssh/identity

I have not copied the id_rsa file from the server, only id_rsa.pub.

>Have you looked at the system log file(s) on
the HP-UX (server) system?

Probably found something there:
Authentication refused: bad ownership or modes for directory ...............

[Steven Schweda]

> I might have confused you here.

It's easy to do.

> Authentication refused: bad ownership or modes for directory ...............

Looks like a problem.

> I have not copied the id_rsa file from the
> server, only id_rsa.pub.

However, my (dim) understanding of public-key
authorization is that one keeps his private
key private, that is, on the client, and he
sends his public key to the (remote) server.
With symmetric keys and clever software, it's
possible to use the keys in reverse, which
seems (to me) to be what you're doing. (Key
pairs normally being created on the client,
so that the private key stays private.)

But, as I said, _I_ could be the one who's
doing everything backward. (But I suspect
that it's you.)

[Matti_Kurkela]

As Steven already suggested...

If you wish to connect _from_ Linux _to_ HPUX, you must create the key on the Linux host and copy the public key to ~/.ssh/authorized_keys on the HPUX host.

With your current configuration, a passwordless connection is allowed _from_ the HPUX host _to_ the Linux host, not vice versa.

MK

[Steven Schweda]

> [...] you must [...]

Perhaps not. Note the messages:

> debug1: Trying private key: /home/XXXXX/.ssh/identity
> debug3: no such identity: /home/XXXXX/.ssh/identity
> debug1: Offering public key: /home/XXXXX/.ssh/id_rsa

I know nothing, but I suspect that if the
client can't find a private key, but can find
a public key, then it'll try the public key
(and hope that the corresponding private key
is at the other end).

As usual, with sufficiently clever software,
(and, here, symmetric keys) many things are
possible. Personally, I tend to configure
the stuff right-side-up, so I haven't tested
the backward-key hypothesis. (And I'm too
lazy to read enough to see if it's supposed
to work that way.)

[swaggart]

Problem solved.

Turning it the right side around, and generating the key on the Linux side was of course necessary. But after that still had to remove group permissions on the users home directory on the HP-UX side.

[Steven Schweda]

> [...] generating the key on the Linux side
> was of course necessary [...]

Not really, so long as the right files are
put into the right places.

> [...] had to remove group permissions [...]

group:write should be the trouble maker. I'd
expect group:read,execute to be harmless.