So, I used the example on http://www.jcraft.com/jsch/examples/Sftp.java and I was trying to connect to ftp.secureftp-test.com.
That destination is a valid testing SFTP server (as mentioned in secureftp-test dot com/). I confirmed it by connecting to the server through nautilus. I also made sure that the password on my program was correct as well.
But, when I run the program and it hits session.connect(), it just says "INFO: Connection established" then it becomes quiet for a minute then it return:
"com.jcraft.jsch.JSchException: connection is closed by foreign host"
I am pretty sure that it got stuck in the while loop of the library but I do not know why. I tried it against my local ftp server and it also had the same problem.
During the quiet moment, I can type. But pressing enter does not send anything to the server.
Has anyone heard or seen the same problem?
Okay, it seems that secureftp-test.com is NOT an sftp server. That is ftps server.
What I did instead was creating my own sftp:
http://wiki.vpslink.com/Configuring_vsftpd_for_secure_connections_(TLS/SSL/SFTP)
Then run the example code but making sure that I have these lines before doing session.connect:
String knownHostsFilename = "/home/yourname/.ssh/known_hosts";
jsch.setKnownHosts(knownHostsFilename);
Related
We have a client and server communicating each other with grpc. Previously the server was running on Windows Server, and the client running on Linux or MacOS. Everything works perfectly until we migrate the server from Windows Server to a docker container.
Then we observed some weird tcp broken when we send a large amount of request from client to server.
Then we dig into the grpc arena and run our client and server with GRPC_VERBOSITY=info and GRPC_TRACE=tcp. Then we found that the disconnection was caused from the server side, with error message below:
tcp_custom.cc:218] write complete on 029FCC20: error={"created":"#1594210168.896000000","description":"TCP Write failed","file":"d:\a\grpc-node\grpc-node\packages\grpc-native-core\deps\grpc\src\core\lib\iomgr\tcp_uv.cc","file_line":72,"grpc_status":14,"os_error":"message too long"}
So my question is what does the os_error: message too long really means? What is the next step for me to investigate?
Linked issue
The string "message too long" is the error message for the error code UV_EMSGSIZE, which corresponds to the Linux error code EMSGSIZE. That appears to generally mean that gRPC is trying to write a buffer that is too large to the socket, but I'm not sure what exactly could trigger that.
I have a setup where I use Flask-MQTT to connect my python Flask API to a Mosquitto broker. Whenever I run the Flask API with the development server all is well. But whenever I spin it up for production (using wsgi+nginx), the connection with Mosquitto is made, but everytime i try to publish something i get the following error:
Socket error on client <unknown>, disconnecting.
My app.ini has the processes configured to 1 (processes = 1)
My mosquitto.config has the allow_anonymous flag set to trye (allow_anonymous true)
I can't really seem to figure out what I'm doing wrong here...
Update:
So what i think is happening is that the Flask-uwsgi application is trying to connect to mosquitto more than once. There is a master process that connects with Mosquitto on initialize. Then there is a second process that is being used whenever input is given on the Flask app. I'm not sure, but I think Mosquitto only wants one connection at the time, therefor erroring on the second. So now i either need to:
A) Configure Mosquitto in a way that it accepts multiple connection from the same device
B) Configure Flask in a way that wil only use one single process (configuring processes = 1 is not enough, it will still spawn two processes)
99% of the time, a "Socket error on client <unknown>" is an authentication error. I don't know Flask, so I don't know where to point you at, but something in your code is either trying to pass a username/password that is not defined to Mosquitto, or its trying a TLS connection with an cert that Mosquitto doesn't like.
Alright, it turns I could've read that the whole multiple processes wouldn't work from the start at the official Flask-MQTT documentation. It sais right there in think letters:
Flask-MQTT is currently not suitable for the use with multiple worker
instances.
So I looked at my uwsgi app.ini file again closely and actually the answer is quite simple. I turned out i had a like in there master = true.. after I removed that it works like a charm.
First off, there a similar question with the same issue here, but there is no answer, so I rewrote the question once again in more detail.
I am connected to an SMSC, and I noticed that there are a lot of messages are not delivered to us, we asked the SMSC to check the routing and it was fine, but SMSC noticed that there are too many connections established from your side to his side, although, we have one single connection only.
I was using NowSMS SMPP Client application to handle the connectivity, then, the SMSC asked me to change the application although I was thinking that NowSMS had no issues as I am using it 7 years ago, however, I asked NowSMS's team to investigate by opening a support ticket.
Later, I had to change NowSMS and install Kannel on a new Linux machine, after getting connected over Kannel to the SMSC, we got the same issue once again, and when I read all Kannel's logs, I found "System error (104): Connection reset by peer" which makes me, logically, to open a new connection with the SMSC. Accordingly, I suggested to have a live TCP trace from both sides at the same time, and I found the below packet in Wireshark trace file:
As you see, this is a RST/ACK from SMSC to me without requesting RST or anything from my side, and when I asked them why do you send RST/ACK or why do you RST the connection, I didn't get any useful answere, but they told me to read more about the RST/ACK and RST and I have no idea about networking, but when I read, I found that I had no control on RST connection as there was no requests from my side to the SMSC asking for the same. They always guid me to this post and what I see that it doesn't belong to me.
NOW: I just need to know what should I do or what should I ask whom about? As, I asked the Data Center's team about the same, and they confirmed that the VPN between me and the SMSC works normally without any exceptions. I believe, that there is no issue in application layer, but I cannot recognize the root of the issue.
P.S. Kannel's log file, and both TCP Trace file are here
Ask them to activate the Enquire link packet in order to drop inactive connections. It's clearly a problem from their side.
I am interacting with a SFTP server that deletes files once they are downloaded. To prevent data loss, I need to read the file, land it on persistent storage and then close the connection to indicate I have received it. What's not obvious to me is what happens if I can't safely store the file. Is there a way to close the connection in a way that semantically indicates 'I'm closing the connection and it failed'? All I am finding in the RFC is a SSH_FXP_CLOSE message, which seems to only signal successful transfer. All the other error message types appear to only be used when a server returns a response to a client, not the other way around.
You cannot signal an error to the SFTP server, that's not what SFTP is intended for.
For your particular case, simply closing an SFTP connection without closing the file explicitly (not sending the SSH_FXP_CLOSE) could indicate to the server that something went wrong.
Though it really depends on your server implementation, what it considers an error. The documentation of the SFTP server should describe what it is that triggers the delete.
In SFTP there's nothing like a "download" operation (contrary to FTP RETR command). There are only trivial file operations, like opening file (for reading or writing), reading piece of a file, closing a file. So it is not as simple as "server deletes the file after it is downloaded". The rule can say for example "server deletes the file after it is closed after being previously opened for reading" or something like that.
I have CoreFTP configured for localhost and the next code:
JSch.setLogger(new MyJschLogger()); //class for console output
Session session = jsch.getSession("user", "localhost", 21);
Properties config = new Properties();
config.put("StrictHostKeyChecking", "no");
session.setConfig(config);
session.setPassword("password");
session.connect();
when program achieves connect(), two messages appear at console output:
INFO: Connecting to localhost port 21
INFO: Connection established
...and nothing more happens. After some minutes, connection is closed by foreign host exception appears.
Why?
Thanks for all!
Port 21 is the normal port for FTP. JSch is only an SSH client, with support for SFTP in the ChannelSFTP class. JSch knows nothing about FTP (and SFTP is unrelated to FTP, other than by name and that it allows similar things).
You need to setup your server to use the SSH protocol (usually on port 22, but you can use any port, as long as you use the same port on the client). See the documentation - I think you have to check the SSH check box.
Also, if your code is nothing more than what you posted, then nothing more than connecting will happen. To transfer files, you will need to open a ChannelSFTP, and issue the right commands (e.g. call one or more of the put/get methods).
I also faced the similar issue:
"ERROR 2016-04-27 15:05:16,489 [CollectionThreadPool-0] com.dell.supportassist.collector.cli.executor.SSHExecutor: com.jcraft.jsch.JSchException: connection is closed by foreign host"
In my case, channel was getting closed randomly. And when we are trying to re-connect the channel then it was not re-connecting and failing.
This was happening due to looping logic while connecting, so I tried to connect the session without channel by calling method connectWithoutOpenChannel instead of connectinternal(). This resolved my issue.