It looks like the machine that you are connecting to is denying the connection. Are you in control of the remote machine? Are you specifying what user to connect as in filezilla (if not then add that)?

Try this from you Ubuntu box:

ssh user@ip.address.ofremote.sftp

(example: ssh root@192.168.1.1)

If you can connect to it then at least that section (ssh) is working.

Or, from the command line you could do sftp user@remoteserver.ip.addre.ss and see if that will connect. (example: sftp root@192.168.1.1 )

Oh, on a side note. Telnet is often used in troubleshooting to see if the port is even open. So when you did that and got a response then people know that the remote server is responding on port 22. Next you need to see if it's accepting your user.

Here's something fun:

telnet google.com 80

then type:

GET /

and hit enter twice. You'll get a wall of text that is the web page. Basically you're connecting to the server on port 80 and then sending it a GET / request so it replies to you.

Below I posted the instructions I had to setup this sftp server, followed by the log named "auth".

Instructions:

Setting up chroot SFTP server on ubuntu 12.04Here is how to set up a secured SFTP server where the user is not permitted shell access, nor access to any other part of the filesystem than what you allow with the chroot. I did this in September 2012 on Ubuntu 12.04.First, I want to create a place for all the files to live:sudo mkdir /data/OpenSSH requires that the sftp user cannot have write access to the root directory, so you have to create at least one sub directory that can be owned by the sftp user:sudo mkdir /data/incoming/Second, we want to add a new user solely for this server:sudo useradd --home-dir /data/incoming --no-create-home sftpuserChange their password to something long and strong:sudo passwd sftpupserGive them control over the incoming directory so they can deposit files there:sudo chown sftpuser:sftpuser /data/incoming/Third, we need to enable SFTP in the SSHD configuration. Edit the file /etc/ssh/sshd_config and change the sftp line to this:Subsystem sftp internal-sftpThen add this chunk to the end of the file (make sure to put it after the “UsePAM” line!) :Match User sftpuser ChrootDirectory /data AllowTCPForwarding no X11Forwarding no ForceCommand internal-sftpRestart the SSH server with “sudo service ssh restart” and then you should be all set to go!

May 14 21:39:19 linux sshd[2514]: Address 192.168.1.149 maps to r400.domain.local, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
May 14 21:39:19 linux sshd[2514]: Accepted password for bitnami from 192.168.1.149 port 53203 ssh2
May 14 21:39:19 linux sshd[2514]: pam_unix(sshd:session): session opened for user bitnami by (uid=0)

Do you have SELINUX installed?

It looks like as far as PAM is concerned your are authenticating correctly. There must be something else stopping the connect, or disconnecting.

In redhat the first thing I would try it to temporarily disable selinux with the following comand, then attempt to connect again.

The error above suggest that you may have an ssh-key mismatch or you don't have the proper DNS mapping. Try running your external sftp with the -o option. If that works, then you might try commenting out the key in your ~/.ssh/known_hosts to see if you can load a new key when you connect externally.

When trying to connect remotely, I disconnect from the lan, shut off my wireless via a hardware switch on the front of my laptop, and then tether via my smartphone.

I've also been trying to connect from home during lunch or after hours with the same results. SFTP via FileZilla always asks me to accept the key, but the server immediately disconnects and FileZilla shows this:

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

I'm definitely off the network when tethering. Ipconfig/all shows a new IP Address.

As far as the firewall, I worked with sonicwall support to setup the port forwarding. Not sure, but they said that because the key handshake was initiated remotely, the port forwarding was setup correctly.

Then try to connect to ssh and tell me if you get anything in the logs.

If not then on the server try this:

watch -n 1 'netstat -anp | grep :22'

That lets us see if the client is even making it to the server to authenticate. If you get additional connections (usually it will say ESTABLISHED, anything besides LISTEN is a good sign) then we know you are making it through your firewall to the server. If not then I think it's a forwarding issue and we can head down that path.

~/.ssh/known_hosts refers to a file named known_hosts in your home directory (~) under the hidden folder named .ssh. If you are using openssh on the command line, you will have that file. That's where it stores the host keys of the systems you connect to.

If you're connecting remotely with the user wellstar1, then you can only sftp to it.

did you run that and then attempt to login remotely? If so then I don't see your connection attempt in there. The entry you refer to just means that you used sudo to run the tail command (which you didn't have to)

I don't mind not getting points. I just answer to help. I get enough from other questions I answer to be able to view the "solutions" that I wish to see.

I didn't see your post about having the sonicwall when I replied. This site doesn't update new messages while I type.

I got a bad command on the -D command above. But, was able to run it after the -A one. I might have messed up the order there....

Your comment suggests that you didn't have a deny directive that matched the default Input deny. The -D means to delete the entry -A means add. Did you check the output of iptables -L to see if you had any rules that were set before you added the entries. I suspect that you may not have.

Very good to know about the firewall rules. I will definitely use that in the future. What I didn't know was how to page up & down (using SHIFT + Page Up or CTRL + Page Up), so I didn't know how to check it correctly. There weren't any rules that needed changed, however.

SSH (Secure Shell) - Tips and Tricks
As you all know SSH(Secure Shell) is a network protocol, which we use to access/transfer files securely between two networked devices. SSH was actually designed as a replacement for insecure protocols that sen…

We all know how boring and exhausting it is to transfer huge web projects developed locally to a webserver simply via FTP.
The File Transfer Protocol is a really nice solution if you need to transfer small amounts of files, but if you're plannin…

Learn how to find files with the shell using the find and locate commands.
Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:

Learn how to navigate the file tree with the shell.
Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…