Secured ftp from Unix to VMS cluster

[Chand Basha]

I am trying to setup the secured ftp from Unix to VMS cluster machine. As a part of this I am running the below command to copy the public key file from Unix to VMS cluster. But it is not copying the file and everytime it is asking for the password.

scp file.pub "sftpuser@xxx.xxx.com"
Enter sftpuser password:
Permission denied, please try again.

Even though I am entering correct password it is not allowing me to copy this on VMS cluster.

Same thing I am able to do on development machine where I have single machine (without cluster).

I don't know what is the problem here.

Could you please anybody help me to find out the problem.

I am able to login to VMS cluster sftpuser account using telnet.

Thanks,
Chand

[Steven Schweda]

Does "ssh" to the VMS host work? (Is this a
general authentication problem, or, perhaps,
a file permission problem?)

Does "scp -v" tell you anything?

Does adding a destination file name
("sftpuser@xxx.xxx.com:file.pub", or even
"sftpuser@xxx.xxx.com:") help?

Does "sftpuser" have permission to write this
(or any) file at the destination?

[Chand Basha]

The correct command is
scp file.pub "sftpuser@xxx.xxx.com:ssh2/"

Sftpuser on VMS is having privilege to create the file.

[Chand Basha]

scp -v command gives the following output
Executing: program /usr/bin/ssh host tyson1.tyson.com, user sftpuser, command s/
OpenSSH_3.8.1p1, OpenSSL 0.9.6m 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so): 0509-022 Cannot.
0509-026 System error: A file or directory in the path name does not ex.

debug1: Error loading Kerberos, disabling Kerberos auth.
debug1: Connecting to tyson1.tyson.com [10.16.2.23] port 22.
debug1: Connection established.
debug1: identity file /home/sftpuser/.ssh/identity type 0
debug1: identity file /home/sftpuser/.ssh/id_rsa type -1
debug1: identity file /home/sftpuser/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version 3.2.0 F-SECURE SSt
debug1: no match: 3.2.0 F-SECURE SSH - Process Software MultiNet
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
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: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The DSA host key for tyson1.tyson.com has changed,
and the key for the according IP address 10.16.2.23
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/sftpuser/.ssh/known_hosts:5
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the DSA host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
8e:f6:52:56:08:56:2d:4c:60:9d:9f:af:94:1b:83:e4.
Please contact your system administrator.
Add correct host key in /home/sftpuser/.ssh/known_hosts to get rid of this mess.
Offending key in /home/sftpuser/.ssh/known_hosts:2
DSA host key for tyson1.tyson.com has changed and you have requested strict che.
Host key verification failed.
lost connection

[Chand Basha]

I tried to give the hostname which IP address is constant. But it is not allowing to copy the file and asking the password again and again.

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: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/sftpuser/.ssh/id_rsa
debug1: Offering public key: /home/sftpuser/.ssh/id_dsa
debug1: Authentications that can continue: password
debug1: Next authentication method: password
sftpuser@abcde1.xxx.com's password:
debug1: Authentications that can continue: password
Permission denied, please try again.
sftpuser@abcde1.xxx.com's password:
debug1: Authentications that can continue: password
Permission denied, please try again.
sftpuser@abcde1.xxx.com's password:

[Steven Schweda]

"Process Software MultiNet" is useful
information, anyway. I have HP's TCPIP, so
I can't say much about the MultiNet details.

All those complaints about bad and changed
keys ("scp -v") make it look as if this is
a general "s" authentication problem.

I'll try again. Does "ssh" to the VMS host
work?

I think that it was serious about this part:

Please contact your system administrator.
Add correct host key in /home/sftpuser/.ssh/known_hosts to get rid of this mess.

[Richard Whalen]

I think that the "answer" to the problem is contained in the text below:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@
The DSA host key for tyson1.tyson.com has changed,
and the key for the according IP address 10.16.2.23
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/sftpuser/.ssh/known_hosts:5
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the DSA host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
8e:f6:52:56:08:56:2d:4c:60:9d:9f:af:94:1b:83:e4.
Please contact your system administrator.
Add correct host key in /home/sftpuser/.ssh/known_hosts to get rid of this mess.
Offending key in /home/sftpuser/.ssh/known_hosts:2
DSA host key for tyson1.tyson.com has changed and you have requested strict che.
Host key verification failed.


Basically this is saying that the host key for the remote system is different than it was the last time, and the configuration on the client system is such that it will not allow a connection when it is different.

[Chand Basha]

I know that the hostname which I was using is getting changed and assigning to one of the VMS cluster machine. So I was getting the DNS snoofing message.

Later I tried to copy the file using the one of the VMS machine hostname but got the same prompt enter password again and again.

For ssh hostname also getting same prompt(Enter password) again and again. Though I am entering the correct password it is not allowing me to login

[Steven Schweda]

Ok, if "ssh" fails just like "scp", then
it's a general "s" authorization problem.

The MultiNet software is trying to tell you
how to fix it:

The DSA host key for tyson1.tyson.com has changed, [...]

Add correct host key in /home/sftpuser/.ssh/known_hosts to get rid of this mess.
Offending key in /home/sftpuser/.ssh/known_hosts:2

I don't know enough to tell you what's wrong
there, but it might be simplest to delete
any lines in files (or whole files) related
to the host(s) with the problems.

It's possible that the "ssh" software will
then copy the new, correct host data over
automatically, the next time you try to
log in ("ssh"). In this case, having no
data is better than having wrong data. You
need to remove the wrong data (and get some
right data).

[Richard Whalen]

It's also possible that the server system has marked the username as an intruder.

Can you try a different username (after fixing the problem with the keys).