(outside observer)

While I agree that getting SCTP support for SSH would be real nice.  The presented patch merely uses SCTP in (what is effectively) TCP emulation mode.

SCTP offers a lot of features that mesh well with ssh, ie.:
 - seperate channels for stdin/stdout/stderr, for every port forward, for authentication agents, X forwarding, etc.
 - the ability to monitor IP addresses available on the machine the client or server is running on and add these to the existing connection
 - others?

I realize of course that implementing all these 'features' would be a *lot* more work than simply using TCP emulation mode.  However if we start off with TCP emulation mode won't we than have to support it for ever more - wouldn't it make sense to start of with a _real_ implementation?  Is there a benefit to supporting ssh over sctp in tcp emulation mode?  Won't performance be pretty much identical to using tcp?

(really just food for thought...)

The main benefit from using SCTP is access to non TCP accessible sites. Or blocked by firewalls or connected via pure SCTP network.

> The main benefit from using SCTP is access to non TCP accessible sites.
> Or blocked by firewalls or connected via pure SCTP network.

SCTP is not a new protocol the likes of ipv6, as such I'm not quite sure what you mean by a pure SCTP network.  The only reasonable case of a pure SCTP network I can think of is in a test lab, where UDP & TCP have been blocked to promote SCTP.

If a firewall is really restrictive enough to block ssh/tcp traffic then it will probably also block unknown protocols (ie. sctp) anyway - or it will implement the same policy for ssh/sctp as for ssh/tcp.  Thus switching ssh from tcp to sctp will rarely help avoid the firewall.

Since using SCTP requires both SCTP capable client ssh and server sshd binaries, with sctp access enabled, I fail to see how in all but very very rare cases this is an easier solution than getting a tcp port opened.

(I've actually run sshd/ssh over sctp with an ld_preload tcp->sctp converter, and I'm mostly commenting here out of curiosity, since I'd really like to see a real ssh over sctp implementation)

a) many "firewals" are not so restrictive, so unknown => pass
b) this is the first try of SCTP. If success there are other goals as QoS requirements.

OK, I guess I'm just hoping that this doesn't prevent a full-fledged implementation later on due to the need to maintain backward compatibility.

I think that this is a basis of it. This patch brings a possibility to play with other SCTP features.

What I need most is roaming between IP addresses, when e.g. switching
between various wired and wireless networks.

I'm interested in exploring the options for the SSH protocol to make use of the multi-streaming capability of SCTP as a Master thesis.

As part of the project I'd like to explore several methods of mapping logical channels in the Connection Protocol to individual streams in SCTP, research the possible effect on confidentiality and integrity of these choices and implement at least on of the methods in OpenSSH.

*** Bug 2016 has been marked as a duplicate of this bug. ***

Created attachment 2572 [details]
openssh-6.8_p1-sctp.patch

more complete patch for 6.8p1 ported from bug 2016

--- a/readconf.c
+++ b/readconf.c
@@ -130,6 +130,9 @@ typedef enum {
 	oPasswordAuthentication, oRSAAuthentication,
 	oChallengeResponseAuthentication, oXAuthLocation,
 	oIdentityFile, oHostName, oPort, oCipher, oRemoteForward, oLocalForward,
+#ifdef SCTP
+	oTransport,
+#endif
 	oUser, oEscapeChar, oRhostsRSAAuthentication, oProxyCommand,
 	oGlobalKnownHostsFile, oUserKnownHostsFile, oConnectionAttempts,
 	oBatchMode, oCheckHostIP, oStrictHostKeyChecking, oCompression,
@@ -198,6 +201,9 @@ static struct {
 	{ "hostname", oHostName },
 	{ "hostkeyalias", oHostKeyAlias },
 	{ "proxycommand", oProxyCommand },
+#ifdef SCTP
+	{ "transport", oTransport },
+#endif
 	{ "port", oPort },
 	{ "cipher", oCipher },
 	{ "ciphers", oCiphers },

The common way to add conditional options is:

#ifdef FEATURE
	{ "feature", oFeature },
#else
	{ "feature", oUnsupported },
#endif

and adding the oFeature unconditionally to the OpCodes.

Created attachment 2573 [details]
openssh-6.8_p1-sctp.patch

i've removed some of the #ifdef's in favor of the unsupported option

not sure how to handle the getopt() logic in the main programs short of not supporting it as a short option at all ...

Created attachment 3346 [details]
openssh-8.1-0248ec7c763dee9ff730a589e3d166eac5c74d7c.patch

refreshed patch to latest git tree

i changed the short option behavior so that z is always passed to getopt, but we display an explicit error message that sctp support isn't enabled.  this makes the code simpler, follows the man pages better (which always list the z option), and makes it more obvious to the user what's going on (vs a generic "unknown option" error).