0

I am running Microsoft Windows Server 2019 Datacenter Version 10.0.17763 Build 17763 on Azure and I had SFTP working just fine until EITHER a recent update and reboot on Windows OR an SFTP username (the "vendor1" user) password change on ActiveDirectory clobbered this working install of OpenSSH.

Now when attempting to SFTP from a client machine, all I get is,

Connection reset by xxx.xxx.xxx.xxx port 22

Connection closed

What could be wrong? Has anyone else experienced this and solved it?

Here's my sshd_config file, which was working:

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey __PROGRAMDATA__/ssh/ssh_host_rsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_dsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ecdsa_key
#HostKey __PROGRAMDATA__/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile  .ssh/authorized_keys

#AuthorizedPrincipalsFile none

# For this to work you will also need host keys in %programData%/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
Banner F:\SFTP-Welcome.txt
#Banner /SFTP-Welcome.txt

# override default of no subsystems
Subsystem   sftp    sftp-server.exe

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server

#Match Group administrators
#       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

#DenyGroups company\vendors company\auditors
#AllowGroups company\administrators

Match Group vendors
   ChrootDirectory F:\Vendors
   #ChrootDirectory F:\Vendors\%u
   #ChrootDirectory %h
   ForceCommand internal-sftp
   X11Forwarding no
   AllowTcpForwarding no

# no default banner path
#Banner F:\Vendors\SFTP-Welcome.txt
#Banner /SFTP-Welcome.txt

Using the -v (verbose) option in my SFTP command (sftp -v [email protected]) yields:

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\mylocalusername/.ssh/id_rsa
debug1: Trying private key: C:\\Users\\mylocalusername/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\mylocalusername/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\mylocalusername/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\mylocalusername/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
[email protected]'s password:
debug1: Authentication succeeded (password).
Authenticated to its.my.ip.addrr ([its.my.ip.addrr]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
Connection reset by its.my.ip.addrr port 22
Connection closed

That user "mylocalusername" is my local client PC Windows login name.

12
  • How about looking in the server logs? Is your firewall filtering / blocking the port 22 requests?
    – Lenniey
    May 2, 2019 at 8:46
  • In PowerShell, I ran: Get-NetFirewallRule -Name ssh Here are the results: Name : OpenSSH-Server-In-TCP DisplayName : OpenSSH SSH Server (sshd) Description : Inbound rule for OpenSSH SSH Server (sshd) DisplayGroup : OpenSSH Server Group : OpenSSH Server Enabled : True Profile : Any Platform : {} Direction : Inbound Action : Allow EdgeTraversalPolicy : Block LooseSourceMapping : False LocalOnlyMapping : False May 2, 2019 at 8:50
  • Basically, the firewall seems fine. Uncommenting the log lines in the sshd_config file fields nothing in the C:\ProgramData\ssh\logs folder. Checking the Event Viewer now.... May 2, 2019 at 8:52
  • In the Event Viewer's Application and Services Log, inside OpenSSH | Operational, I see sshd: Accepted password for vendor1 from its.my.ip.addr port 11678 ssh2....not sure why the port is different but it looks like it's recognizing me. May 2, 2019 at 9:01
  • It's the source port of the connection, it won't be 22. Are outbound connections from sshd allowed in your firewall? You only listed inbound. Check the clients verbose message as well, e. g.: ssh -v user@host
    – Lenniey
    May 2, 2019 at 9:07

0

You must log in to answer this question.

Browse other questions tagged .