passwordless sftp is not working from Unix to windows

[laiju.c.babu]

Hi Team,

One user had a requirement for doing the passwordless sftp from a Unix server to windows server.  The requirement is in Unix server the user is "psacc" and in windows server account name is "mass_ftp" .

When i logged on the .ssh directory of the user psacc i saw a file called "id_dsa.pub.f-secure". I had send this to windows team as the key.

But still the pasacc is not able to access the server. I am attaching the out put of  error which i got while using  the command below on the Unix server

sftp -vvv mass_ftp@<windows server name>

Could you please help me on this

Regards

[Matti_Kurkela]

Your error.txt indicates the psacc user has both ~/.ssh/id_rsa and ~/.ssh/id_dsa. And the remote version string indicates that the remote SSH server is F-Secure (=commercial) version, so the OpenSSH public key should have been converted to the commercial SSH format for sending to the windows team. The filename "id_dsa.pub.f-secure" suggests this is what was done, but it's better to check to make sure.

First, as the psacc user, run:

cd $HOME/.ssh
ssh-keygen -B -f id_dsa

This will output a single line of text that includes a series of nonsense "words", like:

xedad-pozen-gunys-podyz-pogom-pevyn-cysed-hetys-degon-hotid-voxax

This string can be used to identify the public key corresponding to this private key.

Because the id_dsa.pub.f-secure is probably converted to commercial format, you will need to convert it back to OpenSSH format to identify it.

Do this:

ssh-keygen -i -f id_dsa.pub.f-secure >/tmp/testkey.pub
ssh-keygen -B -f /tmp/testkey.pub
rm /tmp/testkey.pub

This will output another string of nonsense.

If the string of nonsense from this step is the same as the string from the previous step, then the public key matches the private key stored in ~/.ssh/id_dsa. In this case, the problem is probably with the Windows server: perhaps the Windows team has not placed the public key file correctly, or has set incorrect permissions for the files that determine which key(s) will be accepted for the mass_ftp user.

Checking the Windows event log for messages written by the Windows SSH server should be helpful: if a critical SSH authentication file or directory on the Windows server has incorrect permissions, the log file will tell which file/directory it is. If the log says the key authentication was rejected because there is no public key, then the Windows team has not placed the key file in the correct location, or has made a mistake writing the authorization file that lists the keys that are accepted for this user.

(With a commercial SSH server, placing the key in the correct directory is not enough: there must also be an authorization file that tells the SSH server which keys in the directory should actually be allowed. In Unix versions of the commercial SSH server, the name of the authorization file is "authorization" with no suffix; I think it is the same with Windows versions.)

You might want to remind the Windows team that file permissions problems with SSH authentication files are often the opposite from the usual: if an authentication file has too much permissions, the SSH server "thinks" the file may have been tampered with and won't trust it. The authentication files referring to the mass_ftp user should probably be writeable by the mass_ftp user only.

If the two strings of nonsense are different, then you've sent the Windows team the wrong key.

Is there a ~/.ssh/id_dsa.pub file? If there is one, test it with "ssh-keygen -B -f id_dsa.pub". If that outputs the same string of nonsense as the private key file (in the first step), then that is the matching public key.

The next step in this case is to convert the correct public key into commercial SSH format:

ssh-keygen -e -f id_dsa.pub >id_dsa.pub.f-secure.new

 ...and then send the correct key file to the Windows team.

[laiju.c.babu]

Hi MK,

Thanks a lot for your reply,

I had checked both the file id_dsa and testkey.pub. Both the values are same . Please find the output below

<Server name>*PSAC*/u09/ps/psacc/.ssh >ssh-keygen -B -f id_dsa
1024 xedef-gitib-kamyp-kabeg-guhet-syzez-zivud-huzyb-toryd-hotyb-kyxix id_dsa.pub

<Server name>*PSAC*/u09/ps/psacc/.ssh >ssh-keygen -i -f id_dsa.pub.f-secure >/tmp/testkey.pub

<Server name>*PSAC*/u09/ps/psacc/.ssh >ssh-keygen -B -f /tmp/testkey.pub
1024 xedef-gitib-kamyp-kabeg-guhet-syzez-zivud-huzyb-toryd-hotyb-kyxix /tmp/testkey.pub

Regards

[Matti_Kurkela]

OK, now you know that you've sent the correct key to the Windows team, and your "error.txt" file indicates that your sftp client is already trying to use the corresponding private key for authentication. So your side of the connection is OK.

Now you can go tell the Windows team that they've made a mistake.

Don't tease them too much though ;-)

This line from your error.txt identifies the Windows SSH server version:

debug1: Remote protocol version 2.0, remote software version 3.2.0 F-Secure SSH Windows NT Server

I know that the F-Secure SSH version 3.2.0 is rather old and may seem very strange to Windows administrators.

Tell the Windows team to check the logs on the Windows system: when a connection fails, the Windows SSH server produces very informative messages about the failure reason.

Also tell them to pay attention to the file/directory permission requirements in the F-Secure SSH documentation: giving full access to everyone (the Windows equivalent of "chmod 777") is *not* going to work.