sftp without password

[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.