Add IP-wise transfer filtering and update SSH session protocol

[neil-karania]

Closes #2187

Summary
This branch adds source-IP-based transfer scope filtering for file operations, without depending on SFTPGo’s built-in connection allow list.

What this branch changes

• adds a new transfer IP filter feature toggle:
  • SFTPGO_IP_FILTER_ENABLED
• adds enforcement mode support:
  • allow_unmatched
  • deny_unmatched
• adds scope support:
  • data_only
  • all_requests placeholder
• reuses IP list allow entries to express transfer scope:
  • allow both upload and download
  • allow upload only
  • allow download only
• applies enforcement in the shared permission path so it covers major file-operation flows consistently
• keeps admin/auth behavior separate for data_only
• updates admin UI messaging to distinguish:
  • connection allow list status
  • transfer IP filtering status

Security behavior

When the transfer filter is enabled:

• missing remote IP is denied
• IP lookup errors are denied
• unmatched IP behavior follows SFTPGO_IP_FILTER_MODE
• read and write permissions are checked independently against the configured entry scope

Important fixes included

• copy semantics treated as both read and write from the IP filter perspective
• protocol normalization improved so internal protocol labels map correctly for IP list evaluation
• admin UI messaging updated so operators are not misled when:
  • connection allow list is disabled
  • transfer filtering is still active

Example config

SFTPGO_COMMON__ALLOWLIST_STATUS=0
SFTPGO_IP_FILTER_ENABLED=1
SFTPGO_IP_FILTER_MODE=deny_unmatched
SFTPGO_IP_FILTER_SCOPE=data_only

Intended use case
This is meant for deployments where access direction depends on network segment, for example:

• network A: upload only
• network B: download only
  while preserving normal login flows and avoiding admin lockout.

Caveats
This feature assumes SFTPGo sees the real client IP. If it is deployed behind a reverse proxy, load balancer, or NAT that hides the real source IP, the filtering behavior may not reflect the actual client network.

Checklist for Pull Requests

• Have you signed the Contributor License Agreement?

---

[CLAassistant]

All committers have signed the CLA.

[drakkan]

Thank you for the idea and for sharing this WIP PR. We can see how this feature may be useful for certain, more specialized use cases; however, it’s not something we are planning to include in the OSS edition at this time.