Configured sftp still requires password

Hi Gurus:)

I have to connect from a SunOS 5.10 to a 5.8 using sftp in BatchMode. For this, I have generated a Public-Key (ssh-keygen -b 1024 -P "" -t dsa) on the 5.10 and saved it in ~remote-user/.ssh/authorized-keys on the 5.8.

Then, running either one of ssh or sftp, it asks for the remote-user's password:confused:

For your added information, as you might already know, the above procedure works fine when going from 5.10 to 5.10.

Can you please tell me what am I missing here?
With my greatest appreciations,
unilover

just a thought, that setup is for openSSH, does 5.8 use ssh2, if so then the key will have to be converted (ssh-keygen can do that). If it does use openSSH are the permissions correct on the keyfile and .ssh directory (600 for files 700 for directories).

Make also sure that that the key you've just copyed into authorized_keys is just in one line (notice the low underscore).
Check that public key authentication is allowed on the remote server. Have a look at your sshd_config file for that.
Regards.

Thanks a lot both.

Here is the few lines from Remote-Server's /usr/local/etc/ssh/sshd_config:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++
# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /usr/local/etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /usr/local/etc/ssh_host_rsa_key
#HostKey /usr/local/etc/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /usr/local/etc/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

++++++++++++++++++++++++++++++++++++++++++++++++++

Also, running "sftp -v rmt_srvr" produces the following lines:
++++++++++++++++++++++++++++++++++++++++++++++++++

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Peer sent proposed langtags, ctos:
debug1: Peer sent proposed langtags, stoc:
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 123/256
debug1: bits set: 997/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sbdevsvr59' is known and matches the RSA host key.
debug1: Found key in /home/testuser/.ssh/known_hosts:14
debug1: bits set: 1005/2048
debug1: ssh_rsa_verify: signature correct
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/testuser/.ssh/id_rsa
debug1: Trying public key: /home/testuser/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
testuser@rmt_srvr's password:
++++++++++++++++++++++++++++++++++++++++++++++++

Moreover, both permissions are as you've specified.

Thanks again.

Two key questions here:

1) Is the remote user account accessible and in sync with the password you're trying to use? We often see these due to passwords having expired, etc. (Authentication's intact but only so long as the account is viable;

2) Are you certain that it's not prompting you for a Passphrase instead of a password? If your public key file was not generated with an empty passphrase session authentication will be forced to prompt you for an input on this..negates your automation somewhat.

Lastly, if your client is using SSH2 (Tectia, for example) and your host server is using SSH (OpenSSH, for example), then you'd need to convert the key formats to fit.

Thanks a lot curleb.

Yes. The remote-user's account is valid and in sync (which I'd used it to transfer the generated id_dsa.pub on the local-host and save it in .ssh/authorized_keys).

No. It is definitely asking for the password. First because I used 'ssh-keygen -b 1024 -P "" -t dsa' to generate the Public-Key and second, when I enter the remote-user's password, I'm successfully logged-in.

As for the ssh version, I ran a �pkginfo | grep -i openssh� command and it does tell me that openssh is installed.

There's something that looks a little weird to me:

debug1: Trying private key: /home/testuser/.ssh/id_rsa
debug1: Trying public key: /home/testuser/.ssh/id_dsa

Why don't you try to "ssh-keygen" an RSA key pair?
Look, this is the output on one of my servers:

debug1: Trying private key: /home/grial/.ssh/identity
debug1: Offering public key: /home/grial/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

Regards.

Thanks grial. It is odd indeed. I had tried rsa before dsa and here is the outcome of the re-try:

debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying public key: /home/testuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying public key: /home/testuser/.ssh/id_dsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
testuser@rmt_srvr's password:

Still asking for the password!!

very strange. Try cleaning up the keys file on the remote end.

  1. move the .ssh/authorized_keys file out of the way (rename it to something).
  2. scp the public backover
  3. on the remote end rename the public key you just scp'd over to be .ssh/authorized_keys
  4. logout and try again

On my system (OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007 on Archlinux testing to OpenSSH.4.3.p2_Debian-9 on Debian Etch) I get the following:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/chris/.ssh/identity
debug1: Trying private key: /home/chris/.ssh/id_rsa
debug1: Offering public key: /home/chris/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 435
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).

I assume the different messages are just because of different versions, possibly.

PS don't forget to check the ownership and permissions on the files in ~/.ssh/

I like to keep mine very restrictive at 0700 for the directory and 0600 for the files, the maximum that OpenSSH seems to allow is 0644 for the files.

Thanks wempy.

I had done all these "tricks" before posting my request here.
I believe it is somewhere deep in either OpenSSH and/or Solaris 8!!

Let's step back a second and revisit the key pair that you'd generated. From your post:

Passphrase has apparently gained the misnomer of equal to the password, unfortunately. It's not, and it's intended to serve as a means to ensure public sharing of the key-pair without granting full account access to the remote host. Also, you don't need (or want) to specify your passphrase (ie, -P "") on the command-line, as it can be used against you, should anyone gain access to your key-pair and/or .sh_history file.

Instead of using -P (which is really intended to allow for revision of the passphrase in a given key-pair), let the ssh-keygen program prompt you for your passphrase. Leave all other switches as they are, but scratch the

-P ""

options. The program will prompt you for the empty passphrase..to which you'll just enter twice. It doesn't matter what key type you're creating either..same goes for rsa and dsa.

Lastly, just be sure that you're placing the Public Key into the remote user's .ssh directory as well. You don't have to have identical users between the machines..or even have separate machines for that matter (ie, unilover@localhost can access unilever@localhost, much the same as unilover@localhost can access unilever@remotehost or unilover@remotehost). So long as the key placement is done right..you can automate the login with an empty passphrase.

HTH

Thanks curleb.

I regenerated the Public-Key on the localhost per your instructions and copied the contents to the .ssh/authorized_keys on the remotehost.

Mind you, NOTHING CHANGED!!

Had I to copy over the "id_dsa & id_dsa.pub" pair of files too?!?!

No, only the .pub file goes to the remote location..you cat it into the ~/.ssh/authorized_keys file and scratch the original .pub file.

One thing I'd caution you on..and many of the SAs I deal with can't quite grasp: are you sudo or sesu or similar while trying to do any of this? This throws off the EID of the process and SSH won't let on, for obvious reasons.

OK!

Do you mean I should remove the id_dsa.pub file (which I had copied over to .ssh/authorized_keys on the remotehost) in .ssh directory on localhost?!?!

I have also the pair of "id_dsa & id_dsa.pub" files in .ssh on remotehost which, of course, belong to the remoteuser. Should I remove them?!?

Finally, I am quite aware of the EUID problem when using ssh and "no" I am logged-in directly on the localhost and thanks for pointing that out.

The local key pair can be left as is..deleting them causes a problem (ie, the remote host's authorized_keys file has nothing to work with... :smiley: ). The local copy of the id_dsa.pub file is meaningless to the local (or client) side of the authentication, while the remote copy of the id_dsa.pub is part of the authorized_keys file. This serves to authenticate against the local key file (ie, id_dsa).

You can/should get rid of the .pub file on the remote side, once you've cat-ted it into the remote account's ~/.ssh/authorized_keys file. Leaving it around is fine, but best practice's would suggest that you scratch it..just to be safe(r).

Thanks a lot for the detailed explanation.

So, having done all that and complied to all rules and regulations, why on earth it is still asking for the password?

:confused:
What about ssh_config on the client side?

What about it?

Please keep in mind that exactly the same setting works fine when I connect to a Solaris-10 box. That's why I really think that the problem is either with Solaris-8 (the remote-server) or the OpenSSh's compatibility on 10 & 8!?!?

Well... The only thing that comes to my mind then, is that it could be caused by something related to cyphers and/or crypt libs, key length......... But I'm just guessing, I really have no idea... :slight_smile: