# SFTP questions and errors



## csptra (Aug 16, 2016)

Hello,

I'm running a chrooted SFTP environment. I am trying sftp larger files to the server. The transfer clicks a long pretty good, and then looks like packet loss occurs and the connection drops. However, it seems to log the below in the log.


```
debug2: tcpwinsz: 65700 for connection: 3
```

I'm trying to find out what this means for sure, I've tried google around and found references to tcpwinsz, but being that I'm new to networking protocols and still learning about BSD/UNIX, I'm trying to find out if it just means connection dropped/terminated or if it is a problem with the chroot sftp implementation. 

Here is the code right before it:


```
Aug 16 17:45:48 hostname sshd[42449]: debug3: mm_request_receive entering
Aug 16 17:45:48 hostname sshd[42449]: debug3: monitor_read: checking request 113
Aug 16 17:45:48 hostname sshd[42449]: debug3: mm_answer_audit_command entering
Aug 16 17:45:48 hostname sshd[42449]: debug3: mm_request_receive entering
Aug 16 17:45:48 hostname sshd[42449]: debug1: do_cleanup
Aug 16 17:45:48 hostname sshd[42449]: debug1: PAM: cleanup
Aug 16 17:45:48 hostname sshd[42449]: debug1: PAM: closing session
Aug 16 17:45:48 hostname sshd[42449]: debug1: PAM: deleting credentials
Aug 16 17:45:48 hostname sshd[42449]: debug3: PAM: sshpam_thread_cleanup entering
Aug 16 17:45:55 hostname sshd[42308]: debug2: tcpwinsz: 65700 for connection: 3
```

Being that I'm new, I don't know what else to provide. 

Thanks for any help


----------



## rigoletto@ (Aug 17, 2016)

Hum. I do not know if it also affect SFTP or just the "normal" SSH, but had you set keep alive on server and client?


```
ClientAliveInterval=300 # on [MAN=1] sshd_config[/MAN]
ServerAliveInterval=60 # on [MAN=1]ssh_config[/MAN]
```

The time 300 and 60 are what I use, adjust as you like.


----------



## rigoletto@ (Aug 17, 2016)

May also be helpfull for SSH as a whole:

How to Set Up an SFTP User on FreeBSD
Secure Secure Shell

I am including my sshd_config as reference (comments are not mine):


```
# Server basics
ListenAddress 127.0.0.1
ListenAddress 192.168.0.254
Port 22

# Only enable version 2
Protocol 2

# Don't enable DSA and ECDSA server authentication
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# If you have a recent OpenSSH client, disable weak ciphers and Message Authentication Code
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

# Disable root login. Users have to su to root
PermitRootLogin no

# Turn on Public key authentication
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

# Disable .rhost and normal password authentication
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no

# Only allow users in the wheel group to login
AllowGroups wheel

# In those groups only allow the following users
# The @<domainname> is optional but replaces the
# older AllowHosts directive
AllowUsers $USER                        ### Your user here

# Logging
SyslogFacility AUTH
LogLevel INFO

# Keep alive
ClientAliveInterval=300

# Enable internal SFTP Server
Subsystem sftp internal-sftp
        Match Group sftponly
        AllowGroups sftponly
        AllowUsers $USER                        ### Your user here
        ChrootDirectory /home/%u
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp
```


----------



## csptra (Aug 17, 2016)

Thanks lebarondemerde,

I didn't use ClientAliveInterval, but I set it and restarted sshd(8).  I tried to add the ServerAliveInterval, however, it got invalid configuration option when using that directive.

`sshd -v` shows

```
sshd: illegal option -- v
OpenSSH_6.6.1p1, OpenSSL 1.0.1p-freebsd 9 Jul 2015
```
however, from my research, I need to use ServerAliveInterval on the client. (But I use a windows based client - so I need to research that)

Also, I read that I need to put ServerAliveInterval in sshd_config, but it's throwing the error. So I get to more research as this forum:
http://stackoverflow.com/questions/37265279/bad-configuration-option-serveraliveinterval  mentions it's not a valid option according to the man page of sshd_config(5) (I checked, not in there) but ssh_config(5) mentions it. So I need to understand these better, more research.

Thanks for your help, I will try setting ClientAliveInterval and ClientAliveCountMax for now

Edit: 

 I think I had my own question answered, ServerAliveInterval goes on the client side in the ssh_config  not sshd_config.


----------



## rigoletto@ (Aug 17, 2016)

Yes, as had pointed out:


```
ClientAliveInterval=300 # on [MAN=1]sshd_config[/MAN]
ServerAliveInterval=60 # on [MAN=1]ssh_config[/MAN]
```



EDIT: IIRC "config" can be used instead "ssh_config", you may find with that name on Windows.


----------



## csptra (Aug 17, 2016)

oops, I apologize, I overlooked the difference on the comment. However, it doesn't seem to make a difference.    I'm wondering if tcpwinsz is with windowing size?


----------



## rigoletto@ (Aug 17, 2016)

I do not know exactly what is going on. Some one with more knowledge of SSH than me may be more helpful but if  you are trying to forward X, have you set `ForwardX11=yes` on ssh_config(1) file, and have X installed on the server?

Although, forward X is considered insecure. Better use sftp(1) in text mode, yet less complicated.

Also to simplify your life you can create *Hosts* com on the client config file like this:


```
Host *
        Port 22
        UseRoaming no
        ServerAliveInterval 60
        PubkeyAuthentication yes
        PasswordAuthentication no
        ChallengeResponseAuthentication no
        KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
        HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa
        Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

Host Server
        HostName 192.168.0.254
        User $USER          # your user here
        IdentityFile ~/.ssh/id_rsa.pub
```

Then you just need to type `ssh Server` to connect to Server Host with all specific commands you want.

EDIT: if you are willing to transfer files inside your network sporadically, may be more simple to use scp(1) instead of SFTP.


----------



## rigoletto@ (Aug 18, 2016)

csptra how much memory do you have? As you said you trying to transfer large files low memory may be a issue, and provoke ssh to lost the connection.

EDIT: you may also want to take a look on it.
EDIT.2: you can use top(1) to watch what is going on with the memory during the transfer.
EDIT.3: you can also use tcpdump(1) to watch the connection too.
EDIT.4: another option.


----------



## SirDice (Aug 18, 2016)

lebarondemerde said:


> I do not know exactly what is going on. Some one with more knowledge of SSH than me may be more helpful but if you are trying to forward X, have you set  ForwardX11=yes on ssh_config(1) file, and have X installed on the server?


I'm sorry, how did we get from SFTP problems to X forwarding? Did you perhaps mistakenly believe TCP window size has something to do with X?

https://en.wikipedia.org/wiki/TCP_window_scale_option


----------



## rigoletto@ (Aug 18, 2016)

SirDice Yes, my fault. I think I misread the TCP part...


----------



## csptra (Aug 24, 2016)

Hello Everyone,

I aplogize for the delay, I think I started off with 8GB on a virtual machine. I say started because I think it got reduced, however, the problems we were having was with 8GB.


----------



## SirDice (Aug 24, 2016)

The amount of memory is not relevant to the issue. Even with very little memory and huge swap usage it'll still work, horribly slow but it'll work.

I'm actually thinking the "sliding" window size is a symptom, not a cause. TCP/IP simply tries to do its best when the connection is a bit dodgy.


----------



## csptra (Aug 24, 2016)

Thanks,
So If I understand correctly (I may not) .. then the tcpwinsz in OP debug statement has to do with tcp window scaling due to a dodgy internet connection?  Would there be any way to capture additional debug statements via tcpdump/wireshark on either client or the server side. 

For one client, I do think I have the problem found, but we have 5 clients that try to sftp. So we are either overloading the server? or they all have bad internet connections.


----------



## SirDice (Aug 25, 2016)

csptra said:


> So If I understand correctly (I may not) .. then the tcpwinsz in OP debug statement has to do with tcp window scaling due to a dodgy internet connection?


Yes, that's what I'm thinking. I'd have to look up the specifics when this happens, it's not something you deal with on a daily basis. If you ever want to know _every_ little detail about TCP/IP I can highly recommend getting your hands on "TCP/IP Illustrated, Volume 1" by Richard Stevens. It's a great book and an invaluable source of information. 



> Would there be any way to capture additional debug statements via tcpdump/wireshark on either client or the server side.


Not anything specific but looking at the captures would surely provide a lot more information. Definitely look for things like re-transmissions, double ACKs, that sort of thing.


----------



## csptra (Aug 29, 2016)

Thanks everyone,

 I will continue to look into this.


----------

