Link to home
Create AccountLog in
Avatar of 2_under_par
2_under_parFlag for United States of America

asked on

can SFTP locally, but not remotely

Ubuntu 12.04

First, I did THIS.  

I can connect locally via SFTP, but not remotely.  Upon connecting remotely, I get asked to accept the key, but it disconnects with this error:

Command:      Trust new Hostkey: Once
Error:      Server unexpectedly closed network connection
Error:      Could not connect to server

It doesn't matter which user I log in as either...

Telnet to that server on port 22 shows:
SSH-2.0-OpenSSH_5.4.

Any ideas?  I'm a total NOOB at linux, so you'll have to elaborate with any suggestions.
Avatar of d1234567
d1234567

if you want to telnet over port 22, it involves some handshaking, some exchange of encryption information, etc. also it's not recommend to just use telnet to port 22.

--> install PuTty for remote conecction.
Avatar of 2_under_par

ASKER

I'm trying to connect using FileZilla via "SFTP - SSH File Transfer Protocol".  

I just showed telnet because another thread mentioned it in the troubleshooting process.
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.
Avatar of Steven Vona
Look at the logs on the remote server (the one your trying to connect to).

I do not use ubuntu, but for redhat I would check the /var/log/messages and /var/log/secure
On Ubuntu it would be /var/log/syslog and /var/log/auth.log.
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.04
Here 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 sftpuser
Change their password to something long and strong:
sudo passwd sftpupser
Give 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-sftp
Then 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-sftp
Restart the SSH server with “sudo service ssh restart” and then you should be all set to go!

Open in new window


LOG FILE:

May 13 18:31:39 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/bin/mkdir /data/

May 13 18:31:39 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 18:31:39 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 18:32:01 linux CRON[1256]: pam_unix(cron:session): session opened for user bitnami by (uid=0)

May 13 18:32:02 linux CRON[1256]: pam_unix(cron:session): session closed for user bitnami

May 13 18:36:03 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/bin/mkdir /data/wellstar/

May 13 18:36:03 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 18:36:03 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 18:37:48 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/usr/sbin/useradd --home-dir /data/wellstar --no-create-home wellstar1

May 13 18:37:48 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 18:37:48 linux useradd[1288]: new group: name=wellstar1, GID=1002

May 13 18:37:48 linux useradd[1288]: new user: name=wellstar1, UID=1002, GID=1002, home=/data/wellstar, shell=/bin/sh

May 13 18:37:48 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 18:40:25 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/usr/bin/passwd wellstar1

May 13 18:40:26 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 18:41:26 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 18:41:30 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/usr/bin/passwd wellstar1

May 13 18:41:30 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 18:41:44 linux passwd[1296]: pam_unix(passwd:chauthtok): password changed for wellstar1

May 13 18:41:44 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 18:43:43 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/bin/chown wellstar1:wellstar1 /data/wellstar/

May 13 18:43:43 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 18:43:43 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 18:45:07 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/usr/bin/apt-get install openssh-server

May 13 18:45:07 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 18:45:07 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 18:53:05 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/usr/bin/vi /etc/ssh/sshd_config

May 13 18:53:05 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 19:02:56 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 19:06:59 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/usr/sbin/service ssh restart

May 13 19:06:59 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 19:06:59 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 19:07:52 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/usr/bin/vi /etc/ssh/sshd_config

May 13 19:07:52 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 19:09:07 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 19:09:11 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/usr/sbin/service ssh restart

May 13 19:09:11 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 19:09:11 linux sshd[1343]: Server listening on 0.0.0.0 port 22.

May 13 19:09:11 linux sshd[1343]: Server listening on :: port 22.

May 13 19:09:11 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 19:10:57 linux sshd[1346]: Address 192.168.1.149 maps to r400.domain.local, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!

May 13 19:10:57 linux sshd[1346]: Accepted password for wellstar1 from 192.168.1.149 port 55794 ssh2

May 13 19:10:57 linux sshd[1346]: pam_unix(sshd:session): session opened for user wellstar1 by (uid=0)

May 13 19:10:57 linux sshd[1358]: subsystem request for sftp by user wellstar1

May 13 19:11:35 linux sudo:  bitnami : TTY=tty1 ; PWD=/home/bitnami ; USER=root ; COMMAND=/usr/bin/vi /etc/ssh/sshd_config

May 13 19:11:35 linux sudo: pam_unix(sudo:session): session opened for user root by bitnami(uid=1000)

May 13 19:12:24 linux sudo: pam_unix(sudo:session): session closed for user root

May 13 19:12:41 linux sshd[1346]: pam_unix(sshd:session): session closed for user wellstar1

May 13 19:12:42 linux sshd[1363]: 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:24:50 linux sshd[2482]: 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:24:50 linux sshd[2482]: Accepted password for bitnami from 192.168.1.149 port 64738 ssh2

May 14 21:24:50 linux sshd[2482]: pam_unix(sshd:session): session opened for user bitnami by (uid=0)

May 14 21:24:50 linux sshd[2494]: subsystem request for sftp by user bitnami
May 14 21:24:53 linux sshd[2482]: pam_unix(sshd:session): session closed for user bitnami
May 14 21:24:53 linux sshd[2468]: pam_unix(sshd:session): session closed for user bitnami

May 14 21:39:09 linux sshd[2499]: 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:09 linux sshd[2499]: Accepted password for bitnami from 192.168.1.149 port 53202 ssh2

May 14 21:39:09 linux sshd[2499]: pam_unix(sshd:session): session opened for user bitnami by (uid=0)

May 14 21:39:09 linux sshd[2511]: subsystem request for sftp by user bitnami

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)

May 14 21:39:19 linux sshd[2526]: subsystem request for sftp by user bitnami

Open in new window

This looks like you successfully logged in:

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.

setenforce 0

According to the man pages it will work in ubuntu also.
Make sure that in your sshd config file you have it configured to listen on your external IP.

ListenAddress 192.12.12.123
Listenport 22

Then restart sshd. If you get an error then check my syntax. I am posting from a tablet so its a pain for me to verify if that's right but I think it is.
savone,

I believe some of those logins were locally and some were remotely.  Also, when using the command "setenforce 0" I received the following:
"sudo: setenforce: command not found

atechnicnate,

This is what my config file shows:

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

If my default gate way is, say, 192.168.1.1, can you show me what to change the above to?
I may be way off on that.  It looks like current versions bind to all IP's by default.  Can you run this command for me and send the output:

netstat -anp | grep sshd

Also, when you just ssh to the server does it work fine?
Address 192.168.1.149 maps to r400.domain.local, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!

Open in new window


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.
sftp -o GSSAPIAuthentication=no 

Open in new window

Using Putty, I can SSH into that server & login, etc.  Remotely, I just get a blank screen.  (although I may be doing something wrong, as I've never tried that before)

"netstat -anp | grep sshd" produces the following output:

tcp     0     0     0.0.0.0:22    0.0.0.0:*    LISTEN  2043/sshd

tcp6   0     0     :::22              :::*            LISTEN  2043/sshd
So your ssh session is listening on all ip's/ports so that's good.

When you say remotely are you going to a public IP and then trying to get to the machine via ssh?  Or does the machine have multiple interfaces?
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:

Command:      Trust new Hostkey: Once
Error:      Server unexpectedly closed network connection
Error:      Could not connect to server
Here's my sshd_config file:

# Package generated configuration file

# See the sshd_config(5) manpage for details



# What ports, IPs and protocols we listen for

Port 22

# Use these options to restrict which interfaces/protocols sshd will bind to

#ListenAddress ::

#ListenAddress 0.0.0.0

Protocol 2

# HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

HostKey /etc/ssh/ssh_host_ecdsa_key

#Privilege Separation is turned on for security

UsePrivilegeSeparation yes



# Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600

ServerKeyBits 768



# Logging

SyslogFacility AUTH

LogLevel INFO



# Authentication:

LoginGraceTime 120

PermitRootLogin yes

StrictModes yes


RSAAuthentication yes

PubkeyAuthentication yes

#AuthorizedKeysFile	%h/.ssh/authorized_keys



# Don't read the user's ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

# For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no

# similar for protocol version 2

HostbasedAuthentication no

# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication

#IgnoreUserKnownHosts yes



# To enable empty passwords, change to yes (NOT RECOMMENDED)

PermitEmptyPasswords no



# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)

ChallengeResponseAuthentication no



# Change to no to disable tunnelled clear text passwords

#PasswordAuthentication yes



# Kerberos options

#KerberosAuthentication no

#KerberosGetAFSToken no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes



# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes



X11Forwarding yes

X11DisplayOffset 10

PrintMotd no

PrintLastLog yes

TCPKeepAlive yes

#UseLogin no



#MaxStartups 10:30:60

#Banner /etc/issue.net



# Allow client to pass locale environment variables

AcceptEnv LANG LC_*


Subsystem sftp internal-sftp 



# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication.  Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

UsePAM yes

Match User wellstar1
  
    ChrootDirectory /data/wellstar/
  
    AllowTCPForwarding no
  
    X11Forwarding no
  
    ForceCommand internal-sftp

Open in new window

serialband,

Are you assuming that I am connecting via Ubuntu?  I don't know what "~/.ssh/known_hosts" is.
When you tether you're connecting to your Internet/Public IP correct?

If that's the case do you have a firewall entry for port forwarding setup on your router?
atechnicnate,

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.
ASKER CERTIFIED SOLUTION
Avatar of atechnicnate
atechnicnate

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
~/.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.

Do you have a firewall turned on?
Here's a screenshot of the results from entering "tail -f /var/log/auth".  I believe the May 15 18:27:13 time stamp is my attempt to connect via sftp remotely.

User generated image
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)

Here's what sudo tail -f /var/log/auth.log looks like on my machine:

May 15 07:19:47 ubuntu sudo:     nate : TTY=pts/2 ; PWD=/home/nate ; USER=root ; COMMAND=/usr/bin/tail -f /var/log/auth.log

Try running this:

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

Then attempt to login remotely.  Watch the screen close and see if it ever has a new entry besides the LISTEN ones.  I don't think your traffic is making it to the server.
Oh second idea.  If you telnet external.ip.address 22 does it reply with the OpenSSH or just black screen?

If I telnet locally, I get...

"SSH-2.0-OpenSSH_5.9pl Debian-5ubuntu1"

Remotely, I get a blank screen that times out.
Try the watch/netstat command or I can make up a fancy tcpdump to grab the traffic.  However, I'm fairly certain that your traffic is never making it to the server.  

Do you have a firewall app installed on the server like pfsense or anything? If not then let me know the results of the watch/netstat command
watch -n 1 'netstat -anp | grep :22'

it just sits there.  Sounds like you are right, my firewall is still blocking traffic.

I will call sonicwall again and work through this.
If I telnet locally, I get...

"SSH-2.0-OpenSSH_5.9pl Debian-5ubuntu1"

Remotely, I get a blank screen that times out.
 

That suggests a firewall.  To see what iptables firewall ruleset you have, run

iptables -L

If you have iptables turned on with firewall rules, you'll need to open a port.

iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

You will also need to run the following to move this rule to the end, or all port 22 traffic is dropped before it gets to the accept rule.
iptables -D INPUT -j DROP
iptables -A INPUT -j DROP
I spoke with Sonicwall, so let's try this again.

I just did what serialband suggested.  I couldn't read everything after using "iptables-L", but I did the following anyway...

iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
iptables -D INPUT -j DROP
iptables -A INPUT -j DROP

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....

Now, when I telnet on port 22, I get: "SSH-2.0-OpenSSH_5.4".

I still can't SFTP via FileZilla or WinSCP.

Now, this is new... using Putty, if I SSH on port 22, I can log into my firewall via a command prompt.
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Success!

In the Sonicall, SSH was still checked here...

Network > Interfaces > WAN

Thanks for your patience atechnicnate!  

I'm not sure if serialband's suggestion about the iptables helped or not, so I'm not sure how to divide up the points.
Awesome! Feel free to divide them however you see fit. I don't think any of us will mind.

Congrats on getting it working!
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.

You could always delete those entries again to clear it.

iptables -D INPUT -p tcp -m tcp --dport 22 -j ACCEPT
iptables -D INPUT -j DROP


This will list any firewall rules you have.
iptables -L
serialband,

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.