scp fails with "lost connection" while ssh works

[kwwall]

Just started playing around with EnGarde 3.0.21 for use as a DMZ server used with IPCop.
(However, have lots of experience with *nix, so am not a *nix noob, just a EnGarde noob. ;-)

I have configured my SSH keys and am able to ssh successfully to this new DMZ server running Engarde
from a Windows client in the "blue" network off IPCop.

I am able to use SSH from both PuTTY and from Cygwin's ssh. However all attempts to
use either 'scp' or 'sftp' from this same client fails almost immediately with an obscure
"lost connection" message. (Message using PuTTY is almost the same.)

I thought perhaps I was taking too long to type in the passphrase for the private key or
typing it wrong, so I temporarily set up a new DSA key with NO passphrase for testing.
I can SSH OK with this new DSA key, but it still results in the same "lost connection" message
as before when I try it with either scp or sftp.

I've tried looking in EnGarde's /var/log/auth.log but that isn't very helpful (logging level is INFO).
Also have tried both ssh and sftp using extremely verbose debug output (-vvv), but after wading
through that, it was not much help either.

I think I have a fairly standard install of EnGarde. The only thing that I could think of that might
be causing this problem is if scp or sftp operate in manner similar to FTP in 'active' mode, whereby
the SSHD server on the DMZ machine is trying to initiate a "data channel". If something like
that is going on, IPCop is likely blocking it. (I also have a FW rule set up on the EnGarde LInux
in the DMZ ["orange" network in IPCop world] that rejects all outgoing attempts from that
server to anywhere else on port 22 (ssh).) Have not be able to find the Shorewall log files yet,
otherwise I would take a peak at them. Another thing that it might be is some SELinux policy.
I am running in "enforcing" mode, but have not tweaked SELinux ruleset at all.

Anyway, all non-null pointers of why scp and sftp is failing and what I can do to make it work
would be much appreciated.
TIA,
-kevin

[wkeys]

hi

Another thing that it might be is some SELinux policy.
I am running in "enforcing" mode, but have not tweaked SELinux ruleset at all.

Did you try to set SELinux to permissive mode so that we can make sure that SELinux is not the problem?

Bests
~BIll

[kwwall]

wkeys wrote...

Did you try to set SELinux to permissive mode so that we can make sure that SELinux
is not the problem?

Thanks for the suggestion. It was some SELinux policy. It worked when I executed:
setenforce Permissive

-kevin

[wkeys]

hi

Glad to hear.

Bests,
~Bill

[Betsie]

s there a ssh user config for root (probably under $HOME/.ssh/config) ? In case there is, does it work if you move it so that the default config is used?

Based on what you describe it looks as if it's trying to connect to Tectia Server using the SSH1 protocol,which is not supported by Tectia Server (only supports the SSH2 protocol since SSH1 is unsafe).

But it's strange that scp would work for other users and not for root, unless there was a specific user config for root which differs from the global one.