SFTP questions and errors

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.

Code:
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:

Code:
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
 
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?

Code:
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.
 
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):

Code:
# 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
 
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
Code:
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.
 
Yes, as had pointed out:

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

:D

EDIT: IIRC "config" can be used instead "ssh_config", you may find with that name on Windows.
 
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?
 
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:

Code:
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
Back
Top