I connect my client laptop to a server via VPN and be able to send a file from the client to the server using the "scp" command.
Now, I want to send a file from the server back to the client using the "scp" command, but I got a permission denied message. I believe I have to setup a publickey of the sender on the receiver first before doing this, but whose publickey? Is it the VPN server's publickey or the server's publickey?
I have got an answer. I can simply run the "scp" command on the remote client to copy file from the server. I was trying to make thing complicate by trying to run scp command on the server, which is unnecessary and stupid.
Related
I want to transfer a few files weekly from mainframe to a Linux server running RedHat using a batch (JCL) job using FTPS.
Linux server is configured with vsftpd. Is it possible to send file from mainframe to linux using FTPS?
Getting this error while transferring the file from mainframe to Linux.
EZA1736I FTP
EZY2640I Using 'SYS1.TCPPARMS(FTPDATA)' for local site configuration parameters.
EZA1450I xxx FTP CS xxx
EZA1456I Connect to ?
EZA1736I host_name
EZA1554I Connecting to: host_name xxx.xxx.xxx.xxx port: 21.
220 (vsFTPd 2.0.5)
EZA1701I >>> AUTH TLS
234 Proceed with negotiation.
EZA2897I Authentication negotiation failed
EZA1534I *** Control connection with host_name dies.
EZA1457I You must first issue the 'OPEN' command
EZA1460I Command:
EZA1618I Unknown command: 'Atul'
EZA1619I For a list of the available commands, say HELP
EZA1460I Command:
EZA1736I Summer#123
EZA1618I Unknown command: 'Monsoon#123'
EZA1460I Command:
EZA1736I cd /home/Atul/
EZA1457I You must first issue the 'OPEN' command
From your log you seem to be able to set up an unsecured connection to the FTP server. That's good.
EZA2897I Authentication negotiation failed indicates that the TLS-handshake did not complete successfully. Either the partners could not find a common TLS-version and/or ciphersuite or (that's the point I'd examine first) the certificate provided by the FTPs-server isn't trusted by the client user. To be sure you would have to capture and examine a TCP- or TLS-trace.
In a first step I would check the certificate provided by the FTP server and compare it to the trusted certificates in your security manager. In the case of RACF you would have to examine SITE-certificates and/or certificates in the user's keyring.
Yes, sending from the mainframe using FTPS to VSFTP is certainly possible. Both the client (z/OS in this case) and server (Linux in this case) need to agree on the encryption method to be used and I believe by default, z/OS has to trust the certificate for the server, which may involve importing the certificate bundle to a key ring that the batch job has access to. The job not having access to a keyring that trusts the chain for the server certificate would be my first guess.
I don't have experience with setting up the RACF keyring things, but I can say that people do successfully send us data every day from z/OS to our Linux server via FTPS.
I'm having 2 apps that communicate via unix domain socket on linux.
After running the apps, I see a file corresponding to the socket path name was created in file system.
Then I tried with a scenario as below:
Start server app, server is listening now
Delete the file that created by above server from terminal
Start the client app.
The result was: server still listens forever, and client failed to connect to server.
My question: Is there any way to protect the socket file from being removed while it is in used (e.g: hide it completely from other processes, or lock it until the owner release the lock)?
I am implementing an FTP server. Suppose a client sends PORT command first. Then it sends SYST command. To which port should I send the response?
The client port from which SYST command is received
The client port specified in PORT command?
Please advise.
PORT command (as well as PASV, EPRT and EPSV), affect data connections only. SYST command, as well as majority of FTP commands, make no use of the data connection. A data connection is used by RETR, STOR, LIST and similar commands only.
So PORT (and the others) have no effect on SYST. You process SYST the same way, as if no PORT command was used: You send the response to the same connection, from which you have received the SYST command.
We have a windows program. This program performs a soap request to a server in our DMZ
(it is a direct HTTP request to - let's say 192.168.100.10).
Now - for security reasons, we have to change the setting. The request should go via a secure
channel to the server.
The future workflow has to be the following:
Before we start the SOAP request, we have to call "putty.exe" with special parameters in order to dynamically create a secure tunnel.
putty.exe -L 5510:192.168.100.10:8080 -l user1 -i c:\private_key.ppk 192.168.100.10
After this we perform the soap request to "localhost:5510". The dynamically created secure tunnel will foward the packets of the request through the ssh channel to the web server of 192.168.100.10. The response will come the same way back.
After a list of maybe 500 requests have been performed, the secure tunnel should be closed and the program should be ended.
Apart from getting the process id of the putty process and killing the process, is there any other way to close the putty secure ssh tunnel?
Thanks alot in advance
[Server A] ----- [FTP server] ---- [Server B]
Server A and B can both see the FTP server but not each other. Is there a way to create a tunnel between them through the ftp server, only using the FTP protocol?
FTP will only transfer data to disk or from disk, so the only way to tunnel anything is to store the data on one side and retrieve them on the other side.
You need to install a FTP Proxy on the FTP server, maybe your server already supports proxy connections. This allows Server A to connect to FTP Server and use it as a proxy to connect to Server B and vice versa.
Once Server A has connected to the FTP Server, the FTP Protocol allows to send the command USER <user>#ServerB which will result in FTP Server connecting to Server B and function as a proxy from now on.
I have some experience with FileZilla and it worked fine for me testing a FTP Proxy Product as it offers a lot of the supported mechanisms how to tell a FTP Proxy to connect to the destination server. It also displays all FTP Commands which will be send over the wire, which really helped a lot in troubleshooting.