Link to home
Start Free TrialLog in
Avatar of sunhux
sunhux

asked on

Free sftp server tt supports both keys exchange plus credentials authentication; passing credentials to Unix sftp client

We have a number of internal backend servers that run Linux, Solaris
& Windows OS.

These backend servers need to do sftp put+get to an sftp server in our
DMZ & this DMZ server will interface (put+get) with an Oracle Cloud
server via Internet.

Bitwise is free for personal use only.

Q1:
I deem that the internal servers should be sftp client rather than they
act as sftp server: I prefer higher-trust servers to be the client & lower
trust to be the ssh/sftp server (servers will need to be subject to more
rigors such as penetration testing): is my view correct?

Q2:
We tried a couple free sftp servers (Filezilla & SolarWinds) & found that
the free version don't support ssh keys exchange plus credentials
authentication.  Can anyone recommend a free sftp server for Windows
(don't want for Linux/Unix as the sysadmin is a Wintel guy) that could
offer both ssh keys exchange plus credentials?   It must be free for
commercial use.

Q3:
As a number of our internal backend servers are running Solaris/Linux,
the native Unix sftp client don't take in id/password (credentials) as
parameters, unless we do TCL/Expect scripting (Shell script wont do).
Even if we do TCL/Expect scripting, the credentials will be hardcoded
in the scripts (& if we convert these Shell scripts to binary, the hard-
code password is still visible), so I reckon it's not a good cyber hygiene.
So if we have to choose between ssh keys exchange or credentials
authentication, which of the two is the usual practice?  Management
liked to have both for enhanced security, thus I'm asking for a free
sftp server (for commercial) that supports both keys & credentials.

If there's any free sftp clients for RHEL, Oracle Linux & Solaris 10
that could take in credentials (& ssh keys) as its parameter, do
recommend as well.

Someone recommends that we place a Windows sftp client VM
in our internal zone so that this Windows VM sftp to the various
Linux/Solaris servers & in turn this VM sftp to the DMZ server
but this is not good as it add an extra point of failure, adds on to
the transfer timing & require an extra Windows licence


I just know putty's pscp (a free sftp client) supports both but putty
& its components only run on Windows:

C:\putty> pscp /? | find "key"
  -i key    private key file for user authentication
  -hostkey aa:bb:cc:  ...
            manually specify a host key (may be repeated)

C:\putty> pscp /? | find "specified"
  -l user   connect with specified username
  -pw passw login with specified password

SOLUTION
Avatar of ste5an
ste5an
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of sunhux
sunhux

ASKER

>Passwords can be cracked or guessed and require an additional key exchange which could theoretically be attacked.
Is Stefan referring to password or the ssh keys that could be attacked?

>Why is the intermediate server in the DMZ and not in the internal network?
This intermediate server needs to sftp out to Internet, thus it acts as sort of 'proxy'
& it's best that proxy is in DMZ.  If it's in internal zone, have to permit a firewall
sftp rule across 2 layers of firewalls;  if it's in DMZ, it's only the perimeter firewall.

>cygwin
Quite complex to set up cygwin

>OpenSSH 
Is above from MS & offers both keys exchange as well as credentials authentication
free (as long as we have Win2019 licence)?

> pscp is also derived from scp.
So Solaris & Linux scp could take in id+password as parameters?
Eg: in Solaris' help, I got the following (is it the -W option?):
# scp
Usage: scp [ -4 ] [ -6 ] [ -a ascii-mode ] [ -B ] [ -b buffer-size ]
           [ -c cipher ] [ -d ] [ -D debug-level ] [ -F config-file ]
            . . .
           [ -v ] [ -V ] [ -W password-file ] [ --overwrite arg ]
           [[user@]host[#port]:]file_or_dir ... [[user@]host[#port]:]file_or_dir

Hmm, didn't realize scp support "-a ascii-mode"   the sftp doesn't.
I really miss the old ftp's ascii mode (that converts betw Windows
& Unix text files.

I don't have access to a RHEL & Oracle Linux currently but do
they support similar syntax ie -W  and -a ?


SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of sunhux

ASKER

So ssh keys is a much better option that authenticating using id+password when doing
scp/sftp?

Is the -W option in Solaris scp meant for passing password?

I don't have access to a RHEL & Oracle Linux currently but do
they support similar syntax ie -W  and -a ?
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
You asked, "So ssh keys is a much better option that authenticating using id+password when doing scp/sftp?"

Saying one is better than the other... you'd have to define what "better" might mean to you, as this is a judgment call.

I always use empty passphrase keys, because this keeps all code dirt simple, as their's no complexity figuring out how to pass some password via some alternative mechanism... like sshpass or something similar...

Also along the lines of what noci said, I always give people a password... never letting them set their own password, as these are almost always too weak.

Depending on exact type of system, I generate a unique + random 16 or 32 byte alphanumeric code with no special characters, which ensures they can easily cut + paste the code + the code is always strong.