sftp can't log in.

[Johns Manville]

This is HP-UX 11.11.

I have a remote office that wants to use sftp to place a file on this server at my office.

I created a restricted ftp user that was restricted to their home directory. I was hoping that restricted ftp user on my side would jail the outside user when they log in.

However, when I test, sftp asks for the password of the user I put on the command line, but that password will not log them in. Plain old ftp works as it's intended.

I ran sftp with -v and it looks like sftp is comparing keys and recognized my root key instead of the sftp user's password.

I'm guessing I either went about this all wrong, or I need to change to allow password authentication in the sshd_config file? Or will they need to send me their pub key?

I'm using this version of OpenSSH:

OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL

Thanks for any help.

[Steven Schweda]

> I created a restricted ftp user [...]

I don't know what that means (to you).

Except for the similar spelling, SFTP and FTP
are very different, and the configuration of
one has very little to do with the
configuration of the other.

> I ran sftp [...] it looks like [...]

That tells me approximately nothing. As
usual, showing actual commands with their
actual output can be more helpful than vague
descriptions or interpretations. What is
the SFTP client? Running on what? As which
user?

> I'm guessing [...]

With almost no useful information to work
with, that's about all I can do, too.

> OpenSSH_3.6.1p2, [...]

It may not matter, but that's not the latest
kit, is it?

> Thanks for any help.

You first. What, exactly, are you doing?
What, exactly, happens when you do it?

[Uday_S_Ankolekar]

You need to configure ssh for the user.
Have you created key file by running ssh-keygen -t dsa? to generate private key ?

[Johns Manville]

Yes I created an ssh key with ssh-keygen -t rsa for the new user that will access the account. I added that to the authorized_user file on the target server.

Here is the output with a -v added for verbose output:

$ sftp -v username@hpux41
Connecting to hpux41...
OpenSSH_4.3p2-hpn, OpenSSL 0.9.7i 14 Oct 2005
HP-UX Secure Shell-A.04.30.007, HP-UX Secure Shell version
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to hpux41 [166.92.13.147] port 22.
debug1: Connection established.
debug1: identity file /home/username/.ssh/id_rsa type 1
debug1: identity file /home/username/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2-hpn
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hpux41' is known and matches the RSA host key.
debug1: Found key in /home/username/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/username/.ssh/id_rsa
debug1: Authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive
debug1: Trying private key: /home/username/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive
debug1: Next authentication method: password
username@hpux41's password:
debug1: Authentications that can continue: external-keyx,gssapi,publickey,password,keyboard-interactive
Permission denied, please try again.
username@hpux41's password:

[Steven Schweda]

> Yes I created [...]

Still not exactly rich in details on the
preparation.

> $ sftp -v username@hpux41
> [...]

It's a start.

> debug1: Trying private key: /home/username/.ssh/id_dsa
> debug1: Next authentication method: keyboard-interactive

The server appears to hate your key data. As
a Forum search for SSH/SFTP problems would
probably reveal, this could be caused by many
things. Among the most popular might be bad
key data, or bad file or directory ownership
or permissions. With only my weak psychic
powers to work with, it's hard to offer
specific suggestions. In such a situation,
the server knows all, but tells the client
little. Inspecting the server system log
file(s) should provide the reason for the
log-in failure (or at least some suggestive
clues).

[Steven1970]

You wrote:
Yes I created an ssh key with ssh-keygen -t rsa for the new user that will access the account. I added that to the authorized_user file on the target server.

Did you add the key into a file named authorized_user or authorized_keys

If it was authorized_user then that is wrong, it should be authorized_keys

[Steven Schweda]

> Did you add the key into a file named
> authorized_user or authorized_keys [?]

Again, copy+paste of an actual "ls -l"
command with its actual output would be more
useful than a vague and/or inaccurate
description. Just a thought.

[Uday_S_Ankolekar]

It should be authorized_keys as mentioned in above post. Also look for the permission and ownership of .ssh dir

[Johns Manville]

# ls -l
total 6
-rw------- 1 username ftponly 397 Jun 3 06:38 authorized_keys
-rw------- 1 username ftponly 887 Jun 3 06:31 id_rsa
-rw-r--r-- 1 username ftponly 225 Jun 3 06:31 id_rsa.pub

[Patrick Wallek]

Are there any errors in the /var/adm/syslog/syslog.log file on the server your are trying to sftp to?

[Johns Manville]

No, none.

[Mel Burslan]

where did you create the keys ? ON your server side or on the client side ?

you said it looks like it is recognizing your root key's instead of sftp user's keys. Are you sure you are initiating the connection after logging in to (or su'ing into) this sftp user with a "-", as in 'su - sftpuser', if you do, what you are telling about root's keys, doesn't make an iota of sense.

Last but not the least, if you created the key par, are you absolutely sure that you sent the private portion of the key to the client side and they placed it in the proper directory with the proper permissions. What you gave answers to, above, seems like the directory listings from the server and your problem is most probably residing on the client (i.e. remote) site.

Do you have access to this remote office server ? If so, can you check the ownership and permissions of .ssh directory and the files underneath it ?

[Steven Schweda]

> # ls -l
> [...]

Great. Now, if I could guess where you were
when you did that, then I might know
something useful.

There are two computers involved here, the
SFTP client and the SFTP server. (Or, for
testing purposes, perhaps one computer in two
roles, but exactly what you're doing where is
unclear.) The non-psychics in your audience
don't know where you're doing these things,
or as which user, or much else, unless you
reveal the relevant facts.

> I'm using this version of OpenSSH:
>
> OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL

> $ sftp -v username@hpux41
> Connecting to hpux41...
> OpenSSH_4.3p2-hpn, OpenSSL 0.9.7i 14 Oct 2005

And some of the things you say seem, well,
inconsistent?


> No, none.

Really? I know nothing, but I've never seen
an ssh/sftp login failure which left no
evidence in the system log file on the
server. Worst case, it is possible to run
the server daemon with a debug/verbose
option, which might tell you more.

> [...] will they need to send me their pub
> key? [...]

> [...] sent the private portion of the key
> to the client [...]

Many things are possible, but normally, the
key pair is generated at the client end, and
the public key is sent to the server end
(keeping the client's private key data
private).

[Johns Manville]

OK. A useful person informed me that sftp does not have the capability to chroot or jail the user until OpenSSH version 5. That pretty much answers this question.

I apologize for not being more clear in my questions. Unfortunately, I swamped and have to help, so I wasn't as careful or detailed as I could have been. I usually do better.

I want to thank those of you who tried to be helpful without being demeaning. I will score him with a 0.

[Johns Manville]

Chroot or jail capability is not available for sftp until OpenSSH version 5.

[Steven Schweda]

> OK. A useful person informed me that sftp
> does not have the capability to chroot or
> jail the user until OpenSSH version 5.

And we knew that you were trying to do this
because you told us where?

> Unfortunately, I swamped [...]

Not too busy to waste other people's time,
though.

> [...] demeaning.

If asking for a clear exposition of a problem
is demeaning, then count me in every time.

> I will score him with a 0.

The pain, the pain...