Remote access to SFTP server...

I'm working with an OS X Server (5.0.4) and I want to set up a SFTP server that users can access remotely.


I've turned on the FTP service, and that is working wonderfully inside of the office. I've got them set up on a dDNS, and that's working wonderfully and resolving well. Other than port forwarding, what's next?


Also... I have a feeling I'm not understanding something. I think I'm setting up an FTP service. How do I make certain it is the more secure SFTP? Again, this is for remote access, not local.


Thank you in advanced for any help.

Posted on Jan 3, 2018 11:29 AM

Reply
16 replies

Jan 8, 2018 10:14 AM in response to phospholipid77

Whatever client is in use has not had the usual ssh directories set up. No keys were established, so that failure isn’t a surprise. Since it’s a server, make sure the target user is permitted ssh access; explicitly added or in an existing and permitted group for ssh access. See the Service Access Control List support (SACL).


https://help.apple.com/serverapp/mac/5.4/#/apd21a2ffdaa


There’s more to keepijg a server secure and locked down. Assuming the Duplicati package encrypts the data using AES and decent passwords, then that backup data can be stored anywhere, safely. I’d not generally prefer to open up remote access into this server. That makes for a much more complex environment to manage, and ine that risks all of the local data, not just an (encrypted) backup.

Jan 5, 2018 2:32 PM in response to phospholipid77

Please go ask the Duplicati folks?


I am unfamiliar with Microsoft Windows, and with Duplicati, which is the bulk of this question. The other hunk here involves the details of the particular network firewall box in use here; those vary widely.


As for macOS and for enabling and allowing remote sftp access, get that working locally, then open up TCP port 22 at the firewall and set up port forwarding from the firewall to the server, test remotely, and have at.


Make certain all your passwords on all of your accounts are secure.


Set up DDNS at your network firewall (and that associated with your account with your preferred DDNS provider), or get static IP and DNS, and use that for remote references into your systems.


Hope that your ISP doesn’t block TCP port 22, too. Some do.


Opening TCP port 22 also allows remote ssh access by default; command-line access to the target system. See the previous response for details.


How Duplicati is configured for sftp, I don’t know.


You’re really not centrally asking a macOS Server question here. This is mostly an IP networking question, and particularly with configuring and managing Duplicati on Windows, and setting up rules on your network firewall. Get that configured and working to an arbitrary sftp server, and then get macOS configured as that arbitrary server.

Jan 4, 2018 5:48 PM in response to MrHoffman

This is all really valuable insight.


I'm wondering if I tell you what the situation is, if you might have some advice.


Currently, in our office, there are five people on Windows who use Duplicati to backup to an OSX server locally via FTP. Two of those people are leaving town for several months. They want to be able to run backups remotely while they're gone. Yes, Dropbox, and yes, Google Drive... that's not what they want. They want to be able to run the same backups they do now, to the OSX server in their office, except while they are out of town. Ideally this would be automatically without them having to fuss a whole lot.


I thought if I just set up a dDNS with like duckdns.org or something, and forwarded the ports, I could make the local FTP accessible to them remotely, change their target address in Duplicati, and all would be well.


Is there a better option within these parameters?

Jan 5, 2018 11:02 AM in response to MrHoffman

So, it's pretty clear to me that I won't be using FTP.


Duplicati is really open. I can use just about any protocol I want. I'm not going to use Backblaze because they want everything in house. That means I have to use the OSX server as my terget. That's just the parameters I am to work with. So...


Assuming I can make Duplicati target the OSX server any way I want, what is the best way to do that? I'm guessing setting up a VPN server is the best route. Or sftp? Is that what you would say? If so, I can start working on that today, I think.

Jan 7, 2018 6:08 PM in response to MrHoffman

That's excellent. All of this help is exceptional.


Here were the steps I followed.


I enabled "remote login" in System Preferences to turn on ssh.

I forwarded port 22 to the computer's IP address.

I created a duckdns domain name for that computer.


When I'm on a remote client, like FileZilla or CyberDuck, I am able to get to the computer but there are some login issues.


With FileZilla, I get this notice:

Error: Server sent an additional login prompt. You need to use the interactive login type.
Error: Critical error: Could not connect to server


With CyberDuck, I get this notice:

"Broken transport; encountered EOF."


On FileZilla, when I use the "interactive login type" it asks me for the password with a dialogue box. Then it asks me again right away. The first time, it says it wants the "SSH server authentication" and the second time it says it wants the "SSH password".


I know the password and server are correct, and I get clear indications that the DNS is working. There must be something else I'm missing, likely on the server side. Some setting or flag or something I need to enable...


¯\_😕_/¯

Jan 8, 2018 2:49 PM in response to MrHoffman

So, would I follow a site like this one to make keys? I'm guessing I make the key client-side and then put a copy on the server, right? If I make a key in an OSX client and then put it in the OSX server, can I simply copy that same key into the Windows machine?


I want to make this work just so that I learn and know that I have accomplished something. In the meanwhile, I'm looking for another remote upload because I have to make this work by Wednesday. 😟

Jan 8, 2018 3:07 PM in response to phospholipid77

I think I'm missing something *very* basic here.


I just tried to SSH into the server locally by using a local IP address. This is what happens:


colecovision:~ jaime$ ssh USER@10.0.1.77

Password: [I enter USER's password at this point and get this prompt:]


USER@10.0.1.77's password: [I enter USER's password at this point and get this response]


Authentication failed.

colecovision:~ jaime$


I tried to enter the password for user "jaime" in that first prompt. It gives me three tries, then gives me the second password prompt, then kicks me.


Does the test USER somehow have two separate passwords? Is there a second password I don't know about?

Jan 7, 2018 8:36 PM in response to phospholipid77

Ah, the GUI. Forget the GUI. Use the ssh client directly. From a remote macOS or BSD or Linux system, launch Terminal.app or analogous, and then ssh -vvv user@example.com, where user is the target username and example.com is the target host name or (better) the external IP address of the server.


Review the ssh -vvv diagnostic output for any sensitive details, and then post it here or to one of the other text-hosting sites.


Older packages may not connect to macOS server (or to other current systems) due to upgrades in security requirements in recent releases.


if you must use Windows for testing, make sure it’s Windows 10 with the most recent updates loaded and with the ssh client installed. (Shouldn't be running anything prior to 10 at this point anyway.). The ssh support is an optional part of the most recent Windows betas. Much like Windows, I’m also not familiar with PuTTY, but that too can connect via ssh.


Hosting the backups remotely reduces the risk to your server, and will likely be esiser to configure and maintain, too.

Jan 7, 2018 8:54 PM in response to MrHoffman

So, when I run ssh -vvv, this is what I get back (it ends with "authentication failed"):


Last login: Sat Jan 6 20:54:43 on ttys000

colecovision:~ desktopuser$ ssh -vvv SSHUSER@SFTPSERVER.COM

OpenSSH_7.4p1, LibreSSL 2.5.0

debug1: Reading configuration data /etc/ssh/ssh_config

debug2: resolving "SFTPSERVER.COM" port 22

debug2: ssh_connect_direct: needpriv 0

debug1: Connecting to SFTPSERVER.COM [xxx.xxx.xxx.x] port 22.

debug1: Connection established.

debug1: key_load_public: No such file or directory

debug1: identity file /Users/desktopuser/.ssh/id_rsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/desktopuser/.ssh/id_rsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/desktopuser/.ssh/id_dsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/desktopuser/.ssh/id_dsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/desktopuser/.ssh/id_ecdsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/desktopuser/.ssh/id_ecdsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/desktopuser/.ssh/id_ed25519 type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/desktopuser/.ssh/id_ed25519-cert type -1

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_7.4

debug1: Remote protocol version 2.0, remote software version OpenSSH_7.3

debug1: match: OpenSSH_7.3 pat OpenSSH* compat 0x04000000

debug2: fd 5 setting O_NONBLOCK

debug1: Authenticating to SFTPSERVER.COM:22 as 'SSHUSER'

debug3: hostkeys_foreach: reading file "/Users/desktopuser/.ssh/known_hosts"

debug3: record_hostkey: found key type ECDSA in file /Users/desktopuser/.ssh/known_hosts:2

debug3: load_hostkeys: loaded 1 keys from SFTPSERVER.COM

debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521

debug3: send packet: type 20

debug1: SSH2_MSG_KEXINIT sent

debug3: receive packet: type 20

debug1: SSH2_MSG_KEXINIT received

debug2: local client KEXINIT proposal

debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-e xchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffi e-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group 14-sha1,ext-info-c

debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc

debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc

debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

debug2: compression ctos: none,zlib@openssh.com,zlib

debug2: compression stoc: none,zlib@openssh.com,zlib

debug2: languages ctos:

debug2: languages stoc:

debug2: first_kex_follows 0

debug2: reserved 0

debug2: peer server KEXINIT proposal

debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-e xchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffi e-hellman-group14-sha256,diffie-hellman-group14-sha1

debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519

debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

debug2: compression ctos: none,zlib@openssh.com

debug2: compression stoc: none,zlib@openssh.com

debug2: languages ctos:

debug2: languages stoc:

debug2: first_kex_follows 0

debug2: reserved 0

debug1: kex: algorithm: curve25519-sha256@libssh.org

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

debug3: send packet: type 30

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug3: receive packet: type 31

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:X+eh4qEqVWblQac4M/1nafBmRObFXSDw+1uPG56M1jY

debug3: hostkeys_foreach: reading file "/Users/desktopuser/.ssh/known_hosts"

debug3: record_hostkey: found key type ECDSA in file /Users/desktopuser/.ssh/known_hosts:2

debug3: load_hostkeys: loaded 1 keys from SFTPSERVER.COM

debug3: hostkeys_foreach: reading file "/Users/desktopuser/.ssh/known_hosts"

debug1: Host 'SFTPSERVER.COM' is known and matches the ECDSA host key.

debug1: Found key in /Users/desktopuser/.ssh/known_hosts:2

Warning: Permanently added the ECDSA host key for IP address 'xxx.xxx.xxx.xxx' to the list of known hosts.

debug3: send packet: type 21

debug2: set_newkeys: mode 1

debug1: rekey after 134217728 blocks

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug3: receive packet: type 21

debug1: SSH2_MSG_NEWKEYS received

debug2: set_newkeys: mode 0

debug1: rekey after 134217728 blocks

debug2: key: /Users/desktopuser/.ssh/id_rsa (0x0)

debug2: key: /Users/desktopuser/.ssh/id_dsa (0x0)

debug2: key: /Users/desktopuser/.ssh/id_ecdsa (0x0)

debug2: key: /Users/desktopuser/.ssh/id_ed25519 (0x0)

debug3: send packet: type 5

debug3: receive packet: type 7

debug1: SSH2_MSG_EXT_INFO received

debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>

debug3: receive packet: type 6

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug3: send packet: type 50

debug3: receive packet: type 51

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive

debug3: start over, passed a different list publickey,gssapi-with-mic,password,keyboard-interactive

debug3: preferred publickey,keyboard-interactive,password

debug3: authmethod_lookup publickey

debug3: remaining preferred: keyboard-interactive,password

debug3: authmethod_is_enabled publickey

debug1: Next authentication method: publickey

debug1: Trying private key: /Users/desktopuser/.ssh/id_rsa

debug3: no such identity: /Users/desktopuser/.ssh/id_rsa: No such file or directory

debug1: Trying private key: /Users/desktopuser/.ssh/id_dsa

debug3: no such identity: /Users/desktopuser/.ssh/id_dsa: No such file or directory

debug1: Trying private key: /Users/desktopuser/.ssh/id_ecdsa

debug3: no such identity: /Users/desktopuser/.ssh/id_ecdsa: No such file or directory

debug1: Trying private key: /Users/desktopuser/.ssh/id_ed25519

debug3: no such identity: /Users/desktopuser/.ssh/id_ed25519: No such file or directory

debug2: we did not send a packet, disable method

debug3: authmethod_lookup keyboard-interactive

debug3: remaining preferred: password

debug3: authmethod_is_enabled keyboard-interactive

debug1: Next authentication method: keyboard-interactive

debug2: userauth_kbdint

debug3: send packet: type 50

debug2: we sent a keyboard-interactive packet, wait for reply

debug3: receive packet: type 60

debug2: input_userauth_info_req

debug2: input_userauth_info_req: num_prompts 1

Password:


[at which point I enter the USER password and get…]


debug3: send packet: type 61

debug3: receive packet: type 51

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive

debug2: userauth_kbdint

debug3: send packet: type 50

debug2: we sent a keyboard-interactive packet, wait for reply

debug3: receive packet: type 51

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive

debug2: userauth_kbdint

debug3: send packet: type 50

debug2: we sent a keyboard-interactive packet, wait for reply

debug3: receive packet: type 51

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive

debug2: we did not send a packet, disable method

debug3: authmethod_lookup password

debug3: remaining preferred:

debug3: authmethod_is_enabled password

debug1: Next authentication method: password

USER@SFTPSERVER.COM's password:


[at which point I enter the USER password and get…]


debug3: send packet: type 50

debug2: we sent a password packet, wait for reply

Authentication failed.

colecovision:~ desktopuser$

Jan 4, 2018 5:33 PM in response to phospholipid77

Please post up your login credentials here; your username and password and your server host name. Because that's part of the problem with FTP. It exposes your login credentials. FTP is a huge pile of grief around firewalls; it's basically incompatible with dumb client- and server-side firewalls. Decent-grade network firewalls now actually sniff for and look inside the FTP network traffic and take steps to allow the fundamentally-broken FTP protocol to connect through the firewalls, too. FTP is totally and completely insecure. FTP is also removed from and now an add-on on recent macOS releases, due in no small part to its complete and utter and total and absolute completely raging massive insecurity.


If you're getting the impression I'm not very fond of FTP...


If you really need FTP, encapsulate it. Either find and configure an FTPS client and server, or use FTP via a VPN.


For sftp, open up and forward TCP port 22 through the firewall and into the target server, and disable interactive logins for the remote sftp users if you're inclined to deny that access. sftp shares three letters and a basic purpose with FTP, but is otherwise completely different. It's secured, can use your own certificates or other features in place of or in addition to passwords, and it's vastly easier to deal with around firewalls. And it doesn't expose your username and password and file contents to anyone with a privileged network position...


I'd either establish a VPN or would push the files to a hosting site elsewhere, rather than opening up remote access.


My preference here is a VPN server embedded in a mid-grade firewall; residential firewalls tend to lack that, but the low- and mid-grade business- and server-focused firewalls are inexpensive and offer a variety of features useful for servers. I'm using ZyXEL ZYWALL USG series, but there are other good products available that contain embedded VPN servers. With these, the client uses a VPN to connect to the firewall, and then appears to be connected directly to the local LAN.


macos - How do I configure SSH on OS X? - Super User

http://www.binarytides.com/vsftpd-configure-ssl-ftps/

Jan 5, 2018 11:02 AM in response to phospholipid77

TL;DR: Set up Duplicati aimed at Backblaze for the remote folks.


So if I understand the question so far, you're seeking assistance with establishing and maintaining a backup strategy for Microsoft Windows systems, and one that currently uses the Duplicati open source package for backups, and one happens to use insecure FTP transfers to a remote server system running an FTP server? In this case, that remote server happens to be macOS Server, but could, well, any sort of server?


If so and if you're interested in keeping Duplicati around, I'd suggest also asking for suggestions over in the Duplicati forums, to learn what those folks have for suggestions and alternatives. (This is the first question about Duplicati I can recall being posted to the forums, and I've not used Windows in a number of years.) macOS supports sftp, FTP (via add-ons on recent macOS releases), FTP via VPN (with either the in-built VPN server or a firewall with an embedded VPN server), and WebDAV if you want to work at it.


Again: FTP is a complete and utter disaster, and no amount of magic is going to make the protocol work better, nor make it secure. Your eventual choices are to migrate from FTP to FTP over SSL (FTPS), or FTP via VPN (requires launching the VPN first), or (usually easier) switch to sftp. Duplicati supports sftp among other targets, based on what I can find over in the Duplicati forums. (Oddly unable to locate a spec for Duplicati capabilities posted over at their web site, though. From the Duplicati source code repository: "Amazon S3, OneDrive, Google Drive, Rackspace Cloud Files, HubiC, Backblaze (B2), Amazon Cloud Drive (AmzCD), Swift / OpenStack, WebDAV, SSH (SFTP), FTP, and more!")


I'd really look at hosting the Microsoft Windows Duplicati-based backups remotely (Backblaze, Amazon, Dropbox, etc), as your folks are probably going to find backups take longer over the network, and pushing those backups over your local network pipe is potentially going to fill that. From the perspective of the Windows users, it's all still Duplicati, though with a different target and with whatever latency the network connection incurs. The different target probably won't be particularly visible to the users, but the time the backups take will be.


Using Backblaze or Amazon also means you won't need to set up DNS translations for your local organization, and won't end up with a static IP address. If you don't already have that — your reference to DDNS implies you don't. Yeah, Dynamic DNS (DDNS) can work, but your ISP will also have to allow inbound network connections of whatever type you eventually use — VPN, FTP, sftp, WebDAV, etc — and not all ISPs allow all protocols into dynamic-addressed hosts. Some ISPs filter some protocols. Most ISPs that offer static IP allow all protocols to those servers. DDNS is good for residential stuff, but it's not so good for servers and it doesn't work very well for some tasks, and — once there's DDNS around, what's running on a server with remote access usually accretes yet more services...


macOS here is really little more than a bystander. If you do choose to use macOS as the target, you'll want to establish a VPN server to allow remote access into your network or to set up ssh/sftp (TCP port 22) port forwarding through the firewall — sftp operates via ssh. I would not open up FTP access, but if you really, really, really, really... really, really want to do that, you'll want to acquire a firewall with FTP introspection or with FTP triggering features (if your current firewall lacks that), as you'll otherwise need to open up the entire ephemeral port range — FTP operates over two connections, the control and the data connections, and because of the way the two connections are established within the protocol, one of the two inevitably has to be special-cased through a firewall on either the client or the server end of the connection. In other words, you'll have to work at it to allow FTP to expose your credentials and your data. And as was mentioned earlier in the thread, FTP is being deprecated from macOS and is no longer part of the macOS installations, so you're either going to have to work to keep what you have with FTP, or you'll be looking to migrate to sftp locally and remotely, or to some other protocol and server otherwise.


As soon as you open up any holes through your firewall, remote folks will find those open ports and will start probing and will start dictionary attacks against passwords and the rest of the background hum of the Internet. They will find sftp and FTP servers, usually within an hour and probably within minutes, and they'll then be trying to log into those and read from and write to those — with brute-force password attacks and and whatever else they can think of. This means keeping better track of your passwords. Though FTP is tantamount to posting your server access credentials to the 'net.

Jan 5, 2018 4:17 PM in response to MrHoffman

Thanks again for the input!


Configuring Duplicati in any capacity isn't my issue. I got that covered. 100%. I can hook Duplicati into any target with any protocol I want, and it's really straight forward. Extremely.


My problem up until now has been configuring the target which, by design, in this particular environment, has to be the OSX server computer. But, I think you have answered that for me. Enable sftp locally, open port 22, set up my dDNS, and try to connect. It sounds like that should work. I will likely have to re-establish the Duplicati connection with that protocol, but that's not a big deal.


I'm going to play with establishing a remote sftp connection now. If I have any more questions for setting up the target on the OSX machine, I'll ask. And if that solves my situation, I'll absolutely let you know. Thanks again!

Jan 6, 2018 8:45 AM in response to phospholipid77

  • Enable ssh locally. sftp operates atop ssh.
  • Opening up ssh access will also allow remote command-line access into your systems, unless that's explicitly disabled. Some of us use that environment to manage our systems; it's both more complex and far more capable than what can be managed from the macOS GUI tools.
  • Ensure that all passwords are now "not obvious" as forwarding TCP port 22 will allow remote access into your server, at least as far as the login prompt. And the remote folks — their botnets, actually — will try every obvious password, and will eventually try every password recovered from the lists of common passwords from previous breaches; these password lists are widely available, and have tens of thousands and more of the most common choices for passwords.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Remote access to SFTP server...

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.