From des at des.no  Tue May  1 01:39:52 2012
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon, 30 Apr 2012 17:39:52 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 (Dotan Cohen's message of "Mon, 30 Apr 2012 16:55:00 +0300")
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
Message-ID: <86pqapjkjb.fsf@ds4.des.no>

Dotan Cohen <dotancohen at gmail.com> writes:
> One can log into a remote shell via SSH, and one can use an FTP
> application to log in via SFTP using the same credentials over SSH.
> Why then, can one not initiate a file transfer from the remote host to
> the local host when logged into a shell via SSH?

man ssh_config, search for ControlMaster.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From dotancohen at gmail.com  Tue May  1 04:49:23 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Mon, 30 Apr 2012 21:49:23 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <86pqapjkjb.fsf@ds4.des.no>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
Message-ID: <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>

On Mon, Apr 30, 2012 at 18:39, Dag-Erling Sm?rgrav <des at des.no> wrote:
> man ssh_config, search for ControlMaster.
>

Thank you Dag!

The ControlMaster option allows for the reuse of a session, but does
not provide any nice "cpLocal" command for easily moving files from
the remote machine to local (or vice versa).

Rereading my original post, I see that I did not explicitly state that
such an easy command was my goal. I often SSH into different machines
and many of those I cannot modify with aliases and such. However, a
facility for easily transferring files from / to these machines would
be very nice.

Thanks.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From dtucker at zip.com.au  Tue May  1 20:48:52 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 1 May 2012 20:48:52 +1000
Subject: Feature request: virtual servers
In-Reply-To: <201204260834.33198.philipp.marek@linbit.com>
References: <201204251002.11357.philipp.marek@linbit.com>
 <alpine.BSO.2.00.1204260930120.2929@natsu.mindrot.org>
 <20120426035042.GA27364@gate.dtucker.net>
 <201204260834.33198.philipp.marek@linbit.com>
Message-ID: <20120501104852.GA16512@gate.dtucker.net>

On Thu, Apr 26, 2012 at 08:34:32AM +0200, Philipp Marek wrote:
> Could you put that in OpenSSH, so that -portable and the distributions can 
> pick that up sometime?

We're looking at it.

In the mean time, here's an updated patch that:
 - fixes a problem with the "Match Port" code
 - fixes the regress tests and adds a couple more
 - some minor cleanups
 - applies to openssh-6.0p1

Index: auth.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/auth.c,v
retrieving revision 1.149
diff -u -p -r1.149 auth.c
--- auth.c	29 May 2011 11:40:42 -0000	1.149
+++ auth.c	1 May 2012 10:36:24 -0000
@@ -544,9 +544,14 @@ getpwnamallow(const char *user)
 #endif
 #endif
 	struct passwd *pw;
+	ConnectionInfo connection_info;
 
-	parse_server_match_config(&options, user,
-	    get_canonical_hostname(options.use_dns), get_remote_ipaddr());
+	connection_info.user = user;
+	connection_info.host = get_canonical_hostname(options.use_dns);
+	connection_info.address = get_remote_ipaddr();
+	connection_info.laddress = get_local_ipaddr(packet_get_connection_in());
+	connection_info.lport = get_local_port();
+	parse_server_match_config(&options, &connection_info);
 
 #if defined(_AIX) && defined(HAVE_SETAUTHDB)
 	aix_setauthdb(user);
Index: servconf.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/servconf.c,v
retrieving revision 1.220
diff -u -p -r1.220 servconf.c
--- servconf.c	2 Oct 2011 07:57:38 -0000	1.220
+++ servconf.c	1 May 2012 10:36:24 -0000
@@ -598,19 +598,20 @@ out:
 }
 
 static int
-match_cfg_line(char **condition, int line, const char *user, const char *host,
-    const char *address)
+match_cfg_line(char **condition, int line, ConnectionInfo *ci)
 {
-	int result = 1;
+	int result = 1, port;
 	char *arg, *attrib, *cp = *condition;
 	size_t len;
 
-	if (user == NULL)
+	if (ci == NULL)
 		debug3("checking syntax for 'Match %s'", cp);
 	else
-		debug3("checking match for '%s' user %s host %s addr %s", cp,
-		    user ? user : "(null)", host ? host : "(null)",
-		    address ? address : "(null)");
+		debug3("checking match for '%s' user %s host %s addr %s "
+		    "laddr %s lport %d", cp, ci->user ? ci->user : "(null)",
+		    ci->host ? ci->host : "(null)",
+		    ci->address ? ci->address : "(null)",
+		    ci->laddress ? ci->laddress : "(null)", ci->lport);
 
 	while ((attrib = strdelim(&cp)) && *attrib != '\0') {
 		if ((arg = strdelim(&cp)) == NULL || *arg == '\0') {
@@ -619,37 +620,63 @@ match_cfg_line(char **condition, int lin
 		}
 		len = strlen(arg);
 		if (strcasecmp(attrib, "user") == 0) {
-			if (!user) {
+			if (ci == NULL || ci->user == NULL) {
 				result = 0;
 				continue;
 			}
-			if (match_pattern_list(user, arg, len, 0) != 1)
+			if (match_pattern_list(ci->user, arg, len, 0) != 1)
 				result = 0;
 			else
 				debug("user %.100s matched 'User %.100s' at "
-				    "line %d", user, arg, line);
+				    "line %d", ci->user, arg, line);
 		} else if (strcasecmp(attrib, "group") == 0) {
-			switch (match_cfg_line_group(arg, line, user)) {
+			if (ci == NULL || ci->user == NULL) {
+				result = 0;
+				continue;
+			}
+			switch (match_cfg_line_group(arg, line, ci->user)) {
 			case -1:
 				return -1;
 			case 0:
 				result = 0;
 			}
 		} else if (strcasecmp(attrib, "host") == 0) {
-			if (!host) {
+			if (ci == NULL || ci->host == NULL) {
 				result = 0;
 				continue;
 			}
-			if (match_hostname(host, arg, len) != 1)
+			if (match_hostname(ci->host, arg, len) != 1)
 				result = 0;
 			else
 				debug("connection from %.100s matched 'Host "
-				    "%.100s' at line %d", host, arg, line);
+				    "%.100s' at line %d", ci->host, arg, line);
 		} else if (strcasecmp(attrib, "address") == 0) {
-			switch (addr_match_list(address, arg)) {
+			if (ci == NULL || ci->address == NULL) {
+				result = 0;
+				continue;
+			}
+			switch (addr_match_list(ci->address, arg)) {
 			case 1:
 				debug("connection from %.100s matched 'Address "
-				    "%.100s' at line %d", address, arg, line);
+				    "%.100s' at line %d", ci->address, arg, line);
+				break;
+			case 0:
+			case -1:
+				result = 0;
+				break;
+			case -2:
+				return -1;
+			}
+		} else if (strcasecmp(attrib, "localaddress") == 0){
+			if (ci == NULL || ci->laddress == NULL) {
+				result = 0;
+				continue;
+			}
+			switch (addr_match_list(ci->laddress, arg)) {
+			case 1:
+				debug("connection from %.100s matched "
+				    "'LocalAddress %.100s' at line %d",
+				    ci->laddress, arg, line);
 				break;
 			case 0:
 			case -1:
@@ -658,12 +685,25 @@ match_cfg_line(char **condition, int lin
 			case -2:
 				return -1;
 			}
+		} else if (strcasecmp(attrib, "localport") == 0) {
+			if ((port = a2port(arg)) == -1) {
+				error("Invalid LocalPort '%s' on Match line",
+				    arg);
+				return -1;
+			}
+			if (ci == NULL) {
+				result = 0;
+				continue;
+			}
+			/* TODO support port lists */
+			if (port != ci->lport)
+				result = 0;
 		} else {
 			error("Unsupported Match attribute %s", attrib);
 			return -1;
 		}
 	}
-	if (user != NULL)
+	if (ci != NULL)
 		debug3("match %sfound", result ? "" : "not ");
 	*condition = cp;
 	return result;
@@ -710,8 +750,8 @@ static const struct multistate multistat
 
 int
 process_server_config_line(ServerOptions *options, char *line,
-    const char *filename, int linenum, int *activep, const char *user,
-    const char *host, const char *address)
+    const char *filename, int linenum, int *activep,
+    ConnectionInfo *connectinfo)
 {
 	char *cp, **charptr, *arg, *p;
 	int cmdline = 0, *intptr, value, value2, n;
@@ -742,7 +782,7 @@ process_server_config_line(ServerOptions
 	if (*activep && opcode != sMatch)
 		debug3("%s:%d setting %s %s", filename, linenum, arg, cp);
 	if (*activep == 0 && !(flags & SSHCFG_MATCH)) {
-		if (user == NULL) {
+		if (connectinfo == NULL) {
 			fatal("%s line %d: Directive '%s' is not allowed "
 			    "within a Match block", filename, linenum, arg);
 		} else { /* this is a directive we have already processed */
@@ -1313,7 +1353,7 @@ process_server_config_line(ServerOptions
 		if (cmdline)
 			fatal("Match directive not supported as a command-line "
 			   "option");
-		value = match_cfg_line(&cp, linenum, user, host, address);
+		value = match_cfg_line(&cp, linenum, connectinfo);
 		if (value < 0)
 			fatal("%s line %d: Bad Match condition", filename,
 			    linenum);
@@ -1451,16 +1491,57 @@ load_server_config(const char *filename,
 }
 
 void
-parse_server_match_config(ServerOptions *options, const char *user,
-    const char *host, const char *address)
+parse_server_match_config(ServerOptions *options, ConnectionInfo *connectinfo)
 {
 	ServerOptions mo;
 
 	initialize_server_options(&mo);
-	parse_server_config(&mo, "reprocess config", &cfg, user, host, address);
+	parse_server_config(&mo, "reprocess config", &cfg, connectinfo);
 	copy_set_server_options(options, &mo, 0);
 }
 
+int parse_server_match_testspec(ConnectionInfo *ci, char *spec)
+{
+	char *p;
+
+	while ((p = strsep(&spec, ",")) && *p != '\0') {
+		if (strncmp(p, "addr=", 5) == 0) {
+			ci->address = xstrdup(p + 5);
+		} else if (strncmp(p, "host=", 5) == 0) {
+			ci->host = xstrdup(p + 5);
+		} else if (strncmp(p, "user=", 5) == 0) {
+			ci->user = xstrdup(p + 5);
+		} else if (strncmp(p, "laddr=", 6) == 0) {
+			ci->laddress = xstrdup(p + 6);
+		} else if (strncmp(p, "lport=", 6) == 0) {
+			ci->lport = a2port(p + 6);
+			if (ci->lport == -1) {
+				fprintf(stderr, "Invalid port '%s' in test mode"
+				   " specification %s\n", p+6, p);
+				return -1;
+			}
+		} else {
+			fprintf(stderr, "Invalid test mode specification %s\n",
+			   p);
+			return -1;
+		}
+	}
+	return 0;
+}
+
+/*
+ * returns 1 for a complete spec, 0 for partial spec and -1 for an
+ * empty spec.
+ */
+int server_match_spec_complete(ConnectionInfo *ci)
+{
+	if (ci->user && ci->host && ci->address)
+		return 1;	/* complete */
+	if (!ci->user && !ci->host && !ci->address)
+		return -1;	/* empty */
+	return 0;	/* partial */
+}
+
 /* Helper macros */
 #define M_CP_INTOPT(n) do {\
 	if (src->n != -1) \
@@ -1534,7 +1615,7 @@ copy_set_server_options(ServerOptions *d
 
 void
 parse_server_config(ServerOptions *options, const char *filename, Buffer *conf,
-    const char *user, const char *host, const char *address)
+    ConnectionInfo *connectinfo)
 {
 	int active, linenum, bad_options = 0;
 	char *cp, *obuf, *cbuf;
@@ -1542,11 +1623,11 @@ parse_server_config(ServerOptions *optio
 	debug2("%s: config %s len %d", __func__, filename, buffer_len(conf));
 
 	obuf = cbuf = xstrdup(buffer_ptr(conf));
-	active = user ? 0 : 1;
+	active = connectinfo ? 0 : 1;
 	linenum = 1;
 	while ((cp = strsep(&cbuf, "\n")) != NULL) {
 		if (process_server_config_line(options, cp, filename,
-		    linenum++, &active, user, host, address) != 0)
+		    linenum++, &active, connectinfo) != 0)
 			bad_options++;
 	}
 	xfree(obuf);
Index: servconf.h
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/servconf.h,v
retrieving revision 1.91
diff -u -p -r1.91 servconf.h
--- servconf.h	22 Jun 2011 22:30:03 -0000	1.91
+++ servconf.h	1 May 2012 10:36:24 -0000
@@ -168,6 +168,17 @@ typedef struct {
 	char   *authorized_principals_file;
 }       ServerOptions;
 
+
+/* Information about the incoming connection as used by Match */
+typedef struct {
+	const char *user;
+	const char *host;	/* possibly resolved hostname */
+	const char *address; 	/* remote address */
+	const char *laddress;	/* local address */
+	int lport;		/* local port */
+} ConnectionInfo;
+
+
 /*
  * These are string config options that must be copied between the
  * Match sub-config and the main config, and must be sent from the
@@ -185,12 +196,13 @@ typedef struct {
 void	 initialize_server_options(ServerOptions *);
 void	 fill_default_server_options(ServerOptions *);
 int	 process_server_config_line(ServerOptions *, char *, const char *, int,
-	     int *, const char *, const char *, const char *);
+	     int *, ConnectionInfo *);
 void	 load_server_config(const char *, Buffer *);
 void	 parse_server_config(ServerOptions *, const char *, Buffer *,
-	     const char *, const char *, const char *);
-void	 parse_server_match_config(ServerOptions *, const char *, const char *,
-	     const char *);
+	     ConnectionInfo *);
+void	 parse_server_match_config(ServerOptions *, ConnectionInfo *);
+int	 parse_server_match_testspec(ConnectionInfo *, char *);
+int	 server_match_spec_complete(ConnectionInfo *);
 void	 copy_set_server_options(ServerOptions *, ServerOptions *, int);
 void	 dump_config(ServerOptions *);
 char	*derelativise_path(const char *);
Index: sshd.8
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd.8,v
retrieving revision 1.225
diff -u -p -r1.225 sshd.8
--- sshd.8	2 Oct 2011 07:57:38 -0000	1.225
+++ sshd.8	10 Oct 2011 06:14:47 -0000
@@ -114,6 +114,8 @@ The connection parameters are supplied a
 The keywords are
 .Dq user ,
 .Dq host ,
+.Dq laddr ,
+.Dq lport ,
 and
 .Dq addr .
 All are required and may be supplied in any order, either with multiple
Index: sshd.c
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd.c,v
retrieving revision 1.411
diff -u -p -r1.411 sshd.c
--- sshd.c	14 Feb 2012 18:03:31 -0000	1.411
+++ sshd.c	1 May 2012 10:36:24 -0000
@@ -1320,14 +1320,14 @@ main(int ac, char **av)
 	int opt, i, j, on = 1;
 	int sock_in = -1, sock_out = -1, newsock = -1;
 	const char *remote_ip;
-	char *test_user = NULL, *test_host = NULL, *test_addr = NULL;
 	int remote_port;
-	char *line, *p, *cp;
+	char *line;
 	int config_s[2] = { -1 , -1 };
 	u_int64_t ibytes, obytes;
 	mode_t new_umask;
 	Key *key;
 	Authctxt *authctxt;
+	ConnectionInfo connection_info;
 
 #ifdef HAVE_SECUREWARE
 	(void)set_auth_parameters(ac, av);
@@ -1357,6 +1357,10 @@ main(int ac, char **av)
 	/* Initialize configuration options to their default values. */
 	initialize_server_options(&options);
 
+	connection_info.user = connection_info.host = connection_info.address
+	    = connection_info.laddress = NULL;
+	connection_info.lport = 0;
+
 	/* Parse command-line arguments. */
 	while ((opt = getopt(ac, av, "f:p:b:k:h:g:u:o:C:dDeiqrtQRT46")) != -1) {
 		switch (opt) {
@@ -1449,20 +1453,9 @@ main(int ac, char **av)
 			test_flag = 2;
 			break;
 		case 'C':
-			cp = optarg;
-			while ((p = strsep(&cp, ",")) && *p != '\0') {
-				if (strncmp(p, "addr=", 5) == 0)
-					test_addr = xstrdup(p + 5);
-				else if (strncmp(p, "host=", 5) == 0)
-					test_host = xstrdup(p + 5);
-				else if (strncmp(p, "user=", 5) == 0)
-					test_user = xstrdup(p + 5);
-				else {
-					fprintf(stderr, "Invalid test "
-					    "mode specification %s\n", p);
-					exit(1);
-				}
-			}
+			if (parse_server_match_testspec(&connection_info,
+			    optarg) == -1)
+				exit(1);
 			break;
 		case 'u':
 			utmp_len = (u_int)strtonum(optarg, 0, MAXHOSTNAMELEN+1, NULL);
@@ -1474,7 +1467,7 @@ main(int ac, char **av)
 		case 'o':
 			line = xstrdup(optarg);
 			if (process_server_config_line(&options, line,
-			    "command-line", 0, NULL, NULL, NULL, NULL) != 0)
+			    "command-line", 0, NULL, NULL) != 0)
 				exit(1);
 			xfree(line);
 			break;
@@ -1530,13 +1523,10 @@ main(int ac, char **av)
 	 * the parameters we need.  If we're not doing an extended test,
 	 * do not silently ignore connection test params.
 	 */
-	if (test_flag >= 2 &&
-	   (test_user != NULL || test_host != NULL || test_addr != NULL)
-	    && (test_user == NULL || test_host == NULL || test_addr == NULL))
+	if (test_flag >= 2 && server_match_spec_complete(&connection_info) == 0)
 		fatal("user, host and addr are all required when testing "
 		   "Match configs");
-	if (test_flag < 2 && (test_user != NULL || test_host != NULL ||
-	    test_addr != NULL))
+	if (test_flag < 2 && server_match_spec_complete(&connection_info) >= 0)
 		fatal("Config test connection parameter (-C) provided without "
 		   "test mode (-T)");
 
@@ -1548,7 +1538,7 @@ main(int ac, char **av)
 		load_server_config(config_file_name, &cfg);
 
 	parse_server_config(&options, rexeced_flag ? "rexec" : config_file_name,
-	    &cfg, NULL, NULL, NULL);
+	    &cfg, NULL);
 
 	seed_rng();
 
@@ -1710,9 +1700,8 @@ main(int ac, char **av)
 	}
 
 	if (test_flag > 1) {
-		if (test_user != NULL && test_addr != NULL && test_host != NULL)
-			parse_server_match_config(&options, test_user,
-			    test_host, test_addr);
+		if (server_match_spec_complete(&connection_info) == 1)
+			parse_server_match_config(&options, &connection_info);
 		dump_config(&options);
 	}
 
Index: sshd_config.5
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/sshd_config.5,v
retrieving revision 1.143
diff -u -p -r1.143 sshd_config.5
--- sshd_config.5	22 Sep 2011 11:37:13 -0000	1.143
+++ sshd_config.5	1 May 2012 10:36:24 -0000
@@ -675,6 +675,8 @@ The available criteria are
 .Cm User ,
 .Cm Group ,
 .Cm Host ,
+.Cm LocalAddress ,
+.Cm LocalPort ,
 and
 .Cm Address .
 The match patterns may consist of single entries or comma-separated
Index: regress/addrmatch.sh
===================================================================
RCS file: /usr/local/src/security/openssh/cvs/openssh/regress/addrmatch.sh,v
retrieving revision 1.5
diff -u -p -r1.5 addrmatch.sh
--- regress/addrmatch.sh	24 Feb 2010 06:26:39 -0000	1.5
+++ regress/addrmatch.sh	1 May 2012 10:36:46 -0000
@@ -7,39 +7,47 @@ mv $OBJ/sshd_proxy $OBJ/sshd_proxy_bak
 
 run_trial()
 {
-	user="$1"; addr="$2"; host="$3"; expected="$4"; descr="$5"
+	user="$1"; addr="$2"; host="$3"; laddr="$4"; lport="$5"
+	expected="$6"; descr="$7"
 
 	verbose "test $descr for $user $addr $host"
 	result=`${SSHD} -f $OBJ/sshd_proxy -T \
-	    -C user=${user},addr=${addr},host=${host} | \
-	    awk '/^passwordauthentication/ {print $2}'`
+	    -C user=${user},addr=${addr},host=${host},laddr=${laddr},lport=${lport} | \
+	    awk '/^forcecommand/ {print $2}'`
 	if [ "$result" != "$expected" ]; then
-		fail "failed for $user $addr $host: expected $expected, got $result"
+		fail "failed '$descr' expected $expected got $result"
 	fi
 }
 
 cp $OBJ/sshd_proxy_bak $OBJ/sshd_proxy
 cat >>$OBJ/sshd_proxy <<EOD
-PasswordAuthentication no
+ForceCommand nomatch
 Match Address 192.168.0.0/16,!192.168.30.0/24,10.0.0.0/8,host.example.com
-	PasswordAuthentication yes
+	ForceCommand match1
 Match Address 1.1.1.1,::1,!::3,2000::/16
-	PasswordAuthentication yes
+	ForceCommand match2
+Match LocalAddress 127.0.0.1,::1
+	ForceCommand match3
+Match LocalPort 5678
+	ForceCommand match4
 EOD
 
-run_trial user 192.168.0.1 somehost yes		"permit, first entry"
-run_trial user 192.168.30.1 somehost no		"deny, negative match"
-run_trial user 19.0.0.1 somehost no		"deny, no match"
-run_trial user 10.255.255.254 somehost yes	"permit, list middle"
-run_trial user 192.168.30.1 192.168.0.1 no	"deny, faked IP in hostname"
-run_trial user 1.1.1.1 somehost.example.com yes	"permit, bare IP4 address"
-test "$TEST_SSH_IPV6" = "no" && exit
-run_trial user ::1 somehost.example.com	 yes	"permit, bare IP6 address"
-run_trial user ::2 somehost.exaple.com no	"deny IPv6"
-run_trial user ::3 somehost no			"deny IP6 negated"
-run_trial user ::4 somehost no			"deny, IP6 no match"
-run_trial user 2000::1 somehost yes		"permit, IP6 network"
-run_trial user 2001::1 somehost no		"deny, IP6 network"
+run_trial user 192.168.0.1 somehost 1.2.3.4 1234 match1 "first entry"
+run_trial user 192.168.30.1 somehost 1.2.3.4 1234 nomatch "negative match"
+run_trial user 19.0.0.1 somehost 1.2.3.4 1234 nomatch "no match"
+run_trial user 10.255.255.254 somehost 1.2.3.4 1234 match1 "list middle"
+run_trial user 192.168.30.1 192.168.0.1 1.2.3.4 1234 nomatch "faked IP in hostname"
+run_trial user 1.1.1.1 somehost.example.com 1.2.3.4 1234 match2 "bare IP4 address"
+run_trial user 19.0.0.1 somehost 127.0.0.1 1234 match3 "localaddress"
+run_trial user 19.0.0.1 somehost 1.2.3.4 5678 match4 "localport"
+run_trial user ::1 somehost.example.com ::2 1234 match2 "bare IP6 address"
+run_trial user ::2 somehost.exaple.com ::2 1234 nomatch "deny IPv6"
+run_trial user ::3 somehost ::2 1234 nomatch "IP6 negated"
+run_trial user ::4 somehost ::2 1234 nomatch "IP6 no match"
+run_trial user 2000::1 somehost ::2 1234 match2 "IP6 network"
+run_trial user 2001::1 somehost ::2 1234 nomatch "IP6 network"
+run_trial user ::5 somehost ::1 1234 match3 "IP6 localaddress"
+run_trial user ::5 somehost ::2 5678 match4 "IP6 localport"
 
 cp $OBJ/sshd_proxy_bak $OBJ/sshd_proxy
 rm $OBJ/sshd_proxy_bak
-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From oliver at anonsphere.com  Thu May  3 11:49:42 2012
From: oliver at anonsphere.com (Oliver)
Date: Thu, 03 May 2012 03:49:42 +0200
Subject: Strange behaviour of ssh client on arch
Message-ID: <4FA1E436.8090200@anonsphere.com>

Hi,

I don't know, if this is a developer question, but it is too strange for
the user list and maybe a possible bug. My setup is a little bit 
complicated, but I will try to explain as simple as possible. I've got 3 server:

All Server:
System: Debian 6
Interfaces on server1: eth0 tun0 tun1
$ ssh -v
OpenSSH_5.5p1 Debian-6+squeeze1, OpenSSL 0.9.8o 01 Jun 2010

Server 1 is for connecting and tunneling via ssh, let's say public ip
123.1.1.1. If I connect to Server 1, I can surf the web with the server
1 ip - fine!

Server 2 is in the same network, let's say public ip 123.1.1.2. It is
connected on tun0 with server 1 - IP 10.1.0.1 (on server 2) and IP
10.1.0.6 (on server 1)

I mark the traffic of the tunnel with the owner (me => uid 2000):

iptables -t mangle -I OUTPUT -m owner --uid-owner 2000 -j MARK
--set-mark 0x1

and add a rule on server 1 with iproute2:

ip rule from 123.1.1.1 fwmark 0x1 lookup vpn_to_server2

This table sets the default gateway on tun0, so the traffic is
redirected. I can connect to server 1 and surf the web with the ip of
server 2 - fine!

Server 3 is in a remote network, let's say public ip 132.1.1.3. It is
connected on tun1 with server 1 - IP 10.2.0.1 (on server3) an IP
10.2.0.6 (on server 1)

I change the ip rule to

ip rule from 123.1.1.1 fwmark 0x1 lookup vpn_to_server3

Exactly the same settings as above with default gateway on tun1.

I connect with with plink.exe -D 8888 me at server1.com on windows xp. I
can connect and surf with the ip of server 3. Fine! Setup works! But ...

I connect from arch (ssh -v => OpenSSH_6.0p1, OpenSSL 1.0.1a 19 Apr
2012) to server 1 with ssh -vvv -D 8888 me at server1.com and when I try to
surf a page, I get these errors:

debug1: Connection to port 8888 forwarding to socks port 0 requested.
debug2: fd 9 setting TCP_NODELAY
debug2: fd 9 setting O_NONBLOCK
debug3: fd 9 is O_NONBLOCK
debug1: channel 3: new [dynamic-tcpip]
debug2: channel 3: pre_dynamic: have 0
debug2: channel 3: pre_dynamic: have 3
debug2: channel 3: decode socks5
debug2: channel 3: socks5 auth done
debug2: channel 3: pre_dynamic: need more
debug2: channel 3: pre_dynamic: have 0
debug2: channel 3: pre_dynamic: have 20
debug2: channel 3: decode socks5
debug2: channel 3: socks5 post auth
debug2: channel 3: dynamic request: socks5 host www.google.de port 443
command 1
debug1: Connection to port 8888 forwarding to socks port 0 requested.
debug2: fd 10 setting TCP_NODELAY
debug2: fd 10 setting O_NONBLOCK
debug3: fd 10 is O_NONBLOCK
debug1: channel 4: new [dynamic-tcpip]
debug2: channel 4: pre_dynamic: have 0
debug2: channel 4: pre_dynamic: have 3
debug2: channel 4: decode socks5
debug2: channel 4: socks5 auth done
debug2: channel 4: pre_dynamic: need more
debug2: channel 4: pre_dynamic: have 0
debug2: channel 4: pre_dynamic: have 20
debug2: channel 4: decode socks5
debug2: channel 4: socks5 post auth
debug2: channel 4: dynamic request: socks5 host www.google.de port 443
command 1
channel 3: open failed: administratively prohibited: open failed
debug2: channel 3: zombie
debug2: channel 3: garbage collecting
debug1: channel 3: free: direct-tcpip: listening port 8888 for
www.google.de port 443, connect from 127.0.0.1 port 34502, nchannels 5
debug3: channel 3: status: The following connections are open:
  #2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)
  #4 direct-tcpip: listening port 8888 for www.google.de port 443,
connect from 127.0.0.1 port 34503 (t3 r-1 i0/0 o0/10 fd 10/10 cc -1)

Can anybody tell me what I am doing wrong?

regards Oliver



From oliver at anonsphere.com  Thu May  3 12:16:04 2012
From: oliver at anonsphere.com (Oliver)
Date: Thu, 03 May 2012 04:16:04 +0200
Subject: Strange behaviour of ssh client on arch
In-Reply-To: <4FA1E436.8090200@anonsphere.com>
References: <4FA1E436.8090200@anonsphere.com>
Message-ID: <4FA1EA64.7040309@anonsphere.com>

I tried on ubuntu (ssh -v => OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL
1.0.0e 6 Sep 2011) and it works perfect. Is this a problem of archlinux
or a problem of the OpenSSH Version?

From bert.wesarg at googlemail.com  Thu May  3 21:33:37 2012
From: bert.wesarg at googlemail.com (Bert Wesarg)
Date: Thu,  3 May 2012 13:33:37 +0200
Subject: [PATCH/RFC 0/6] New mux client request to list open tcp forwardings.
Message-ID: <cover.1336043194.git.bert.wesarg@googlemail.com>

These patches implement a new mux client request to list the currently opened
TCP forwardings. It also removes some todos regarding keeping the list
of forwardings in the options up-to-date.

Bert Wesarg (6):
  attach the forwarding type to struct Forward
  merge local and remote forward lists
  generate unique ids for forwardings to be used for identification
  remove closed forwardings from options
  maintain lists of forwards when changed from a mux client command
    line
  [mux.c] new request to list open forwardings

 PROTOCOL.mux |   36 ++++++++++-
 clientloop.c |   40 +++++++++---
 mux.c        |  200 ++++++++++++++++++++++++++++------------------------------
 readconf.c   |  128 +++++++++++++++++++------------------
 readconf.h   |   23 ++++---
 ssh.c        |  103 +++++++++++++++++++-----------
 sshconnect.c |    8 +-
 7 files changed, 308 insertions(+), 230 deletions(-)

-- 
1.7.9.rc0.542.g07ca1


From bert.wesarg at googlemail.com  Thu May  3 21:33:46 2012
From: bert.wesarg at googlemail.com (Bert Wesarg)
Date: Thu,  3 May 2012 13:33:46 +0200
Subject: [PATCH/RFC 0/6] New mux client request to list open tcp forwardings.
Message-ID: <cover.1336043194.git.bert.wesarg@googlemail.com>

These patches implement a new mux client request to list the currently opened
TCP forwardings. It also removes some todos regarding keeping the list
of forwardings in the options up-to-date.

Bert Wesarg (6):
  attach the forwarding type to struct Forward
  merge local and remote forward lists
  generate unique ids for forwardings to be used for identification
  remove closed forwardings from options
  maintain lists of forwards when changed from a mux client command
    line
  [mux.c] new request to list open forwardings

 PROTOCOL.mux |   36 ++++++++++-
 clientloop.c |   40 +++++++++---
 mux.c        |  200 ++++++++++++++++++++++++++++------------------------------
 readconf.c   |  128 +++++++++++++++++++------------------
 readconf.h   |   23 ++++---
 ssh.c        |  103 +++++++++++++++++++-----------
 sshconnect.c |    8 +-
 7 files changed, 308 insertions(+), 230 deletions(-)

-- 
1.7.9.rc0.542.g07ca1


From bert.wesarg at googlemail.com  Thu May  3 21:33:47 2012
From: bert.wesarg at googlemail.com (Bert Wesarg)
Date: Thu,  3 May 2012 13:33:47 +0200
Subject: [PATCH/RFC 1/6] attach the forwarding type to struct Forward
In-Reply-To: <cover.1336043194.git.bert.wesarg@googlemail.com>
References: <cover.1336043194.git.bert.wesarg@googlemail.com>
Message-ID: <d49593444653b63b67b09dd51257c4d8c7ecc356.1336043194.git.bert.wesarg@googlemail.com>

---
 clientloop.c |   21 +++++++++---------
 mux.c        |   65 ++++++++++++++++++++++++++++-----------------------------
 readconf.c   |   19 ++++++++++------
 readconf.h   |    8 ++++++-
 ssh.c        |    8 +++---
 5 files changed, 66 insertions(+), 55 deletions(-)

diff --git a/clientloop.c b/clientloop.c
index 58357cf..6c62bb7 100644
--- a/clientloop.c
+++ b/clientloop.c
@@ -863,7 +863,8 @@ process_cmdline(void)
 {
 	void (*handler)(int);
 	char *s, *cmd, *cancel_host;
-	int delete = 0, local = 0, remote = 0, dynamic = 0;
+	int delete = 0, i;
+	u_int fwdtype;
 	int cancel_port, ok;
 	Forward fwd;
 
@@ -914,11 +915,11 @@ process_cmdline(void)
 		s++;
 	}
 	if (*s == 'L')
-		local = 1;
+		fwdtype = SSH_FWD_LOCAL;
 	else if (*s == 'R')
-		remote = 1;
+		fwdtype = SSH_FWD_REMOTE;
 	else if (*s == 'D')
-		dynamic = 1;
+		fwdtype = SSH_FWD_DYNAMIC;
 	else {
 		logit("Invalid command.");
 		goto out;
@@ -947,14 +948,14 @@ process_cmdline(void)
 			logit("Bad forwarding close port");
 			goto out;
 		}
-		if (remote)
+		if (fwdtype == SSH_FWD_REMOTE)
 			ok = channel_request_rforward_cancel(cancel_host,
 			    cancel_port) == 0;
-		else if (dynamic)
-                	ok = channel_cancel_lport_listener(cancel_host,
+		else if (fwdtype == SSH_FWD_DYNAMIC)
+			ok = channel_cancel_lport_listener(cancel_host,
 			    cancel_port, 0, options.gateway_ports) > 0;
 		else
-                	ok = channel_cancel_lport_listener(cancel_host,
+			ok = channel_cancel_lport_listener(cancel_host,
 			    cancel_port, CHANNEL_CANCEL_PORT_STATIC,
 			    options.gateway_ports) > 0;
 		if (!ok) {
@@ -963,11 +964,11 @@ process_cmdline(void)
 		}
 		logit("Canceled forwarding.");
 	} else {
-		if (!parse_forward(&fwd, s, dynamic, remote)) {
+		if (!parse_forward(&fwd, s, fwdtype)) {
 			logit("Bad forwarding specification.");
 			goto out;
 		}
-		if (local || dynamic) {
+		if (fwdtype == SSH_FWD_LOCAL || fwdtype == SSH_FWD_DYNAMIC) {
 			if (channel_setup_local_fwd_listener(fwd.listen_host,
 			    fwd.listen_port, fwd.connect_host,
 			    fwd.connect_port, options.gateway_ports) < 0) {
diff --git a/mux.c b/mux.c
index d90605e..e7b81d1 100644
--- a/mux.c
+++ b/mux.c
@@ -156,9 +156,9 @@ struct mux_master_state {
 #define MUX_S_TTY_ALLOC_FAIL	0x80000008
 
 /* type codes for MUX_C_OPEN_FWD and MUX_C_CLOSE_FWD */
-#define MUX_FWD_LOCAL   1
-#define MUX_FWD_REMOTE  2
-#define MUX_FWD_DYNAMIC 3
+#define MUX_FWD_LOCAL   SSH_FWD_LOCAL
+#define MUX_FWD_REMOTE  SSH_FWD_REMOTE
+#define MUX_FWD_DYNAMIC SSH_FWD_DYNAMIC
 
 static void mux_session_confirm(int, int, void *);
 
@@ -511,11 +511,11 @@ process_mux_terminate(u_int rid, Channel *c, Buffer *m, Buffer *r)
 }
 
 static char *
-format_forward(u_int ftype, Forward *fwd)
+format_forward(Forward *fwd)
 {
 	char *ret;
 
-	switch (ftype) {
+	switch (fwd->type) {
 	case MUX_FWD_LOCAL:
 		xasprintf(&ret, "local forward %.200s:%d -> %.200s:%d",
 		    (fwd->listen_host == NULL) ?
@@ -537,7 +537,7 @@ format_forward(u_int ftype, Forward *fwd)
 		    fwd->connect_host, fwd->connect_port);
 		break;
 	default:
-		fatal("%s: unknown forward type %u", __func__, ftype);
+		fatal("%s: unknown forward type %u", __func__, fwd->type);
 	}
 	return ret;
 }
@@ -555,6 +555,8 @@ compare_host(const char *a, const char *b)
 static int
 compare_forward(Forward *a, Forward *b)
 {
+	if (a->type != b->type)
+		return 0;
 	if (!compare_host(a->listen_host, b->listen_host))
 		return 0;
 	if (a->listen_port != b->listen_port)
@@ -631,11 +633,10 @@ process_mux_open_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 {
 	Forward fwd;
 	char *fwd_desc = NULL;
-	u_int ftype;
 	int i, ret = 0, freefwd = 1;
 
 	fwd.listen_host = fwd.connect_host = NULL;
-	if (buffer_get_int_ret(&ftype, m) != 0 ||
+	if (buffer_get_int_ret(&fwd.type, m) != 0 ||
 	    (fwd.listen_host = buffer_get_string_ret(m, NULL)) == NULL ||
 	    buffer_get_int_ret(&fwd.listen_port, m) != 0 ||
 	    (fwd.connect_host = buffer_get_string_ret(m, NULL)) == NULL ||
@@ -655,11 +656,11 @@ process_mux_open_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 	}
 
 	debug2("%s: channel %d: request %s", __func__, c->self,
-	    (fwd_desc = format_forward(ftype, &fwd)));
+	    (fwd_desc = format_forward(&fwd)));
 
-	if (ftype != MUX_FWD_LOCAL && ftype != MUX_FWD_REMOTE &&
-	    ftype != MUX_FWD_DYNAMIC) {
-		logit("%s: invalid forwarding type %u", __func__, ftype);
+	if (fwd.type != MUX_FWD_LOCAL && fwd.type != MUX_FWD_REMOTE &&
+	    fwd.type != MUX_FWD_DYNAMIC) {
+		logit("%s: invalid forwarding type %u", __func__, fwd.type);
  invalid:
 		if (fwd.listen_host)
 			xfree(fwd.listen_host);
@@ -675,19 +676,19 @@ process_mux_open_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 		    fwd.listen_port);
 		goto invalid;
 	}
-	if (fwd.connect_port >= 65536 || (ftype != MUX_FWD_DYNAMIC &&
-	    ftype != MUX_FWD_REMOTE && fwd.connect_port == 0)) {
+	if (fwd.connect_port >= 65536 || (fwd.type != MUX_FWD_DYNAMIC &&
+	    fwd.type != MUX_FWD_REMOTE && fwd.connect_port == 0)) {
 		logit("%s: invalid connect port %u", __func__,
 		    fwd.connect_port);
 		goto invalid;
 	}
-	if (ftype != MUX_FWD_DYNAMIC && fwd.connect_host == NULL) {
+	if (fwd.type != MUX_FWD_DYNAMIC && fwd.connect_host == NULL) {
 		logit("%s: missing connect host", __func__);
 		goto invalid;
 	}
 
 	/* Skip forwards that have already been requested */
-	switch (ftype) {
+	switch (fwd.type) {
 	case MUX_FWD_LOCAL:
 	case MUX_FWD_DYNAMIC:
 		for (i = 0; i < options.num_local_forwards; i++) {
@@ -731,7 +732,7 @@ process_mux_open_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 		}
 	}
 
-	if (ftype == MUX_FWD_LOCAL || ftype == MUX_FWD_DYNAMIC) {
+	if (fwd.type == MUX_FWD_LOCAL || fwd.type == MUX_FWD_DYNAMIC) {
 		if (channel_setup_local_fwd_listener(fwd.listen_host,
 		    fwd.listen_port, fwd.connect_host, fwd.connect_port,
 		    options.gateway_ports) < 0) {
@@ -783,11 +784,10 @@ process_mux_close_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 	Forward fwd, *found_fwd;
 	char *fwd_desc = NULL;
 	const char *error_reason = NULL;
-	u_int ftype;
 	int i, listen_port, ret = 0;
 
 	fwd.listen_host = fwd.connect_host = NULL;
-	if (buffer_get_int_ret(&ftype, m) != 0 ||
+	if (buffer_get_int_ret(&fwd.type, m) != 0 ||
 	    (fwd.listen_host = buffer_get_string_ret(m, NULL)) == NULL ||
 	    buffer_get_int_ret(&fwd.listen_port, m) != 0 ||
 	    (fwd.connect_host = buffer_get_string_ret(m, NULL)) == NULL ||
@@ -807,11 +807,11 @@ process_mux_close_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 	}
 
 	debug2("%s: channel %d: request cancel %s", __func__, c->self,
-	    (fwd_desc = format_forward(ftype, &fwd)));
+	    (fwd_desc = format_forward(&fwd)));
 
 	/* make sure this has been requested */
 	found_fwd = NULL;
-	switch (ftype) {
+	switch (fwd.type) {
 	case MUX_FWD_LOCAL:
 	case MUX_FWD_DYNAMIC:
 		for (i = 0; i < options.num_local_forwards; i++) {
@@ -835,22 +835,22 @@ process_mux_close_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 
 	if (found_fwd == NULL)
 		error_reason = "port not forwarded";
-	else if (ftype == MUX_FWD_REMOTE) {
+	else if (found_fwd->type == MUX_FWD_REMOTE) {
 		/*
 		 * This shouldn't fail unless we confused the host/port
 		 * between options.remote_forwards and permitted_opens.
 		 * However, for dynamic allocated listen ports we need
 		 * to lookup the actual listen port.
 		 */
-	        listen_port = (fwd.listen_port == 0) ?
-		    found_fwd->allocated_port : fwd.listen_port;
-		if (channel_request_rforward_cancel(fwd.listen_host,
+		listen_port = (found_fwd->listen_port == 0) ?
+		    found_fwd->allocated_port : found_fwd->listen_port;
+		if (channel_request_rforward_cancel(found_fwd->listen_host,
 		    listen_port) == -1)
 			error_reason = "port not in permitted opens";
 	} else {	/* local and dynamic forwards */
 		/* Ditto */
-		if (channel_cancel_lport_listener(fwd.listen_host,
-		    fwd.listen_port, fwd.connect_port,
+		if (channel_cancel_lport_listener(found_fwd->listen_host,
+		    found_fwd->listen_port, found_fwd->connect_port,
 		    options.gateway_ports) == -1)
 			error_reason = "port not found";
 	}
@@ -859,6 +859,7 @@ process_mux_close_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 		buffer_put_int(r, MUX_S_OK);
 		buffer_put_int(r, rid);
 
+		found_fwd->type = 0;
 		if (found_fwd->listen_host != NULL)
 			xfree(found_fwd->listen_host);
 		if (found_fwd->connect_host != NULL)
@@ -1597,13 +1598,13 @@ mux_client_request_terminate(int fd)
 }
 
 static int
-mux_client_forward(int fd, int cancel_flag, u_int ftype, Forward *fwd)
+mux_client_forward(int fd, int cancel_flag, Forward *fwd)
 {
 	Buffer m;
 	char *e, *fwd_desc;
 	u_int type, rid;
 
-	fwd_desc = format_forward(ftype, fwd);
+	fwd_desc = format_forward(fwd);
 	debug("Requesting %s %s",
 	    cancel_flag ? "cancellation of" : "forwarding of", fwd_desc);
 	xfree(fwd_desc);
@@ -1611,7 +1612,7 @@ mux_client_forward(int fd, int cancel_flag, u_int ftype, Forward *fwd)
 	buffer_init(&m);
 	buffer_put_int(&m, cancel_flag ? MUX_C_CLOSE_FWD : MUX_C_OPEN_FWD);
 	buffer_put_int(&m, muxclient_request_id);
-	buffer_put_int(&m, ftype);
+	buffer_put_int(&m, fwd->type);
 	buffer_put_cstring(&m,
 	    fwd->listen_host == NULL ? "" : fwd->listen_host);
 	buffer_put_int(&m, fwd->listen_port);
@@ -1680,13 +1681,11 @@ mux_client_forwards(int fd, int cancel_flag)
 	/* XXX ExitOnForwardingFailure */
 	for (i = 0; i < options.num_local_forwards; i++) {
 		if (mux_client_forward(fd, cancel_flag,
-		    options.local_forwards[i].connect_port == 0 ?
-		    MUX_FWD_DYNAMIC : MUX_FWD_LOCAL,
 		    options.local_forwards + i) != 0)
 			ret = -1;
 	}
 	for (i = 0; i < options.num_remote_forwards; i++) {
-		if (mux_client_forward(fd, cancel_flag, MUX_FWD_REMOTE,
+		if (mux_client_forward(fd, cancel_flag,
 		    options.remote_forwards + i) != 0)
 			ret = -1;
 	}
diff --git a/readconf.c b/readconf.c
index 097bb05..29e12bd 100644
--- a/readconf.c
+++ b/readconf.c
@@ -269,6 +269,7 @@ add_local_forward(Options *options, const Forward *newfwd)
 	    sizeof(*options->local_forwards));
 	fwd = &options->local_forwards[options->num_local_forwards++];
 
+	fwd->type = newfwd->type;
 	fwd->listen_host = newfwd->listen_host;
 	fwd->listen_port = newfwd->listen_port;
 	fwd->connect_host = newfwd->connect_host;
@@ -290,6 +291,7 @@ add_remote_forward(Options *options, const Forward *newfwd)
 	    sizeof(*options->remote_forwards));
 	fwd = &options->remote_forwards[options->num_remote_forwards++];
 
+	fwd->type = newfwd->type;
 	fwd->listen_host = newfwd->listen_host;
 	fwd->listen_port = newfwd->listen_port;
 	fwd->connect_host = newfwd->connect_host;
@@ -784,8 +786,9 @@ parse_int:
 		}
 
 		if (parse_forward(&fwd, fwdarg,
-		    opcode == oDynamicForward ? 1 : 0,
-		    opcode == oRemoteForward ? 1 : 0) == 0)
+		    opcode == oDynamicForward ? SSH_FWD_DYNAMIC :
+		    opcode == oRemoteForward  ? SSH_FWD_REMOTE :
+		                                SSH_FWD_LOCAL) == 0)
 			fatal("%.200s line %d: Bad forwarding specification.",
 			    filename, linenum);
 
@@ -1378,19 +1381,20 @@ fill_default_options(Options * options)
 /*
  * parse_forward
  * parses a string containing a port forwarding specification of the form:
- *   dynamicfwd == 0
+ *   fwdtype != SSH_FWD_DYNAMIC
  *	[listenhost:]listenport:connecthost:connectport
- *   dynamicfwd == 1
+ *   fwdtype == SSH_FWD_DYNAMIC
  *	[listenhost:]listenport
  * returns number of arguments parsed or zero on error
  */
 int
-parse_forward(Forward *fwd, const char *fwdspec, int dynamicfwd, int remotefwd)
+parse_forward(Forward *fwd, const char *fwdspec, u_int fwdtype)
 {
 	int i;
 	char *p, *cp, *fwdarg[4];
 
 	memset(fwd, '\0', sizeof(*fwd));
+	fwd->type = fwdtype;
 
 	cp = p = xstrdup(fwdspec);
 
@@ -1438,7 +1442,7 @@ parse_forward(Forward *fwd, const char *fwdspec, int dynamicfwd, int remotefwd)
 
 	xfree(p);
 
-	if (dynamicfwd) {
+	if (fwd->type == SSH_FWD_DYNAMIC) {
 		if (!(i == 1 || i == 2))
 			goto fail_free;
 	} else {
@@ -1448,7 +1452,8 @@ parse_forward(Forward *fwd, const char *fwdspec, int dynamicfwd, int remotefwd)
 			goto fail_free;
 	}
 
-	if (fwd->listen_port < 0 || (!remotefwd && fwd->listen_port == 0))
+	if (fwd->listen_port < 0 ||
+	    (fwd->type != SSH_FWD_REMOTE && fwd->listen_port == 0))
 		goto fail_free;
 
 	if (fwd->connect_host != NULL &&
diff --git a/readconf.h b/readconf.h
index be30ee0..b15d916 100644
--- a/readconf.h
+++ b/readconf.h
@@ -18,7 +18,13 @@
 
 /* Data structure for representing a forwarding request. */
 
+/* This is also part of the MUX protocol */
+#define SSH_FWD_LOCAL   1
+#define SSH_FWD_REMOTE  2
+#define SSH_FWD_DYNAMIC 3
+
 typedef struct {
+	u_int	  type;			/* Type of forwarding [1, 2, 3] */
 	char	 *listen_host;		/* Host (address) to listen on. */
 	int	  listen_port;		/* Port to forward. */
 	char	 *connect_host;		/* Host to connect. */
@@ -151,11 +157,11 @@ typedef struct {
 void     initialize_options(Options *);
 void     fill_default_options(Options *);
 int	 read_config_file(const char *, const char *, Options *, int);
-int	 parse_forward(Forward *, const char *, int, int);
 
 int
 process_config_line(Options *, const char *, char *, const char *, int, int *);
 
+int	 parse_forward(Forward *, const char *, u_int);
 void	 add_local_forward(Options *, const Forward *);
 void	 add_remote_forward(Options *, const Forward *);
 
diff --git a/ssh.c b/ssh.c
index 68e1315..a63bfab 100644
--- a/ssh.c
+++ b/ssh.c
@@ -456,7 +456,7 @@ main(int ac, char **av)
 				fatal("stdio forward already specified");
 			if (muxclient_command != 0)
 				fatal("Cannot specify stdio forward with -O");
-			if (parse_forward(&fwd, optarg, 1, 0)) {
+			if (parse_forward(&fwd, optarg, SSH_FWD_DYNAMIC)) {
 				stdio_forward_host = fwd.listen_host;
 				stdio_forward_port = fwd.listen_port;
 				xfree(fwd.connect_host);
@@ -538,7 +538,7 @@ main(int ac, char **av)
 			break;
 
 		case 'L':
-			if (parse_forward(&fwd, optarg, 0, 0))
+			if (parse_forward(&fwd, optarg, SSH_FWD_LOCAL))
 				add_local_forward(&options, &fwd);
 			else {
 				fprintf(stderr,
@@ -549,7 +549,7 @@ main(int ac, char **av)
 			break;
 
 		case 'R':
-			if (parse_forward(&fwd, optarg, 0, 1)) {
+			if (parse_forward(&fwd, optarg, SSH_FWD_REMOTE)) {
 				add_remote_forward(&options, &fwd);
 			} else {
 				fprintf(stderr,
@@ -560,7 +560,7 @@ main(int ac, char **av)
 			break;
 
 		case 'D':
-			if (parse_forward(&fwd, optarg, 1, 0)) {
+			if (parse_forward(&fwd, optarg, SSH_FWD_DYNAMIC)) {
 				add_local_forward(&options, &fwd);
 			} else {
 				fprintf(stderr,
-- 
1.7.9.rc0.542.g07ca1


From bert.wesarg at googlemail.com  Thu May  3 21:33:49 2012
From: bert.wesarg at googlemail.com (Bert Wesarg)
Date: Thu,  3 May 2012 13:33:49 +0200
Subject: [PATCH/RFC 3/6] generate unique ids for forwardings to be used for
 identification
In-Reply-To: <1424f68ae6f5f34093dc6db36968b4748eb8db6f.1336043194.git.bert.wesarg@googlemail.com>
References: <cover.1336043194.git.bert.wesarg@googlemail.com>
 <d49593444653b63b67b09dd51257c4d8c7ecc356.1336043194.git.bert.wesarg@googlemail.com>
 <1424f68ae6f5f34093dc6db36968b4748eb8db6f.1336043194.git.bert.wesarg@googlemail.com>
Message-ID: <9ba2cfc284b3a0d22b2c32619812c4363a3bdae5.1336043194.git.bert.wesarg@googlemail.com>

---
 mux.c      |   21 +++++++++++----------
 readconf.c |    6 +++++-
 readconf.h |    3 ++-
 ssh.c      |   23 ++++++++++++++++++++---
 4 files changed, 38 insertions(+), 15 deletions(-)

diff --git a/mux.c b/mux.c
index d57c1de..337ef54 100644
--- a/mux.c
+++ b/mux.c
@@ -113,7 +113,7 @@ struct mux_session_confirm_ctx {
 struct mux_channel_confirm_ctx {
 	u_int cid;	/* channel id */
 	u_int rid;	/* request id */
-	int fid;	/* forward id */
+	u_int fid;	/* forward id */
 };
 
 /* fd to control socket */
@@ -574,9 +574,10 @@ mux_confirm_remote_forward(int type, u_int32_t seq, void *ctxt)
 {
 	struct mux_channel_confirm_ctx *fctx = ctxt;
 	char *failmsg = NULL;
-	Forward *rfwd;
+	Forward *rfwd = NULL;
 	Channel *c;
 	Buffer out;
+	int i;
 
 	if ((c = channel_by_id(fctx->cid)) == NULL) {
 		/* no channel for reply */
@@ -584,13 +585,14 @@ mux_confirm_remote_forward(int type, u_int32_t seq, void *ctxt)
 		return;
 	}
 	buffer_init(&out);
-	if (fctx->fid >= options.num_forwards) {
-		xasprintf(&failmsg, "unknown forwarding id %d", fctx->fid);
-		goto fail;
+	for (i = 0; i < options.num_forwards; i++) {
+		if (options.forwards[i].id == fctx->fid) {
+			rfwd = &options.forwards[i];
+			break;
+		}
 	}
-	rfwd = &options.forwards[fctx->fid];
-	if (rfwd->type != SSH_FWD_REMOTE) {
-		xasprintf(&failmsg, "non-remote forwarding id %d", fctx->fid);
+	if (rfwd == NULL || rfwd->type != MUX_FWD_REMOTE) {
+		xasprintf(&failmsg, "unknown forwarding id %d", fctx->fid);
 		goto fail;
 	}
 	debug("%s: %s for: listen %d, connect %s:%d", __func__,
@@ -742,11 +744,10 @@ process_mux_open_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 		    fwd.listen_port, fwd.connect_host, fwd.connect_port);
 		if (fwd.handle < 0)
 			goto fail;
-		add_forward(&options, &fwd);
 		fctx = xcalloc(1, sizeof(*fctx));
 		fctx->cid = c->self;
 		fctx->rid = rid;
-		fctx->fid = options.num_forwards - 1;
+		fctx->fid = add_forward(&options, &fwd);
 		client_register_global_confirm(mux_confirm_remote_forward,
 		    fctx);
 		freefwd = 0;
diff --git a/readconf.c b/readconf.c
index d0687af..a89b07a 100644
--- a/readconf.c
+++ b/readconf.c
@@ -255,9 +255,10 @@ static struct {
  * error.
  */
 
-void
+u_int
 add_forward(Options *options, const Forward *newfwd)
 {
+	static u_int fid_sequence;
 	Forward *fwd;
 #ifndef NO_IPPORT_RESERVED_CONCEPT
 	if (newfwd->type != SSH_FWD_REMOTE) {
@@ -271,6 +272,7 @@ add_forward(Options *options, const Forward *newfwd)
 	    sizeof(*options->forwards));
 	fwd = &options->forwards[options->num_forwards++];
 
+	fwd->id = fid_sequence++;
 	fwd->type = newfwd->type;
 	fwd->listen_host = newfwd->listen_host;
 	fwd->listen_port = newfwd->listen_port;
@@ -280,6 +282,8 @@ add_forward(Options *options, const Forward *newfwd)
 		fwd->handle = newfwd->handle;
 		fwd->allocated_port = 0;
 	}
+
+	return fwd->id;
 }
 
 static void
diff --git a/readconf.h b/readconf.h
index c4ce149..d44946b 100644
--- a/readconf.h
+++ b/readconf.h
@@ -24,6 +24,7 @@
 #define SSH_FWD_DYNAMIC 3
 
 typedef struct {
+	u_int	  id;			/* sequential id of this forward */
 	u_int	  type;			/* Type of forwarding [1, 2, 3] */
 	char	 *listen_host;		/* Host (address) to listen on. */
 	int	  listen_port;		/* Port to forward. */
@@ -158,6 +159,6 @@ int
 process_config_line(Options *, const char *, char *, const char *, int, int *);
 
 int	 parse_forward(Forward *, const char *, u_int);
-void	 add_forward(Options *, const Forward *);
+u_int	 add_forward(Options *, const Forward *);
 
 #endif				/* READCONF_H */
diff --git a/ssh.c b/ssh.c
index c29f522..999fc6a 100644
--- a/ssh.c
+++ b/ssh.c
@@ -1018,8 +1018,23 @@ fork_postauth(void)
 static void
 ssh_confirm_remote_forward(int type, u_int32_t seq, void *ctxt)
 {
-	Forward *rfwd = (Forward *)ctxt;
+	u_int fid = *(u_int *)ctxt;
+	Forward *rfwd = NULL;
+	int i;
+
+	xfree(ctxt);
+
 	remote_forward_confirms_pending--;
+	for (i = 0; i < options.num_forwards; i++) {
+		if (options.forwards[i].id == fid) {
+			rfwd = &options.forwards[i];
+			break;
+		}
+	}
+	if (rfwd == NULL) {
+		debug("remote forwarding not found: %u", fid);
+		return;
+	}
 
 	/* XXX verbose() on failure? */
 	debug("remote forward %s for: listen %d, connect %s:%d",
@@ -1141,8 +1156,10 @@ ssh_init_forwarding(void)
 				    "forwarding.");
 		} else {
 			remote_forward_confirms_pending++;
+			u_int *idcp = xmalloc(sizeof(*idcp));
+			*idcp = options.forwards[i].id;
 			client_register_global_confirm(ssh_confirm_remote_forward,
-			    &options.forwards[i]);
+			    idcp);
 		}
 	}
 
@@ -1155,7 +1172,7 @@ ssh_init_forwarding(void)
 			else
 				error("Could not request tunnel forwarding.");
 		}
-	}			
+	}
 }
 
 static void
-- 
1.7.9.rc0.542.g07ca1


From bert.wesarg at googlemail.com  Thu May  3 21:33:50 2012
From: bert.wesarg at googlemail.com (Bert Wesarg)
Date: Thu,  3 May 2012 13:33:50 +0200
Subject: [PATCH/RFC 4/6] remove closed forwardings from options
In-Reply-To: <9ba2cfc284b3a0d22b2c32619812c4363a3bdae5.1336043194.git.bert.wesarg@googlemail.com>
References: <cover.1336043194.git.bert.wesarg@googlemail.com>
 <d49593444653b63b67b09dd51257c4d8c7ecc356.1336043194.git.bert.wesarg@googlemail.com>
 <1424f68ae6f5f34093dc6db36968b4748eb8db6f.1336043194.git.bert.wesarg@googlemail.com>
 <9ba2cfc284b3a0d22b2c32619812c4363a3bdae5.1336043194.git.bert.wesarg@googlemail.com>
Message-ID: <8ee315546f64a31266c0be4f57934dd210002faf.1336043194.git.bert.wesarg@googlemail.com>

---
 mux.c      |    8 +-------
 readconf.c |   32 ++++++++++++++++++++++++++++++++
 readconf.h |    1 +
 3 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/mux.c b/mux.c
index 337ef54..c59bb97 100644
--- a/mux.c
+++ b/mux.c
@@ -835,13 +835,7 @@ process_mux_close_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 		buffer_put_int(r, MUX_S_OK);
 		buffer_put_int(r, rid);
 
-		found_fwd->type = 0;
-		if (found_fwd->listen_host != NULL)
-			xfree(found_fwd->listen_host);
-		if (found_fwd->connect_host != NULL)
-			xfree(found_fwd->connect_host);
-		found_fwd->listen_host = found_fwd->connect_host = NULL;
-		found_fwd->listen_port = found_fwd->connect_port = 0;
+		remove_forward(&options, found_fwd);
 	} else {
 		buffer_put_int(r, MUX_S_FAILURE);
 		buffer_put_int(r, rid);
diff --git a/readconf.c b/readconf.c
index a89b07a..371570d 100644
--- a/readconf.c
+++ b/readconf.c
@@ -286,6 +286,38 @@ add_forward(Options *options, const Forward *newfwd)
 	return fwd->id;
 }
 
+/*
+ * Remove a TCP/IP port forward from the options.
+ */
+
+void
+remove_forward(Options *options, Forward *remfwd)
+{
+	if (remfwd < options->forwards ||
+	    options->forwards + options->num_forwards <= remfwd)
+		fatal("Invalid forwarding to remove.");
+
+	if (remfwd->listen_host != NULL)
+		xfree(remfwd->listen_host);
+	if (remfwd->connect_host != NULL)
+		xfree(remfwd->connect_host);
+	remfwd->listen_host = remfwd->connect_host = NULL;
+	remfwd->listen_port = remfwd->connect_port = 0;
+
+	options->num_forwards--;
+	while (remfwd < options->forwards + options->num_forwards) {
+		*remfwd = *(remfwd + 1);
+		remfwd++;
+	}
+	if (options->num_forwards > 0)
+		options->forwards = xrealloc(options->forwards,
+		    options->num_forwards, sizeof(*remfwd));
+	else {
+		xfree(options->forwards);
+		options->forwards = NULL;
+	}
+}
+
 static void
 clear_forwardings(Options *options)
 {
diff --git a/readconf.h b/readconf.h
index d44946b..6877888 100644
--- a/readconf.h
+++ b/readconf.h
@@ -160,5 +160,6 @@ process_config_line(Options *, const char *, char *, const char *, int, int *);
 
 int	 parse_forward(Forward *, const char *, u_int);
 u_int	 add_forward(Options *, const Forward *);
+void	 remove_forward(Options *, Forward *);
 
 #endif				/* READCONF_H */
-- 
1.7.9.rc0.542.g07ca1


From bert.wesarg at googlemail.com  Thu May  3 21:33:51 2012
From: bert.wesarg at googlemail.com (Bert Wesarg)
Date: Thu,  3 May 2012 13:33:51 +0200
Subject: [PATCH/RFC 5/6] maintain lists of forwards when changed from a mux
 client command line
In-Reply-To: <8ee315546f64a31266c0be4f57934dd210002faf.1336043194.git.bert.wesarg@googlemail.com>
References: <cover.1336043194.git.bert.wesarg@googlemail.com>
 <d49593444653b63b67b09dd51257c4d8c7ecc356.1336043194.git.bert.wesarg@googlemail.com>
 <1424f68ae6f5f34093dc6db36968b4748eb8db6f.1336043194.git.bert.wesarg@googlemail.com>
 <9ba2cfc284b3a0d22b2c32619812c4363a3bdae5.1336043194.git.bert.wesarg@googlemail.com>
 <8ee315546f64a31266c0be4f57934dd210002faf.1336043194.git.bert.wesarg@googlemail.com>
Message-ID: <86ea35d32351b2f41c2fc6f65efa905d668d7ed6.1336043194.git.bert.wesarg@googlemail.com>

---
 clientloop.c |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/clientloop.c b/clientloop.c
index 6c62bb7..018df0d 100644
--- a/clientloop.c
+++ b/clientloop.c
@@ -933,7 +933,6 @@ process_cmdline(void)
 	while (isspace(*++s))
 		;
 
-	/* XXX update list of forwards in options */
 	if (delete) {
 		cancel_port = 0;
 		cancel_host = hpdelim(&s);	/* may be NULL */
@@ -962,6 +961,23 @@ process_cmdline(void)
 			logit("Unkown port forwarding.");
 			goto out;
 		}
+		for (i = 0; i < options.num_forwards; i++) {
+			Forward *efwd = options.forwards + i;
+			int listen_port = (efwd->listen_port == 0) ?
+			    efwd->allocated_port : efwd->listen_port;
+			if (fwdtype != efwd->type)
+				continue;
+			if (cancel_port != listen_port)
+				continue;
+			if ((efwd->listen_host == NULL && cancel_host != NULL) ||
+			    (efwd->listen_host != NULL && cancel_host == NULL))
+				continue;
+			if (cancel_host == NULL ||
+			    strcmp(efwd->listen_host, cancel_host) == 0) {
+				remove_forward(&options, efwd);
+				break;
+			}
+		}
 		logit("Canceled forwarding.");
 	} else {
 		if (!parse_forward(&fwd, s, fwdtype)) {
@@ -983,6 +999,7 @@ process_cmdline(void)
 				goto out;
 			}
 		}
+		add_forward(&options, &fwd);
 		logit("Forwarding port.");
 	}
 
-- 
1.7.9.rc0.542.g07ca1


From bert.wesarg at googlemail.com  Thu May  3 21:33:52 2012
From: bert.wesarg at googlemail.com (Bert Wesarg)
Date: Thu,  3 May 2012 13:33:52 +0200
Subject: [PATCH/RFC 6/6] [mux.c] new request to list open forwardings
In-Reply-To: <86ea35d32351b2f41c2fc6f65efa905d668d7ed6.1336043194.git.bert.wesarg@googlemail.com>
References: <cover.1336043194.git.bert.wesarg@googlemail.com>
 <d49593444653b63b67b09dd51257c4d8c7ecc356.1336043194.git.bert.wesarg@googlemail.com>
 <1424f68ae6f5f34093dc6db36968b4748eb8db6f.1336043194.git.bert.wesarg@googlemail.com>
 <9ba2cfc284b3a0d22b2c32619812c4363a3bdae5.1336043194.git.bert.wesarg@googlemail.com>
 <8ee315546f64a31266c0be4f57934dd210002faf.1336043194.git.bert.wesarg@googlemail.com>
 <86ea35d32351b2f41c2fc6f65efa905d668d7ed6.1336043194.git.bert.wesarg@googlemail.com>
Message-ID: <ac1b745f0bc0aeb9cd42a9384a008f6f01bdbbb8.1336043194.git.bert.wesarg@googlemail.com>

---
 PROTOCOL.mux |   36 +++++++++++++++++++++++++++++++++---
 mux.c        |   31 +++++++++++++++++++++++++++++++
 2 files changed, 64 insertions(+), 3 deletions(-)

diff --git a/PROTOCOL.mux b/PROTOCOL.mux
index 49cbe5b..26b5f8d 100644
--- a/PROTOCOL.mux
+++ b/PROTOCOL.mux
@@ -171,13 +171,41 @@ and remove its listener socket.
 A server may reply with a MUX_S_OK, a MUX_S_PERMISSION_DENIED or a
 MUX_S_FAILURE.
 
-9. Status messages
+9. Request a list of open forwardings from the mux listener
+
+A client may request the master to send the list of open port forwardings.
+
+	uint32	MUX_C_LIST_FWDS
+	uint32	request id
+
+The server will reply with a MUX_S_RESULT and the following payload:
+
+	uint32	MUX_S_RESULT
+	uint32	client request id
+	[ uint32	forwarding id
+	  uint32	forwarding type
+	  string	listen host
+	  uint32	listen port
+	  string	connect host
+	  uint32	connect port
+	  uint32	allocated port [if appropriate] ]...
+
+The allocated port entry is only there for remote forwardings with a listen port
+equal zero.
+
+10. Status messages
 
 The MUX_S_OK message is empty:
 
 	uint32	MUX_S_OK
 	uint32	client request id
 
+The MUX_S_RESULT message has a payload depending on the client request:
+
+	uint32	MUX_S_RESULT
+	uint32	client request id
+	[payload]
+
 The MUX_S_PERMISSION_DENIED and MUX_S_FAILURE include a reason:
 
 	uint32	MUX_S_PERMISSION_DENIED
@@ -188,7 +216,7 @@ The MUX_S_PERMISSION_DENIED and MUX_S_FAILURE include a reason:
 	uint32	client request id
 	string	reason
 
-10. Protocol numbers
+11. Protocol numbers
 
 #define MUX_MSG_HELLO		0x00000001
 #define MUX_C_NEW_SESSION	0x10000002
@@ -198,6 +226,7 @@ The MUX_S_PERMISSION_DENIED and MUX_S_FAILURE include a reason:
 #define MUX_C_CLOSE_FWD		0x10000007
 #define MUX_C_NEW_STDIO_FWD	0x10000008
 #define MUX_C_STOP_LISTENING	0x10000009
+#define MUX_C_LIST_FWDS		0x1000000a
 #define MUX_S_OK		0x80000001
 #define MUX_S_PERMISSION_DENIED	0x80000002
 #define MUX_S_FAILURE		0x80000003
@@ -206,13 +235,14 @@ The MUX_S_PERMISSION_DENIED and MUX_S_FAILURE include a reason:
 #define MUX_S_SESSION_OPENED	0x80000006
 #define MUX_S_REMOTE_PORT	0x80000007
 #define MUX_S_TTY_ALLOC_FAIL	0x80000008
+#define MUX_S_RESULT		0x80000009
 
 #define MUX_FWD_LOCAL	1
 #define MUX_FWD_REMOTE	2
 #define MUX_FWD_DYNAMIC	3
 
 XXX TODO
-XXX extended status (e.g. report open channels / forwards)
+XXX extended status (e.g. report open channels)
 XXX lock (maybe)
 XXX watch in/out traffic (pre/post crypto)
 XXX inject packet (what about replies)
diff --git a/mux.c b/mux.c
index c59bb97..d975007 100644
--- a/mux.c
+++ b/mux.c
@@ -146,6 +146,7 @@ struct mux_master_state {
 #define MUX_C_CLOSE_FWD		0x10000007
 #define MUX_C_NEW_STDIO_FWD	0x10000008
 #define MUX_C_STOP_LISTENING	0x10000009
+#define MUX_C_LIST_FWDS		0x1000000a
 #define MUX_S_OK		0x80000001
 #define MUX_S_PERMISSION_DENIED	0x80000002
 #define MUX_S_FAILURE		0x80000003
@@ -154,6 +155,7 @@ struct mux_master_state {
 #define MUX_S_SESSION_OPENED	0x80000006
 #define MUX_S_REMOTE_PORT	0x80000007
 #define MUX_S_TTY_ALLOC_FAIL	0x80000008
+#define MUX_S_RESULT		0x80000009
 
 /* type codes for MUX_C_OPEN_FWD and MUX_C_CLOSE_FWD */
 #define MUX_FWD_LOCAL   SSH_FWD_LOCAL
@@ -170,6 +172,7 @@ static int process_mux_open_fwd(u_int, Channel *, Buffer *, Buffer *);
 static int process_mux_close_fwd(u_int, Channel *, Buffer *, Buffer *);
 static int process_mux_stdio_fwd(u_int, Channel *, Buffer *, Buffer *);
 static int process_mux_stop_listening(u_int, Channel *, Buffer *, Buffer *);
+static int process_mux_list_fwds(u_int, Channel *, Buffer *, Buffer *);
 
 static const struct {
 	u_int type;
@@ -183,6 +186,7 @@ static const struct {
 	{ MUX_C_CLOSE_FWD, process_mux_close_fwd },
 	{ MUX_C_NEW_STDIO_FWD, process_mux_stdio_fwd },
 	{ MUX_C_STOP_LISTENING, process_mux_stop_listening },
+	{ MUX_C_LIST_FWDS, process_mux_list_fwds },
 	{ 0, NULL }
 };
 
@@ -982,6 +986,33 @@ process_mux_stop_listening(u_int rid, Channel *c, Buffer *m, Buffer *r)
 	return 0;
 }
 
+static int
+process_mux_list_fwds(u_int rid, Channel *c, Buffer *m, Buffer *r)
+{
+	int i;
+
+	debug("%s: channel %d: list forwardings", __func__, c->self);
+
+	/* prepare reply */
+	buffer_put_int(r, MUX_S_RESULT);
+	buffer_put_int(r, rid);
+
+	for (i = 0; i < options.num_forwards; i++) {
+		Forward *fwd = &options.forwards[i];
+		buffer_put_int(r, fwd->id);
+		buffer_put_int(r, fwd->type);
+		buffer_put_cstring(r, fwd->listen_host ? fwd->listen_host : "");
+		buffer_put_int(r, fwd->listen_port);
+		buffer_put_cstring(r, fwd->connect_host ? fwd->connect_host : "");
+		buffer_put_int(r, fwd->connect_port);
+		if (fwd->type == MUX_FWD_REMOTE && fwd->listen_port == 0) {
+			buffer_put_int(r, fwd->allocated_port);
+		}
+	}
+
+	return 0;
+}
+
 /* Channel callbacks fired on read/write from mux slave fd */
 static int
 mux_master_read_cb(Channel *c)
-- 
1.7.9.rc0.542.g07ca1


From bert.wesarg at googlemail.com  Thu May  3 21:33:48 2012
From: bert.wesarg at googlemail.com (Bert Wesarg)
Date: Thu,  3 May 2012 13:33:48 +0200
Subject: [PATCH/RFC 2/6] merge local and remote forward lists
In-Reply-To: <d49593444653b63b67b09dd51257c4d8c7ecc356.1336043194.git.bert.wesarg@googlemail.com>
References: <cover.1336043194.git.bert.wesarg@googlemail.com>
 <d49593444653b63b67b09dd51257c4d8c7ecc356.1336043194.git.bert.wesarg@googlemail.com>
Message-ID: <1424f68ae6f5f34093dc6db36968b4748eb8db6f.1336043194.git.bert.wesarg@googlemail.com>

---
 mux.c        |   99 ++++++++++++++++++++--------------------------------------
 readconf.c   |   87 +++++++++++++++-----------------------------------
 readconf.h   |   13 ++-----
 ssh.c        |   74 ++++++++++++++++++++++++-------------------
 sshconnect.c |    8 ++--
 5 files changed, 110 insertions(+), 171 deletions(-)

diff --git a/mux.c b/mux.c
index e7b81d1..d57c1de 100644
--- a/mux.c
+++ b/mux.c
@@ -584,11 +584,15 @@ mux_confirm_remote_forward(int type, u_int32_t seq, void *ctxt)
 		return;
 	}
 	buffer_init(&out);
-	if (fctx->fid >= options.num_remote_forwards) {
+	if (fctx->fid >= options.num_forwards) {
 		xasprintf(&failmsg, "unknown forwarding id %d", fctx->fid);
 		goto fail;
 	}
-	rfwd = &options.remote_forwards[fctx->fid];
+	rfwd = &options.forwards[fctx->fid];
+	if (rfwd->type != SSH_FWD_REMOTE) {
+		xasprintf(&failmsg, "non-remote forwarding id %d", fctx->fid);
+		goto fail;
+	}
 	debug("%s: %s for: listen %d, connect %s:%d", __func__,
 	    type == SSH2_MSG_REQUEST_SUCCESS ? "success" : "failure",
 	    rfwd->listen_port, rfwd->connect_host, rfwd->connect_port);
@@ -688,37 +692,23 @@ process_mux_open_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 	}
 
 	/* Skip forwards that have already been requested */
-	switch (fwd.type) {
-	case MUX_FWD_LOCAL:
-	case MUX_FWD_DYNAMIC:
-		for (i = 0; i < options.num_local_forwards; i++) {
-			if (compare_forward(&fwd,
-			    options.local_forwards + i)) {
- exists:
-				debug2("%s: found existing forwarding",
-				    __func__);
-				buffer_put_int(r, MUX_S_OK);
-				buffer_put_int(r, rid);
-				goto out;
-			}
-		}
-		break;
-	case MUX_FWD_REMOTE:
-		for (i = 0; i < options.num_remote_forwards; i++) {
-			if (compare_forward(&fwd,
-			    options.remote_forwards + i)) {
-				if (fwd.listen_port != 0)
-					goto exists;
-				debug2("%s: found allocated port",
-				    __func__);
-				buffer_put_int(r, MUX_S_REMOTE_PORT);
-				buffer_put_int(r, rid);
-				buffer_put_int(r,
-				    options.remote_forwards[i].allocated_port);
-				goto out;
-			}
+	for (i = 0; i < options.num_forwards; i++) {
+		if (!compare_forward(&fwd, &options.forwards[i]))
+			continue;
+		if (fwd.type == MUX_FWD_REMOTE && fwd.listen_port == 0) {
+			debug2("%s: found allocated port",
+			    __func__);
+			buffer_put_int(r, MUX_S_REMOTE_PORT);
+			buffer_put_int(r, rid);
+			buffer_put_int(r,
+			    options.forwards[i].allocated_port);
+		} else {
+			debug2("%s: found existing forwarding",
+			    __func__);
+			buffer_put_int(r, MUX_S_OK);
+			buffer_put_int(r, rid);
 		}
-		break;
+		goto out;
 	}
 
 	if (options.control_master == SSHCTL_MASTER_ASK ||
@@ -743,7 +733,7 @@ process_mux_open_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 			buffer_put_cstring(r, "Port forwarding failed");
 			goto out;
 		}
-		add_local_forward(&options, &fwd);
+		add_forward(&options, &fwd);
 		freefwd = 0;
 	} else {
 		struct mux_channel_confirm_ctx *fctx;
@@ -752,11 +742,11 @@ process_mux_open_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 		    fwd.listen_port, fwd.connect_host, fwd.connect_port);
 		if (fwd.handle < 0)
 			goto fail;
-		add_remote_forward(&options, &fwd);
+		add_forward(&options, &fwd);
 		fctx = xcalloc(1, sizeof(*fctx));
 		fctx->cid = c->self;
 		fctx->rid = rid;
-		fctx->fid = options.num_remote_forwards - 1;
+		fctx->fid = options.num_forwards - 1;
 		client_register_global_confirm(mux_confirm_remote_forward,
 		    fctx);
 		freefwd = 0;
@@ -811,26 +801,11 @@ process_mux_close_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 
 	/* make sure this has been requested */
 	found_fwd = NULL;
-	switch (fwd.type) {
-	case MUX_FWD_LOCAL:
-	case MUX_FWD_DYNAMIC:
-		for (i = 0; i < options.num_local_forwards; i++) {
-			if (compare_forward(&fwd,
-			    options.local_forwards + i)) {
-				found_fwd = options.local_forwards + i;
-				break;
-			}
-		}
-		break;
-	case MUX_FWD_REMOTE:
-		for (i = 0; i < options.num_remote_forwards; i++) {
-			if (compare_forward(&fwd,
-			    options.remote_forwards + i)) {
-				found_fwd = options.remote_forwards + i;
-				break;
-			}
+	for (i = 0; i < options.num_forwards; i++) {
+		if (compare_forward(&fwd, &options.forwards[i])) {
+			found_fwd = &options.forwards[i];
+			break;
 		}
-		break;
 	}
 
 	if (found_fwd == NULL)
@@ -838,7 +813,7 @@ process_mux_close_fwd(u_int rid, Channel *c, Buffer *m, Buffer *r)
 	else if (found_fwd->type == MUX_FWD_REMOTE) {
 		/*
 		 * This shouldn't fail unless we confused the host/port
-		 * between options.remote_forwards and permitted_opens.
+		 * between options.forwards and permitted_opens.
 		 * However, for dynamic allocated listen ports we need
 		 * to lookup the actual listen port.
 		 */
@@ -1674,19 +1649,13 @@ mux_client_forwards(int fd, int cancel_flag)
 {
 	int i, ret = 0;
 
-	debug3("%s: %s forwardings: %d local, %d remote", __func__,
-	    cancel_flag ? "cancel" : "request",
-	    options.num_local_forwards, options.num_remote_forwards);
+	debug3("%s: %s %d forwardings", __func__,
+	    cancel_flag ? "cancel" : "request", options.num_forwards);
 
 	/* XXX ExitOnForwardingFailure */
-	for (i = 0; i < options.num_local_forwards; i++) {
-		if (mux_client_forward(fd, cancel_flag,
-		    options.local_forwards + i) != 0)
-			ret = -1;
-	}
-	for (i = 0; i < options.num_remote_forwards; i++) {
+	for (i = 0; i < options.num_forwards; i++) {
 		if (mux_client_forward(fd, cancel_flag,
-		    options.remote_forwards + i) != 0)
+		    &options.forwards[i]) != 0)
 			ret = -1;
 	}
 	return ret;
diff --git a/readconf.c b/readconf.c
index 29e12bd..d0687af 100644
--- a/readconf.c
+++ b/readconf.c
@@ -256,48 +256,30 @@ static struct {
  */
 
 void
-add_local_forward(Options *options, const Forward *newfwd)
+add_forward(Options *options, const Forward *newfwd)
 {
 	Forward *fwd;
 #ifndef NO_IPPORT_RESERVED_CONCEPT
-	extern uid_t original_real_uid;
-	if (newfwd->listen_port < IPPORT_RESERVED && original_real_uid != 0)
-		fatal("Privileged ports can only be forwarded by root.");
+	if (newfwd->type != SSH_FWD_REMOTE) {
+		extern uid_t original_real_uid;
+		if (newfwd->listen_port < IPPORT_RESERVED && original_real_uid != 0)
+			fatal("Privileged ports can only be forwarded by root.");
+	}
 #endif
-	options->local_forwards = xrealloc(options->local_forwards,
-	    options->num_local_forwards + 1,
-	    sizeof(*options->local_forwards));
-	fwd = &options->local_forwards[options->num_local_forwards++];
-
-	fwd->type = newfwd->type;
-	fwd->listen_host = newfwd->listen_host;
-	fwd->listen_port = newfwd->listen_port;
-	fwd->connect_host = newfwd->connect_host;
-	fwd->connect_port = newfwd->connect_port;
-}
-
-/*
- * Adds a remote TCP/IP port forward to options.  Never returns if there is
- * an error.
- */
-
-void
-add_remote_forward(Options *options, const Forward *newfwd)
-{
-	Forward *fwd;
-
-	options->remote_forwards = xrealloc(options->remote_forwards,
-	    options->num_remote_forwards + 1,
-	    sizeof(*options->remote_forwards));
-	fwd = &options->remote_forwards[options->num_remote_forwards++];
+	options->forwards = xrealloc(options->forwards,
+	    options->num_forwards + 1,
+	    sizeof(*options->forwards));
+	fwd = &options->forwards[options->num_forwards++];
 
 	fwd->type = newfwd->type;
 	fwd->listen_host = newfwd->listen_host;
 	fwd->listen_port = newfwd->listen_port;
 	fwd->connect_host = newfwd->connect_host;
 	fwd->connect_port = newfwd->connect_port;
-	fwd->handle = newfwd->handle;
-	fwd->allocated_port = 0;
+	if (newfwd->type == SSH_FWD_REMOTE) {
+		fwd->handle = newfwd->handle;
+		fwd->allocated_port = 0;
+	}
 }
 
 static void
@@ -305,26 +287,16 @@ clear_forwardings(Options *options)
 {
 	int i;
 
-	for (i = 0; i < options->num_local_forwards; i++) {
-		if (options->local_forwards[i].listen_host != NULL)
-			xfree(options->local_forwards[i].listen_host);
-		xfree(options->local_forwards[i].connect_host);
+	for (i = 0; i < options->num_forwards; i++) {
+		if (options->forwards[i].listen_host != NULL)
+			xfree(options->forwards[i].listen_host);
+		xfree(options->forwards[i].connect_host);
 	}
-	if (options->num_local_forwards > 0) {
-		xfree(options->local_forwards);
-		options->local_forwards = NULL;
+	if (options->num_forwards > 0) {
+		xfree(options->forwards);
+		options->forwards = NULL;
 	}
-	options->num_local_forwards = 0;
-	for (i = 0; i < options->num_remote_forwards; i++) {
-		if (options->remote_forwards[i].listen_host != NULL)
-			xfree(options->remote_forwards[i].listen_host);
-		xfree(options->remote_forwards[i].connect_host);
-	}
-	if (options->num_remote_forwards > 0) {
-		xfree(options->remote_forwards);
-		options->remote_forwards = NULL;
-	}
-	options->num_remote_forwards = 0;
+	options->num_forwards = 0;
 	options->tun_open = SSH_TUNMODE_NO;
 }
 
@@ -792,13 +764,8 @@ parse_int:
 			fatal("%.200s line %d: Bad forwarding specification.",
 			    filename, linenum);
 
-		if (*activep) {
-			if (opcode == oLocalForward ||
-			    opcode == oDynamicForward)
-				add_local_forward(options, &fwd);
-			else if (opcode == oRemoteForward)
-				add_remote_forward(options, &fwd);
-		}
+		if (*activep)
+			add_forward(options, &fwd);
 		break;
 
 	case oClearAllForwardings:
@@ -1173,10 +1140,8 @@ initialize_options(Options * options)
 	options->escape_char = -1;
 	options->num_system_hostfiles = 0;
 	options->num_user_hostfiles = 0;
-	options->local_forwards = NULL;
-	options->num_local_forwards = 0;
-	options->remote_forwards = NULL;
-	options->num_remote_forwards = 0;
+	options->forwards = NULL;
+	options->num_forwards = 0;
 	options->clear_forwardings = -1;
 	options->log_level = SYSLOG_LEVEL_NOT_SET;
 	options->preferred_authentications = NULL;
diff --git a/readconf.h b/readconf.h
index b15d916..c4ce149 100644
--- a/readconf.h
+++ b/readconf.h
@@ -104,13 +104,9 @@ typedef struct {
 	char   *identity_files[SSH_MAX_IDENTITY_FILES];
 	Key    *identity_keys[SSH_MAX_IDENTITY_FILES];
 
-	/* Local TCP/IP forward requests. */
-	int     num_local_forwards;
-	Forward *local_forwards;
-
-	/* Remote TCP/IP forward requests. */
-	int     num_remote_forwards;
-	Forward *remote_forwards;
+	/* Local and remote TCP/IP forward requests. */
+	int     num_forwards;
+	Forward *forwards;
 	int	clear_forwardings;
 
 	int	enable_ssh_keysign;
@@ -162,7 +158,6 @@ int
 process_config_line(Options *, const char *, char *, const char *, int, int *);
 
 int	 parse_forward(Forward *, const char *, u_int);
-void	 add_local_forward(Options *, const Forward *);
-void	 add_remote_forward(Options *, const Forward *);
+void	 add_forward(Options *, const Forward *);
 
 #endif				/* READCONF_H */
diff --git a/ssh.c b/ssh.c
index a63bfab..c29f522 100644
--- a/ssh.c
+++ b/ssh.c
@@ -184,7 +184,7 @@ Buffer command;
 int subsystem_flag = 0;
 
 /* # of replies received for global requests */
-static int remote_forward_confirms_received = 0;
+static int remote_forward_confirms_pending = 0;
 
 /* mux.c */
 extern int muxserver_sock;
@@ -539,7 +539,7 @@ main(int ac, char **av)
 
 		case 'L':
 			if (parse_forward(&fwd, optarg, SSH_FWD_LOCAL))
-				add_local_forward(&options, &fwd);
+				add_forward(&options, &fwd);
 			else {
 				fprintf(stderr,
 				    "Bad local forwarding specification '%s'\n",
@@ -550,7 +550,7 @@ main(int ac, char **av)
 
 		case 'R':
 			if (parse_forward(&fwd, optarg, SSH_FWD_REMOTE)) {
-				add_remote_forward(&options, &fwd);
+				add_forward(&options, &fwd);
 			} else {
 				fprintf(stderr,
 				    "Bad remote forwarding specification "
@@ -561,7 +561,7 @@ main(int ac, char **av)
 
 		case 'D':
 			if (parse_forward(&fwd, optarg, SSH_FWD_DYNAMIC)) {
-				add_local_forward(&options, &fwd);
+				add_forward(&options, &fwd);
 			} else {
 				fprintf(stderr,
 				    "Bad dynamic forwarding specification "
@@ -1019,6 +1019,7 @@ static void
 ssh_confirm_remote_forward(int type, u_int32_t seq, void *ctxt)
 {
 	Forward *rfwd = (Forward *)ctxt;
+	remote_forward_confirms_pending--;
 
 	/* XXX verbose() on failure? */
 	debug("remote forward %s for: listen %d, connect %s:%d",
@@ -1045,7 +1046,7 @@ ssh_confirm_remote_forward(int type, u_int32_t seq, void *ctxt)
 			logit("Warning: remote port forwarding failed for "
 			    "listen port %d", rfwd->listen_port);
 	}
-	if (++remote_forward_confirms_received == options.num_remote_forwards) {
+	if (remote_forward_confirms_pending == 0) {
 		debug("All remote forwarding requests processed");
 		if (fork_after_authentication_flag)
 			fork_postauth();
@@ -1085,54 +1086,63 @@ static void
 ssh_init_forwarding(void)
 {
 	int success = 0;
+	int num_local_forwards = 0;
 	int i;
 
 	/* Initiate local TCP/IP port forwardings. */
-	for (i = 0; i < options.num_local_forwards; i++) {
+	for (i = 0; i < options.num_forwards; i++) {
+		if (options.forwards[i].type == SSH_FWD_REMOTE)
+			continue;
+		num_local_forwards++;
 		debug("Local connections to %.200s:%d forwarded to remote "
 		    "address %.200s:%d",
-		    (options.local_forwards[i].listen_host == NULL) ?
+		    (options.forwards[i].listen_host == NULL) ?
 		    (options.gateway_ports ? "*" : "LOCALHOST") :
-		    options.local_forwards[i].listen_host,
-		    options.local_forwards[i].listen_port,
-		    options.local_forwards[i].connect_host,
-		    options.local_forwards[i].connect_port);
+		    options.forwards[i].listen_host,
+		    options.forwards[i].listen_port,
+		    options.forwards[i].connect_host,
+		    options.forwards[i].connect_port);
 		success += channel_setup_local_fwd_listener(
-		    options.local_forwards[i].listen_host,
-		    options.local_forwards[i].listen_port,
-		    options.local_forwards[i].connect_host,
-		    options.local_forwards[i].connect_port,
+		    options.forwards[i].listen_host,
+		    options.forwards[i].listen_port,
+		    options.forwards[i].connect_host,
+		    options.forwards[i].connect_port,
 		    options.gateway_ports);
 	}
-	if (i > 0 && success != i && options.exit_on_forward_failure)
+	if (num_local_forwards > 0 &&
+	    success != num_local_forwards &&
+	    options.exit_on_forward_failure)
 		fatal("Could not request local forwarding.");
-	if (i > 0 && success == 0)
+	if (num_local_forwards > 0 && success == 0)
 		error("Could not request local forwarding.");
 
 	/* Initiate remote TCP/IP port forwardings. */
-	for (i = 0; i < options.num_remote_forwards; i++) {
+	for (i = 0; i < options.num_forwards; i++) {
+		if (options.forwards[i].type != SSH_FWD_REMOTE)
+			continue;
 		debug("Remote connections from %.200s:%d forwarded to "
 		    "local address %.200s:%d",
-		    (options.remote_forwards[i].listen_host == NULL) ?
-		    "LOCALHOST" : options.remote_forwards[i].listen_host,
-		    options.remote_forwards[i].listen_port,
-		    options.remote_forwards[i].connect_host,
-		    options.remote_forwards[i].connect_port);
-		options.remote_forwards[i].handle =
+		    (options.forwards[i].listen_host == NULL) ?
+		    "LOCALHOST" : options.forwards[i].listen_host,
+		    options.forwards[i].listen_port,
+		    options.forwards[i].connect_host,
+		    options.forwards[i].connect_port);
+		options.forwards[i].handle =
 		    channel_request_remote_forwarding(
-		    options.remote_forwards[i].listen_host,
-		    options.remote_forwards[i].listen_port,
-		    options.remote_forwards[i].connect_host,
-		    options.remote_forwards[i].connect_port);
-		if (options.remote_forwards[i].handle < 0) {
+		    options.forwards[i].listen_host,
+		    options.forwards[i].listen_port,
+		    options.forwards[i].connect_host,
+		    options.forwards[i].connect_port);
+		if (options.forwards[i].handle < 0) {
 			if (options.exit_on_forward_failure)
 				fatal("Could not request remote forwarding.");
 			else
 				logit("Warning: Could not request remote "
 				    "forwarding.");
 		} else {
+			remote_forward_confirms_pending++;
 			client_register_global_confirm(ssh_confirm_remote_forward,
-			    &options.remote_forwards[i]);
+			    &options.forwards[i]);
 		}
 	}
 
@@ -1291,7 +1301,7 @@ ssh_session(void)
 	 */
 	if (fork_after_authentication_flag) {
 		if (options.exit_on_forward_failure &&
-		    options.num_remote_forwards > 0) {
+		    remote_forward_confirms_pending) {
 			debug("deferring postauth fork until remote forward "
 			    "confirmation received");
 		} else
@@ -1475,7 +1485,7 @@ ssh_session2(void)
 	 */
 	if (fork_after_authentication_flag) {
 		if (options.exit_on_forward_failure &&
-		    options.num_remote_forwards > 0) {
+		    remote_forward_confirms_pending) {
 			debug("deferring postauth fork until remote forward "
 			    "confirmation received");
 		} else
diff --git a/sshconnect.c b/sshconnect.c
index 0ee7266..9e98346 100644
--- a/sshconnect.c
+++ b/sshconnect.c
@@ -1014,12 +1014,12 @@ check_host_key(char *hostname, struct sockaddr *hostaddr, u_short port,
 			options.forward_x11 = 0;
 			cancelled_forwarding = 1;
 		}
-		if (options.num_local_forwards > 0 ||
-		    options.num_remote_forwards > 0) {
+		if (options.num_forwards > 0) {
 			error("Port forwarding is disabled to avoid "
 			    "man-in-the-middle attacks.");
-			options.num_local_forwards =
-			    options.num_remote_forwards = 0;
+			options.num_forwards = 0;
+			xfree(options.forwards);
+			options.forwards = NULL;
 			cancelled_forwarding = 1;
 		}
 		if (options.tun_open != SSH_TUNMODE_NO) {
-- 
1.7.9.rc0.542.g07ca1


From alex at alex.org.uk  Thu May  3 22:35:39 2012
From: alex at alex.org.uk (Alex Bligh)
Date: Thu, 03 May 2012 13:35:39 +0100
Subject: [PATCH/RFC 0/6] New mux client request to list open tcp
 forwardings.
In-Reply-To: <cover.1336043194.git.bert.wesarg@googlemail.com>
References: <cover.1336043194.git.bert.wesarg@googlemail.com>
Message-ID: <734A08E33E57C6F6F0C48342@Ximines.local>



--On 3 May 2012 13:33:46 +0200 Bert Wesarg <bert.wesarg at googlemail.com> 
wrote:

> These patches implement a new mux client request to list the currently
> opened TCP forwardings. It also removes some todos regarding keeping the
> list of forwardings in the options up-to-date.

Interesting.

I have a related application where a process on the /server/ wants to
know the list of port forwardings. In essence I have a large number of
clients all connecting using public key, and all forwarding one of
their local ports with -R, and dynamically allocating a listen port
on the server side. The server needs to establish (without being able
to trust the client) which port an ssh session with a given public
key is listening on. Currently I do this by a combination of
forcing a command on the server side, and some nasty hackery with lsof
type things. It would be useful if there were something that could
be queried on the server to definitively establish which forwarded
port was what, particularly as my method does not work with more
than one forwarded port (hence fails with autossh).

-- 
Alex Bligh

From bowman at math.utah.edu  Fri May  4 00:47:03 2012
From: bowman at math.utah.edu (Pieter Bowman)
Date: Thu, 3 May 2012 08:47:03 -0600 (MDT)
Subject: Portablility patch for openssh 6.0p1 configure.ac
Message-ID: <CMM.0.94.0.1336056423.bowman@tortola.math.utah.edu>

The following patch corrects a portablility issue when compiling
openssh 6.0p1 on MirOS (aka. mirbsd).  The issue is:

sftp-server.c: In function `send_statvfs':
sftp-server.c:510: error: request for member `val' in something not a structure or union
sftp-server.c:510: error: request for member `val' in something not a structure or union

The patch is:

--- configure.ac.orig	2012-04-19 05:46:38.000000000 -0600
+++ configure.ac	2012-05-03 08:25:49.429260884 -0600
@@ -3236,6 +3236,7 @@
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/param.h>
 #ifdef HAVE_SYS_TIME_H
 # include <sys/time.h>
 #endif


Thanks,

Pieter

From des at des.no  Fri May  4 03:17:09 2012
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Thu, 03 May 2012 19:17:09 +0200
Subject: Portablility patch for openssh 6.0p1 configure.ac
In-Reply-To: <CMM.0.94.0.1336056423.bowman@tortola.math.utah.edu> (Pieter
 Bowman's message of "Thu, 3 May 2012 08:47:03 -0600 (MDT)")
References: <CMM.0.94.0.1336056423.bowman@tortola.math.utah.edu>
Message-ID: <86vckddw16.fsf@ds4.des.no>

Pieter Bowman <bowman at math.utah.edu> writes:
> --- configure.ac.orig	2012-04-19 05:46:38.000000000 -0600
> +++ configure.ac	2012-05-03 08:25:49.429260884 -0600
> @@ -3236,6 +3236,7 @@
>  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
>  #include <sys/types.h>
>  #include <sys/stat.h>
> +#include <sys/param.h>
>  #ifdef HAVE_SYS_TIME_H
>  # include <sys/time.h>
>  #endif

<sys/param.h> includes <sys/types.h> and should always be included
before any other headers.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From bowman at math.utah.edu  Fri May  4 04:08:35 2012
From: bowman at math.utah.edu (Pieter Bowman)
Date: Thu, 3 May 2012 12:08:35 -0600 (MDT)
Subject: Portablility patch for openssh 6.0p1 configure.ac
In-Reply-To: Your message of Thu, 03 May 2012 19:17:09 +0200
Message-ID: <CMM.0.94.0.1336068515.bowman@tortola.math.utah.edu>


>> ...
>> Pieter Bowman <bowman at math.utah.edu> writes:
>> > --- configure.ac.orig	2012-04-19 05:46:38.000000000 -0600
>> > +++ configure.ac	2012-05-03 08:25:49.429260884 -0600
>> > @@ -3236,6 +3236,7 @@
>> >  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
>> >  #include <sys/types.h>
>> >  #include <sys/stat.h>
>> > +#include <sys/param.h>
>> >  #ifdef HAVE_SYS_TIME_H
>> >  # include <sys/time.h>
>> >  #endif
>> 
>> <sys/param.h> includes <sys/types.h> and should always be included
>> before any other headers.
>> ...

You are probably correct.  However, after examining the full source of
OpenSSH, I find that in most cases <sys/types.h> precedes
<sys/param.h>.  I could generate patches to "fix" all instances, but
that might be better for one of the OpenSSH developers to handle.

Pieter

From dtucker at zip.com.au  Fri May  4 11:11:14 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 4 May 2012 11:11:14 +1000
Subject: Portablility patch for openssh 6.0p1 configure.ac
In-Reply-To: <86vckddw16.fsf@ds4.des.no>
References: <CMM.0.94.0.1336056423.bowman@tortola.math.utah.edu>
 <86vckddw16.fsf@ds4.des.no>
Message-ID: <20120504011114.GA24181@gate.dtucker.net>

On Thu, May 03, 2012 at 07:17:09PM +0200, Dag-Erling Sm?rgrav wrote:
> Pieter Bowman <bowman at math.utah.edu> writes:
> > --- configure.ac.orig	2012-04-19 05:46:38.000000000 -0600
> > +++ configure.ac	2012-05-03 08:25:49.429260884 -0600
> > @@ -3236,6 +3236,7 @@
> >  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
> >  #include <sys/types.h>
> >  #include <sys/stat.h>
> > +#include <sys/param.h>
> >  #ifdef HAVE_SYS_TIME_H
> >  # include <sys/time.h>
> >  #endif
> 
> <sys/param.h> includes <sys/types.h> and should always be included
> before any other headers.

Indeed, the OpenBSD style guide says to include only one of these two as
the first include.  That said, doing includes portably is a massive
headache, so actually doing this in all the source files is likely to
break something somewhere.

Anyway, I've committed a change of sys/types.h to sys/params.h for just
this test (similar to a couple of other tests in configure) which should
resolve the problem.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From gan32n at yahoo.com  Fri May  4 17:47:59 2012
From: gan32n at yahoo.com (Niculescu Gabriel)
Date: Fri, 4 May 2012 00:47:59 -0700 (PDT)
Subject: LOTURI DE CASA (500mp) CU VEDERE LA MARE,
 (in rate de 200E / Luna) LANGA PLAJA CORBU / PRET - incepand de la
 5500
Message-ID: <1336117679.84030.yext-apple-iphone@web45715.mail.sp1.yahoo.com>

Niculescu Gabriel Anton

Sent from my iPhone

From rudupa at easylink.com  Tue May  8 05:32:39 2012
From: rudupa at easylink.com (Raghu Udupa)
Date: Mon, 7 May 2012 19:32:39 +0000
Subject: Can not capture internal-sftp process log in syslog
Message-ID: <10F20BC0C13B3F4C928EFD1C3A651F36310E76@PSEXMBX01.netmaster.corp.easylink.com>

Hi,

I am trying to use internal-sftp to limit sftp only access to a set of users.

I have set sshd_config as follows 
sshd_config
===========
Subsystem sftp internal-sftp -f LOCAL0 -l VERBOSE 
Match group ftp
 ChrootDirectory /sftp/%u
 X11Forwarding no
 AllowTcpForwarding no
 ForceCommand internal-sftp -f LOCAL0 -l VERBOSE
Match

I am able to access internal-sftp and run sftp sessions properly.

But, I am not able to capture the loggings written by internal-sftp process.

My syslog config settings are
/etc/syslog/syslog
==================
SYSLOGD_OPTIONS="-m 0 -a /sftp/sftp.log.socket"

syslog.conf
===========
In addition, syslog.conf has
local7.debug                                            /var/log/sftp.log
# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

I am running RedHad 6 (2.6.9) in VM environment and I am using openssh 5.9

I need help in capturing internal-sftp process log in syslogs.

Thanks,
Raghu

From dtucker at zip.com.au  Tue May  8 13:15:34 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 8 May 2012 13:15:34 +1000
Subject: Can not capture internal-sftp process log in syslog
In-Reply-To: <10F20BC0C13B3F4C928EFD1C3A651F36310E76@PSEXMBX01.netmaster.corp.easylink.com>
References: <10F20BC0C13B3F4C928EFD1C3A651F36310E76@PSEXMBX01.netmaster.corp.easylink.com>
Message-ID: <20120508031534.GA1173@gate.dtucker.net>

On Mon, May 07, 2012 at 07:32:39PM +0000, Raghu Udupa wrote:
> I am trying to use internal-sftp to limit sftp only access to a set of users.
[...]
> SYSLOGD_OPTIONS="-m 0 -a /sftp/sftp.log.socket"

the code in syslog(3) is probably trying to open /dev/log within the
chroot.  Try -a /sftp/dev/log, and if that fails try strace'ing the sshd
process to see where it's looking.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From Lars.Nordin at SDlabs.se  Tue May  8 17:10:33 2012
From: Lars.Nordin at SDlabs.se (Lars Nordin)
Date: Tue, 08 May 2012 09:10:33 +0200
Subject: Converting a public PEM-file to OpenSSH public file format
Message-ID: <4FA8C6E9.4010608@SDlabs.se>

Hi,

I have made a new option i ssh-keygen, to read a public key in 
PEM-format and write a public key in openSSH-format. This file can be 
used to make the authorized_keys file.

I needed this function because I made an openssh-client where the 
private key in a smartcard and therefore not available for ssh-keygen to 
make the public file..

I can make a patch for this if anyone is interested!

/Lars

From Kun_Carol.Chen at alcatel-lucent.com  Tue May  8 18:41:57 2012
From: Kun_Carol.Chen at alcatel-lucent.com (CHEN Kun carol)
Date: Tue, 8 May 2012 08:41:57 +0000
Subject: About bug 640857
Message-ID: <0FE95886A282D546BBFE17F4208222ED0E44F636@CNSHJMBX03.ad4.ad.alcatel.com>

Hi, Dear OpenSSH support,

I'm writing to ask whether this bug is fixed in your openSSH 6.0. If no, do you have any plan?
https://bugzilla.redhat.com/show_bug.cgi?id=640857

Regards,
Carol


From dtucker at zip.com.au  Tue May  8 21:10:46 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 8 May 2012 21:10:46 +1000
Subject: About bug 640857
In-Reply-To: <0FE95886A282D546BBFE17F4208222ED0E44F636@CNSHJMBX03.ad4.ad.alcatel.com>
References: <0FE95886A282D546BBFE17F4208222ED0E44F636@CNSHJMBX03.ad4.ad.alcatel.com>
Message-ID: <20120508111046.GA13382@gate.dtucker.net>

On Tue, May 08, 2012 at 08:41:57AM +0000, CHEN Kun carol wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=640857
> I'm writing to ask whether this bug is fixed in your openSSH 6.0.

Yes, it was fixed a while ago and is in 6.0p1.

---------------------
PatchSet 6063 
Date: 2009/11/18 17:48:30
Author: djm
Branch: HEAD
Tag: (none) 
Branches: 
Log:
 - (djm) [channels.c misc.c misc.h sshd.c] add missing setsockopt() to
   set IPV6_V6ONLY for local forwarding with GatwayPorts=yes. Unify
   setting IPV6_V6ONLY behind a new function misc.c:sock_set_v6only()
   report and fix from jan.kratochvil AT redhat.com

Members: 
	ChangeLog:1.5320->1.5321 
	channels.c:1.285->1.286 
	misc.c:1.89->1.90 
	misc.h:1.41->1.42 
	sshd.c:1.386->1.387 

Index: openssh/ChangeLog
diff -u openssh/ChangeLog:1.5320 openssh/ChangeLog:1.5321
--- openssh/ChangeLog:1.5320	Sat Nov  7 16:03:14 2009
+++ openssh/ChangeLog	Wed Nov 18 17:48:30 2009
@@ -1,4 +1,10 @@
 20091107
+ - (djm) [channels.c misc.c misc.h sshd.c] add missing setsockopt() to
+   set IPV6_V6ONLY for local forwarding with GatwayPorts=yes. Unify
+   setting IPV6_V6ONLY behind a new function misc.c:sock_set_v6only()
+   report and fix from jan.kratochvil AT redhat.com
+
+20091107
  - (dtucker) [authfile.c] Fall back to 3DES for the encryption of private
     keys when built with OpenSSL versions that don't do AES.
 
Index: openssh/channels.c
diff -u openssh/channels.c:1.285 openssh/channels.c:1.286
--- openssh/channels.c:1.285	Fri Aug 28 11:02:37 2009
+++ openssh/channels.c	Wed Nov 18 17:48:30 2009
@@ -2577,6 +2577,8 @@
 		}
 
 		channel_set_reuseaddr(sock);
+		if (ai->ai_family == AF_INET6)
+			sock_set_v6only(sock);
 
 		debug("Local forwarding listening on %s port %s.",
 		    ntop, strport);
@@ -3108,13 +3110,8 @@
 					continue;
 				}
 			}
-#ifdef IPV6_V6ONLY
-			if (ai->ai_family == AF_INET6) {
-				int on = 1;
-				if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, &on, sizeof(on)) < 0)
-					error("setsockopt IPV6_V6ONLY: %.100s", strerror(errno));
-			}
-#endif
+			if (ai->ai_family == AF_INET6)
+				sock_set_v6only(sock);
 			if (x11_use_localhost)
 				channel_set_reuseaddr(sock);
 			if (bind(sock, ai->ai_addr, ai->ai_addrlen) < 0) {
Index: openssh/misc.c
diff -u openssh/misc.c:1.89 openssh/misc.c:1.90
--- openssh/misc.c:1.89	Sun Feb 22 08:47:02 2009
+++ openssh/misc.c	Wed Nov 18 17:48:30 2009
@@ -849,3 +849,14 @@
 	tv->tv_usec = (ms % 1000) * 1000;
 }
 
+void
+sock_set_v6only(int s)
+{
+#ifdef IPV6_V6ONLY
+	int on = 1;
+
+	debug3("%s: set socket %d IPV6_V6ONLY", __func__, s);
+	if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, &on, sizeof(on)) == -1)
+		error("setsockopt IPV6_V6ONLY: %s", strerror(errno));
+#endif
+}
Index: openssh/misc.h
diff -u openssh/misc.h:1.41 openssh/misc.h:1.42
--- openssh/misc.h:1.41	Fri Jun 13 06:42:45 2008
+++ openssh/misc.h	Wed Nov 18 17:48:30 2009
@@ -35,6 +35,7 @@
 void	 sanitise_stdfd(void);
 void	 ms_subtract_diff(struct timeval *, int *);
 void	 ms_to_timeval(struct timeval *, int);
+void	 sock_set_v6only(int);
 
 struct passwd *pwcopy(struct passwd *);
 const char *ssh_gai_strerror(int);
Index: openssh/sshd.c
diff -u openssh/sshd.c:1.386 openssh/sshd.c:1.387
--- openssh/sshd.c:1.386	Sun Jun 21 20:26:17 2009
+++ openssh/sshd.c	Wed Nov 18 17:48:30 2009
@@ -979,15 +979,9 @@
 		    &on, sizeof(on)) == -1)
 			error("setsockopt SO_REUSEADDR: %s", strerror(errno));
 
-#ifdef IPV6_V6ONLY
 		/* Only communicate in IPv6 over AF_INET6 sockets. */
-		if (ai->ai_family == AF_INET6) {
-			if (setsockopt(listen_sock, IPPROTO_IPV6, IPV6_V6ONLY,
-			    &on, sizeof(on)) == -1)
-				error("setsockopt IPV6_V6ONLY: %s",
-				    strerror(errno));
-		}
-#endif
+		if (ai->ai_family == AF_INET6)
+			sock_set_v6only(listen_sock);
 
 		debug("Bind to port %s on %s.", strport, ntop);
 

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From mohsen6648 at yahoo.com  Tue May  8 23:09:07 2012
From: mohsen6648 at yahoo.com (Mohsen Saberi)
Date: Tue, 8 May 2012 06:09:07 -0700 (PDT)
Subject: No subject
Message-ID: <1336482547.69639.YahooMailClassic@web120704.mail.ne1.yahoo.com>



From peter at stuge.se  Wed May  9 01:18:24 2012
From: peter at stuge.se (Peter Stuge)
Date: Tue, 8 May 2012 17:18:24 +0200
Subject: Converting a public PEM-file to OpenSSH public file format
In-Reply-To: <4FA8C6E9.4010608@SDlabs.se>
References: <4FA8C6E9.4010608@SDlabs.se>
Message-ID: <20120508151824.9788.qmail@stuge.se>

Lars Nordin wrote:
> I have made a new option i ssh-keygen, to read a public key in PEM-format 
> and write a public key in openSSH-format. This file can be used to make the 
> authorized_keys file.
>
> I needed this function because I made an openssh-client where the private 
> key in a smartcard and therefore not available for ssh-keygen to make the 
> public file..

You made an openssh-client? Hm. There is already PKCS#11 support on
the client side, and possibly ssh-keygen can already read the public
key from a card that way, and output OpenSSH format. Did you try
this approach?


> I can make a patch for this if anyone is interested!

I'm interested at least. Let's see it!


//Peter

From rudupa at easylink.com  Wed May  9 06:15:03 2012
From: rudupa at easylink.com (Raghu Udupa)
Date: Tue, 8 May 2012 20:15:03 +0000
Subject: Can not capture internal-sftp process log in syslog
In-Reply-To: <20120508031534.GA1173@gate.dtucker.net>
References: <10F20BC0C13B3F4C928EFD1C3A651F36310E76@PSEXMBX01.netmaster.corp.easylink.com>
 <20120508031534.GA1173@gate.dtucker.net>
Message-ID: <10F20BC0C13B3F4C928EFD1C3A651F36311472@PSEXMBX01.netmaster.corp.easylink.com>

Thanks Darren.

I captured the strace. I am getting the error "Too many levels of symbolic links" while trying to connect to /dev/log

connect(7, {sa_family=AF_FILE, path="/dev/log"}, 16) = -1 ELOOP (Too many levels of symbolic links)
close(7)                                = 0

my chrooted dir is /sftp/sftptest
/dev/log is linked to /sftp/sftptest/dev/log

Here is the detailed strace

close(5) = 0
getuid32()              = 0
setgid32(50) = 0
open("/proc/sys/kernel/ngroups_max", O_RDONLY) = 5
read(5, "65536\n", 31)                  = 6
close(5)                                = 0
open("/etc/group", O_RDONLY)            = 5
fcntl64(5, F_GETFD)                     = 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
fstat64(5, {st_mode=S_IFREG|0644, st_size=670, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f29000
_llseek(5, 0, [0], SEEK_CUR)            = 0
read(5, "root:x:0:root\nbin:x:1:root,bin,d"..., 4096) = 670
read(5, "", 4096)                       = 0
close(5)                                = 0
munmap(0xb7f29000, 4096)                = 0
setgroups32(1, [50])                    = 0
stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/sftp/", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat64("/sftp/sftptest", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
chdir("/sftp/sftptest")                 = 0
chroot("/sftp/sftptest")                = 0
chdir("/")                              = 0
time(NULL)                              = 1336507416
stat64("/etc/localtime", 0xbfef6420)    = -1 ENOENT (No such file or directory)
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
open("/etc/localtime", O_RDONLY)        = -1 ENOENT (No such file or directory)
socket(PF_FILE, SOCK_DGRAM, 0)          = 5
fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
connect(5, {sa_family=AF_FILE, path="/dev/log"}, 16) = -1 ELOOP (Too many levels of symbolic links)
close(5)                                = 0
getuid32()                              = 0
getgid32()                              = 50
time(NULL)                              = 1336507416

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: Monday, May 07, 2012 11:16 PM
To: Raghu Udupa
Cc: 'openssh-unix-dev at mindrot.org'
Subject: Re: Can not capture internal-sftp process log in syslog

On Mon, May 07, 2012 at 07:32:39PM +0000, Raghu Udupa wrote:
> I am trying to use internal-sftp to limit sftp only access to a set of users.
[...]
> SYSLOGD_OPTIONS="-m 0 -a /sftp/sftp.log.socket"

the code in syslog(3) is probably trying to open /dev/log within the
chroot.  Try -a /sftp/dev/log, and if that fails try strace'ing the sshd
process to see where it's looking.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From keisial at gmail.com  Wed May  9 07:38:00 2012
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Tue, 08 May 2012 23:38:00 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
Message-ID: <4FA99238.9090004@gmail.com>

On 30/04/12 20:49, Dotan Cohen wrote:
> On Mon, Apr 30, 2012 at 18:39, Dag-Erling Sm?rgrav <des at des.no> wrote:
>> man ssh_config, search for ControlMaster.
> Thank you Dag!
>
> The ControlMaster option allows for the reuse of a session, but does
> not provide any nice "cpLocal" command for easily moving files from
> the remote machine to local (or vice versa).
If you have a master connection, you can open another terminal in local
and do a sftp/rsync from that, which would go through that connection.


> Rereading my original post, I see that I did not explicitly state that
> such an easy command was my goal. I often SSH into different machines
> and many of those I cannot modify with aliases and such. However, a
> facility for easily transferring files from / to these machines would
> be very nice.
How do you expect such command to work?
You could reconfigure your current connection adding a tunnel, and then
use that for transfering the files, but you'd still need a local daemon
(eg. ftpd) where to drop them.



From keisial at gmail.com  Wed May  9 07:46:06 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Tue, 08 May 2012 23:46:06 +0200
Subject: Can not capture internal-sftp process log in syslog
In-Reply-To: <10F20BC0C13B3F4C928EFD1C3A651F36311472@PSEXMBX01.netmaster.corp.easylink.com>
References: <10F20BC0C13B3F4C928EFD1C3A651F36310E76@PSEXMBX01.netmaster.corp.easylink.com>
 <20120508031534.GA1173@gate.dtucker.net>
 <10F20BC0C13B3F4C928EFD1C3A651F36311472@PSEXMBX01.netmaster.corp.easylink.com>
Message-ID: <4FA9941E.6070602@gmail.com>

On 08/05/12 22:15, Raghu Udupa wrote:
> Thanks Darren.
>
> I captured the strace. I am getting the error "Too many levels of symbolic links" while trying to connect to /dev/log
>
> connect(7, {sa_family=AF_FILE, path="/dev/log"}, 16) = -1 ELOOP (Too many levels of symbolic links)
> close(7)                                = 0
>
> my chrooted dir is /sftp/sftptest
> /dev/log is linked to /sftp/sftptest/dev/log
I think /dev/log is not linked to /sftp/sftptest/dev/log, but
/sftp/sftptest/dev/log points to /dev/log

Obviously, once you're in the /sftp/sftptest chroot,the /dev/log seen
from the inside is the same as the outside /sftp/sftptest/dev/log.
In other words, it has become a symlink to itself (thus it fails with
ELOOP).

You should either make them hard links (but you should probably recreate
them on each reboot), instruct syslogd to also listen on the chroot
/dev/log, or mount --bind the two /dev/log


From peter at stuge.se  Wed May  9 08:10:33 2012
From: peter at stuge.se (Peter Stuge)
Date: Wed, 9 May 2012 00:10:33 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
Message-ID: <20120508221033.10785.qmail@stuge.se>

Dotan Cohen wrote:
> The ControlMaster option allows for the reuse of a session, but does
> not provide any nice "cpLocal" command for easily moving files from
> the remote machine to local (or vice versa).

It allows sftp on your local machine to reuse a session to a remote
machine.


But in the other direction things are a lot more complicated:

1. Your local machine runs an SSH client.
2. Your remote machine runs the SSH server.

The SSH protocol allows the SSH server to spontaneously open a
channel back to the SSH client, so cpLocal could somehow signal
the SSH server to open such a channel, but the problem is that your
SSH client has no idea what to do with this new channel.

The SFTP protocol is well-specified, but it is only specified in the
context of an SSH client requesting an SSH server to start the sftp
subsystem in a channel which the client just opened.

While it is legal in the SSH protocol for the SSH server to try to
open an sftp channel to the SSH client, the SSH client does not
really know how to accomodate this wish. I think you agree that it
is also undesirable from a security point of view.


I'll reply with a counter-question:

How would you like the user-interface on the client side to work for
the cpLocal feature?


//Peter

From peter at stuge.se  Wed May  9 08:15:30 2012
From: peter at stuge.se (Peter Stuge)
Date: Wed, 9 May 2012 00:15:30 +0200
Subject: Can not capture internal-sftp process log in syslog
In-Reply-To: <10F20BC0C13B3F4C928EFD1C3A651F36311472@PSEXMBX01.netmaster.corp.easylink.com>
References: <10F20BC0C13B3F4C928EFD1C3A651F36310E76@PSEXMBX01.netmaster.corp.easylink.com>
 <20120508031534.GA1173@gate.dtucker.net>
 <10F20BC0C13B3F4C928EFD1C3A651F36311472@PSEXMBX01.netmaster.corp.easylink.com>
Message-ID: <20120508221530.11334.qmail@stuge.se>

Raghu Udupa wrote:
> my chrooted dir is /sftp/sftptest
> /dev/log is linked to /sftp/sftptest/dev/log

Do it the other way around.

Make syslogd listen on a real socket at /sftp/sftptest/dev/log

Symlink /dev/log (outside the chroot) to /sftp/sftptest/dev/log

Or, make syslogd listen to both sockets, if yours can.


//Peter

From lfilipoz at emyr.net  Wed May  9 14:20:33 2012
From: lfilipoz at emyr.net (Luca Filipozzi)
Date: Wed, 9 May 2012 04:20:33 +0000
Subject: feature request: modify getrrsetbyname() to use libunbound
Message-ID: <20120509042033.GB14446@emyr.net>

Dear OpenSSH Developers,

I'm a member of the Debian System Administration (DSA) team. [1]  We
manage the Debian Projects computing infrastructure.

Recently, DSA had the opportunity to address a member's request that we
begin using certificates to authenticate Debian Project machines to ssh
clients.  We provided a lengthy reply, the summary of which is "we
publish SSHFP records; use VerifyHostKeyDNS; set up a local caching
resolver to avoid MITM attacks".

That said, it seems rather cumbersome to have users install a local
caching resolver in order to secure the last mile of DNS queries (who
trusts their ISP, after all), so we postulated whether it would be
possible to modify openssh such that the ssh client could perform the
queries itself.

It turns out that this is quite straightforward to implement (see
preliminary patch, attached), entirely because you have have well
encapsulated the DNS query code.

Since we are quite concerned that our project members (let alone our
general user population) aren't managing their known_hosts in a secure
or timely manner, we are keen on using SSHFP records .. but only if the
DNSSEC last mile issue can be addressed in a relatively easy way for
users.

We propose that openssh be modified as follows:

(1) introduce a new ssh_config directive: UnboundConfigurationFile

(2) modify getrrsetbyname() such that, if UnboundConfigurationFile is
set, then the unbound resolver is used; if not, then libc

(3) provide a default unbound configuration in /etc/ssh/ssh_unbound_conf

In this way, the standard mode of operation for ssh remains unchanged by
default.  Users who would like to use SSHFP records in a secure manner
would set the configuration directive.

Please find attached a preliminary patch that modifies getrrsetbyname()
to use libunbound rather than libc.

We have proposed [2] this modification to the Debian openssh package
maintainers.  Knowing that they (and we, too, frankly) would prefer the
modification to be adopted by upstream, I've subscribed to the
openssh-unix-dev list to begin the discussion (I've carbon copied my DSA
colleagues and the openssh package maintainers so that they are aware).

If there is interest in this proposal, I would be pleased to work with
you to complete the patch.  (In the meantime, I'm using openssh patched
with libunbound on my macbook since OS/X's libc doesn't support DNSSEC.)

Thanks for your consideration,

Luca Filipozzi

[1] http://www.debian.org/intro/organization
[2] http://lists.debian.org/debian-ssh/2012/05/msg00004.html

-- 
Luca Filipozzi
Member, Debian System Administration Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh.diff
Type: text/x-diff
Size: 2654 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120509/689f068e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120509/689f068e/attachment-0001.bin>

From peter at stuge.se  Wed May  9 16:08:47 2012
From: peter at stuge.se (Peter Stuge)
Date: Wed, 9 May 2012 08:08:47 +0200
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120509042033.GB14446@emyr.net>
References: <20120509042033.GB14446@emyr.net>
Message-ID: <20120509060847.14556.qmail@stuge.se>

Luca Filipozzi wrote:
> We propose that openssh be modified as follows:
> 
> (1) introduce a new ssh_config directive: UnboundConfigurationFile

I don't think any SSH configuration directives should be tied to a
specific implementation of anything outside the SSH domain.


> (3) provide a default unbound configuration in /etc/ssh/ssh_unbound_conf

What needs to be set in that config? I think adding DNSSEC-related
directives to ssh_config and perhaps also sshd_config would be more
in line with the rest of the configuration directives.

Hopefully configuration can be given also programatically to
libunbound, so that OpenSSH could use the same configuration
directives regardless of which resolver library is used.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120509/9d614818/attachment.bin>

From dtucker at zip.com.au  Wed May  9 16:41:32 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 9 May 2012 16:41:32 +1000
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120509042033.GB14446@emyr.net>
References: <20120509042033.GB14446@emyr.net>
Message-ID: <20120509064132.GA4613@gate.dtucker.net>

On Wed, May 09, 2012 at 04:20:33AM +0000, Luca Filipozzi wrote:
[...]
> We propose that openssh be modified as follows:
>
> (1) introduce a new ssh_config directive: UnboundConfigurationFile
> 
> (2) modify getrrsetbyname() such that, if UnboundConfigurationFile is
> set, then the unbound resolver is used; if not, then libc
> 
> (3) provide a default unbound configuration in /etc/ssh/ssh_unbound_conf

OK, here's my opinion:
 - I am OK with adding support for libunbound (we already have
   compile-time support for an alternate resolver, ldns), however
 - I am oposed to a new configuration file option because
   Portable-specific options increase the maintenance burden in both
   directions.

But first: why doesn't the system resolver support dnssec?  Wouldn't the
effort be better spent fixing that instead?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From lfilipoz at emyr.net  Wed May  9 17:00:33 2012
From: lfilipoz at emyr.net (Luca Filipozzi)
Date: Wed, 9 May 2012 07:00:33 +0000
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120509060847.14556.qmail@stuge.se>
References: <20120509042033.GB14446@emyr.net>
 <20120509060847.14556.qmail@stuge.se>
Message-ID: <20120509070031.GA20141@emyr.net>

On Wed, May 09, 2012 at 08:08:47AM +0200, Peter Stuge wrote:
> Luca Filipozzi wrote:
> > We propose that openssh be modified as follows:
> > 
> > (1) introduce a new ssh_config directive: UnboundConfigurationFile
> 
> I don't think any SSH configuration directives should be tied to a
> specific implementation of anything outside the SSH domain.

Fair enough.  I'm more interested in achieving good DNSSEC behaviour
than I am in introducing unbound-specific configuration directives.

> > (3) provide a default unbound configuration in /etc/ssh/ssh_unbound_conf
> 
> What needs to be set in that config? I think adding DNSSEC-related
> directives to ssh_config and perhaps also sshd_config would be more
> in line with the rest of the configuration directives.

The patch that I attached uses ub_ctx_config(<filename>), which laods
an unbound-specific configuration.  It was an attempt to limit the
number of ssh_config directives that might be needed.

I expect that we will need at least two directives:

(1) something that specifies the root anchor to prime DNSSEC

      DNSSECRootAnchorFile <filename>

    and/or

      DNSSECRootAnchor <string>

(2) something that sets edns0 buffer size to deal with broken networks

      ExtendedDNSBufferSize <string>
  
Both of these are DNSSEC-general rather than unbound-specific.

> Hopefully configuration can be given also programatically to
> libunbound, so that OpenSSH could use the same configuration
> directives regardless of which resolver library is used.

Absolutely.

We can use ub_ctx_add_ta(<string>) or ub_ctx_add_file(<filename>) for
the first one.

We can use ub_ctx_set_option("edns_buffer_size", <string>) for the
second.

I'm happy to move in this direction.

-- 
Luca Filipozzi

From ondrej at caletka.cz  Wed May  9 17:50:22 2012
From: ondrej at caletka.cz (=?UTF-8?B?T25kxZllaiBDYWxldGth?=)
Date: Wed, 09 May 2012 09:50:22 +0200
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120509042033.GB14446@emyr.net>
References: <20120509042033.GB14446@emyr.net>
Message-ID: <4FAA21BE.9000106@gmail.com>

Dne 9.5.2012 06:20, Luca Filipozzi napsal(a):
> That said, it seems rather cumbersome to have users install a local
> caching resolver in order to secure the last mile of DNS queries (who
> trusts their ISP, after all), so we postulated whether it would be
> possible to modify openssh such that the ssh client could perform the
> queries itself.

Wouldn't it be done by just adding trust anchor to current ldns
resolving code? It looks like there is already some kind of autonomous
validation attempt in getrrsetbyname-ldns.c:

       /* Check for authenticated data */
        if (ldns_pkt_ad(pkt)) {
                rrset->rri_flags |= RRSET_VALIDATED;
        } else { /* AD is not set, try autonomous validation */
                ldns_rr_list * trusted_keys = ldns_rr_list_new();


Regards,
Ond?ej Caletka

From lfilipoz at emyr.net  Wed May  9 18:49:11 2012
From: lfilipoz at emyr.net (Luca Filipozzi)
Date: Wed, 9 May 2012 08:49:11 +0000
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120509064132.GA4613@gate.dtucker.net>
References: <20120509042033.GB14446@emyr.net>
 <20120509064132.GA4613@gate.dtucker.net>
Message-ID: <20120509084911.GB20141@emyr.net>

On Wed, May 09, 2012 at 04:41:32PM +1000, Darren Tucker wrote:
> OK, here's my opinion:
>  - I am OK with adding support for libunbound (we already have
>    compile-time support for an alternate resolver, ldns), however

*blush*  Should have looked at 6.0 release notes.  I'm going to give 6.0
a try now.

>  - I am oposed to a new configuration file option because
>    Portable-specific options increase the maintenance burden in both
>    directions.

See other response but may be moot given 6.0 + ldns.

> But first: why doesn't the system resolver support dnssec?  Wouldn't the
> effort be better spent fixing that instead?

Certainly.  However, there can be a lengthy delay in accomplishing this
for certain operating systems.  Again, may be moot given 6.0 + ldns.

-- 
Luca Filipozzi

From lfilipoz at emyr.net  Wed May  9 19:30:41 2012
From: lfilipoz at emyr.net (Luca Filipozzi)
Date: Wed, 9 May 2012 09:30:41 +0000
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <4FAA21BE.9000106@gmail.com>
References: <20120509042033.GB14446@emyr.net>
 <4FAA21BE.9000106@gmail.com>
Message-ID: <20120509093041.GA24146@emyr.net>

On Wed, May 09, 2012 at 09:50:22AM +0200, Ond??ej Caletka wrote:
> Dne 9.5.2012 06:20, Luca Filipozzi napsal(a):
> > That said, it seems rather cumbersome to have users install a local
> > caching resolver in order to secure the last mile of DNS queries (who
> > trusts their ISP, after all), so we postulated whether it would be
> > possible to modify openssh such that the ssh client could perform the
> > queries itself.
> 
> Wouldn't it be done by just adding trust anchor to current ldns
> resolving code?

It's sufficient to add "anchor /path/to/root.key" to /etc/resolv.conf.

Thanks very much for adding ldns support to 6.0.  I don't think we need
both libunbound (which links against libldns) and libldns.

-- 
Luca Filipozzi

From ondrej at caletka.cz  Wed May  9 20:44:13 2012
From: ondrej at caletka.cz (=?UTF-8?B?T25kxZllaiBDYWxldGth?=)
Date: Wed, 09 May 2012 12:44:13 +0200
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120509093041.GA24146@emyr.net>
References: <20120509042033.GB14446@emyr.net> <4FAA21BE.9000106@gmail.com>
 <20120509093041.GA24146@emyr.net>
Message-ID: <4FAA4A7D.7060002@gmail.com>

Dne 9.5.2012 11:30, Luca Filipozzi napsal(a):
> 
> It's sufficient to add "anchor /path/to/root.key" to /etc/resolv.conf.
Wow, thanks for pointing it out, I didn't know about this ldns feature.
Maybe there should be some note in the documentation.

There is only one pitfall. The autonomous validation is attempted only
if the DNS response does not contain the AD flag. Therefore if someone
changes the DNS response on the wire and leaves the AD flag set,
spurious data are trusted without further validating. This is not
secure, as link between computer and DNS resolver cannot be generally
trusted.

Regards,
Ond?ej Caletka

From rstory at tislabs.com  Wed May  9 22:50:21 2012
From: rstory at tislabs.com (Robert Story)
Date: Wed, 9 May 2012 08:50:21 -0400
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120509064132.GA4613@gate.dtucker.net>
References: <20120509042033.GB14446@emyr.net>
 <20120509064132.GA4613@gate.dtucker.net>
Message-ID: <20120509085021.58e20a6e@tp.vb.futz.org>

On Wed, 9 May 2012 16:41:32 +1000 Darren wrote:
DT> On Wed, May 09, 2012 at 04:20:33AM +0000, Luca Filipozzi wrote:
DT> [...]
DT> > We propose that openssh be modified as follows:
DT> >
DT> > (1) introduce a new ssh_config directive: UnboundConfigurationFile
DT> > 
DT> > (2) modify getrrsetbyname() such that, if UnboundConfigurationFile is
DT> > set, then the unbound resolver is used; if not, then libc
DT> > 
DT> > (3) provide a default unbound configuration
DT> > in /etc/ssh/ssh_unbound_conf
DT> 
DT> OK, here's my opinion:
DT>  - I am OK with adding support for libunbound (we already have
DT>    compile-time support for an alternate resolver, ldns), however

There is also a patch that I submitted back in 2009 to use libval from
DNSSEC-Tools to do local validation. Any chance of getting that accepted?
The last time I updated it was for 5.8, but I'd be glad to update it for
6.0 if there's a chance it will be accepted.

	https://bugzilla.mindrot.org/show_bug.cgi?id=1672

We also added a new option, AutoAnswerValidatedKeys, to (optionally)
automatically accept new keys which match a DNSSEC validated sshfp record.
And we always do the validation in the library, and do not ever trust the
AD bit from remote resolvers.


Robert

--
Senior Software Engineer
SPARTA, Inc., a Parsons Company
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120509/155a7baf/attachment.bin>

From rstory at tislabs.com  Wed May  9 22:59:53 2012
From: rstory at tislabs.com (Robert Story)
Date: Wed, 9 May 2012 08:59:53 -0400
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <4FAA4A7D.7060002@gmail.com>
References: <20120509042033.GB14446@emyr.net> <4FAA21BE.9000106@gmail.com>
 <20120509093041.GA24146@emyr.net> <4FAA4A7D.7060002@gmail.com>
Message-ID: <20120509085953.0477bace@tp.vb.futz.org>

On Wed, 09 May 2012 12:44:13 +0200 Ond?ej wrote:
OC> There is only one pitfall. The autonomous validation is attempted only
OC> if the DNS response does not contain the AD flag. Therefore if someone
OC> changes the DNS response on the wire and leaves the AD flag set,
OC> spurious data are trusted without further validating. This is not
OC> secure, as link between computer and DNS resolver cannot be generally
OC> trusted.  

Yes, which is why we prefer our DNSSEC-Tools libval patch, which always
does local validation and does not depend on the AD flag.

	https://bugzilla.mindrot.org/show_bug.cgi?id=1672

Robert

--
Senior Software Engineer
SPARTA, Inc., a Parsons Company
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120509/8e9433b0/attachment.bin>

From lfilipoz at emyr.net  Thu May 10 04:56:08 2012
From: lfilipoz at emyr.net (Luca Filipozzi)
Date: Wed, 9 May 2012 18:56:08 +0000
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120509085953.0477bace@tp.vb.futz.org>
References: <20120509042033.GB14446@emyr.net> <4FAA21BE.9000106@gmail.com>
 <20120509093041.GA24146@emyr.net> <4FAA4A7D.7060002@gmail.com>
 <20120509085953.0477bace@tp.vb.futz.org>
Message-ID: <20120509185608.GA27523@emyr.net>

On Wed, May 09, 2012 at 08:59:53AM -0400, Robert Story wrote:
> On Wed, 09 May 2012 12:44:13 +0200 Ond??ej wrote:
> > There is only one pitfall. The autonomous validation is attempted
> > only if the DNS response does not contain the AD flag. Therefore if
> > someone changes the DNS response on the wire and leaves the AD flag
> > set, spurious data are trusted without further validating.

Ondrej: Thanks for pointing this out.  (I had to dig through ldns source
to find the 'anchor' directive -- agree poorly documented feature.)

> > This is not secure, as link between computer and DNS resolver
> > cannot be generally trusted.  

This is the whole point of the unbound patch and our request.  I don't
want to trust the AD flag from an upstream resolver (like my ISP).  But I
also don't want to tell users to install a local resolver.

> Yes, which is why we prefer our DNSSEC-Tools libval patch, which always
> does local validation and does not depend on the AD flag.
> 
> 	https://bugzilla.mindrot.org/show_bug.cgi?id=1672

Robert, this is a very well written rationale for local DNSSEC
validation.  I agree with you: it is very important to have openssh
perform anchored DNSSEC validations and not trust the AD flag.

There seem to be three possible approaches (please correct me if I'm
wrong).  If the library-specific implementation is encapsulate in
getrrsetbyname(), we could support all three.

(1) modify the current ldns version of getrrsetbyname() to not trust the
AD flag and to perform anchored validations (possibly optionally based on
whether StrictDnssecChecking is set)

(2) make use of Robert's DNSSEC-Tools-based implementation; could the
DNSSEC-Tools-specific implementation be moved from verify_host_key_dns()
to getrrsetbyname()?

(3) make use of a libunbound-based implementation (which might not be
able to support StrictDnssecChecking=no); could be redundant given (1)
but allows for significant configuration... though one could argue "just
install unbound" if one needs that much tweaking

Is it too ugly to have the validation-enforcing implementations of
getrrsetbyname() function be aware of options->strict_dnssec_checking?

If the underlying tool makes use of a specific supplementary file
(/etc/resolv.conf or /etc/ssh/ssh_unbound_config), then we can allow for
external configuration without introducing additional configuration
directives in ssh_config).

I don't use OpenBSD but, in looking through it's source, it seems that
nothing in the getrrsetbyname() -> res_query() -> res_mkquery() chain
enforces anchored DNSSEC validation.  In other words, OpenBSD also
trusts the AD flag (please correct me if I'm mistaken).

I hope this means that openssh and openssh-portable would not need to be
too different as anchored DNSSEC validation might be of interest to the
OpenBSD community, also.

-- 
Luca Filipozzi
Member, Debian System Administration Team

From support at cainetworks.com  Thu May 10 07:21:07 2012
From: support at cainetworks.com (Support Team)
Date: Wed, 9 May 2012 14:21:07 -0700
Subject: warning from configuring openssh-6.0p1
Message-ID: <001101cd2e29$a92fee80$fb8fcb80$@cainetworks.com>

When running "configure" for openssh-6.0p1 , I got the following output from
"configure":


configure: WARNING: linux/filter.h: present but cannot be compiled
configure: WARNING: linux/filter.h:     check for missing prerequisite
headers?
configure: WARNING: linux/filter.h: see the Autoconf documentation
configure: WARNING: linux/filter.h:     section "Present But Cannot Be
Compiled"
configure: WARNING: linux/filter.h: proceeding with the compiler's result
configure: WARNING:     ## ------------------------------------------- ##
configure: WARNING:     ## Report this to openssh-unix-dev at mindrot.org ##
configure: WARNING:     ## ------------------------------------------- ##
checking for linux/filter.h... no

I can still successfully make and the "sshd" that is made appears to run
fine.

The build machine is a Red Hat 9 machine running  linux 2.4.20-8smp .  More
from
"config.log" ....


configure:6925: checking linux/filter.h usability
configure:6925: gcc -c -g -O2 -Wall -Wpointer-arith -Wuninitialized
-Wsign-compare -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2
-fno-builtin-memset -std=gnu99 -I /usr/src/ssl/openssl/include conftest.c
>&5
In file included from conftest.c:108:
/usr/include/linux/filter.h:21: error: parse error before "__u16"
/usr/include/linux/filter.h:23: error: parse error before "jf"
/usr/include/linux/filter.h:24: error: parse error before "k"
configure:6925: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenSSH"
| #define PACKAGE_TARNAME "openssh"
| #define PACKAGE_VERSION "Portable"
| #define PACKAGE_STRING "OpenSSH Portable"
| #define PACKAGE_BUGREPORT "openssh-unix-dev at mindrot.org"
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define _FILE_OFFSET_BITS 64
| #define LOGIN_PROGRAM_FALLBACK "/bin/login"
| #define _PATH_PASSWD_PROG "/usr/bin/passwd"
| #define HAVE_RLIMIT_NPROC /**/
| #define HAVE_ATTRIBUTE__NONNULL__ 1
| #define HAVE_CRYPT_H 1
| #define HAVE_DIRENT_H 1
| #define HAVE_ENDIAN_H 1
| #define HAVE_FEATURES_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_GETOPT_H 1
| #define HAVE_GLOB_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_NETDB_H 1
| #define HAVE_PATHS_H 1
| #define HAVE_POLL_H 1
| #define HAVE_PTY_H 1
| #define HAVE_RPC_TYPES_H 1
| #define HAVE_SECURITY_PAM_APPL_H 1
| #define HAVE_SHADOW_H 1
| #define HAVE_STDDEF_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_STRING_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_SYS_BITYPES_H 1
| #define HAVE_SYS_CDEFS_H 1
| #define HAVE_SYS_DIR_H 1
| #define HAVE_SYS_MMAN_H 1
| #define HAVE_SYS_POLL_H 1
| #define HAVE_SYS_PRCTL_H 1
| #define HAVE_SYS_SELECT_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_SYS_STROPTS_H 1
| #define HAVE_SYS_STATVFS_H 1
| #define HAVE_SYS_SYSMACROS_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_SYS_UN_H 1
| #define HAVE_TIME_H 1
| #define HAVE_TTYENT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_UTIME_H 1
| #define HAVE_UTMP_H 1
| #define HAVE_UTMPX_H 1
| #define HAVE_LASTLOG_H 1
| #define HAVE_SYS_MOUNT_H 1
| #define PAM_TTY_KLUDGE 1
| #define LOCKED_PASSWD_PREFIX "!"
| #define SPT_TYPE SPT_REUSEARGV
| #define LINK_OPNOTSUPP_ERRNO EPERM
| #define _PATH_BTMP "/var/log/btmp"
| #define USE_BTMP 1
| #define LINUX_OOM_ADJUST 1
| #define HAVE_LINUX_IF_TUN_H 1
| #define SSH_TUN_LINUX 1
| #define SSH_TUN_COMPAT_AF 1
| #define SSH_TUN_PREPEND_AF 1
| /* end confdefs.h.  */
| #include <stdio.h>
| #ifdef HAVE_SYS_TYPES_H
| # include <sys/types.h>
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include <sys/stat.h>
| #endif
| #ifdef STDC_HEADERS
| # include <stdlib.h>
| # include <stddef.h>
| #else
| # ifdef HAVE_STDLIB_H
| #  include <stdlib.h>
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| #  include <memory.h>
| # endif
| # include <string.h>
| #endif
| #ifdef HAVE_STRINGS_H
| # include <strings.h>
| #endif
| #ifdef HAVE_INTTYPES_H
| # include <inttypes.h>
| #endif
| #ifdef HAVE_STDINT_H
| # include <stdint.h>
| #endif
| #ifdef HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| #include <linux/filter.h>
configure:6925: result: no
configure:6925: checking linux/filter.h presence
configure:6925: gcc -E -I /usr/src/ssl/openssl/include conftest.c
configure:6925: $? = 0
configure:6925: result: yes
configure:6925: WARNING: linux/filter.h: present but cannot be compiled
configure:6925: WARNING: linux/filter.h:     check for missing prerequisite
headers?
configure:6925: WARNING: linux/filter.h: see the Autoconf documentation
configure:6925: WARNING: linux/filter.h:     section "Present But Cannot Be
Compiled"
configure:6925: WARNING: linux/filter.h: proceeding with the compiler's
result
configure:6925: checking for linux/filter.h
configure:6925: result: no
configure:6925: checking linux/audit.h usability


From rstory at tislabs.com  Thu May 10 08:11:00 2012
From: rstory at tislabs.com (Robert Story)
Date: Wed, 9 May 2012 18:11:00 -0400
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120509185608.GA27523@emyr.net>
References: <20120509042033.GB14446@emyr.net> <4FAA21BE.9000106@gmail.com>
 <20120509093041.GA24146@emyr.net> <4FAA4A7D.7060002@gmail.com>
 <20120509085953.0477bace@tp.vb.futz.org>
 <20120509185608.GA27523@emyr.net>
Message-ID: <20120509181100.551bdfae@tp.vb.futz.org>

On Wed, 9 May 2012 18:56:08 +0000 Luca wrote:
LF> > Yes, which is why we prefer our DNSSEC-Tools libval patch, which
LF> > always does local validation and does not depend on the AD flag.
LF> > 
LF> > 	https://bugzilla.mindrot.org/show_bug.cgi?id=1672  

I just updated the patch for 6.0p1, in case anyone is interested in trying
it.

LF> (2) make use of Robert's DNSSEC-Tools-based implementation; could the
LF> DNSSEC-Tools-specific implementation be moved from verify_host_key_dns()
LF> to getrrsetbyname()?  

We wanted to have the lowest impact possible, and only do DNSSEC for
verifying sshfp records. If upstream is willing to accept optional
validation of all records, we could do that too.



Robert

--
Senior Software Engineer
SPARTA, Inc., a Parsons Company

[signature.asc  application/pgp-signature (198 bytes)] 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120509/ef35fd5d/attachment.bin>

From lfilipoz at emyr.net  Fri May 11 05:35:23 2012
From: lfilipoz at emyr.net (Luca Filipozzi)
Date: Thu, 10 May 2012 19:35:23 +0000
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120509174137.680ec5f3@sparta.com>
References: <20120509042033.GB14446@emyr.net> <4FAA21BE.9000106@gmail.com>
 <20120509093041.GA24146@emyr.net> <4FAA4A7D.7060002@gmail.com>
 <20120509085953.0477bace@tp.vb.futz.org>
 <20120509185608.GA27523@emyr.net>
 <20120509174137.680ec5f3@sparta.com>
Message-ID: <20120510193523.GA21986@emyr.net>

On Wed, May 09, 2012 at 05:41:37PM -0400, Robert Story wrote:
> On Wed, 9 May 2012 18:56:08 +0000 Luca wrote:
> LF> > Yes, which is why we prefer our DNSSEC-Tools libval patch, which
> LF> > always does local validation and does not depend on the AD flag.
> LF> > 
> LF> > 	https://bugzilla.mindrot.org/show_bug.cgi?id=1672
> 
> I just updated the patch for 6.0p1, in case anyone is interested in trying
> it.

Thanks very much.

> LF> (2) make use of Robert's DNSSEC-Tools-based implementation; could the
> LF> DNSSEC-Tools-specific implementation be moved from verify_host_key_dns()
> LF> to getrrsetbyname()?
> 
> We wanted to have the lowest impact possible, and only do DNSSEC for
> verifying sshfp records. If upstream is willing to accept optional
> validation of all records, we could do that too.

I'm in favour of encapsulating the libary-of-choice related code changes
into getrrsetbyname(), leaving only the OpenSSH configuration related
code changes in common openssh/openssh-portable code.

But before we invest more time in this effort, it would be helpful to
hear upstream's opinion regarding our request for anchored DNSSEC
validation to be built into openssh.

We don't want to trust on an upstream resolver's AD bit and we don't
want to require that users install a local resolver.  Do they concur?

-- 
Luca Filipozzi

From whit at transpect.com  Fri May 11 09:10:58 2012
From: whit at transpect.com (Whit Blauvelt)
Date: Thu, 10 May 2012 19:10:58 -0400
Subject: Is there any method, with ChrootDirectory and internal-sftp, to
 automatically cd to a subdir on login?
Message-ID: <20120510231058.GA14673@black.transpect.com>

Hi,

This is either a query or a feature request. I have a system where sftp
users are chrooted using scponly, which while requiring much more setup than
OpenSSH's internal-sftp method, has the useful feature of allowing an
initial chroot to a subdirectory, typically the one used for file exchange.
I've searched for a way to do the same thing with OpenSSH. So far haven't
found it.

If there is a way, then I can transparently substitute it. Otherwise users
would have to do the cd themselves. That's not trivial in my case since a
number of the users run scripts which assume that they'll simply drop in
their correct directory on login.

Thanks for any advice, or consideration of this as a future feature if
there's no present method to achieve it.

Whit


From peter at stuge.se  Fri May 11 09:34:40 2012
From: peter at stuge.se (Peter Stuge)
Date: Fri, 11 May 2012 01:34:40 +0200
Subject: Is there any method, with ChrootDirectory and internal-sftp,
 to automatically cd to a subdir on login?
In-Reply-To: <20120510231058.GA14673@black.transpect.com>
References: <20120510231058.GA14673@black.transpect.com>
Message-ID: <20120510233440.897.qmail@stuge.se>

Whit Blauvelt wrote:
> Thanks for any advice

Quoting sshd_config(8):

     ChrootDirectory
             Specifies the pathname of a directory to chroot(2) to after
             authentication.  All components of the pathname must be root-
             owned directories that are not writable by any other user or
             group.  After the chroot, sshd(8) changes the working directory
             to the user's home directory.

So set the home directory to what you want them to land in, relative
the ChrootDirectory root.


//Peter

From dotancohen at gmail.com  Sun May 13 03:45:20 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Sat, 12 May 2012 20:45:20 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <4FA99238.9090004@gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
Message-ID: <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>

On Wed, May 9, 2012 at 12:38 AM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
>> Rereading my original post, I see that I did not explicitly state that
>> such an easy command was my goal. I often SSH into different machines
>> and many of those I cannot modify with aliases and such. However, a
>> facility for easily transferring files from / to these machines would
>> be very nice.
>
> How do you expect such command to work?
>

I imagine something like this:
The user would run a command such as the following:
remoteServer$ cp2local someFile.c
The SSH server on the remote host would then push the file to the SSH
client running locally just as if scp had been used, but it would
reuse the existing connection. The local SSH client would then write
the file just as it would have had scp been used.



> You could reconfigure your current connection adding a tunnel, and then
> use that for transfering the files, but you'd still need a local daemon
> (eg. ftpd) where to drop them.

I am sure that you recognise the added complexity for the user by way
of the workaround that you mention. From a technical point of view,
OpenSSH already has the components necessary to make this a simple
procedure.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From bert.wesarg at googlemail.com  Sun May 13 07:05:16 2012
From: bert.wesarg at googlemail.com (Bert Wesarg)
Date: Sat, 12 May 2012 23:05:16 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
Message-ID: <CAKPyHN3u5LkRirxH7rNg70XGNYJgfTh2X=uK5uSJ+eymfMFJkw@mail.gmail.com>

On Sat, May 12, 2012 at 7:45 PM, Dotan Cohen <dotancohen at gmail.com> wrote:
> On Wed, May 9, 2012 at 12:38 AM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
>> You could reconfigure your current connection adding a tunnel, and then
>> use that for transfering the files, but you'd still need a local daemon
>> (eg. ftpd) where to drop them.
>
> I am sure that you recognise the added complexity for the user by way
> of the workaround that you mention. From a technical point of view,
> OpenSSH already has the components necessary to make this a simple
> procedure.

It's not. Because SSH does not monitor what commands you execute in
the remote shell and the shell does not know that it's a remote shell.
Your SSH client just sends your locally typed key strokes to the
remote terminal. Maybe the command line activated via ~C (see the
escape char option in ssh(1)) could be used to initiate file
transfers.

Bert

From keisial at gmail.com  Sun May 13 08:45:10 2012
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Sun, 13 May 2012 00:45:10 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
Message-ID: <4FAEE7F6.2060007@gmail.com>

On 12/05/12 19:45, Dotan Cohen wrote:
> I imagine something like this: The user would run a command such as
> the following: remoteServer$ cp2local someFile.c The SSH server on the
> remote host would then push the file to the SSH client running locally
> just as if scp had been used, but it would reuse the existing
> connection. The local SSH client would then write the file just as it
> would have had scp been used. 
The big problem with that approach is that you're trusting your
credentials to the remote side.
If I ssh from A to B, and B is compromised, it shouldn't be able to
compromise A.
Can you provide an alternative usage without that hole?

It may be an issue to be solved in a client, which allowed you to switch
between console and file view (sftp).

>> You could reconfigure your current connection adding a tunnel, and then
>> use that for transfering the files, but you'd still need a local daemon
>> (eg. ftpd) where to drop them.
> I am sure that you recognise the added complexity for the user by way
> of the workaround that you mention. From a technical point of view,
> OpenSSH already has the components necessary to make this a simple
> procedure.
Sure. I was throwing out some ideas which could, perhaps, turn out to be
useful (eg. for doing it in a script).
Regards


From pavann.n at gmail.com  Sun May 13 10:46:49 2012
From: pavann.n at gmail.com (pavan n)
Date: Sat, 12 May 2012 20:46:49 -0400
Subject: Defeating Timing Attacks
Message-ID: <CADrOQ2MnzLqmsZQcvwkOJPowaQMghE=us3twJDT8neRAGMr8RQ@mail.gmail.com>

Hello,

My name is Pavan and I was working on the timing attacks in Open SSH. I
wanted to know where I can find the patch files for open SSH as I am not
able to find it on the specified link.

Thank You

From dotancohen at gmail.com  Sun May 13 17:49:52 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Sun, 13 May 2012 10:49:52 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKPyHN3u5LkRirxH7rNg70XGNYJgfTh2X=uK5uSJ+eymfMFJkw@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <CAKPyHN3u5LkRirxH7rNg70XGNYJgfTh2X=uK5uSJ+eymfMFJkw@mail.gmail.com>
Message-ID: <CAKDXFkPjyYw-TaX95C6tNMsmkUr1dGK8-Szh2=7GAWJEBPGYKg@mail.gmail.com>

On Sun, May 13, 2012 at 12:05 AM, Bert Wesarg
<bert.wesarg at googlemail.com> wrote:
>> I am sure that you recognise the added complexity for the user by way
>> of the workaround that you mention. From a technical point of view,
>> OpenSSH already has the components necessary to make this a simple
>> procedure.
>
> It's not. Because SSH does not monitor what commands you execute in
> the remote shell and the shell does not know that it's a remote shell.
>

I am not suggesting that the local SSH client monitor what is being
typed into the shell. Rather, the SSH server on the remote host would
have a command cpLocal that would wrap scp with all the needed
connection information. If the user is not connected via SSH then
cpLocal could throw an error.



-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From dotancohen at gmail.com  Sun May 13 17:52:59 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Sun, 13 May 2012 10:52:59 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <4FAEE7F6.2060007@gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
Message-ID: <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>

On Sun, May 13, 2012 at 1:45 AM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
> The big problem with that approach is that you're trusting your
> credentials to the remote side.
> If I ssh from A to B, and B is compromised, it shouldn't be able to
> compromise A.
> Can you provide an alternative usage without that hole?
>

Sure: just reuse the existing connection. Just like how sftp works.


> It may be an issue to be solved in a client, which allowed you to switch
> between console and file view (sftp).
>

That would be nice.


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From keisial at gmail.com  Sun May 13 20:06:20 2012
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Sun, 13 May 2012 12:06:20 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
Message-ID: <4FAF879C.3000407@gmail.com>

On 13/05/12 09:52, Dotan Cohen wrote:
> On Sun, May 13, 2012 at 1:45 AM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
>> The big problem with that approach is that you're trusting your
>> credentials to the remote side.
>> If I ssh from A to B, and B is compromised, it shouldn't be able to
>> compromise A.
>> Can you provide an alternative usage without that hole?
> Sure: just reuse the existing connection. Just like how sftp works.
???
If a command such as the proposed cp2local is able to write arbitrary
files in the local end*, it allows such compromise.

* For instance, a profile file run by your shell each time you log in, see 
CVE-2010-2252.



From dotancohen at gmail.com  Sun May 13 20:41:31 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Sun, 13 May 2012 13:41:31 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <4FAF879C.3000407@gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
 <4FAF879C.3000407@gmail.com>
Message-ID: <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>

On Sun, May 13, 2012 at 1:06 PM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
> If a command such as the proposed cp2local is able to write arbitrary
> files in the local end*, it allows such compromise.
>

I understand that you feel that allowing the remote server to write
(not execute) arbitrary files to the local machine is a security risk.
I also assume that you do not feel that scp being able to write
arbitrary files to the local machine is not a security risk because it
requires the explicit typing of a username and password, or better yet
of a keypair. Please confirm or deny if my assumption is correct.

I counter that the proposed cp2Local is no more of a security risk
than scp because it _also_ requires the user of a username/password or
keypair to explicitly express intent (establishing the initial SSH
connection). Assuming the worst-case scenario that this feature is
enabled and the user SSHes into a compromised box, the user will be
only downloading unwanted, malicious files to his local machine, he
will not be executing them automatically. This is no different than
visiting a webpage. In fact, this is safer: web browsers _can_ run
arbitrary code in the form of Javascript.

You could argue that the web browser downloads to a cache, whereas
cpLocal would download to $HOME. Therefore have it downlaod to a
different directory, Free Desktop has conventions for this, see this
Stack Overflow discussion:
http://unix.stackexchange.com/a/15238/9760

In short, I recognise the problem of allowing the remote machine
access to write to your local machine. However, this has been a
problem with many other technologies (www, email, ftp, etc.) and it is
a solved issue in the general sense. That is, best practices and
damage-mitigation strategies have already been established.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From gert at greenie.muc.de  Sun May 13 21:06:30 2012
From: gert at greenie.muc.de (Gert Doering)
Date: Sun, 13 May 2012 13:06:30 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
 <4FAF879C.3000407@gmail.com>
 <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
Message-ID: <20120513110630.GJ1359@greenie.muc.de>

Hi,

On Sun, May 13, 2012 at 01:41:31PM +0300, Dotan Cohen wrote:
> I counter that the proposed cp2Local is no more of a security risk
> than scp because it _also_ requires the user of a username/password or
> keypair to explicitly express intent (establishing the initial SSH
> connection). Assuming the worst-case scenario that this feature is
> enabled and the user SSHes into a compromised box, the user will be
> only downloading unwanted, malicious files to his local machine, he
> will not be executing them automatically. This is no different than
> visiting a webpage. In fact, this is safer: web browsers _can_ run
> arbitrary code in the form of Javascript.

"unwanted, malicious files" could be .ssh/authorized_keys, .shosts, 
.profile / .bashrc, etc. - which might not be executed right away, but
will give the attacker interesting options to attack the original client 
machine.

[..]
> In short, I recognise the problem of allowing the remote machine
> access to write to your local machine. However, this has been a
> problem with many other technologies (www, email, ftp, etc.) and it is
> a solved issue in the general sense. That is, best practices and
> damage-mitigation strategies have already been established.

Actually, none of these technologies allow downloading arbitrary files
to the client machine, using server-controlled file names, just by
logging into a malicious server.

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From keisial at gmail.com  Sun May 13 23:47:36 2012
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Sun, 13 May 2012 15:47:36 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
 <4FAF879C.3000407@gmail.com>
 <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
Message-ID: <4FAFBB78.6060402@gmail.com>

On 13/05/12 12:41, Dotan Cohen wrote:
> On Sun, May 13, 2012 at 1:06 PM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
>> If a command such as the proposed cp2local is able to write arbitrary
>> files in the local end*, it allows such compromise.
>>
> I understand that you feel that allowing the remote server to write
> (not execute) arbitrary files to the local machine is a security risk.
Yes

> I also assume that you do not feel that scp being able to write
> arbitrary files to the local machine is not a security risk because it
> requires the explicit typing of a username and password, or better yet
> of a keypair. Please confirm or deny if my assumption is correct.
No. It is not a security risk because the user explicitely and
unambiguously provides the target filename.


> I counter that the proposed cp2Local is no more of a security risk
> than scp because it _also_ requires the user of a username/password or
> keypair to explicitly express intent (establishing the initial SSH
> connection).
Connecting to a malicious host != downloading files.

> Assuming the worst-case scenario that this feature is
> enabled and the user SSHes into a compromised box, the user will be
> only downloading unwanted, malicious files to his local machine,
...and potentially getting valuable data overwritten
> he will not be executing them automatically. 
Unless the arbitrary name the file is saved as, is one which lead to
other programs to automatically execute it.

> This is no different than visiting a webpage. In fact, this is safer: web browsers _can_ run
> arbitrary code in the form of Javascript.
JavaScript runs in a sandbox and can't modify your files.
A better analogy would be a document macro.

You open the document. But that doesn't mean you want to allow its macro
to spread to all your documents and email new copies to your contact book.


> You could argue that the web browser downloads to a cache, whereas
> cpLocal would download to $HOME. Therefore have it downlaod to a
> different directory, Free Desktop has conventions for this, see this
> Stack Overflow discussion:
> http://unix.stackexchange.com/a/15238/9760
I usually wouldn't want to get it to a Download folder. However, that
would indeed solve the security issue.

I assume you change your request to a
 cp2local <file>
command, which copies <file> into $HOME/Downloads
 (or another folder configured in ssh_config), and the user is
responsible for moving it from there to wherever they want in the local
folder?


> In short, I recognise the problem of allowing the remote machine
> access to write to your local machine. However, this has been a
> problem with many other technologies (www, email, ftp, etc.) and it is
> a solved issue in the general sense. That is, best practices and
> damage-mitigation strategies have already been established.
The CVE that I provided (the web server being able to control the
destination filename), was fixed in wget by disabling that feature by
default :)



From dotancohen at gmail.com  Sun May 13 23:59:29 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Sun, 13 May 2012 16:59:29 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <20120513110630.GJ1359@greenie.muc.de>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
 <4FAF879C.3000407@gmail.com>
 <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
 <20120513110630.GJ1359@greenie.muc.de>
Message-ID: <CAKDXFkMBcX2JD0ag3aCse1vchCxb7sCVuzdUt1N5MyAnO-VPzQ@mail.gmail.com>

On Sun, May 13, 2012 at 2:06 PM, Gert Doering <gert at greenie.muc.de> wrote:
> "unwanted, malicious files" could be .ssh/authorized_keys, .shosts,
> .profile / .bashrc, etc. - which might not be executed right away, but
> will give the attacker interesting options to attack the original client
> machine.
>

Let's assume that a compromised machine pushes a malicious file called
authorized_keys. It gets put in the user's Downloads directory, or in
the case of a misconfigured configuration gets put in $HOME. Now what?
The user would have to explicitly place that file in another location
for it to do any harm.


>> In short, I recognise the problem of allowing the remote machine
>> access to write to your local machine. However, this has been a
>> problem with many other technologies (www, email, ftp, etc.) and it is
>> a solved issue in the general sense. That is, best practices and
>> damage-mitigation strategies have already been established.
>
> Actually, none of these technologies allow downloading arbitrary files
> to the client machine, using server-controlled file names, just by
> logging into a malicious server.
>

I see the point about the file names. Actually, web browsers _do_
allow arbitrary file names by using an unrecognised (by the browser)
MIME type, though by default in that case the user must accept the
download. If the problem is the server-specified filename, then
perhaps a client-side confirmation is appropriate. How do you propose
that work, from a UI perspective?


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From dotancohen at gmail.com  Mon May 14 00:32:58 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Sun, 13 May 2012 17:32:58 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <4FAFBB78.6060402@gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
 <4FAF879C.3000407@gmail.com>
 <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
 <4FAFBB78.6060402@gmail.com>
Message-ID: <CAKDXFkNY8jye-7c_FMdJEP9f3c=whQJAJZVkdnPp1uiijFJ-hQ@mail.gmail.com>

On Sun, May 13, 2012 at 4:47 PM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
>> I understand that you feel that allowing the remote server to write
>> (not execute) arbitrary files to the local machine is a security risk.
> Yes
>
>> I also assume that you do not feel that scp being able to write
>> arbitrary files to the local machine is not a security risk because it
>> requires the explicit typing of a username and password, or better yet
>> of a keypair. Please confirm or deny if my assumption is correct.
> No. It is not a security risk because the user explicitely and
> unambiguously provides the target filename.
>

I see. I address the filename issue in a reply to Gert. By analogy
with the web browser (which under certain condition prompts the user
to save a file in a "main" directory with a server-choosen filename),
there could be a client-side prompt to confirm / deny the cpLocal
command which was run on the host.


>> I counter that the proposed cp2Local is no more of a security risk
>> than scp because it _also_ requires the user of a username/password or
>> keypair to explicitly express intent (establishing the initial SSH
>> connection).
> Connecting to a malicious host != downloading files.
>

Correct, but downloading files is the only new functionality that we
are discussing. All other attack vectors are identical to current SSH
(without the feature under discussion).


>> Assuming the worst-case scenario that this feature is
>> enabled and the user SSHes into a compromised box, the user will be
>> only downloading unwanted, malicious files to his local machine,
>
> ...and potentially getting valuable data overwritten

Then the prompt will mitigate this, just as the web browser
file-download prompt.


>> he will not be executing them automatically.
>
> Unless the arbitrary name the file is saved as, is one which lead to
> other programs to automatically execute it.
>

Again, this is no more of a risk than downloading files with the web browser.


>> This is no different than visiting a webpage. In fact, this is safer: web browsers _can_ run
>> arbitrary code in the form of Javascript.
>
> JavaScript runs in a sandbox and can't modify your files.
> A better analogy would be a document macro.
>

Fine, then.


> You open the document. But that doesn't mean you want to allow its macro
> to spread to all your documents and email new copies to your contact book.
>

How is that any more of a concern if the file is acquired via scp vs.
being downloaded in a web browser?


>> You could argue that the web browser downloads to a cache, whereas
>> cpLocal would download to $HOME. Therefore have it downlaod to a
>> different directory, Free Desktop has conventions for this, see this
>> Stack Overflow discussion:
>> http://unix.stackexchange.com/a/15238/9760
> I usually wouldn't want to get it to a Download folder. However, that
> would indeed solve the security issue.
>
> I assume you change your request to a
> ?cp2local <file>
> command, which copies <file> into $HOME/Downloads
> ?(or another folder configured in ssh_config), and the user is
> responsible for moving it from there to wherever they want in the local
> folder?
>

That would be terrific.


>> In short, I recognise the problem of allowing the remote machine
>> access to write to your local machine. However, this has been a
>> problem with many other technologies (www, email, ftp, etc.) and it is
>> a solved issue in the general sense. That is, best practices and
>> damage-mitigation strategies have already been established.
> The CVE that I provided (the web server being able to control the
> destination filename), was fixed in wget by disabling that feature by
> default :)
>
>

Actually, modelling the defaults and options on the wget defaults and
options would be terrific. However, in this case there is no URL, and
the file has to have _some_ name, so I suggest that the server
"suggest" a filename and that the prompts allow it to be overwritten.

Are you familiar with VIM's little popup windows on the bottom of the
screen, such as when typing :marks or :ls with multiple buffers? I do
know know what that feature is called, so I'll refer to it as a
VIM-popup here.

As we have described it, the cpLocal feature would work something like this:

me at local:~$ ls
file1 file2
me at local:~$ ssh anotherMe at remote
anotherMe at remote:~$ ls
document1 document2
anotherMe at remote:~$ cpLocal document1

----------------------------------    <-- Here opens a "VIM-window" (see above)
| me at local: Download document1?  |
| [y/N/r/l]?                     |     <-- 'r' is Rename, 'l' is Choose Location

anotherMe at remote:~$ exit
me at local:~$ ls
document1 file1 file2
me at local:~$


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From john.m.olsson at ericsson.com  Mon May 14 17:02:01 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Mon, 14 May 2012 09:02:01 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>

Hi,


> I imagine something like this:
> The user would run a command such as the following:
> remoteServer$ cp2local someFile.c
> The SSH server on the remote host would then push the file to the
> SSH client running locally just as if scp had been used, but it
> would reuse the existing connection. The local SSH client would
> then write the file just as it would have had scp been used.

You also need to consider the case where the user is *not* running a normal (like TCSH, Bash, ZSH, ...) shell on the server and where the file system is exposed as a virtual filesystem via SFTP (which might run in another chrooted directory than the SSH subsystem).

What would a path to a local file look like in this context?

I see this as a security hole since you suddenly get acess to files via SSH which you do not get access to via SFTP (since it is chrooted)...


/John

From dotancohen at gmail.com  Mon May 14 19:55:57 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Mon, 14 May 2012 12:55:57 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <CAKDXFkM5PFzK-qJ+DJKf4xDJq8Pm4rJkahBzXsd7Wrbxh0E9+A@mail.gmail.com>

On Mon, May 14, 2012 at 10:02 AM, John Olsson M
<john.m.olsson at ericsson.com> wrote:
> You also need to consider the case where the user is *not* running a normal (like TCSH, Bash, ZSH, ...) shell on
> the server and where the file system is exposed as a virtual filesystem via SFTP (which might run in another
> chrooted directory than the SSH subsystem).
>
> What would a path to a local file look like in this context?
>

The feature would obviously not be available in the SFTP context. For
one thing, the feature requires a remote server script / command
cpLocal which initiates the transfer and in SFTP there is no access to
scripts / commands.


> I see this as a security hole since you suddenly get acess to files via SSH which you do not get access to via
> SFTP (since it is chrooted)...
>

If the user has access to read a file in a BASH shell then what is to
prevent him from copying the text of that file right from his
terminal? In fact, that is exactly what I have been doing and is quite
the reason for suggesting the download feature.



-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From sdaoden at googlemail.com  Mon May 14 20:23:30 2012
From: sdaoden at googlemail.com (Steffen Daode Nurpmeso)
Date: Mon, 14 May 2012 12:23:30 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <4fb0dd22.HC3DmYYPIDxvCIictt2A2Uos@dietcurd.wild-life.local>

John Olsson M <john.m.olsson at ericsson.com> wrote:

 | > I imagine something like this:
 | > The user would run a command such as the following:
 | > remoteServer$ cp2local someFile.c
 | > The SSH server on the remote host would then push the file to the
 | > SSH client running locally just as if scp had been used, but it
 | > would reuse the existing connection. The local SSH client would
 | > then write the file just as it would have had scp been used.
 |
 | You also need to consider the case where the user is *not* running a normal (like TCSH, Bash, ZSH, ...) shell on the server and where the file system is exposed as a virtual filesystem via SFTP (which might run in another chrooted directory than the SSH subsystem).
 |
 | What would a path to a local file look like in this context?
 |
 | I see this as a security hole since you suddenly get acess to files via SSH which you do not get access to via SFTP (since it is chrooted)...

As i understood him (unfortunately i've dropped the mail after
i've got the impression this will not make it anyway, sorry!) he
thought about something like

  myself at local-host$ ssh myself at host-over-ssh
  myself at host-over-ssh$ ~Copy_file path_on_local-host path(_on_host-over-ssh)

Why should this open a security hole, given that
myself at host-over-ssh has proper permissions for
path_on_host-over-ssh?  E.g., the session can do

  myself at host-over-ssh$ echo $(date) > path(_on_host-over-ssh)

The problem i see however is that there will be no filename
completion for at least path_on_local-host.

 | /John

--steffen
Forza Figa!

From john.m.olsson at ericsson.com  Mon May 14 20:33:42 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Mon, 14 May 2012 12:33:42 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkM5PFzK-qJ+DJKf4xDJq8Pm4rJkahBzXsd7Wrbxh0E9+A@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
 <CAKDXFkM5PFzK-qJ+DJKf4xDJq8Pm4rJkahBzXsd7Wrbxh0E9+A@mail.gmail.com>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FAB4@ESESSCMS0360.eemea.ericsson.se>

> If the user has access to read a file in a BASH shell then
> what is to prevent him from copying the text of that file
> right from his terminal? In fact, that is exactly what I
> have been doing and is quite the reason for suggesting the
> download feature.

You are missing my point. I'm talking about a node/computer/machine/... that offers a CLI interface via SSH on port 22 that is *not* a generic Bash-like shell. Instead it is a text-based managmenet interface of some equipment (for instance a switch or a router). This interface does not operate on files, instead it is configuration commands.

This node also offers an SFTP interface where a file system is exposed (some kind of virtual filesystem) where files can be uploaded and downloaded. Files in this virtual filesystem can ofcourse be referenced from the SSH CLI interface (e.g. configuration data is read from a file etc.).

The SFTP service might run in a chrooted environemnt, whereas the SSH CLI interface can not do this due to that it must be able to access (behind the scenes) all of the physical filesystem.


If you now enable support so that you could transfer /etc/passwd via a built-in SSH command from a node that does not expose a filesystem in the shell I see this as a security problem. That is, since the SSH CLI process can access a larger/different part of the filesystem, the proposed built-in SSH CLI filesystem transfer command could then expose any file that the process can access, right?

I'm just raising this issue, since not all nodes that offer SSH access looks and behave the same way. Not everything is a Bash shell. :)


/John

-----Original Message-----
From: Dotan Cohen [mailto:dotancohen at gmail.com] 
Sent: den 14 maj 2012 11:56
To: John Olsson M
Cc: ?ngel Gonz?lez; openssh-unix-dev at mindrot.org
Subject: Re: Transferring file to local machine when SSHing into a foreign box

On Mon, May 14, 2012 at 10:02 AM, John Olsson M <john.m.olsson at ericsson.com> wrote:
> You also need to consider the case where the user is *not* running a 
> normal (like TCSH, Bash, ZSH, ...) shell on the server and where the 
> file system is exposed as a virtual filesystem via SFTP (which might run in another chrooted directory than the SSH subsystem).
>
> What would a path to a local file look like in this context?
>

The feature would obviously not be available in the SFTP context. For one thing, the feature requires a remote server script / command cpLocal which initiates the transfer and in SFTP there is no access to scripts / commands.


> I see this as a security hole since you suddenly get acess to files 
> via SSH which you do not get access to via SFTP (since it is chrooted)...
>

If the user has access to read a file in a BASH shell then what is to prevent him from copying the text of that file right from his terminal? In fact, that is exactly what I have been doing and is quite the reason for suggesting the download feature.



--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From gert at greenie.muc.de  Mon May 14 21:23:29 2012
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 14 May 2012 13:23:29 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <4fb0dd22.HC3DmYYPIDxvCIictt2A2Uos@dietcurd.wild-life.local>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
 <4fb0dd22.HC3DmYYPIDxvCIictt2A2Uos@dietcurd.wild-life.local>
Message-ID: <20120514112329.GA1359@greenie.muc.de>

Hi,

On Mon, May 14, 2012 at 12:23:30PM +0200, Steffen Daode Nurpmeso wrote:
>   myself at local-host$ ssh myself at host-over-ssh
>   myself at host-over-ssh$ ~Copy_file path_on_local-host path(_on_host-over-ssh)
> 
> Why should this open a security hole, given that
> myself at host-over-ssh has proper permissions for
> path_on_host-over-ssh?  

If you're just talking about from-local-to-remote, one thing that comes
to mind is "an evil remote host stealing your local files without your
doing".

So while I can understand the convenience factor of this, making it
properly secure (like "only operate out of a well-defined quarantaine
folder on local-host, and do not permit absolute or relative path names
with '..' in them") are likely ging to make this inconvenient enough
to then not-use it...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From peter at stuge.se  Mon May 14 23:02:52 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 14 May 2012 15:02:52 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
 <4FAF879C.3000407@gmail.com>
 <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
Message-ID: <20120514130252.16357.qmail@stuge.se>

Dotan Cohen wrote:
> I understand that you feel that allowing the remote server to write
> (not execute) arbitrary files to the local machine is a security risk.

Correct. It's completely unacceptable in the general case.


> I also assume that you do not feel that scp being able to write
> arbitrary files to the local machine is not a security risk because it
> requires the explicit typing of a username and password, or better yet
> of a keypair. Please confirm or deny if my assumption is correct.

Incorrect. What you clearly do not understand is that scp being
invoked is an explicit action taken on the client, whereas something
happening automatically on the client in response to something being
invoked on the server is quite different.


//Peter

From peter at stuge.se  Mon May 14 23:26:00 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 14 May 2012 15:26:00 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkNY8jye-7c_FMdJEP9f3c=whQJAJZVkdnPp1uiijFJ-hQ@mail.gmail.com>
References: <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
 <4FAF879C.3000407@gmail.com>
 <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
 <4FAFBB78.6060402@gmail.com>
 <CAKDXFkNY8jye-7c_FMdJEP9f3c=whQJAJZVkdnPp1uiijFJ-hQ@mail.gmail.com>
Message-ID: <20120514132600.18153.qmail@stuge.se>

Dotan Cohen wrote:
> As we have described it, the cpLocal feature would work something
> like this:
> 
> me at local:~$ ls
> file1 file2
> me at local:~$ ssh anotherMe at remote
> anotherMe at remote:~$ ls
> document1 document2
> anotherMe at remote:~$ cpLocal document1
> 
> ----------------------------------    <-- Here opens a "VIM-window" (see above)
> | me at local: Download document1?  |
> | [y/N/r/l]?                     |     <-- 'r' is Rename, 'l' is Choose Location
> 
> anotherMe at remote:~$ exit
> me at local:~$ ls
> document1 file1 file2
> me at local:~$

Thanks for answering my question about user interface. Unfortunately
it seems that you are not so aware of how the systems you use
actually work, and your proposal further does not address the very
important concerns about a remote system being able to control a
local client.

What you call the "VIM-popup" can not be created by the local SSH
client because it is not operating the terminal in a windowed mode.

You would have to study a bit of systems programming and with
particular focus on how applications can interact with their
controlling terminal to have a good background for finding a good
yet viable solution to this user interface problem.

And as I mentioned the above has a rather severe security problem.
The above can be abused by a remote server to make the logged-in
session unusable. Re-using your analogy with web browsers, think of
having a prompt enabled about approving cookies while navigating to
yahoo.com or cnn.com or some other site with lots of cookies and
banners. The client effectively becomes useless due to all the
prompts.

Now, the ~C command line was mentioned. This can be used to realize a
feature similar to what you ask for, but with some differences, and a
few technical problems to solve:

* difference: file transfer requests must always be initiated manually
  on the client in the ~C command line.
* problem: the client command line does not know the cwd of the
  remote shell, meaning that relative paths can not be used, which is
  somehow the whole point of this proposal.

A further variant on this is where on the remote system a file
transfer is prepared with the semantics of the proposed cp2local
command, but no transfer begins until an explicit ~C command (or
perhaps ~D for download) is entered on the client to actually perform
the transfer. There will be no notification from the client that a
transfer is pending, because in fact nothing is pending, the transfer
has only been prepared on the remote side, and will still be
initiated only by the client, just that on the remote server there is
now the marker running which identifies what should be transfered.

A technical problem still remains; how all this should work in terms
of the SSH protocol and what exactly the marker command (cp2local)
does.


//Peter

From dotancohen at gmail.com  Mon May 14 23:30:42 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Mon, 14 May 2012 16:30:42 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FAB4@ESESSCMS0360.eemea.ericsson.se>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
 <CAKDXFkM5PFzK-qJ+DJKf4xDJq8Pm4rJkahBzXsd7Wrbxh0E9+A@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FAB4@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <CAKDXFkMcbNaQrF6shRXmz8bqmPy8aee9XfkqeOa5yA_TVZci_A@mail.gmail.com>

On Mon, May 14, 2012 at 1:33 PM, John Olsson M
<john.m.olsson at ericsson.com> wrote:
>> If the user has access to read a file in a BASH shell then
>> what is to prevent him from copying the text of that file
>> right from his terminal? In fact, that is exactly what I
>> have been doing and is quite the reason for suggesting the
>> download feature.
>
> You are missing my point. I'm talking about a node/computer/machine/... that offers a CLI interface via SSH on port 22 that is *not* a generic Bash-like shell. Instead it is a text-based managmenet interface of some equipment (for instance a switch or a router). This interface does not operate on files, instead it is configuration commands.
>

So the feature does not have to be exposed under those connection
conditions. Only expose the feature when connecting to a shell
instance.


> This node also offers an SFTP interface where a file system is exposed (some kind of virtual filesystem) where files can be uploaded and downloaded. Files in this virtual filesystem can ofcourse be referenced from the SSH CLI interface (e.g. configuration data is read from a file etc.).
>

So this interface doesn't even need the feature. Terrific. I don't
understand what the problem is.


> The SFTP service might run in a chrooted environemnt, whereas the SSH CLI interface can not do this due to that it must be able to access (behind the scenes) all of the physical filesystem.
>

If the administrator of the machine provides the user with read access
to a file via BASH or any other shell in SSH, then the user can
provide himself with the contents of the file. Their currently is no
straightforward method, but there exist painstaking methods and if
that is not considered a security hole (copy-pasta from console) then
the proposed method is neither a security hole. In other words, the
proposed method exposes no information that is not already exposed.


> If you now enable support so that you could transfer /etc/passwd via a built-in SSH command from a node that does not expose a filesystem in the shell I see this as a security problem. That is, since the SSH CLI process can access a larger/different part of the filesystem, the proposed built-in SSH CLI filesystem transfer command could then expose any file that the process can access, right?
>

How is this any different than the user typing "vim /etc/password" in
a shell via SSH and then copying the contents of the file from his
terminal?


> I'm just raising this issue, since not all nodes that offer SSH access looks and behave the same way. Not everything is a Bash shell. :)
>

I appreciate that you raise the issue! I expect that there will be
contingencies that I do not think of, and it is better to work them
out right now. I thank you for providing your input, _especially_ when
it mentions things that I have not thought of.


Also, presumably there will be configuration options to disable this
feature, something like "PermitCpLocal".

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From dotancohen at gmail.com  Mon May 14 23:38:47 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Mon, 14 May 2012 16:38:47 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <20120514112329.GA1359@greenie.muc.de>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
 <4fb0dd22.HC3DmYYPIDxvCIictt2A2Uos@dietcurd.wild-life.local>
 <20120514112329.GA1359@greenie.muc.de>
Message-ID: <CAKDXFkMeDaqyDAHGkA1Ey=s+UGKR89rQUrzS-1wPsx=gn2U1mw@mail.gmail.com>

On Mon, May 14, 2012 at 2:23 PM, Gert Doering <gert at greenie.muc.de> wrote:
> If you're just talking about from-local-to-remote, one thing that comes
> to mind is "an evil remote host stealing your local files without your
> doing".
>
> So while I can understand the convenience factor of this, making it
> properly secure (like "only operate out of a well-defined quarantaine
> folder on local-host, and do not permit absolute or relative path names
> with '..' in them") are likely ging to make this inconvenient enough
> to then not-use it...
>

Actually, I personally am most interested in the remote-to-local bit
and that is all that has been discussed so far.

I agree that the local-to-remote feature would be nice as well, but
with the necessity that the remote side is initiating, I agree that it
could be problematic. How about only initiating a transfer on the
remote side, but having the local side decide which file. Like this:

me at local:~$ ls
file1 file2
me at local:~$ ssh anotherMe at remote
anotherMe at remote:~$ ls
document1 document2
anotherMe at remote:~$ cpFromLocal
------------------------------------    <-- Here opens a "VIM-window"
(see previous message)
| me at local: Please browse to file  |
| $ ls                             |
| file1 file2                      |
| $ send file1                     |

anotherMe at remote:~$ ls
document1 document2 file1
anotherMe at remote:~$ exit
me at local:~$ ls
file1 file2
me at local:~$



-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From john.m.olsson at ericsson.com  Mon May 14 23:50:20 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Mon, 14 May 2012 15:50:20 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <CAKDXFkMcbNaQrF6shRXmz8bqmPy8aee9XfkqeOa5yA_TVZci_A@mail.gmail.com>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
 <CAKDXFkM5PFzK-qJ+DJKf4xDJq8Pm4rJkahBzXsd7Wrbxh0E9+A@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FAB4@ESESSCMS0360.eemea.ericsson.se>
 <CAKDXFkMcbNaQrF6shRXmz8bqmPy8aee9XfkqeOa5yA_TVZci_A@mail.gmail.com>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FC17@ESESSCMS0360.eemea.ericsson.se>

> So the feature does not have to be exposed under those
> connection conditions. Only expose the feature when
> connecting to a shell instance.

How does the SSH server know this? Shall it be a configuration option per subsystem?


> So this interface doesn't even need the feature. Terrific.
> I don't understand what the problem is.

I do not want a situation where you suddenly out-of-the-box get file transfer capabilities for a node which does not intend to offer file transfer capabilities. Or for that matter gives access to another set of files compared to what is exposed via SFTP.

I really hope I have misunderstood what it is you want to do. :)


> If the administrator of the machine provides the user with read
> access to a file via BASH or any other shell in SSH, then the
> user can provide himself with the contents of the file. Their
> currently is no straightforward method, but there exist
> painstaking methods and if that is not considered a security
> hole (copy-pasta from console) then the proposed method is
> neither a security hole. In other words, the proposed method
> exposes no information that is not already exposed.

I'm just considering the case when the "shell" is not an ordinary Bash-like shell that offers a filesystem view. Thus I do not want any mechanism that allows for escaping out of the sandboxed environment offered by the "shell". For instance being able to ferret out files that is not possible to see via the "shell". Or, for that matter, place files in the filesystem.

Please also note that the logon procedure might not be based on uid and gid. The "shell" might have its own security model based on custom LDAP attributes which restricts what the user is capable of doing and if the user is able to escape from the "shell" everything is done with the rights of the "shell" process.


> How is this any different than the user typing "vim /etc/password"
> in a shell via SSH and then copying the contents of the file from
> his terminal?

If it is possible to access /etc/passwd from an SSH built-in feature to escape from the "shell" to be able to get file access of the nodes filesystem to transfer files in and out it is a huge difference.


> I appreciate that you raise the issue! I expect that there will
> be contingencies that I do not think of, and it is better to
> work them out right now. I thank you for providing your input,
> _especially_ when it mentions things that I have not thought of.


Excellent! That is my intention. People are doing weird things and all computers out there is not just a "Linux box with Bash"... ;)


> Also, presumably there will be configuration options to disable
> this feature, something like "PermitCpLocal".

I would definitely prefer it the other way around; Opt-In instead of Opt-out. That is you must explicitly ask for the feature to enable it; default it should be turned off.


/John

-----Original Message-----
From: Dotan Cohen [mailto:dotancohen at gmail.com] 
Sent: den 14 maj 2012 15:31
To: John Olsson M
Cc: ?ngel Gonz?lez; openssh-unix-dev at mindrot.org
Subject: Re: Transferring file to local machine when SSHing into a foreign box

On Mon, May 14, 2012 at 1:33 PM, John Olsson M <john.m.olsson at ericsson.com> wrote:
>> If the user has access to read a file in a BASH shell then what is to 
>> prevent him from copying the text of that file right from his 
>> terminal? In fact, that is exactly what I have been doing and is 
>> quite the reason for suggesting the download feature.
>
> You are missing my point. I'm talking about a node/computer/machine/... that offers a CLI interface via SSH on port 22 that is *not* a generic Bash-like shell. Instead it is a text-based managmenet interface of some equipment (for instance a switch or a router). This interface does not operate on files, instead it is configuration commands.
>

So the feature does not have to be exposed under those connection conditions. Only expose the feature when connecting to a shell instance.


> This node also offers an SFTP interface where a file system is exposed (some kind of virtual filesystem) where files can be uploaded and downloaded. Files in this virtual filesystem can ofcourse be referenced from the SSH CLI interface (e.g. configuration data is read from a file etc.).
>

So this interface doesn't even need the feature. Terrific. I don't understand what the problem is.


> The SFTP service might run in a chrooted environemnt, whereas the SSH CLI interface can not do this due to that it must be able to access (behind the scenes) all of the physical filesystem.
>

If the administrator of the machine provides the user with read access to a file via BASH or any other shell in SSH, then the user can provide himself with the contents of the file. Their currently is no straightforward method, but there exist painstaking methods and if that is not considered a security hole (copy-pasta from console) then the proposed method is neither a security hole. In other words, the proposed method exposes no information that is not already exposed.


> If you now enable support so that you could transfer /etc/passwd via a built-in SSH command from a node that does not expose a filesystem in the shell I see this as a security problem. That is, since the SSH CLI process can access a larger/different part of the filesystem, the proposed built-in SSH CLI filesystem transfer command could then expose any file that the process can access, right?
>

How is this any different than the user typing "vim /etc/password" in a shell via SSH and then copying the contents of the file from his terminal?


> I'm just raising this issue, since not all nodes that offer SSH access 
> looks and behave the same way. Not everything is a Bash shell. :)
>

I appreciate that you raise the issue! I expect that there will be contingencies that I do not think of, and it is better to work them out right now. I thank you for providing your input, _especially_ when it mentions things that I have not thought of.


Also, presumably there will be configuration options to disable this feature, something like "PermitCpLocal".

--
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From dotancohen at gmail.com  Tue May 15 00:40:29 2012
From: dotancohen at gmail.com (Dotan Cohen)
Date: Mon, 14 May 2012 17:40:29 +0300
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FC17@ESESSCMS0360.eemea.ericsson.se>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
 <CAKDXFkM5PFzK-qJ+DJKf4xDJq8Pm4rJkahBzXsd7Wrbxh0E9+A@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FAB4@ESESSCMS0360.eemea.ericsson.se>
 <CAKDXFkMcbNaQrF6shRXmz8bqmPy8aee9XfkqeOa5yA_TVZci_A@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FC17@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <CAKDXFkMO8n-n8y1-wRb52xXzkgyZjU+jU+AHQDHf=fEZXW04Yg@mail.gmail.com>

On Mon, May 14, 2012 at 4:50 PM, John Olsson M
<john.m.olsson at ericsson.com> wrote:
>> So the feature does not have to be exposed under those
>> connection conditions. Only expose the feature when
>> connecting to a shell instance.
>
> How does the SSH server know this? Shall it be a configuration option per subsystem?
>

The feature will be initiated by a CLI command on the server (remote)
side. So if there is no shell to run commands, then the feature is not
exposed to use by the user. See the prior mail on the subject, dated
Sun, 13 May 2012 17:32:58 +0300 by me. Later I'll summarise the issue
so that we won't have to keep referring back to eclectic emails.


>> So this interface doesn't even need the feature. Terrific.
>> I don't understand what the problem is.
>
> I do not want a situation where you suddenly out-of-the-box get file transfer capabilities for a node which does not intend to offer file transfer capabilities. Or for that matter gives access to another set of files compared to what is exposed via SFTP.
>

Then a config setting such as PermitCpLocal would be prudent.


> I really hope I have misunderstood what it is you want to do. :)
>

I hope not! I would rather that you point out the flaws to help hone
it into something feasible _and_ safe.


>> If the administrator of the machine provides the user with read
>> access to a file via BASH or any other shell in SSH, then the
>> user can provide himself with the contents of the file. Their
>> currently is no straightforward method, but there exist
>> painstaking methods and if that is not considered a security
>> hole (copy-pasta from console) then the proposed method is
>> neither a security hole. In other words, the proposed method
>> exposes no information that is not already exposed.
>
> I'm just considering the case when the "shell" is not an ordinary Bash-like shell that offers a filesystem view. Thus I do not want any mechanism that allows for escaping out of the sandboxed environment offered by the "shell". For instance being able to ferret out files that is not possible to see via the "shell". Or, for that matter, place files in the filesystem.
>

That is not an issue with the current idea of the implementation. Only
files that the user has read access to in his SSH session are
available to transfer, and if the user already has read access then he
can already just copy the (text) files out of his terminal.


> Please also note that the logon procedure might not be based on uid and gid. The "shell" might have its own security model based on custom LDAP attributes which restricts what the user is capable of doing and if the user is able to escape from the "shell" everything is done with the rights of the "shell" process.
>

There is no escaping from the shell. Only those file for which the
user has explicit read access are available.


>> How is this any different than the user typing "vim /etc/password"
>> in a shell via SSH and then copying the contents of the file from
>> his terminal?
>
> If it is possible to access /etc/passwd from an SSH built-in feature to escape from the "shell" to be able to get file access of the nodes filesystem to transfer files in and out it is a huge difference.
>

Huge difference? There is no escaping from the shell, I don't know why
you insist on using that term. If the user can open a file in VIM,
then he can download the file. It is the same exact file access which
UNIX has been providing for decades, and SELinux is refining.

Imagine the script running like this behind the scenes:
cat someFile > scp

Only if the user can cat the file then can he transfer it.


>> I appreciate that you raise the issue! I expect that there will
>> be contingencies that I do not think of, and it is better to
>> work them out right now. I thank you for providing your input,
>> _especially_ when it mentions things that I have not thought of.
>
>
> Excellent! That is my intention. People are doing weird things and all computers out there is not just a "Linux box with Bash"... ;)
>
>
>> Also, presumably there will be configuration options to disable
>> this feature, something like "PermitCpLocal".
>
> I would definitely prefer it the other way around; Opt-In instead of Opt-out. That is you must explicitly ask for the feature to enable it; default it should be turned off.
>

That might be a good idea to start with. New access features should
always be opt-in in my opinion.



-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

From peter at stuge.se  Tue May 15 00:43:03 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 14 May 2012 16:43:03 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FC17@ESESSCMS0360.eemea.ericsson.se>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
 <CAKDXFkM5PFzK-qJ+DJKf4xDJq8Pm4rJkahBzXsd7Wrbxh0E9+A@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FAB4@ESESSCMS0360.eemea.ericsson.se>
 <CAKDXFkMcbNaQrF6shRXmz8bqmPy8aee9XfkqeOa5yA_TVZci_A@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0FC17@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <20120514144303.24286.qmail@stuge.se>

John Olsson M wrote:
> If it is possible to access /etc/passwd from an SSH built-in
> feature to escape from the "shell" to be able to get file access
> of the nodes filesystem to transfer files in and out it is a huge
> difference.

Indeed. I think the sane way to implement this may be in sftp-server.
The problem is of course the marker IPC from the user's shell over to
the not-yet-running sftp-server. :)


> I would definitely prefer it the other way around; Opt-In instead
> of Opt-out. That is you must explicitly ask for the feature to
> enable it; default it should be turned off.

Yes absolutely.


//Peter

From keisial at gmail.com  Tue May 15 00:43:52 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Mon, 14 May 2012 16:43:52 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <4FB11A28.1020302@gmail.com>

On 14/05/12 09:02, John Olsson M wrote:
>> I imagine something like this:
>> The user would run a command such as the following:
>> remoteServer$ cp2local someFile.c
>> The SSH server on the remote host would then push the file to the
>> SSH client running locally just as if scp had been used, but it
>> would reuse the existing connection. The local SSH client would
>> then write the file just as it would have had scp been used.
> You also need to consider the case where the user is *not* running a normal (like TCSH, Bash, ZSH, ...) shell on the server and where the file system is exposed as a virtual filesystem via SFTP (which might run in another chrooted directory than the SSH subsystem).
>
> What would a path to a local file look like in this context?
>
> I see this as a security hole since you suddenly get acess to files via SSH which you do not get access to via SFTP (since it is chrooted)...
>
> /John
If you have shell in the server, and are able to run the cp2local
command, you could presumably also run cat <file> and copy files that
way. So not really a security hole.
But you raise a good point in that opening a sftp connection in the same
ssh session may not be equivalent to the view through the shell.
Maybe cp2local should simply pass the descriptor to a unix socket (or
equivalent, the cp2local connection would be obsiously implementation
defined).



From keisial at gmail.com  Tue May 15 00:59:56 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Mon, 14 May 2012 16:59:56 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <20120514132600.18153.qmail@stuge.se>
References: <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
 <4FAF879C.3000407@gmail.com>
 <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
 <4FAFBB78.6060402@gmail.com>
 <CAKDXFkNY8jye-7c_FMdJEP9f3c=whQJAJZVkdnPp1uiijFJ-hQ@mail.gmail.com>
 <20120514132600.18153.qmail@stuge.se>
Message-ID: <4FB11DEC.50509@gmail.com>

On 14/05/12 15:26, Peter Stuge wrote:
> Dotan Cohen wrote:
>> As we have described it, the cpLocal feature would work something
>> like this:
>>
>> me at local:~$ ls
>> file1 file2
>> me at local:~$ ssh anotherMe at remote
>> anotherMe at remote:~$ ls
>> document1 document2
>> anotherMe at remote:~$ cpLocal document1
>>
>> ----------------------------------    <-- Here opens a "VIM-window" (see above)
>> | me at local: Download document1?  |
>> | [y/N/r/l]?                     |     <-- 'r' is Rename, 'l' is Choose Location
>>
>> anotherMe at remote:~$ exit
>> me at local:~$ ls
>> document1 file1 file2
>> me at local:~$
> Thanks for answering my question about user interface. Unfortunately
> it seems that you are not so aware of how the systems you use
> actually work, and your proposal further does not address the very
> important concerns about a remote system being able to control a
> local client.
>
> What you call the "VIM-popup" can not be created by the local SSH
> client because it is not operating the terminal in a windowed mode.
>
> You would have to study a bit of systems programming and with
> particular focus on how applications can interact with their
> controlling terminal to have a good background for finding a good
> yet viable solution to this user interface problem.
>
> And as I mentioned the above has a rather severe security problem.
> The above can be abused by a remote server to make the logged-in
> session unusable. Re-using your analogy with web browsers, think of
> having a prompt enabled about approving cookies while navigating to
> yahoo.com or cnn.com or some other site with lots of cookies and
> banners. The client effectively becomes useless due to all the
> prompts.
>
> Now, the ~C command line was mentioned. This can be used to realize a
> feature similar to what you ask for, but with some differences, and a
> few technical problems to solve:
>
> * difference: file transfer requests must always be initiated manually
>   on the client in the ~C command line.
> * problem: the client command line does not know the cwd of the
>   remote shell, meaning that relative paths can not be used, which is
>   somehow the whole point of this proposal.
>
> A further variant on this is where on the remote system a file
> transfer is prepared with the semantics of the proposed cp2local
> command, but no transfer begins until an explicit ~C command (or
> perhaps ~D for download) is entered on the client to actually perform
> the transfer. There will be no notification from the client that a
> transfer is pending, because in fact nothing is pending, the transfer
> has only been prepared on the remote side, and will still be
> initiated only by the client, just that on the remote server there is
> now the marker running which identifies what should be transfered.
>
> A technical problem still remains; how all this should work in terms
> of the SSH protocol and what exactly the marker command (cp2local)
> does.
I have been considering a variant of this, where you use a ~command.
~C is already taken, but if could be eg. ~F (for transfering *f*iles).

So when you typed ~F the client opens a sftp channel over the same
connection, and shows you a tree view of files and folders to
browse/download.
If you were on Windows, it could be equivalent to being on a PuTTY session,
and on that action getting a WinSCP spawned (reusing the connection).


From peter at stuge.se  Tue May 15 02:01:13 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 14 May 2012 18:01:13 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <4FB11DEC.50509@gmail.com>
References: <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
 <4FAF879C.3000407@gmail.com>
 <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
 <4FAFBB78.6060402@gmail.com>
 <CAKDXFkNY8jye-7c_FMdJEP9f3c=whQJAJZVkdnPp1uiijFJ-hQ@mail.gmail.com>
 <20120514132600.18153.qmail@stuge.se> <4FB11DEC.50509@gmail.com>
Message-ID: <20120514160113.30824.qmail@stuge.se>

?ngel Gonz?lez wrote:
> > A further variant on this is where on the remote system a file
> > transfer is prepared with the semantics of the proposed cp2local
> > command, but no transfer begins until an explicit ~C command (or
> > perhaps ~D for download) is entered on the client to actually perform
> > the transfer. There will be no notification from the client that a
> > transfer is pending, because in fact nothing is pending, the transfer
> > has only been prepared on the remote side, and will still be
> > initiated only by the client, just that on the remote server there is
> > now the marker running which identifies what should be transfered.
> >
> > A technical problem still remains; how all this should work in terms
> > of the SSH protocol and what exactly the marker command (cp2local)
> > does.
> 
> I have been considering a variant of this, where you use a ~command.
> ~C is already taken, but if could be eg. ~F (for transfering *f*iles).

I was not proposing using ~C as a command since it is obviously
taken, but either adding a command that needs to be typed into the
~C command line, or perhaps using ~D as a shortcut to receive a file.
~U would be the corresponding upload command. There are lots of
variations, ~G(et) ~P(ut), ~S(end) ~R(eceive), and so on.


> So when you typed ~F the client opens a sftp channel over the same
> connection, and shows you a tree view of files and folders to
> browse/download.

Now you are reinventing an SFTP user interface. I think this may be
going too far for OpenSSH. I think it's bad enough that the SFTP
protocol has to be added to the ssh client..

I agree strongly that a filexfer channel is what must be used to
actually perform the transfer.

On Linux it's easy to get the shell's cwd: /proc/childpid/cwd but
what is the situation like on other systems? Unless there is a
portable solution this feature can't really be taken seriously
IMO.

Also, this is a very different user interface than what was
originally requested, and which I think is what makes the most sense.
The question of how exactly the cp2local command will IPC to
sftp-server what file to transfer remains to be solved.


> If you were on Windows, it could be equivalent to being on a PuTTY
> session, and on that action getting a WinSCP spawned (reusing the
> connection).

IMO having an sftp client reuse a connection is a different feature
than requested feature, whose purpose is to save time by being able
to transfer one or more files from remote shell to local filesystem
with very little user interaction.


//Peter

From sdaoden at googlemail.com  Tue May 15 02:06:37 2012
From: sdaoden at googlemail.com (Steffen Daode Nurpmeso)
Date: Mon, 14 May 2012 18:06:37 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <20120514112329.GA1359@greenie.muc.de>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
 <4fb0dd22.HC3DmYYPIDxvCIictt2A2Uos@dietcurd.wild-life.local>
 <20120514112329.GA1359@greenie.muc.de>
Message-ID: <4fb12d8d.CNFgcvv4QMK1xUYv3FeMHnrj@dietcurd.wild-life.local>

Hallo,

Gert Doering <gert at greenie.muc.de> wrote:

 | Hi,
 |
 | On Mon, May 14, 2012 at 12:23:30PM +0200, Steffen Daode Nurpmeso wrote:
 | >   myself at local-host$ ssh myself at host-over-ssh
 | >   myself at host-over-ssh$ ~Copy_file path_on_local-host path(_on_host-over-ssh)
 | > 
 | > Why should this open a security hole, given that
 | > myself at host-over-ssh has proper permissions for
 | > path_on_host-over-ssh?  
 |
 | If you're just talking about from-local-to-remote, one thing that comes
 | to mind is "an evil remote host stealing your local files without your
 | doing".

I don't think this would be possible, since this should all end up
in process_escapes() (talking about command setup and such).
I.e., it should all be filtered by the local client which drives
the interactive terminal session, before any data is sent over the
connection at all.

 | So while I can understand the convenience factor of this, making it
 | properly secure (like "only operate out of a well-defined quarantaine
 | folder on local-host, and do not permit absolute or relative path names
 | with '..' in them") are likely ging to make this inconvenient enough
 | to then not-use it...

It's not the convenience, it's just sitting on front of the
computer and using the keyboard and having that schizophrenic
situation best described as

  All i want to do is '$ cp LOCAL/.vimrc ~/.vimrc', the
  connection is established and i could use '$ cat > ~/.vimrc' and
  copy+paste and it would do exactly that!

Grrrrmmpf!

  Instead i need to switch console and use an explicit scp or
  whatever, that does *so many things* before that simple operation
  is actually performed.

I'm with the original poster - i know these feelings as of my own
experience.  

However i'm not familiar with the actual protocol/RFCs and thus
the question how this could be implemented on the client/server
interaction side beyond my knowledge for a foreseeable period of
time.  And one of the previous answers doesn't give that much hope
in respect to this.

--steffen
Forza Figa!

From peter at stuge.se  Tue May 15 02:21:38 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 14 May 2012 18:21:38 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <4fb12d8d.CNFgcvv4QMK1xUYv3FeMHnrj@dietcurd.wild-life.local>
References: <CAKDXFkPFd0=khFWeseN6mBM+EBKmOQtrAsJ=Xd9qZjsbXz9nNg@mail.gmail.com>
 <86pqapjkjb.fsf@ds4.des.no>
 <CAKDXFkOwcXH4sgTtX6PQ3y5frS9SBYbpjFSUd_8VPEabxFC+cw@mail.gmail.com>
 <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD20E0F8CE@ESESSCMS0360.eemea.ericsson.se>
 <4fb0dd22.HC3DmYYPIDxvCIictt2A2Uos@dietcurd.wild-life.local>
 <20120514112329.GA1359@greenie.muc.de>
 <4fb12d8d.CNFgcvv4QMK1xUYv3FeMHnrj@dietcurd.wild-life.local>
Message-ID: <20120514162138.32544.qmail@stuge.se>

Steffen Daode Nurpmeso wrote:
> However i'm not familiar with the actual protocol/RFCs and thus
> the question how this could be implemented on the client/server
> interaction side beyond my knowledge for a foreseeable period of
> time.

So take the time to study the protocol and what an actual sshd must
do. It's not very difficult.


> And one of the previous answers doesn't give that much hope
> in respect to this.

It's less about the protocol and more about sending messages to a
process which does not yet exist.


//Peter

From mhagger at alum.mit.edu  Wed May 16 19:32:17 2012
From: mhagger at alum.mit.edu (Michael Haggerty)
Date: Wed, 16 May 2012 11:32:17 +0200
Subject: Idea for feature recursive ssh: "scp file user1@gateway:user2@server:"
Message-ID: <4FB37421.2040202@alum.mit.edu>

[I sent this email to the list in January but haven't seen it appear. 
Maybe it didn't get through moderation?]

How many times have I typed in one window

     ssh -L 8022:server:22 user1 at gateway

only so that I can type (in another window!)

     scp -P 8022 file user2 at localhost:

This is a pain:

* cumbersome
* requires two commands windows
* confuses ssh's host key verification

Obviously if one is always accessing the same hosts then it is possible
to simplify the steps using configuration, but I don't know of a way to
make this really easy if there are many remote servers.  Also, the
manner of accessing the servers might be different when you are inside
vs. outside the firewall, making the configuration approach awkward.

It would be very cool to be able to type something like

     scp file user1 at gateway:user2 at server:

and have SSH do the tunneling by itself.

Maybe there is already an easy way to accomplish the same thing, but it
is unknown to me.

The same syntax could be used for ssh itself:

     ssh user1 at gateway:user2 at server

though admittedly this isn't quite such a big win compared to the
approximately equivalent

     ssh -t user1 at gateway ssh user2 at server

Thank you for your attention,
Michael

-- 
Michael Haggerty
mhagger at alum.mit.edu
http://softwareswirl.blogspot.com/

From saku at ytti.fi  Wed May 16 20:15:36 2012
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 16 May 2012 13:15:36 +0300
Subject: Idea for feature recursive ssh: "scp file
 user1@gateway:user2@server:"
In-Reply-To: <4FB37421.2040202@alum.mit.edu>
References: <4FB37421.2040202@alum.mit.edu>
Message-ID: <CAAeewD-b0j5gG1AL1jbEe+qp-QDG0+_HrrzSF7-Jsnd2fSuDHQ@mail.gmail.com>

On 16 May 2012 12:32, Michael Haggerty <mhagger at alum.mit.edu> wrote:

> How many times have I typed in one window
>
> ? ?ssh -L 8022:server:22 user1 at gateway
>
> only so that I can type (in another window!)
>
> ? ?scp -P 8022 file user2 at localhost:

+1. Not far from what I propose here:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2011-October/030030.html

----
Or maybe just 'ssh box1,box2,box3' which would be equivalent to

cat >> .ssh/config
box3
  path box1,box2
---


-- 
? ++ytti

From dtucker at zip.com.au  Wed May 16 20:23:01 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 16 May 2012 20:23:01 +1000
Subject: Idea for feature recursive ssh: "scp file
 user1@gateway:user2@server:"
In-Reply-To: <4FB37421.2040202@alum.mit.edu>
References: <4FB37421.2040202@alum.mit.edu>
Message-ID: <20120516102301.GA28540@gate.dtucker.net>

On Wed, May 16, 2012 at 11:32:17AM +0200, Michael Haggerty wrote:
> [I sent this email to the list in January but haven't seen it
> appear. Maybe it didn't get through moderation?]
> 
> How many times have I typed in one window
> 
>     ssh -L 8022:server:22 user1 at gateway
> 
> only so that I can type (in another window!)
> 
>     scp -P 8022 file user2 at localhost:

You want ProxyCommand + ssh -W.  Try this:

ssh -o 'ProxyCommand ssh -W user2 at gateway:%p' user2 at gateway

or the equivalent in ~/.ssh/config

Host server
	ProxyCommand ssh -W %h:%p server
	User user2

Host gateway
	User user1

Basically, you're using "ssh -W" (aka "netcat mode") as a ProxyCommand.
This logs into "gateway", then establishes a TCP port forwarding and
passes the traffic over stdin/stdout.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From 1282923005 at qq.com  Wed May 16 22:30:02 2012
From: 1282923005 at qq.com (=?gb18030?B?9q32rQ==?=)
Date: Wed, 16 May 2012 20:30:02 +0800
Subject: where is the struct RSA defined??
Message-ID: <tencent_7B40B507707867FF3078B844@qq.com>

In the source code of openssh(my source code is 6.0 for Openbsd??
The content below is Rsa.h

#ifndef RSA_H
#define RSA_H

#include <openssl/bn.h>
#include <openssl/rsa.h>

void     rsa_public_encrypt(BIGNUM *, BIGNUM *, RSA *);
int     rsa_private_decrypt(BIGNUM *, BIGNUM *, RSA *);
void     rsa_generate_additional_parameters(RSA *);

#endif                /* RSA_H */

Question:
    Where is the file openssl/rsa.h? So where is the struct RSA defined??

From tomas.kuthan at oracle.com  Wed May 16 23:03:51 2012
From: tomas.kuthan at oracle.com (Tomas Kuthan)
Date: Wed, 16 May 2012 15:03:51 +0200
Subject: where is the struct RSA defined??
In-Reply-To: <tencent_7B40B507707867FF3078B844@qq.com>
References: <tencent_7B40B507707867FF3078B844@qq.com>
Message-ID: <4FB3A5B7.6090009@oracle.com>

On 05/16/12 14:30, ?? wrote:
> In the source code of openssh(my source code is 6.0 for Openbsd??
> The content below is Rsa.h
>
> #ifndef RSA_H
> #define RSA_H
>
> #include<openssl/bn.h>
> #include<openssl/rsa.h>
>
> void     rsa_public_encrypt(BIGNUM *, BIGNUM *, RSA *);
> int     rsa_private_decrypt(BIGNUM *, BIGNUM *, RSA *);
> void     rsa_generate_additional_parameters(RSA *);
>
> #endif                /* RSA_H */
>
> Question:
>      Where is the file openssl/rsa.h? So where is the struct RSA defined??

Well, as the filepath suggests, in OpenSSL:
http://cvs.openssl.org/fileview?f=openssl/crypto/rsa/rsa.h&v=1.91

  (look for "struct rsa_st")

Tomas


From nicola.muto at cryptolab.net  Wed May 16 23:20:52 2012
From: nicola.muto at cryptolab.net (Nicola Muto)
Date: Wed, 16 May 2012 13:20:52 +0000
Subject: where is the struct RSA =?UTF-8?Q?defined=3F=3F?=
In-Reply-To: <tencent_7B40B507707867FF3078B844@qq.com>
References: <tencent_7B40B507707867FF3078B844@qq.com>
Message-ID: <bc8419736b2a77d25bfb747098b2db24@cryptolab.net>

Hi,

try into the directory /usr/include/openssl.

The RSA structure should be declared into the file 
/usr/include/openssl/ossl_typ.h
included by the file rsa.h.

BRs
\\nm


On 2012-05-16 12:30, ?? wrote:
> In the source code of openssh(my source code is 6.0 for Openbsd??
> The content below is Rsa.h
>
> #ifndef RSA_H
> #define RSA_H
>
> #include <openssl/bn.h>
> #include <openssl/rsa.h>
>
> void     rsa_public_encrypt(BIGNUM *, BIGNUM *, RSA *);
> int     rsa_private_decrypt(BIGNUM *, BIGNUM *, RSA *);
> void     rsa_generate_additional_parameters(RSA *);
>
> #endif                /* RSA_H */
>
> Question:
>     Where is the file openssl/rsa.h? So where is the struct RSA 
> defined??
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From reza.hedayat at adnovum.ch  Thu May 17 01:09:11 2012
From: reza.hedayat at adnovum.ch (Reza Hedayat)
Date: Wed, 16 May 2012 17:09:11 +0200
Subject: Invalid user name: function okname() in scp.c
In-Reply-To: <4F853C97.3040203@adnovum.ch>
References: <4F56500F.9040808@adnovum.ch> <4F565A2E.5040800@gmail.com>
 <4F572BA6.6010003@adnovum.ch> <4F607BE9.30508@adnovum.ch>
 <4F63D924.6020708@gmail.com> <4F853C97.3040203@adnovum.ch>
Message-ID: <4FB3C317.3090706@adnovum.ch>

Hi ?ngel

I've just wanted to enquire about the status of the discussed problem 
concerning the prohibition of hash sign characters in usernames by using 
scp.
Is there a chance that you will remove the complete constraint from the 
function okname()?.

Best wishes
Reza


On 04/11/12 10:11, Reza Hedayat wrote:
> Hi ?ngel
>
> Sorry for my late response, but your solution approach was in 
> clarification.
> Unfortunately, all user names on the IBM AS/400 systems of our 
> customer have a hash sign at the *first position*.
> Therefore, your solution will not solve this problem.
>
> As I've written in my last mail, SSH client and SFTP work perfectly 
> with # characters in user names.
> Therefore, SCP should also work identically.
> So, why can't we just adapt the logic in SCP and allow # characters 
> like in SSH and SFTP?
>
> Best wishes
> Reza
>
>
> On 03/17/12 01:21, ?ngel Gonz?lez wrote:
>> On 14/03/12 12:07, Reza Hedayat wrote:
>>> Hi ?ngel
>>>
>>> I just wanted to enquire if there is a chance that you will remove the
>>> hash sign (#) validation from the OpenSSH code base.
>>>
>>> Even the attempt to escape the # character results in rejection of the
>>> complete command by SCP.
>>> SSH client and SFTP work perfectly with # characters in user names, it
>>> is just SCP that rejects it.
>>> On the server side there are IBM AS/400 systems having usernames
>>> containing # characters, which are completely valid, legal and
>>> commonplace on that platform.
>>>
>>> Best wishes
>>> Reza
>> Hello Reza,
>> I gave it a go. See the attached patch.
>> I just allowed # in the middle of a word, which _should_ be safe to do,
>> as in it's only special for a shell as the first token character (per
>> POSIX rules).
>> It seems to work fine.
>>
>> Best regards
>>
>>
>>

-- 
AdNovum Informatik AG
Reza Hedayat, Software Engineer
Dipl. Informatik-Ing. FH

Roentgenstrasse 22, CH-8005 Zurich
mailto:reza.hedayat at adnovum.ch
phone: +41 44 272 6111, fax: +41 44 272 6312
http://www.adnovum.ch

AdNovum Locations: Bern, Budapest, Singapore, Zurich (HQ)


From mhagger at alum.mit.edu  Thu May 17 02:54:42 2012
From: mhagger at alum.mit.edu (Michael Haggerty)
Date: Wed, 16 May 2012 18:54:42 +0200
Subject: Idea for feature recursive ssh: "scp file
 user1@gateway:user2@server:"
In-Reply-To: <20120516102301.GA28540@gate.dtucker.net>
References: <4FB37421.2040202@alum.mit.edu>
 <20120516102301.GA28540@gate.dtucker.net>
Message-ID: <4FB3DBD2.1070906@alum.mit.edu>

On 05/16/2012 12:23 PM, Darren Tucker wrote:
> On Wed, May 16, 2012 at 11:32:17AM +0200, Michael Haggerty wrote:
>> [I sent this email to the list in January but haven't seen it
>> appear. Maybe it didn't get through moderation?]
>>
>> How many times have I typed in one window
>>
>>      ssh -L 8022:server:22 user1 at gateway
>>
>> only so that I can type (in another window!)
>>
>>      scp -P 8022 file user2 at localhost:
>
> You want ProxyCommand + ssh -W.  Try this:
>
> ssh -o 'ProxyCommand ssh -W user2 at gateway:%p' user2 at gateway

Yikes, that's not very obvious.  Even now that you've shown me the 
necessary options, it's quite difficult to figure out--but I guess your 
command needs to be corrected to

     ssh -o 'ProxyCommand ssh -W server:%p user1 at gateway' user2 at server

> or the equivalent in ~/.ssh/config
>
> Host server
> 	ProxyCommand ssh -W %h:%p server
> 	User user2
>
> Host gateway
> 	User user1

And shouldn't that be

Host server
	ProxyCommand ssh -W %h:%p gateway
	User user2

Host gateway
	User user1

?  It's good that there is a solution, but I think that these commands 
are too obscure and cumbersome to use on a daily basis.  So it would 
still be great to have a shorthand for multi-hop connections such as the 
one that I suggested or the --via or host,host: suggestions that were 
made in the mailing list thread that Saku Ytti pointed out.

Michael

-- 
Michael Haggerty
mhagger at alum.mit.edu
http://softwareswirl.blogspot.com/

From peter at stuge.se  Thu May 17 03:31:27 2012
From: peter at stuge.se (Peter Stuge)
Date: Wed, 16 May 2012 19:31:27 +0200
Subject: Idea for feature recursive ssh: "scp file
 user1@gateway:user2@server:"
In-Reply-To: <4FB3DBD2.1070906@alum.mit.edu>
References: <4FB37421.2040202@alum.mit.edu>
 <20120516102301.GA28540@gate.dtucker.net> <4FB3DBD2.1070906@alum.mit.edu>
Message-ID: <20120516173127.14974.qmail@stuge.se>

Michael Haggerty wrote:
> I think that these commands are too obscure and cumbersome to use
> on a daily basis.

I configure them once and use them forever. IMO it's even better
because I don't even have to use a path; I know that the path is
always used.


//Peter

From whit at transpect.com  Thu May 17 04:25:46 2012
From: whit at transpect.com (Whit Blauvelt)
Date: Wed, 16 May 2012 14:25:46 -0400
Subject: Is there any method, with ChrootDirectory and internal-sftp, to
 automatically cd to a subdir on login?
In-Reply-To: <20120510233440.897.qmail@stuge.se>
References: <20120510231058.GA14673@black.transpect.com>
 <20120510233440.897.qmail@stuge.se>
Message-ID: <20120516182546.GA12864@black.transpect.com>

Peter,

Thanks, but as I understand it that's not an applicable answer in my
circumstance. I need each user to have a unique root directory rather than
have users share one.

If the ChrootDirectory were /home and the users were /home/user1 and
/home/user2 what you suggest would work. But in my case the ChrootDirectory
is %h and the place the users need to end up is %h/files. 

This is trivial to do with scponly. Just set the home directory in
/etc/passwd to be /home/user1//files so the chroot is /home/user1 and the cd
is to /home/user1/files. What I'd like is that same functionality using
OpenSSH's internal sftp server.

I need to chroot my users separately rather than to a common chroot because
the users and their files need to be totally invisible to each other, no
matter what.

Best,
Whit

On Fri, May 11, 2012 at 01:34:40AM +0200, Peter Stuge wrote:
> Whit Blauvelt wrote:
> > Thanks for any advice
> 
> Quoting sshd_config(8):
> 
>      ChrootDirectory
>              Specifies the pathname of a directory to chroot(2) to after
>              authentication.  All components of the pathname must be root-
>              owned directories that are not writable by any other user or
>              group.  After the chroot, sshd(8) changes the working directory
>              to the user's home directory.
> 
> So set the home directory to what you want them to land in, relative
> the ChrootDirectory root.
> 
> 
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From saku at ytti.fi  Thu May 17 04:32:45 2012
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 16 May 2012 21:32:45 +0300
Subject: Idea for feature recursive ssh: "scp file
 user1@gateway:user2@server:"
In-Reply-To: <20120516173127.14974.qmail@stuge.se>
References: <4FB37421.2040202@alum.mit.edu>
 <20120516102301.GA28540@gate.dtucker.net>
 <4FB3DBD2.1070906@alum.mit.edu>
 <20120516173127.14974.qmail@stuge.se>
Message-ID: <CAAeewD-CVwVKBovYXW+UXVXVZ6erWoKFwroRfWfRuZBs0AWoDw@mail.gmail.com>

On 16 May 2012 20:31, Peter Stuge <peter at stuge.se> wrote:

> I configure them once and use them forever. IMO it's even better
> because I don't even have to use a path; I know that the path is
> always used.

This works well if you use few systems for long time. Some people use
lot of systems for short time, and those people would appreciate
little syntactic sugar.

-- 
? ++ytti

From peter at stuge.se  Thu May 17 05:43:22 2012
From: peter at stuge.se (Peter Stuge)
Date: Wed, 16 May 2012 21:43:22 +0200
Subject: Is there any method, with ChrootDirectory and internal-sftp,
 to automatically cd to a subdir on login?
In-Reply-To: <20120516182546.GA12864@black.transpect.com>
References: <20120510231058.GA14673@black.transpect.com>
 <20120510233440.897.qmail@stuge.se>
 <20120516182546.GA12864@black.transpect.com>
Message-ID: <20120516194322.26535.qmail@stuge.se>

Whit Blauvelt wrote:
> as I understand it that's not an applicable answer in my
> circumstance. I need each user to have a unique root directory

You can chroot into whatever directory you want, and as the man page
I quoted clearly says there will be a chdir performed after that
chroot, to the directory that has been configured as the home
directory for the user, and naturally that configuration must take
into account the chroot.


> in my case the ChrootDirectory is %h and the place the users need
> to end up is %h/files.

You can obviously not use the home directory to identify the chroot
if you want to use it for chdiring. You can probably quite easily
configure the correct path for chrooting without using the home
directory, and instead set the home directory to /files for the
relevant users to get exactly what you want.


> This is trivial to do with scponly. Just set the home directory in
> /etc/passwd to be /home/user1//files

Sorry, but that is a mindbogglingly bad idea. It is overloading a
case where there is already absolutely well-defined behavior. Of
course it may work, but it may also fail completely in the face of
less typical circumstances. It's neither smart nor elegant to try to
create some conflicting standard where there is already one.


> What I'd like is that same functionality using OpenSSH's internal
> sftp server.

It's documented how you can get the same result and I not only quoted
you the docs but even wrote a quick summary of how it would work.

Try it out! I think it will work fine.


//Peter

From keisial at gmail.com  Thu May 17 07:13:20 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Wed, 16 May 2012 23:13:20 +0200
Subject: Is there any method, with ChrootDirectory and internal-sftp,
 to automatically cd to a subdir on login?
In-Reply-To: <20120516194322.26535.qmail@stuge.se>
References: <20120510231058.GA14673@black.transpect.com>
 <20120510233440.897.qmail@stuge.se>
 <20120516182546.GA12864@black.transpect.com>
 <20120516194322.26535.qmail@stuge.se>
Message-ID: <4FB41870.6060007@gmail.com>

Peter Stuge wrote:
> Whit Blauvelt wrote:
>> in my case the ChrootDirectory is %h and the place the users need
>> to end up is %h/files.
> You can obviously not use the home directory to identify the chroot
> if you want to use it for chdiring. You can probably quite easily
> configure the correct path for chrooting without using the home
> directory, and instead set the home directory to /files for the
> relevant users to get exactly what you want.
>
>
>> This is trivial to do with scponly. Just set the home directory in
>> /etc/passwd to be /home/user1//files
> Sorry, but that is a mindbogglingly bad idea. It is overloading a
> case where there is already absolutely well-defined behavior. Of
> course it may work, but it may also fail completely in the face of
> less typical circumstances. It's neither smart nor elegant to try to
> create some conflicting standard where there is already one.
If the user folder is /home/username, just change the

ChrootDirectory to /home/%u, and then make their home /home/user1/files



From peter at stuge.se  Thu May 17 07:27:01 2012
From: peter at stuge.se (Peter Stuge)
Date: Wed, 16 May 2012 23:27:01 +0200
Subject: Is there any method, with ChrootDirectory and internal-sftp,
 to automatically cd to a subdir on login?
In-Reply-To: <4FB41870.6060007@gmail.com>
References: <20120510231058.GA14673@black.transpect.com>
 <20120510233440.897.qmail@stuge.se>
 <20120516182546.GA12864@black.transpect.com>
 <20120516194322.26535.qmail@stuge.se> <4FB41870.6060007@gmail.com>
Message-ID: <20120516212701.2021.qmail@stuge.se>

?ngel Gonz?lez wrote:
> Peter Stuge wrote:
> > set the home directory to /files for the relevant users
> 
> If the user folder is /home/username, just change the
> ChrootDirectory to /home/%u, and then make their home
> /home/user1/files

As I wrote, the home directory should be /files in that case.


//Peter

From keisial at gmail.com  Thu May 17 07:35:30 2012
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Wed, 16 May 2012 23:35:30 +0200
Subject: Transferring file to local machine when SSHing into a foreign box
In-Reply-To: <20120514160113.30824.qmail@stuge.se>
References: <4FA99238.9090004@gmail.com>
 <CAKDXFkMHeXu-upw0HFZ_rbatdvRYe2nwf_1KmbUUtm7nVA1mfg@mail.gmail.com>
 <4FAEE7F6.2060007@gmail.com>
 <CAKDXFkPxMkvFKwXTzaEtfyWp36Ytxg_Dp_2c0RMiVXzzP6XmxA@mail.gmail.com>
 <4FAF879C.3000407@gmail.com>
 <CAKDXFkNpZz4npOOc2MoX6MGPsa4bxZsw1YfU3v3fLwM5MHshvA@mail.gmail.com>
 <4FAFBB78.6060402@gmail.com>
 <CAKDXFkNY8jye-7c_FMdJEP9f3c=whQJAJZVkdnPp1uiijFJ-hQ@mail.gmail.com>
 <20120514132600.18153.qmail@stuge.se> <4FB11DEC.50509@gmail.com>
 <20120514160113.30824.qmail@stuge.se>
Message-ID: <4FB41DA2.8070505@gmail.com>

On 14/05/12 18:01, Peter Stuge wrote:
> There are lots of
> variations, ~G(et) ~P(ut), ~S(end) ~R(eceive), and so on.
Sure, the actual option is not that important.

>> So when you typed ~F the client opens a sftp channel over the same
>> connection, and shows you a tree view of files and folders to
>> browse/download.
> Now you are reinventing an SFTP user interface. 
I think it's what they need.

> I think this may be going too far for OpenSSH. I think it's bad enough that the SFTP
> protocol has to be added to the ssh client..
Yes, it seems odd for the command line client provided by OpenSSH. It
may be possible to simply spawn sftp binary instead of implementing sftp
in ssh, though.

> I agree strongly that a filexfer channel is what must be used to
> actually perform the transfer.
>
> On Linux it's easy to get the shell's cwd: /proc/childpid/cwd but
> what is the situation like on other systems? Unless there is a
> portable solution this feature can't really be taken seriously
> IMO.
It seems to be platform dependant. Not all UNIX systems contain a /proc
fs, and even on those who have one, they might not have cwd. For
instance, Solaris seems to have a cwd symlink on /proc/pid, but it
apparently points nowhere :S

Also, even on Linux, take into account that we are not communicating
with the shell, /proc/childpid/cwd would have to be sent to local by
sshd. Also it may have a different view of the fs tree, I'm not sure if
it's under the same chroot as the shell.


> Also, this is a very different user interface than what was
> originally requested, and which I think is what makes the most sense.
> The question of how exactly the cp2local command will IPC to
> sftp-server what file to transfer remains to be solved.
Well, the interface was "You write something on the shell and the file
gets copied",
I just changed cp2local with ~F so that it would be trapped by the local
client :)

>> If you were on Windows, it could be equivalent to being on a PuTTY
>> session, and on that action getting a WinSCP spawned (reusing the
>> connection).
> IMO having an sftp client reuse a connection is a different feature
> than requested feature, whose purpose is to save time by being able
> to transfer one or more files from remote shell to local filesystem
> with very little user interaction.
Not at all. Half of the advantage of doing it from the open shell is
that they skip all the connection and authentication steps (specially if
they're using keyboard-interactive).


From keisial at gmail.com  Thu May 17 08:29:26 2012
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Thu, 17 May 2012 00:29:26 +0200
Subject: Is there any method, with ChrootDirectory and internal-sftp,
 to automatically cd to a subdir on login?
In-Reply-To: <20120516212701.2021.qmail@stuge.se>
References: <20120510231058.GA14673@black.transpect.com>
 <20120510233440.897.qmail@stuge.se>
 <20120516182546.GA12864@black.transpect.com>
 <20120516194322.26535.qmail@stuge.se> <4FB41870.6060007@gmail.com>
 <20120516212701.2021.qmail@stuge.se>
Message-ID: <4FB42A46.3070209@gmail.com>

On 16/05/12 23:27, Peter Stuge wrote:
> ?ngel Gonz?lez wrote:
>> Peter Stuge wrote:
>>> set the home directory to /files for the relevant users
>> If the user folder is /home/username, just change the
>> ChrootDirectory to /home/%u, and then make their home
>> /home/user1/files
> As I wrote, the home directory should be /files in that case.
>
>
> //Peter
Right. Sorry for the confusion. Their home directory should be /files,
which would map to /home/user1/files, but you set it to /files


From yhwebmail at gmail.com  Thu May 17 13:10:03 2012
From: yhwebmail at gmail.com (YH)
Date: Thu, 17 May 2012 13:10:03 +1000
Subject: Programming API for SSH tunnelling
Message-ID: <CAJ0X3Cvu7L8a5z79pc84gz-DcrF_CY_tJZXBMuV+h0Dy41i_MQ@mail.gmail.com>

Hi,

Is it possible to program ssh tunneling in C or C++ rather than to use
shell command? Are there any APIs for ssh tunneling available? I was told
by friends that the openssh is working on it, please point me which version
of openssh support API ssh tunneling.

Thank you.

Kind regards,

J. yh

From dan at doxpara.com  Thu May 17 13:19:25 2012
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 16 May 2012 20:19:25 -0700
Subject: Programming API for SSH tunnelling
In-Reply-To: <CAJ0X3Cvu7L8a5z79pc84gz-DcrF_CY_tJZXBMuV+h0Dy41i_MQ@mail.gmail.com>
References: <CAJ0X3Cvu7L8a5z79pc84gz-DcrF_CY_tJZXBMuV+h0Dy41i_MQ@mail.gmail.com>
Message-ID: <CAEW7ACmwey5mLwbbMp_J9R-n-mCccQ5-He+O_PO=2c_903ob0A@mail.gmail.com>

http://www.libssh2.org/

Good luck!

On Wed, May 16, 2012 at 8:10 PM, YH <yhwebmail at gmail.com> wrote:

> Hi,
>
> Is it possible to program ssh tunneling in C or C++ rather than to use
> shell command? Are there any APIs for ssh tunneling available? I was told
> by friends that the openssh is working on it, please point me which version
> of openssh support API ssh tunneling.
>
> Thank you.
>
> Kind regards,
>
> J. yh
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From aris at 0xbadc0de.be  Thu May 17 18:14:47 2012
From: aris at 0xbadc0de.be (Aris Adamantiadis)
Date: Thu, 17 May 2012 10:14:47 +0200
Subject: Programming API for SSH tunnelling
In-Reply-To: <CAEW7ACmwey5mLwbbMp_J9R-n-mCccQ5-He+O_PO=2c_903ob0A@mail.gmail.com>
References: <CAJ0X3Cvu7L8a5z79pc84gz-DcrF_CY_tJZXBMuV+h0Dy41i_MQ@mail.gmail.com>
 <CAEW7ACmwey5mLwbbMp_J9R-n-mCccQ5-He+O_PO=2c_903ob0A@mail.gmail.com>
Message-ID: <4FB4B377.8010103@0xbadc0de.be>

I'd also add http://www.libssh.org/ :)

And too good luck !

Aris

Le 17/05/12 05:19, Dan Kaminsky a ?crit :
> http://www.libssh2.org/
> 
> Good luck!
> 
> On Wed, May 16, 2012 at 8:10 PM, YH <yhwebmail at gmail.com> wrote:
> 
>> Hi,
>>
>> Is it possible to program ssh tunneling in C or C++ rather than to use
>> shell command? Are there any APIs for ssh tunneling available? I was told
>> by friends that the openssh is working on it, please point me which version
>> of openssh support API ssh tunneling.
>>
>> Thank you.
>>
>> Kind regards,
>>
>> J. yh
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From yhwebmail at gmail.com  Thu May 17 22:04:14 2012
From: yhwebmail at gmail.com (YH)
Date: Thu, 17 May 2012 22:04:14 +1000
Subject: Programming API for SSH tunnelling
Message-ID: <CAJ0X3CuioA89TA2RZr8293u+gzao7qPaqP5QrKRVE1i0sDPH2A@mail.gmail.com>

Thanks Dan and Aris, that's great.
Cheers.
yh


On 2012-05-16 20:19-0700, Dan Kaminsky wrote:
>http://www.libssh2.org/
>
>Good luck!

From nicola.muto at cryptolab.net  Fri May 18 00:19:36 2012
From: nicola.muto at cryptolab.net (Nicola Muto)
Date: Thu, 17 May 2012 16:19:36 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
Message-ID: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>

Hello everybody,

I'm a C/C++ consultant working for Ericsson.

I changed the OpenSSH-Portable code to add a new criteria
into the Match sshd_config option read by the sshd server.

The new criteria is "Subsystem"; so a conditional block based
on subsystem client request can now be added to the sshd_config
configuration server file to override settings in its global
section.

Ericsson requested this new Subsystem criteria because it needs
to "chroot" all the sftp session into a well defined directory
for all users logging into the server from an sftp client.

For details on the Ericsson needs, please refer to the following
OpenSSH mailing list thread

     http://marc.info/?t=132698105300002&r=1&w=2

A little example of the Match Subsystem usage follows

   Match Subsystem sftp
       ChrootDirectory /path/to/sftp/data/jail/on/the/server
       X11Forwarding no
       AllowTcpForwarding no
       ForceCommand internal-sftp

To ensure that the Match Subsystem conditional block will work
properly, that is, the server "chroots" into the directory
specified by the ChrootDirectory directive above, you must also
disable the privilege separation using the config directive

   UsePrivilegeSeparation no

into the sshd_config file. At least I think so; I checked that
the sshd server will skip calling the safely_chroot function if I
keep the privilege separation enabled and login using a no-root user.

I worked on the portable branch of OpenSSH because this feature must be
installed on a SLES (SuSE linux Enterprise Server) distribution.

For the code changes I started from the openssh-6.0p1 released on April
22, 2012, and I followed changes recently made by Darren Tucker to add
other two criteria for the Match option; i.e. LocalAddress and 
LocalPort.
So, my changes are minimized and will be gladly accepted by the OpenSSH
community. :-)
Thank you Darren.

I do not know who should accept and confirm my code changes. Also I 
don't have
an account to check-in the changes into the OpenBSD SVC repository
Hans can you help me?

BRs
\\nm

The diff code list follows

===============================================================================
diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/auth.c 
src/auth.c
===============================================================================
546a547
> 	ConnectionInfo connection_info;
548,549c549,554
< 	parse_server_match_config(&options, user,
< 	    get_canonical_hostname(options.use_dns), get_remote_ipaddr());
---
> 	connection_info.user = user;
> 	connection_info.host = get_canonical_hostname(options.use_dns);
> 	connection_info.address = get_remote_ipaddr();
> 	connection_info.subsystem = NULL;
>
> 	parse_server_match_config(&options, &connection_info);

=======================================================================================
diff -r 
/home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/servconf.c 
src/servconf.c
=======================================================================================
601,602c601
< match_cfg_line(char **condition, int line, const char *user, const 
char *host,
<     const char *address)
---
> match_cfg_line(char **condition, int line, ConnectionInfo *ci)
606a606,614
> 	const char *user = NULL;
> 	const char *host = NULL;
> 	const char *address = NULL;
> 	const char *subsystem = NULL;
>
> 	/* Here the condition is hold
> 	 *     ci==NULL ==> user==NULL
> 	 * that is, it is not possible that ci==NULL but user!=NULL
> 	 */
608c616
< 	if (user == NULL)
---
> 	if (ci == NULL)
610,611c618,624
< 	else
< 		debug3("checking match for '%s' user %s host %s addr %s", cp,
---
> 	else {
> 		user = ci->user;
> 		host = ci->host;
> 		address = ci->address;
> 		subsystem = ci->subsystem;
>
> 		debug3("checking match for '%s' user %s host %s addr %s subsystem 
> %s", cp,
613c626,627
< 		    address ? address : "(null)");
---
> 		    address ? address : "(null)", subsystem ? subsystem : 
> "(null)");
> 	}
622c636,639
< 			if (!user) {
---
> 			if (!user) { /* For clarity: it should be "if (!ci || !user) {" 
> but the two expressions have
> 										* exactly the same values under the above condition that
> 										* (ci==NULL) ==> (user==NULL).
> 			 	 	 	 	 	 	 	*/
631a649,652
> 			if (!user) { /* Same comment as above */
> 				result = 0;
> 				continue;
> 			}
639c660
< 			if (!host) {
---
> 			if (!host) { /* Same comment on the condition as user above */
648a670,673
> 			if (!address) { /* Same comment on the condition as user above */
> 				result = 0;
> 				continue;
> 			}
660a686,695
> 		} else if (strcasecmp(attrib, "subsystem") == 0) {
> 			if (!subsystem) {
> 				result = 0;
> 				continue;
> 			}
> 			if (match_pattern_list(subsystem, arg, len, 0) != 1)
> 				result = 0;
> 			else
> 				debug("subsystem %.100s matched 'Subsystem %.100s' at "
> 				    "line %d", subsystem, arg, line);
666c701,702
< 	if (user != NULL)
---
>
> 	if (ci != NULL)
667a704
>
713,714c750
<     const char *filename, int linenum, int *activep, const char 
*user,
<     const char *host, const char *address)
---
>     const char *filename, int linenum, int *activep, ConnectionInfo 
> *conninfo)
745c781
< 		if (user == NULL) {
---
> 		if (conninfo == NULL) {
1316c1352,1354
< 		value = match_cfg_line(&cp, linenum, user, host, address);
---
>
> 		value = match_cfg_line(&cp, linenum, conninfo);
>
1454,1455c1492
< parse_server_match_config(ServerOptions *options, const char *user,
<     const char *host, const char *address)
---
> parse_server_match_config(ServerOptions *options, ConnectionInfo 
> *conninfo)
1460c1497
< 	parse_server_config(&mo, "reprocess config", &cfg, user, host, 
address);
---
> 	parse_server_config(&mo, "reprocess config", &cfg, conninfo);
1463a1501,1536
> int
> parse_server_match_testspec(ConnectionInfo *ci, char *spec)
> {
> 	char *p;
>
> 	while ((p = strsep(&spec, ",")) && *p != '\0') {
> 		if (strncmp(p, "addr=", 5) == 0)
> 			ci->address = xstrdup(p + 5);
> 		else if (strncmp(p, "host=", 5) == 0)
> 			ci->host = xstrdup(p + 5);
> 		else if (strncmp(p, "user=", 5) == 0)
> 			ci->user = xstrdup(p + 5);
> 		else if (strncmp(p, "subsystem=", 10) == 0)
> 			ci->subsystem = xstrdup(p + 10);
> 		else {
> 			fprintf(stderr, "Invalid test mode specification %s\n", p);
> 			return -1;
> 		}
> 	}
> 	return 0;
> }
>
> /*
>  * returns 1 for a complete spec, 0 for partial spec and -1 for an
>  * empty spec.
>  */
> int
> server_match_spec_complete(ConnectionInfo *ci)
> {
> 	if (ci->user && ci->host && ci->address)
> 		return 1;	/* complete */
> 	if (!ci->user && !ci->host && !ci->address)
> 		return -1;	/* empty */
> 	return 0;	/* partial */
> }
>
1537c1610
<     const char *user, const char *host, const char *address)
---
>     ConnectionInfo *conninfo)
1545c1618,1620
< 	active = user ? 0 : 1;
---
>
> 	active = conninfo ? 0 : 1;
>
1549c1624
< 		    linenum++, &active, user, host, address) != 0)
---
> 				linenum++, &active, conninfo) != 0)

=======================================================================================
diff -r 
/home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/servconf.h 
src/servconf.h
=======================================================================================
170a171,178
> /* Information about the incoming connection as used by Match */
> typedef struct {
> 	const char *user;
> 	const char *host;	/* possibly resolved hostname */
> 	const char *address; 	/* remote address */
> 	const char *subsystem; /* Subsystem service requested by the remote 
> client application */
> } ConnectionInfo;
>
186a195
>
188c197,198
< 	     int *, const char *, const char *, const char *);
---
> 	     int *, ConnectionInfo *);
>
191,193c201,207
< 	     const char *, const char *, const char *);
< void	 parse_server_match_config(ServerOptions *, const char *, const 
char *,
< 	     const char *);
---
> 		    ConnectionInfo *);
>
> void	 parse_server_match_config(ServerOptions *, ConnectionInfo *);
>
> int		 parse_server_match_testspec(ConnectionInfo *, char *);
> int		 server_match_spec_complete(ConnectionInfo *);
>

=====================================================================================
diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/session.c 
src/session.c
=====================================================================================
571d570
<
825a825
>
2089a2090
> 	/* Searching for subsystem into the options repository */
2091,2105c2092,2120
< 		if (strcmp(subsys, options.subsystem_name[i]) == 0) {
< 			prog = options.subsystem_command[i];
< 			cmd = options.subsystem_args[i];
< 			if (strcmp(INTERNAL_SFTP_NAME, prog) == 0) {
< 				s->is_subsystem = SUBSYSTEM_INT_SFTP;
< 				debug("subsystem: %s", prog);
< 			} else {
< 				if (stat(prog, &st) < 0)
< 					debug("subsystem: cannot stat %s: %s",
< 					    prog, strerror(errno));
< 				s->is_subsystem = SUBSYSTEM_EXT;
< 				debug("subsystem: exec() %s", cmd);
< 			}
< 			success = do_exec(s, cmd) == 0;
< 			break;
---
> 		if (strcmp(subsys, options.subsystem_name[i]) == 0)	break;
> 	}
>
> 	if (i < options.num_subsystems) { /* subsystem found */
> 		ConnectionInfo connection_info;
>
> 		connection_info.user = NULL;
> 		connection_info.host = NULL;
> 		connection_info.address = NULL;
> 		connection_info.subsystem = subsys;
>
> 		logit("subsystem request: Parsing server match config options: user 
> == '%s', host == '%s', address == '%s', subsystem == '%s'",
> 				connection_info.user, connection_info.host,
> 				connection_info.address, connection_info.subsystem);
>
> 		parse_server_match_config(&options, &connection_info);
>
> 		prog = options.subsystem_command[i];
> 		cmd = options.subsystem_args[i];
>
> 		if (strcmp(INTERNAL_SFTP_NAME, prog) == 0) {
> 			s->is_subsystem = SUBSYSTEM_INT_SFTP;
> 			debug("subsystem: %s", prog);
> 		} else {
> 			if (stat(prog, &st) < 0)
> 				debug("subsystem: cannot stat %s: %s",
> 				    prog, strerror(errno));
> 			s->is_subsystem = SUBSYSTEM_EXT;
> 			debug("subsystem: exec() %s", cmd);
2106a2122,2123
>
> 		success = do_exec(s, cmd) == 0;

===============================================================================
diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd.8 
src/sshd.8
===============================================================================
111c111
< that would apply to the specified user, host, and address will be set 
before
---
> that would apply to the specified user, host, address, and subsystem 
> will be set before
116a117
> .Dq addr ,
118,119c119,127
< .Dq addr .
< All are required and may be supplied in any order, either with 
multiple
---
> .Dq subsystem .
> Only
> .Dq user ,
> .Dq host ,
> and
> .Dq addr
> keywords are required;
> .Dq subsystem
> is optional. These parameters may be supplied in any order, either 
> with multiple

===============================================================================
diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd.c 
src/sshd.c
===============================================================================
1323d1322
< 	char *test_user = NULL, *test_host = NULL, *test_addr = NULL;
1325c1324
< 	char *line, *p, *cp;
---
> 	char *line;
1330a1330
> 	ConnectionInfo connection_info;
1359a1360,1362
> 	connection_info.address = connection_info.host = 
> connection_info.subsystem =
> 			connection_info.user = NULL;
>
1452,1465c1455,1456
< 			cp = optarg;
< 			while ((p = strsep(&cp, ",")) && *p != '\0') {
< 				if (strncmp(p, "addr=", 5) == 0)
< 					test_addr = xstrdup(p + 5);
< 				else if (strncmp(p, "host=", 5) == 0)
< 					test_host = xstrdup(p + 5);
< 				else if (strncmp(p, "user=", 5) == 0)
< 					test_user = xstrdup(p + 5);
< 				else {
< 					fprintf(stderr, "Invalid test "
< 					    "mode specification %s\n", p);
< 					exit(1);
< 				}
< 			}
---
> 			if (parse_server_match_testspec(&connection_info, optarg) == -1)
> 			exit(1);
1477c1468
< 			    "command-line", 0, NULL, NULL, NULL, NULL) != 0)
---
> 					"command-line", 0, NULL, NULL) != 0)
1533,1540c1524,1529
< 	if (test_flag >= 2 &&
< 	   (test_user != NULL || test_host != NULL || test_addr != NULL)
< 	    && (test_user == NULL || test_host == NULL || test_addr == 
NULL))
< 		fatal("user, host and addr are all required when testing "
< 		   "Match configs");
< 	if (test_flag < 2 && (test_user != NULL || test_host != NULL ||
< 	    test_addr != NULL))
< 		fatal("Config test connection parameter (-C) provided without "
---
> 		if ((test_flag >= 2) && 
> (server_match_spec_complete(&connection_info) == 0))
> 			fatal("user, host and addr are all required when testing "
> 					"Match configs");
>
> 		if ((test_flag < 2) && 
> (server_match_spec_complete(&connection_info) >= 0))
> 			fatal("Config test connection parameter (-C) provided without "
1551c1540
< 	    &cfg, NULL, NULL, NULL);
---
> 			&cfg, NULL);
1713,1715c1702,1703
< 		if (test_user != NULL && test_addr != NULL && test_host != NULL)
< 			parse_server_match_config(&options, test_user,
< 			    test_host, test_addr);
---
> 		if (server_match_spec_complete(&connection_info) == 1)
> 			parse_server_match_config(&options, &connection_info);
2005c1993
<  authenticated:
---
> 	authenticated:

=============================================================================================
diff -r 
/home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd_config.5 
src/sshd_config.5
=============================================================================================
677a678
> .Cm Address ,
679c680
< .Cm Address .
---
> .Cm Subsystem .


From dan at doxpara.com  Fri May 18 00:54:48 2012
From: dan at doxpara.com (Dan Kaminsky)
Date: Thu, 17 May 2012 07:54:48 -0700
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
Message-ID: <13823066-F116-4C59-9EB1-F22CEAC38E88@doxpara.com>

Is it a problem that scp and shell are un-chrooted?  Or are they handled elsewhere?

Sent from my iPhone

On May 17, 2012, at 7:19 AM, Nicola Muto <nicola.muto at cryptolab.net> wrote:

> Hello everybody,
> 
> I'm a C/C++ consultant working for Ericsson.
> 
> I changed the OpenSSH-Portable code to add a new criteria
> into the Match sshd_config option read by the sshd server.
> 
> The new criteria is "Subsystem"; so a conditional block based
> on subsystem client request can now be added to the sshd_config
> configuration server file to override settings in its global
> section.
> 
> Ericsson requested this new Subsystem criteria because it needs
> to "chroot" all the sftp session into a well defined directory
> for all users logging into the server from an sftp client.
> 
> For details on the Ericsson needs, please refer to the following
> OpenSSH mailing list thread
> 
>    http://marc.info/?t=132698105300002&r=1&w=2
> 
> A little example of the Match Subsystem usage follows
> 
>  Match Subsystem sftp
>      ChrootDirectory /path/to/sftp/data/jail/on/the/server
>      X11Forwarding no
>      AllowTcpForwarding no
>      ForceCommand internal-sftp
> 
> To ensure that the Match Subsystem conditional block will work
> properly, that is, the server "chroots" into the directory
> specified by the ChrootDirectory directive above, you must also
> disable the privilege separation using the config directive
> 
>  UsePrivilegeSeparation no
> 
> into the sshd_config file. At least I think so; I checked that
> the sshd server will skip calling the safely_chroot function if I
> keep the privilege separation enabled and login using a no-root user.
> 
> I worked on the portable branch of OpenSSH because this feature must be
> installed on a SLES (SuSE linux Enterprise Server) distribution.
> 
> For the code changes I started from the openssh-6.0p1 released on April
> 22, 2012, and I followed changes recently made by Darren Tucker to add
> other two criteria for the Match option; i.e. LocalAddress and LocalPort.
> So, my changes are minimized and will be gladly accepted by the OpenSSH
> community. :-)
> Thank you Darren.
> 
> I do not know who should accept and confirm my code changes. Also I don't have
> an account to check-in the changes into the OpenBSD SVC repository
> Hans can you help me?
> 
> BRs
> \\nm
> 
> The diff code list follows
> 
> ===============================================================================
> diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/auth.c src/auth.c
> ===============================================================================
> 546a547
>>    ConnectionInfo connection_info;
> 548,549c549,554
> <    parse_server_match_config(&options, user,
> <        get_canonical_hostname(options.use_dns), get_remote_ipaddr());
> ---
>>    connection_info.user = user;
>>    connection_info.host = get_canonical_hostname(options.use_dns);
>>    connection_info.address = get_remote_ipaddr();
>>    connection_info.subsystem = NULL;
>> 
>>    parse_server_match_config(&options, &connection_info);
> 
> =======================================================================================
> diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/servconf.c src/servconf.c
> =======================================================================================
> 601,602c601
> < match_cfg_line(char **condition, int line, const char *user, const char *host,
> <     const char *address)
> ---
>> match_cfg_line(char **condition, int line, ConnectionInfo *ci)
> 606a606,614
>>    const char *user = NULL;
>>    const char *host = NULL;
>>    const char *address = NULL;
>>    const char *subsystem = NULL;
>> 
>>    /* Here the condition is hold
>>     *     ci==NULL ==> user==NULL
>>     * that is, it is not possible that ci==NULL but user!=NULL
>>     */
> 608c616
> <    if (user == NULL)
> ---
>>    if (ci == NULL)
> 610,611c618,624
> <    else
> <        debug3("checking match for '%s' user %s host %s addr %s", cp,
> ---
>>    else {
>>        user = ci->user;
>>        host = ci->host;
>>        address = ci->address;
>>        subsystem = ci->subsystem;
>> 
>>        debug3("checking match for '%s' user %s host %s addr %s subsystem %s", cp,
> 613c626,627
> <            address ? address : "(null)");
> ---
>>            address ? address : "(null)", subsystem ? subsystem : "(null)");
>>    }
> 622c636,639
> <            if (!user) {
> ---
>>            if (!user) { /* For clarity: it should be "if (!ci || !user) {" but the two expressions have
>>                                        * exactly the same values under the above condition that
>>                                        * (ci==NULL) ==> (user==NULL).
>>                                        */
> 631a649,652
>>            if (!user) { /* Same comment as above */
>>                result = 0;
>>                continue;
>>            }
> 639c660
> <            if (!host) {
> ---
>>            if (!host) { /* Same comment on the condition as user above */
> 648a670,673
>>            if (!address) { /* Same comment on the condition as user above */
>>                result = 0;
>>                continue;
>>            }
> 660a686,695
>>        } else if (strcasecmp(attrib, "subsystem") == 0) {
>>            if (!subsystem) {
>>                result = 0;
>>                continue;
>>            }
>>            if (match_pattern_list(subsystem, arg, len, 0) != 1)
>>                result = 0;
>>            else
>>                debug("subsystem %.100s matched 'Subsystem %.100s' at "
>>                    "line %d", subsystem, arg, line);
> 666c701,702
> <    if (user != NULL)
> ---
>> 
>>    if (ci != NULL)
> 667a704
>> 
> 713,714c750
> <     const char *filename, int linenum, int *activep, const char *user,
> <     const char *host, const char *address)
> ---
>>    const char *filename, int linenum, int *activep, ConnectionInfo *conninfo)
> 745c781
> <        if (user == NULL) {
> ---
>>        if (conninfo == NULL) {
> 1316c1352,1354
> <        value = match_cfg_line(&cp, linenum, user, host, address);
> ---
>> 
>>        value = match_cfg_line(&cp, linenum, conninfo);
>> 
> 1454,1455c1492
> < parse_server_match_config(ServerOptions *options, const char *user,
> <     const char *host, const char *address)
> ---
>> parse_server_match_config(ServerOptions *options, ConnectionInfo *conninfo)
> 1460c1497
> <    parse_server_config(&mo, "reprocess config", &cfg, user, host, address);
> ---
>>    parse_server_config(&mo, "reprocess config", &cfg, conninfo);
> 1463a1501,1536
>> int
>> parse_server_match_testspec(ConnectionInfo *ci, char *spec)
>> {
>>    char *p;
>> 
>>    while ((p = strsep(&spec, ",")) && *p != '\0') {
>>        if (strncmp(p, "addr=", 5) == 0)
>>            ci->address = xstrdup(p + 5);
>>        else if (strncmp(p, "host=", 5) == 0)
>>            ci->host = xstrdup(p + 5);
>>        else if (strncmp(p, "user=", 5) == 0)
>>            ci->user = xstrdup(p + 5);
>>        else if (strncmp(p, "subsystem=", 10) == 0)
>>            ci->subsystem = xstrdup(p + 10);
>>        else {
>>            fprintf(stderr, "Invalid test mode specification %s\n", p);
>>            return -1;
>>        }
>>    }
>>    return 0;
>> }
>> 
>> /*
>> * returns 1 for a complete spec, 0 for partial spec and -1 for an
>> * empty spec.
>> */
>> int
>> server_match_spec_complete(ConnectionInfo *ci)
>> {
>>    if (ci->user && ci->host && ci->address)
>>        return 1;    /* complete */
>>    if (!ci->user && !ci->host && !ci->address)
>>        return -1;    /* empty */
>>    return 0;    /* partial */
>> }
>> 
> 1537c1610
> <     const char *user, const char *host, const char *address)
> ---
>>    ConnectionInfo *conninfo)
> 1545c1618,1620
> <    active = user ? 0 : 1;
> ---
>> 
>>    active = conninfo ? 0 : 1;
>> 
> 1549c1624
> <            linenum++, &active, user, host, address) != 0)
> ---
>>                linenum++, &active, conninfo) != 0)
> 
> =======================================================================================
> diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/servconf.h src/servconf.h
> =======================================================================================
> 170a171,178
>> /* Information about the incoming connection as used by Match */
>> typedef struct {
>>    const char *user;
>>    const char *host;    /* possibly resolved hostname */
>>    const char *address;    /* remote address */
>>    const char *subsystem; /* Subsystem service requested by the remote client application */
>> } ConnectionInfo;
>> 
> 186a195
>> 
> 188c197,198
> <         int *, const char *, const char *, const char *);
> ---
>>         int *, ConnectionInfo *);
>> 
> 191,193c201,207
> <         const char *, const char *, const char *);
> < void     parse_server_match_config(ServerOptions *, const char *, const char *,
> <         const char *);
> ---
>>            ConnectionInfo *);
>> 
>> void     parse_server_match_config(ServerOptions *, ConnectionInfo *);
>> 
>> int         parse_server_match_testspec(ConnectionInfo *, char *);
>> int         server_match_spec_complete(ConnectionInfo *);
>> 
> 
> =====================================================================================
> diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/session.c src/session.c
> =====================================================================================
> 571d570
> <
> 825a825
>> 
> 2089a2090
>>    /* Searching for subsystem into the options repository */
> 2091,2105c2092,2120
> <        if (strcmp(subsys, options.subsystem_name[i]) == 0) {
> <            prog = options.subsystem_command[i];
> <            cmd = options.subsystem_args[i];
> <            if (strcmp(INTERNAL_SFTP_NAME, prog) == 0) {
> <                s->is_subsystem = SUBSYSTEM_INT_SFTP;
> <                debug("subsystem: %s", prog);
> <            } else {
> <                if (stat(prog, &st) < 0)
> <                    debug("subsystem: cannot stat %s: %s",
> <                        prog, strerror(errno));
> <                s->is_subsystem = SUBSYSTEM_EXT;
> <                debug("subsystem: exec() %s", cmd);
> <            }
> <            success = do_exec(s, cmd) == 0;
> <            break;
> ---
>>        if (strcmp(subsys, options.subsystem_name[i]) == 0)    break;
>>    }
>> 
>>    if (i < options.num_subsystems) { /* subsystem found */
>>        ConnectionInfo connection_info;
>> 
>>        connection_info.user = NULL;
>>        connection_info.host = NULL;
>>        connection_info.address = NULL;
>>        connection_info.subsystem = subsys;
>> 
>>        logit("subsystem request: Parsing server match config options: user == '%s', host == '%s', address == '%s', subsystem == '%s'",
>>                connection_info.user, connection_info.host,
>>                connection_info.address, connection_info.subsystem);
>> 
>>        parse_server_match_config(&options, &connection_info);
>> 
>>        prog = options.subsystem_command[i];
>>        cmd = options.subsystem_args[i];
>> 
>>        if (strcmp(INTERNAL_SFTP_NAME, prog) == 0) {
>>            s->is_subsystem = SUBSYSTEM_INT_SFTP;
>>            debug("subsystem: %s", prog);
>>        } else {
>>            if (stat(prog, &st) < 0)
>>                debug("subsystem: cannot stat %s: %s",
>>                    prog, strerror(errno));
>>            s->is_subsystem = SUBSYSTEM_EXT;
>>            debug("subsystem: exec() %s", cmd);
> 2106a2122,2123
>> 
>>        success = do_exec(s, cmd) == 0;
> 
> ===============================================================================
> diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd.8 src/sshd.8
> ===============================================================================
> 111c111
> < that would apply to the specified user, host, and address will be set before
> ---
>> that would apply to the specified user, host, address, and subsystem will be set before
> 116a117
>> .Dq addr ,
> 118,119c119,127
> < .Dq addr .
> < All are required and may be supplied in any order, either with multiple
> ---
>> .Dq subsystem .
>> Only
>> .Dq user ,
>> .Dq host ,
>> and
>> .Dq addr
>> keywords are required;
>> .Dq subsystem
>> is optional. These parameters may be supplied in any order, either with multiple
> 
> ===============================================================================
> diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd.c src/sshd.c
> ===============================================================================
> 1323d1322
> <    char *test_user = NULL, *test_host = NULL, *test_addr = NULL;
> 1325c1324
> <    char *line, *p, *cp;
> ---
>>    char *line;
> 1330a1330
>>    ConnectionInfo connection_info;
> 1359a1360,1362
>>    connection_info.address = connection_info.host = connection_info.subsystem =
>>            connection_info.user = NULL;
>> 
> 1452,1465c1455,1456
> <            cp = optarg;
> <            while ((p = strsep(&cp, ",")) && *p != '\0') {
> <                if (strncmp(p, "addr=", 5) == 0)
> <                    test_addr = xstrdup(p + 5);
> <                else if (strncmp(p, "host=", 5) == 0)
> <                    test_host = xstrdup(p + 5);
> <                else if (strncmp(p, "user=", 5) == 0)
> <                    test_user = xstrdup(p + 5);
> <                else {
> <                    fprintf(stderr, "Invalid test "
> <                        "mode specification %s\n", p);
> <                    exit(1);
> <                }
> <            }
> ---
>>            if (parse_server_match_testspec(&connection_info, optarg) == -1)
>>            exit(1);
> 1477c1468
> <                "command-line", 0, NULL, NULL, NULL, NULL) != 0)
> ---
>>                    "command-line", 0, NULL, NULL) != 0)
> 1533,1540c1524,1529
> <    if (test_flag >= 2 &&
> <       (test_user != NULL || test_host != NULL || test_addr != NULL)
> <        && (test_user == NULL || test_host == NULL || test_addr == NULL))
> <        fatal("user, host and addr are all required when testing "
> <           "Match configs");
> <    if (test_flag < 2 && (test_user != NULL || test_host != NULL ||
> <        test_addr != NULL))
> <        fatal("Config test connection parameter (-C) provided without "
> ---
>>        if ((test_flag >= 2) && (server_match_spec_complete(&connection_info) == 0))
>>            fatal("user, host and addr are all required when testing "
>>                    "Match configs");
>> 
>>        if ((test_flag < 2) && (server_match_spec_complete(&connection_info) >= 0))
>>            fatal("Config test connection parameter (-C) provided without "
> 1551c1540
> <        &cfg, NULL, NULL, NULL);
> ---
>>            &cfg, NULL);
> 1713,1715c1702,1703
> <        if (test_user != NULL && test_addr != NULL && test_host != NULL)
> <            parse_server_match_config(&options, test_user,
> <                test_host, test_addr);
> ---
>>        if (server_match_spec_complete(&connection_info) == 1)
>>            parse_server_match_config(&options, &connection_info);
> 2005c1993
> <  authenticated:
> ---
>>    authenticated:
> 
> =============================================================================================
> diff -r /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd_config.5 src/sshd_config.5
> =============================================================================================
> 677a678
>> .Cm Address ,
> 679c680
> < .Cm Address .
> ---
>> .Cm Subsystem .
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From whit at transpect.com  Fri May 18 03:08:54 2012
From: whit at transpect.com (Whit Blauvelt)
Date: Thu, 17 May 2012 13:08:54 -0400
Subject: Is there any method, with ChrootDirectory and internal-sftp, to
 automatically cd to a subdir on login?
In-Reply-To: <4FB42A46.3070209@gmail.com>
References: <20120510231058.GA14673@black.transpect.com>
 <20120510233440.897.qmail@stuge.se>
 <20120516182546.GA12864@black.transpect.com>
 <20120516194322.26535.qmail@stuge.se> <4FB41870.6060007@gmail.com>
 <20120516212701.2021.qmail@stuge.se> <4FB42A46.3070209@gmail.com>
Message-ID: <20120517170854.GA9721@black.transpect.com>

On Thu, May 17, 2012 at 12:29:26AM +0200, ?ngel Gonz?lez wrote:
> On 16/05/12 23:27, Peter Stuge wrote:
> > ?ngel Gonz?lez wrote:
> >> Peter Stuge wrote:
> >>> set the home directory to /files for the relevant users
> >> If the user folder is /home/username, just change the
> >> ChrootDirectory to /home/%u, and then make their home
> >> /home/user1/files
> > As I wrote, the home directory should be /files in that case.
...
> Right. Sorry for the confusion. Their home directory should be /files,
> which would map to /home/user1/files, but you set it to /files

Thanks for the clarifying advice. I hadn't realized that the home directory
cd'd to is relative to the chroot. 

I still can't see how to get this to suffice in my setup though. For one
thing it's not a single directory branch. There are users at

  /path/one/userXdir and
  /path/two/userYdir

Also 

  userXdir != userid

so /home/%u does not capture the layout. I need some way to work from the
home dir as given in /etc/passwd, so that it would chroot to that and then
cd to

  /path/one/userXdir/files

The problem with the OpenSSH approach described so far is that there's no
apparent way to specify the chrootdir for systems with more complicated
layouts than can be expressed in a formula like /home/%u. Or can it?

Whatever the weakness of scponly's design, the specification of a home dir
takes the form of

  /path/one/userXdir//files

resulting in a chroot to /path/one/userXdir/ and a cd to /files. So it
handles a situation where there's both a /path/one and a /path/two fine, and
where the userXdir != uid. It would still be good to find a way to get
equivalent functionality using the OpenSSH internal sftp without scponly,
but from my clearer understanding now, it looks like there's no way.

Thanks again,
Whit

From peter at stuge.se  Fri May 18 03:26:53 2012
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 May 2012 19:26:53 +0200
Subject: Is there any method, with ChrootDirectory and internal-sftp,
 to automatically cd to a subdir on login?
In-Reply-To: <20120517170854.GA9721@black.transpect.com>
References: <20120510231058.GA14673@black.transpect.com>
 <20120510233440.897.qmail@stuge.se>
 <20120516182546.GA12864@black.transpect.com>
 <20120516194322.26535.qmail@stuge.se> <4FB41870.6060007@gmail.com>
 <20120516212701.2021.qmail@stuge.se> <4FB42A46.3070209@gmail.com>
 <20120517170854.GA9721@black.transpect.com>
Message-ID: <20120517172653.3884.qmail@stuge.se>

Whit Blauvelt wrote:
> It would still be good to find a way to get equivalent
> functionality using the OpenSSH internal sftp without scponly,
> but from my clearer understanding now, it looks like there's no
> way.

Suggest something with a patch?


//Peter

From lfilipoz at emyr.net  Fri May 18 10:05:19 2012
From: lfilipoz at emyr.net (Luca Filipozzi)
Date: Fri, 18 May 2012 00:05:19 +0000
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120510193523.GA21986@emyr.net>
References: <20120509042033.GB14446@emyr.net> <4FAA21BE.9000106@gmail.com>
 <20120509093041.GA24146@emyr.net> <4FAA4A7D.7060002@gmail.com>
 <20120509085953.0477bace@tp.vb.futz.org>
 <20120509185608.GA27523@emyr.net>
 <20120509174137.680ec5f3@sparta.com>
 <20120510193523.GA21986@emyr.net>
Message-ID: <20120518000519.GA12818@emyr.net>

On Thu, May 10, 2012 at 07:35:23PM +0000, Luca Filipozzi wrote:
> But before we invest more time in this effort, it would be helpful to
> hear upstream's opinion regarding our request for anchored DNSSEC
> validation to be built into openssh.
> 
> We don't want to trust on an upstream resolver's AD bit and we don't
> want to require that users install a local resolver.  Do they concur?

Alternately, would it be helpful to take Robert's suggestion of a
StrictDnssecChecking configuration directive and apply it to the ldns
implementation in 6.0p1?  This would avoid introducing new dependencies
(unbound, dnssec-tools) while achieving the suggested functionality.

-- 
Luca Filipozzi
Member, Debian System Administration Team

From dtucker at zip.com.au  Fri May 18 15:25:16 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 18 May 2012 15:25:16 +1000
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
Message-ID: <20120518052516.GA2753@gate.dtucker.net>

On Thu, May 17, 2012 at 04:19:36PM +0200, Nicola Muto wrote:
> Hello everybody,
> 
> I'm a C/C++ consultant working for Ericsson.
> 
> I changed the OpenSSH-Portable code to add a new criteria
> into the Match sshd_config option read by the sshd server.
> 
> The new criteria is "Subsystem"; so a conditional block based

The problem with that is that Match is done at connection
establishment time and Subsystem is not a property of the connection,
it's a request type that can be sent zero or more times during the life
of the connection.  What happens if I open a sftp subsytem then a normal
shell session or vice versa?

> you must also disable the privilege separation

that's usually a pretty good indication that you're doing something
wrong.

I'd like to study your diff a bit more but it got mangled to the point
that patch denies there's even a diff in there.  Could you please resend
(a) using diff -u (unified) format and (b) as an text/plain attachment.

Thanks.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From peter at stuge.se  Sat May 19 03:09:38 2012
From: peter at stuge.se (Peter Stuge)
Date: Fri, 18 May 2012 19:09:38 +0200
Subject: feature request: modify getrrsetbyname() to use libunbound
In-Reply-To: <20120518000519.GA12818@emyr.net>
References: <20120509042033.GB14446@emyr.net> <4FAA21BE.9000106@gmail.com>
 <20120509093041.GA24146@emyr.net> <4FAA4A7D.7060002@gmail.com>
 <20120509085953.0477bace@tp.vb.futz.org> <20120509185608.GA27523@emyr.net>
 <20120509174137.680ec5f3@sparta.com> <20120510193523.GA21986@emyr.net>
 <20120518000519.GA12818@emyr.net>
Message-ID: <20120518170938.22289.qmail@stuge.se>

Luca Filipozzi wrote:
> > But before we invest more time in this effort, it would be helpful to
> > hear upstream's opinion regarding our request for anchored DNSSEC
> > validation to be built into openssh.
> > 
> > We don't want to trust on an upstream resolver's AD bit and we don't
> > want to require that users install a local resolver.  Do they concur?
> 
> Alternately, would it be helpful to take Robert's suggestion of a
> StrictDnssecChecking configuration directive and apply it to the ldns
> implementation in 6.0p1?  This would avoid introducing new dependencies
> (unbound, dnssec-tools) while achieving the suggested functionality.

I think this sounds like a good idea. I guess the patch will also be
quite small? Remember to also look at what is going on upstream, ie.
in OpenSSH within OpenBSD.


//Peter

From matt at warnertechnology.com  Sat May 19 10:24:23 2012
From: matt at warnertechnology.com (Matt Warner)
Date: Fri, 18 May 2012 17:24:23 -0700
Subject: Syslog via UDP for chrooted environments
Message-ID: <CAHXP6iitHJUJp1EYATALjvk=feUvP-5Nx1FCGMH-MFTvUkK_ZA@mail.gmail.com>

Good afternoon.

I'm new to the list, so apologies in advance if the noob in me comes
through too loudly.

>From things I've read in the distant past, I have the impression that
the OpenSSH project tries to keep new features to a minimum, and there
are good security reasons to do this. That said, one feature that I
feel would be a good addition to OpenSSH is the ability to send logs
via UDP directly to a syslog server. It seems to me that the benefits
of this approach include:

  1. No need to setup /dev/log in every chroot. This is a huge plus
for anyone dealing with a large number of chrooted users or in
environments where the underlying filesystem has the "nodevices" flag
set (I have both).
  2. The logs are sent directly from the application, with no reliance
on the syslogd of the host OS. For users that have separation of
responsibilities, having logs go directly to a syslog server
maintained by a separate group is a plus since it's more difficult to
tamper with the logs.
  3. The code to add the ability to send the log messages over UDP to
a server is relatively trivial and requires only minimal changes to
the existing code. That is, it's relatively self contained.
  4. I've written code to do this, but wanted to gauge the reaction of
the group before I attempt to submit anything.

I understand if there's no interest in adding this to the existing
OpenSSH code base, but thought I should at least pose the question.
I'm also interested to hear comments and thoughts about the pros and
cons of adding functionality like this.

Regards,

Matt

From peter at stuge.se  Sat May 19 11:10:03 2012
From: peter at stuge.se (Peter Stuge)
Date: Sat, 19 May 2012 03:10:03 +0200
Subject: Syslog via UDP for chrooted environments
In-Reply-To: <CAHXP6iitHJUJp1EYATALjvk=feUvP-5Nx1FCGMH-MFTvUkK_ZA@mail.gmail.com>
References: <CAHXP6iitHJUJp1EYATALjvk=feUvP-5Nx1FCGMH-MFTvUkK_ZA@mail.gmail.com>
Message-ID: <20120519011003.30837.qmail@stuge.se>

Matt Warner wrote:
> I've written code to do this, but wanted to gauge the reaction of
> the group before I attempt to submit anything.

I'd suggest to submit it upstream, ie. OpenSSH in OpenBSD. I for one
think there is a point to have it, especially for the chrooted case.


//Peter

From dtucker at zip.com.au  Sat May 19 14:20:32 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 19 May 2012 14:20:32 +1000
Subject: Syslog via UDP for chrooted environments
In-Reply-To: <CAHXP6iitHJUJp1EYATALjvk=feUvP-5Nx1FCGMH-MFTvUkK_ZA@mail.gmail.com>
References: <CAHXP6iitHJUJp1EYATALjvk=feUvP-5Nx1FCGMH-MFTvUkK_ZA@mail.gmail.com>
Message-ID: <20120519042032.GA25750@gate.dtucker.net>

On Fri, May 18, 2012 at 05:24:23PM -0700, Matt Warner wrote:
> From things I've read in the distant past, I have the impression that
> the OpenSSH project tries to keep new features to a minimum, and there
> are good security reasons to do this. That said, one feature that I
> feel would be a good addition to OpenSSH is the ability to send logs
> via UDP directly to a syslog server. It seems to me that the benefits
> of this approach include:
> 
>   1. No need to setup /dev/log in every chroot. This is a huge plus
> for anyone dealing with a large number of chrooted users or in
> environments where the underlying filesystem has the "nodevices" flag
> set (I have both).

One of the down sides of using UDP is that it's less trustworthy than
the local socket since it's easier to spoof.

Anyway, you could link in an alternative implementation of the syslog
functions at build time that do anything you want, you wouldn't need
to change the code.  Just implement openlog, syslog and closelog (or
the _r equivalents, if that's what your platform has) then ./configure
--with-libs=-lyoursyslog.

An alternative might be to use the existing code for sending log
messages to the monitor (which is not chrooted).  Much of the code
already exists (it was added in 5.9):

 - djm at cvs.openbsd.org 2011/06/17 21:44:31
   [log.c log.h monitor.c monitor.h monitor_wrap.c monitor_wrap.h sshd.c]
   make the pre-auth privsep slave log via a socketpair shared with the
   monitor rather than /var/empty/dev/log; ok dtucker@ deraadt@ markus@


-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From john.m.olsson at ericsson.com  Mon May 21 17:12:41 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Mon, 21 May 2012 09:12:41 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <13823066-F116-4C59-9EB1-F22CEAC38E88@doxpara.com>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <13823066-F116-4C59-9EB1-F22CEAC38E88@doxpara.com>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD2213F1E3@ESESSCMS0360.eemea.ericsson.se>

Hi,

> Is it a problem that scp and shell are un-chrooted?
> Or are they handled elsewhere?

I'm not sure what part you are referring to. What we need to be able to do is to place just the SFTP server in a chroot jail. But I'll give you some background so you can understand better what it is we want to do

We have a box/node/machine/server/whatever that runs SLES as Nicola wrote. This server has two SSH servers running; one on port 22 and one on port 4422. When logging in to port 22 credentials are first verified against /etc/passwd and then an LDAP server is checked if /etc/passwd failed, for port 4422 it is only /etc/passwd that is checked and SFTP subsystem is disabled.

If you just do a "normal" ssh login (without specifying any subsystem) you end up in what we call "COM CLI" which can be thought of as a text-based interface to an information model (you can navigate a tree structure, modify attributes and create objects, etc). This information model will also provide a branch showing a virtual filesystem. Thus this is a completely different animal compared to a Bash shell, it is purely a high level management interface for the server.

Now when connecting to port 22 using an SFTP client, this client may only see the same virtual filesystem that is also visible via the information model. Thus the SFTP server must run in a chrooted environment, but SSH (COM CLI) may not since the COM CLI must be able to access the complete system.

Connecting to port 4422 gives you a standard Bash shell.


Did this answer your question, or did I answer some other question which you did not ask? :)


/John

-----Original Message-----
From: Dan Kaminsky [mailto:dan at doxpara.com]
Sent: den 17 maj 2012 16:55
To: Nicola Muto
Cc: <openssh-unix-dev at mindrot.org>; Nicola Muto; John Olsson M; Hans Insulander
Subject: Re: New Subsystem criteria for Match option block in OpenSSH server

Is it a problem that scp and shell are un-chrooted?  Or are they handled elsewhere?

Sent from my iPhone

On May 17, 2012, at 7:19 AM, Nicola Muto <nicola.muto at cryptolab.net> wrote:

> Hello everybody,
>
> I'm a C/C++ consultant working for Ericsson.
>
> I changed the OpenSSH-Portable code to add a new criteria into the
> Match sshd_config option read by the sshd server.
>
> The new criteria is "Subsystem"; so a conditional block based on
> subsystem client request can now be added to the sshd_config
> configuration server file to override settings in its global section.
>
> Ericsson requested this new Subsystem criteria because it needs to
> "chroot" all the sftp session into a well defined directory for all
> users logging into the server from an sftp client.
>
> For details on the Ericsson needs, please refer to the following
> OpenSSH mailing list thread
>
>    http://marc.info/?t=132698105300002&r=1&w=2
>
> A little example of the Match Subsystem usage follows
>
>  Match Subsystem sftp
>      ChrootDirectory /path/to/sftp/data/jail/on/the/server
>      X11Forwarding no
>      AllowTcpForwarding no
>      ForceCommand internal-sftp
>
> To ensure that the Match Subsystem conditional block will work
> properly, that is, the server "chroots" into the directory specified
> by the ChrootDirectory directive above, you must also disable the
> privilege separation using the config directive
>
>  UsePrivilegeSeparation no
>
> into the sshd_config file. At least I think so; I checked that the
> sshd server will skip calling the safely_chroot function if I keep the
> privilege separation enabled and login using a no-root user.
>
> I worked on the portable branch of OpenSSH because this feature must
> be installed on a SLES (SuSE linux Enterprise Server) distribution.
>
> For the code changes I started from the openssh-6.0p1 released on
> April 22, 2012, and I followed changes recently made by Darren Tucker
> to add other two criteria for the Match option; i.e. LocalAddress and LocalPort.
> So, my changes are minimized and will be gladly accepted by the
> OpenSSH community. :-) Thank you Darren.
>
> I do not know who should accept and confirm my code changes. Also I
> don't have an account to check-in the changes into the OpenBSD SVC
> repository Hans can you help me?
>
> BRs
> \\nm
>
> The diff code list follows
>
> ======================================================================
> ========= diff -r
> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/auth.c
> src/auth.c
> ======================================================================
> =========
> 546a547
>>    ConnectionInfo connection_info;
> 548,549c549,554
> <    parse_server_match_config(&options, user,
> <        get_canonical_hostname(options.use_dns), get_remote_ipaddr());
> ---
>>    connection_info.user = user;
>>    connection_info.host = get_canonical_hostname(options.use_dns);
>>    connection_info.address = get_remote_ipaddr();
>>    connection_info.subsystem = NULL;
>>
>>    parse_server_match_config(&options, &connection_info);
>
> ======================================================================
> ================= diff -r
> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/servconf.c
> src/servconf.c
> ======================================================================
> =================
> 601,602c601
> < match_cfg_line(char **condition, int line, const char *user, const char *host,
> <     const char *address)
> ---
>> match_cfg_line(char **condition, int line, ConnectionInfo *ci)
> 606a606,614
>>    const char *user = NULL;
>>    const char *host = NULL;
>>    const char *address = NULL;
>>    const char *subsystem = NULL;
>>
>>    /* Here the condition is hold
>>     *     ci==NULL ==> user==NULL
>>     * that is, it is not possible that ci==NULL but user!=NULL
>>     */
> 608c616
> <    if (user == NULL)
> ---
>>    if (ci == NULL)
> 610,611c618,624
> <    else
> <        debug3("checking match for '%s' user %s host %s addr %s", cp,
> ---
>>    else {
>>        user = ci->user;
>>        host = ci->host;
>>        address = ci->address;
>>        subsystem = ci->subsystem;
>>
>>        debug3("checking match for '%s' user %s host %s addr %s
>> subsystem %s", cp,
> 613c626,627
> <            address ? address : "(null)");
> ---
>>            address ? address : "(null)", subsystem ? subsystem : "(null)");
>>    }
> 622c636,639
> <            if (!user) {
> ---
>>            if (!user) { /* For clarity: it should be "if (!ci || !user) {" but the two expressions have
>>                                        * exactly the same values under the above condition that
>>                                        * (ci==NULL) ==> (user==NULL).
>>                                        */
> 631a649,652
>>            if (!user) { /* Same comment as above */
>>                result = 0;
>>                continue;
>>            }
> 639c660
> <            if (!host) {
> ---
>>            if (!host) { /* Same comment on the condition as user
>> above */
> 648a670,673
>>            if (!address) { /* Same comment on the condition as user above */
>>                result = 0;
>>                continue;
>>            }
> 660a686,695
>>        } else if (strcasecmp(attrib, "subsystem") == 0) {
>>            if (!subsystem) {
>>                result = 0;
>>                continue;
>>            }
>>            if (match_pattern_list(subsystem, arg, len, 0) != 1)
>>                result = 0;
>>            else
>>                debug("subsystem %.100s matched 'Subsystem %.100s' at "
>>                    "line %d", subsystem, arg, line);
> 666c701,702
> <    if (user != NULL)
> ---
>>
>>    if (ci != NULL)
> 667a704
>>
> 713,714c750
> <     const char *filename, int linenum, int *activep, const char *user,
> <     const char *host, const char *address)
> ---
>>    const char *filename, int linenum, int *activep, ConnectionInfo
>> *conninfo)
> 745c781
> <        if (user == NULL) {
> ---
>>        if (conninfo == NULL) {
> 1316c1352,1354
> <        value = match_cfg_line(&cp, linenum, user, host, address);
> ---
>>
>>        value = match_cfg_line(&cp, linenum, conninfo);
>>
> 1454,1455c1492
> < parse_server_match_config(ServerOptions *options, const char *user,
> <     const char *host, const char *address)
> ---
>> parse_server_match_config(ServerOptions *options, ConnectionInfo
>> *conninfo)
> 1460c1497
> <    parse_server_config(&mo, "reprocess config", &cfg, user, host, address);
> ---
>>    parse_server_config(&mo, "reprocess config", &cfg, conninfo);
> 1463a1501,1536
>> int
>> parse_server_match_testspec(ConnectionInfo *ci, char *spec) {
>>    char *p;
>>
>>    while ((p = strsep(&spec, ",")) && *p != '\0') {
>>        if (strncmp(p, "addr=", 5) == 0)
>>            ci->address = xstrdup(p + 5);
>>        else if (strncmp(p, "host=", 5) == 0)
>>            ci->host = xstrdup(p + 5);
>>        else if (strncmp(p, "user=", 5) == 0)
>>            ci->user = xstrdup(p + 5);
>>        else if (strncmp(p, "subsystem=", 10) == 0)
>>            ci->subsystem = xstrdup(p + 10);
>>        else {
>>            fprintf(stderr, "Invalid test mode specification %s\n", p);
>>            return -1;
>>        }
>>    }
>>    return 0;
>> }
>>
>> /*
>> * returns 1 for a complete spec, 0 for partial spec and -1 for an
>> * empty spec.
>> */
>> int
>> server_match_spec_complete(ConnectionInfo *ci) {
>>    if (ci->user && ci->host && ci->address)
>>        return 1;    /* complete */
>>    if (!ci->user && !ci->host && !ci->address)
>>        return -1;    /* empty */
>>    return 0;    /* partial */
>> }
>>
> 1537c1610
> <     const char *user, const char *host, const char *address)
> ---
>>    ConnectionInfo *conninfo)
> 1545c1618,1620
> <    active = user ? 0 : 1;
> ---
>>
>>    active = conninfo ? 0 : 1;
>>
> 1549c1624
> <            linenum++, &active, user, host, address) != 0)
> ---
>>                linenum++, &active, conninfo) != 0)
>
> ======================================================================
> ================= diff -r
> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/servconf.h
> src/servconf.h
> ======================================================================
> =================
> 170a171,178
>> /* Information about the incoming connection as used by Match */
>> typedef struct {
>>    const char *user;
>>    const char *host;    /* possibly resolved hostname */
>>    const char *address;    /* remote address */
>>    const char *subsystem; /* Subsystem service requested by the
>> remote client application */ } ConnectionInfo;
>>
> 186a195
>>
> 188c197,198
> <         int *, const char *, const char *, const char *);
> ---
>>         int *, ConnectionInfo *);
>>
> 191,193c201,207
> <         const char *, const char *, const char *);
> < void     parse_server_match_config(ServerOptions *, const char *, const char *,
> <         const char *);
> ---
>>            ConnectionInfo *);
>>
>> void     parse_server_match_config(ServerOptions *, ConnectionInfo *);
>>
>> int         parse_server_match_testspec(ConnectionInfo *, char *);
>> int         server_match_spec_complete(ConnectionInfo *);
>>
>
> ======================================================================
> =============== diff -r
> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/session.c
> src/session.c
> ======================================================================
> ===============
> 571d570
> <
> 825a825
>>
> 2089a2090
>>    /* Searching for subsystem into the options repository */
> 2091,2105c2092,2120
> <        if (strcmp(subsys, options.subsystem_name[i]) == 0) {
> <            prog = options.subsystem_command[i];
> <            cmd = options.subsystem_args[i];
> <            if (strcmp(INTERNAL_SFTP_NAME, prog) == 0) {
> <                s->is_subsystem = SUBSYSTEM_INT_SFTP;
> <                debug("subsystem: %s", prog);
> <            } else {
> <                if (stat(prog, &st) < 0)
> <                    debug("subsystem: cannot stat %s: %s",
> <                        prog, strerror(errno));
> <                s->is_subsystem = SUBSYSTEM_EXT;
> <                debug("subsystem: exec() %s", cmd);
> <            }
> <            success = do_exec(s, cmd) == 0;
> <            break;
> ---
>>        if (strcmp(subsys, options.subsystem_name[i]) == 0)    break;
>>    }
>>
>>    if (i < options.num_subsystems) { /* subsystem found */
>>        ConnectionInfo connection_info;
>>
>>        connection_info.user = NULL;
>>        connection_info.host = NULL;
>>        connection_info.address = NULL;
>>        connection_info.subsystem = subsys;
>>
>>        logit("subsystem request: Parsing server match config options: user == '%s', host == '%s', address == '%s', subsystem == '%s'",
>>                connection_info.user, connection_info.host,
>>                connection_info.address, connection_info.subsystem);
>>
>>        parse_server_match_config(&options, &connection_info);
>>
>>        prog = options.subsystem_command[i];
>>        cmd = options.subsystem_args[i];
>>
>>        if (strcmp(INTERNAL_SFTP_NAME, prog) == 0) {
>>            s->is_subsystem = SUBSYSTEM_INT_SFTP;
>>            debug("subsystem: %s", prog);
>>        } else {
>>            if (stat(prog, &st) < 0)
>>                debug("subsystem: cannot stat %s: %s",
>>                    prog, strerror(errno));
>>            s->is_subsystem = SUBSYSTEM_EXT;
>>            debug("subsystem: exec() %s", cmd);
> 2106a2122,2123
>>
>>        success = do_exec(s, cmd) == 0;
>
> ======================================================================
> ========= diff -r
> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd.8
> src/sshd.8
> ======================================================================
> =========
> 111c111
> < that would apply to the specified user, host, and address will be
> set before
> ---
>> that would apply to the specified user, host, address, and subsystem
>> will be set before
> 116a117
>> .Dq addr ,
> 118,119c119,127
> < .Dq addr .
> < All are required and may be supplied in any order, either with
> multiple
> ---
>> .Dq subsystem .
>> Only
>> .Dq user ,
>> .Dq host ,
>> and
>> .Dq addr
>> keywords are required;
>> .Dq subsystem
>> is optional. These parameters may be supplied in any order, either
>> with multiple
>
> ======================================================================
> ========= diff -r
> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd.c
> src/sshd.c
> ======================================================================
> =========
> 1323d1322
> <    char *test_user = NULL, *test_host = NULL, *test_addr = NULL;
> 1325c1324
> <    char *line, *p, *cp;
> ---
>>    char *line;
> 1330a1330
>>    ConnectionInfo connection_info;
> 1359a1360,1362
>>    connection_info.address = connection_info.host = connection_info.subsystem =
>>            connection_info.user = NULL;
>>
> 1452,1465c1455,1456
> <            cp = optarg;
> <            while ((p = strsep(&cp, ",")) && *p != '\0') {
> <                if (strncmp(p, "addr=", 5) == 0)
> <                    test_addr = xstrdup(p + 5);
> <                else if (strncmp(p, "host=", 5) == 0)
> <                    test_host = xstrdup(p + 5);
> <                else if (strncmp(p, "user=", 5) == 0)
> <                    test_user = xstrdup(p + 5);
> <                else {
> <                    fprintf(stderr, "Invalid test "
> <                        "mode specification %s\n", p);
> <                    exit(1);
> <                }
> <            }
> ---
>>            if (parse_server_match_testspec(&connection_info, optarg) == -1)
>>            exit(1);
> 1477c1468
> <                "command-line", 0, NULL, NULL, NULL, NULL) != 0)
> ---
>>                    "command-line", 0, NULL, NULL) != 0)
> 1533,1540c1524,1529
> <    if (test_flag >= 2 &&
> <       (test_user != NULL || test_host != NULL || test_addr != NULL)
> <        && (test_user == NULL || test_host == NULL || test_addr == NULL))
> <        fatal("user, host and addr are all required when testing "
> <           "Match configs");
> <    if (test_flag < 2 && (test_user != NULL || test_host != NULL ||
> <        test_addr != NULL))
> <        fatal("Config test connection parameter (-C) provided without "
> ---
>>        if ((test_flag >= 2) && (server_match_spec_complete(&connection_info) == 0))
>>            fatal("user, host and addr are all required when testing "
>>                    "Match configs");
>>
>>        if ((test_flag < 2) && (server_match_spec_complete(&connection_info) >= 0))
>>            fatal("Config test connection parameter (-C) provided without "
> 1551c1540
> <        &cfg, NULL, NULL, NULL);
> ---
>>            &cfg, NULL);
> 1713,1715c1702,1703
> <        if (test_user != NULL && test_addr != NULL && test_host != NULL)
> <            parse_server_match_config(&options, test_user,
> <                test_host, test_addr);
> ---
>>        if (server_match_spec_complete(&connection_info) == 1)
>>            parse_server_match_config(&options, &connection_info);
> 2005c1993
> <  authenticated:
> ---
>>    authenticated:
>
> ======================================================================
> ======================= diff -r
> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd_config.5
> src/sshd_config.5
> ======================================================================
> =======================
> 677a678
>> .Cm Address ,
> 679c680
> < .Cm Address .
> ---
>> .Cm Subsystem .
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From nicola.muto at cryptolab.net  Mon May 21 18:51:06 2012
From: nicola.muto at cryptolab.net (Nicola Muto)
Date: Mon, 21 May 2012 08:51:06 +0000
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD2213F1E3@ESESSCMS0360.eemea.ericsson.se>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <13823066-F116-4C59-9EB1-F22CEAC38E88@doxpara.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD2213F1E3@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <ec29f387822ffbd1d5fd584bf1e4f2d1@cryptolab.net>

Hi

Much more details about what john's saying can be found at this
mailing list thread "http://marc.info/?t=132698105300002&r=1&w=2".

Anyway to better understand the problem I would like to report what
Hans wrote in an internal document about the wanted functionality.

It should be allowed to run, at the same time, a SSH server on
port 22 With two "conflicting" requirements:

1) It should allow the user to run a very high level "common line 
interface"
    (CLI shell) session simply by logging in with SSH
2) It should allow the user to run a SFTP session that is chrooted such 
that the
    user can only see the files managed by a "file management" software 
component
    and not the rest of the filesystem.

These two requirements are currently in conflict with each other, since 
the
OpenSSH implementation does not provide that feature out of the box.

Moreover, it was confirmed that the desired behavior cannot be achieved 
using
existing functionality. This is also confirmed by the OpenSSH user 
community.
Again, refer to the above OpenSSH mailing list thread.

\\nm



On 2012-05-21 07:12, John Olsson M wrote:
> Hi,
>
>> Is it a problem that scp and shell are un-chrooted?
>> Or are they handled elsewhere?
>
> I'm not sure what part you are referring to. What we need to be able
> to do is to place just the SFTP server in a chroot jail. But I'll 
> give
> you some background so you can understand better what it is we want 
> to
> do
>
> We have a box/node/machine/server/whatever that runs SLES as Nicola
> wrote. This server has two SSH servers running; one on port 22 and 
> one
> on port 4422. When logging in to port 22 credentials are first
> verified against /etc/passwd and then an LDAP server is checked if
> /etc/passwd failed, for port 4422 it is only /etc/passwd that is
> checked and SFTP subsystem is disabled.
>
> If you just do a "normal" ssh login (without specifying any
> subsystem) you end up in what we call "COM CLI" which can be thought
> of as a text-based interface to an information model (you can 
> navigate
> a tree structure, modify attributes and create objects, etc). This
> information model will also provide a branch showing a virtual
> filesystem. Thus this is a completely different animal compared to a
> Bash shell, it is purely a high level management interface for the
> server.
>
> Now when connecting to port 22 using an SFTP client, this client may
> only see the same virtual filesystem that is also visible via the
> information model. Thus the SFTP server must run in a chrooted
> environment, but SSH (COM CLI) may not since the COM CLI must be able
> to access the complete system.
>
> Connecting to port 4422 gives you a standard Bash shell.
>
>
> Did this answer your question, or did I answer some other question
> which you did not ask? :)
>
>
> /John
>
> -----Original Message-----
> From: Dan Kaminsky [mailto:dan at doxpara.com]
> Sent: den 17 maj 2012 16:55
> To: Nicola Muto
> Cc: <openssh-unix-dev at mindrot.org>; Nicola Muto; John Olsson M; Hans
> Insulander
> Subject: Re: New Subsystem criteria for Match option block in OpenSSH 
> server
>
> Is it a problem that scp and shell are un-chrooted?  Or are they
> handled elsewhere?
>
> Sent from my iPhone
>
> On May 17, 2012, at 7:19 AM, Nicola Muto <nicola.muto at cryptolab.net> 
> wrote:
>
>> Hello everybody,
>>
>> I'm a C/C++ consultant working for Ericsson.
>>
>> I changed the OpenSSH-Portable code to add a new criteria into the
>> Match sshd_config option read by the sshd server.
>>
>> The new criteria is "Subsystem"; so a conditional block based on
>> subsystem client request can now be added to the sshd_config
>> configuration server file to override settings in its global 
>> section.
>>
>> Ericsson requested this new Subsystem criteria because it needs to
>> "chroot" all the sftp session into a well defined directory for all
>> users logging into the server from an sftp client.
>>
>> For details on the Ericsson needs, please refer to the following
>> OpenSSH mailing list thread
>>
>>    http://marc.info/?t=132698105300002&r=1&w=2
>>
>> A little example of the Match Subsystem usage follows
>>
>>  Match Subsystem sftp
>>      ChrootDirectory /path/to/sftp/data/jail/on/the/server
>>      X11Forwarding no
>>      AllowTcpForwarding no
>>      ForceCommand internal-sftp
>>
>> To ensure that the Match Subsystem conditional block will work
>> properly, that is, the server "chroots" into the directory specified
>> by the ChrootDirectory directive above, you must also disable the
>> privilege separation using the config directive
>>
>>  UsePrivilegeSeparation no
>>
>> into the sshd_config file. At least I think so; I checked that the
>> sshd server will skip calling the safely_chroot function if I keep 
>> the
>> privilege separation enabled and login using a no-root user.
>>
>> I worked on the portable branch of OpenSSH because this feature must
>> be installed on a SLES (SuSE linux Enterprise Server) distribution.
>>
>> For the code changes I started from the openssh-6.0p1 released on
>> April 22, 2012, and I followed changes recently made by Darren 
>> Tucker
>> to add other two criteria for the Match option; i.e. LocalAddress 
>> and LocalPort.
>> So, my changes are minimized and will be gladly accepted by the
>> OpenSSH community. :-) Thank you Darren.
>>
>> I do not know who should accept and confirm my code changes. Also I
>> don't have an account to check-in the changes into the OpenBSD SVC
>> repository Hans can you help me?
>>
>> BRs
>> \\nm
>>
>> The diff code list follows
>>
>> 
>> ======================================================================
>> ========= diff -r
>> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/auth.c
>> src/auth.c
>> 
>> ======================================================================
>> =========
>> 546a547
>>>    ConnectionInfo connection_info;
>> 548,549c549,554
>> <    parse_server_match_config(&options, user,
>> <        get_canonical_hostname(options.use_dns), 
>> get_remote_ipaddr());
>> ---
>>>    connection_info.user = user;
>>>    connection_info.host = get_canonical_hostname(options.use_dns);
>>>    connection_info.address = get_remote_ipaddr();
>>>    connection_info.subsystem = NULL;
>>>
>>>    parse_server_match_config(&options, &connection_info);
>>
>> 
>> ======================================================================
>> ================= diff -r
>> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/servconf.c
>> src/servconf.c
>> 
>> ======================================================================
>> =================
>> 601,602c601
>> < match_cfg_line(char **condition, int line, const char *user, const 
>> char *host,
>> <     const char *address)
>> ---
>>> match_cfg_line(char **condition, int line, ConnectionInfo *ci)
>> 606a606,614
>>>    const char *user = NULL;
>>>    const char *host = NULL;
>>>    const char *address = NULL;
>>>    const char *subsystem = NULL;
>>>
>>>    /* Here the condition is hold
>>>     *     ci==NULL ==> user==NULL
>>>     * that is, it is not possible that ci==NULL but user!=NULL
>>>     */
>> 608c616
>> <    if (user == NULL)
>> ---
>>>    if (ci == NULL)
>> 610,611c618,624
>> <    else
>> <        debug3("checking match for '%s' user %s host %s addr %s", 
>> cp,
>> ---
>>>    else {
>>>        user = ci->user;
>>>        host = ci->host;
>>>        address = ci->address;
>>>        subsystem = ci->subsystem;
>>>
>>>        debug3("checking match for '%s' user %s host %s addr %s
>>> subsystem %s", cp,
>> 613c626,627
>> <            address ? address : "(null)");
>> ---
>>>            address ? address : "(null)", subsystem ? subsystem : 
>>> "(null)");
>>>    }
>> 622c636,639
>> <            if (!user) {
>> ---
>>>            if (!user) { /* For clarity: it should be "if (!ci || 
>>> !user) {" but the two expressions have
>>>                                        * exactly the same values 
>>> under the above condition that
>>>                                        * (ci==NULL) ==> 
>>> (user==NULL).
>>>                                        */
>> 631a649,652
>>>            if (!user) { /* Same comment as above */
>>>                result = 0;
>>>                continue;
>>>            }
>> 639c660
>> <            if (!host) {
>> ---
>>>            if (!host) { /* Same comment on the condition as user
>>> above */
>> 648a670,673
>>>            if (!address) { /* Same comment on the condition as user 
>>> above */
>>>                result = 0;
>>>                continue;
>>>            }
>> 660a686,695
>>>        } else if (strcasecmp(attrib, "subsystem") == 0) {
>>>            if (!subsystem) {
>>>                result = 0;
>>>                continue;
>>>            }
>>>            if (match_pattern_list(subsystem, arg, len, 0) != 1)
>>>                result = 0;
>>>            else
>>>                debug("subsystem %.100s matched 'Subsystem %.100s' 
>>> at "
>>>                    "line %d", subsystem, arg, line);
>> 666c701,702
>> <    if (user != NULL)
>> ---
>>>
>>>    if (ci != NULL)
>> 667a704
>>>
>> 713,714c750
>> <     const char *filename, int linenum, int *activep, const char 
>> *user,
>> <     const char *host, const char *address)
>> ---
>>>    const char *filename, int linenum, int *activep, ConnectionInfo
>>> *conninfo)
>> 745c781
>> <        if (user == NULL) {
>> ---
>>>        if (conninfo == NULL) {
>> 1316c1352,1354
>> <        value = match_cfg_line(&cp, linenum, user, host, address);
>> ---
>>>
>>>        value = match_cfg_line(&cp, linenum, conninfo);
>>>
>> 1454,1455c1492
>> < parse_server_match_config(ServerOptions *options, const char 
>> *user,
>> <     const char *host, const char *address)
>> ---
>>> parse_server_match_config(ServerOptions *options, ConnectionInfo
>>> *conninfo)
>> 1460c1497
>> <    parse_server_config(&mo, "reprocess config", &cfg, user, host, 
>> address);
>> ---
>>>    parse_server_config(&mo, "reprocess config", &cfg, conninfo);
>> 1463a1501,1536
>>> int
>>> parse_server_match_testspec(ConnectionInfo *ci, char *spec) {
>>>    char *p;
>>>
>>>    while ((p = strsep(&spec, ",")) && *p != '\0') {
>>>        if (strncmp(p, "addr=", 5) == 0)
>>>            ci->address = xstrdup(p + 5);
>>>        else if (strncmp(p, "host=", 5) == 0)
>>>            ci->host = xstrdup(p + 5);
>>>        else if (strncmp(p, "user=", 5) == 0)
>>>            ci->user = xstrdup(p + 5);
>>>        else if (strncmp(p, "subsystem=", 10) == 0)
>>>            ci->subsystem = xstrdup(p + 10);
>>>        else {
>>>            fprintf(stderr, "Invalid test mode specification %s\n", 
>>> p);
>>>            return -1;
>>>        }
>>>    }
>>>    return 0;
>>> }
>>>
>>> /*
>>> * returns 1 for a complete spec, 0 for partial spec and -1 for an
>>> * empty spec.
>>> */
>>> int
>>> server_match_spec_complete(ConnectionInfo *ci) {
>>>    if (ci->user && ci->host && ci->address)
>>>        return 1;    /* complete */
>>>    if (!ci->user && !ci->host && !ci->address)
>>>        return -1;    /* empty */
>>>    return 0;    /* partial */
>>> }
>>>
>> 1537c1610
>> <     const char *user, const char *host, const char *address)
>> ---
>>>    ConnectionInfo *conninfo)
>> 1545c1618,1620
>> <    active = user ? 0 : 1;
>> ---
>>>
>>>    active = conninfo ? 0 : 1;
>>>
>> 1549c1624
>> <            linenum++, &active, user, host, address) != 0)
>> ---
>>>                linenum++, &active, conninfo) != 0)
>>
>> 
>> ======================================================================
>> ================= diff -r
>> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/servconf.h
>> src/servconf.h
>> 
>> ======================================================================
>> =================
>> 170a171,178
>>> /* Information about the incoming connection as used by Match */
>>> typedef struct {
>>>    const char *user;
>>>    const char *host;    /* possibly resolved hostname */
>>>    const char *address;    /* remote address */
>>>    const char *subsystem; /* Subsystem service requested by the
>>> remote client application */ } ConnectionInfo;
>>>
>> 186a195
>>>
>> 188c197,198
>> <         int *, const char *, const char *, const char *);
>> ---
>>>         int *, ConnectionInfo *);
>>>
>> 191,193c201,207
>> <         const char *, const char *, const char *);
>> < void     parse_server_match_config(ServerOptions *, const char *, 
>> const char *,
>> <         const char *);
>> ---
>>>            ConnectionInfo *);
>>>
>>> void     parse_server_match_config(ServerOptions *, ConnectionInfo 
>>> *);
>>>
>>> int         parse_server_match_testspec(ConnectionInfo *, char *);
>>> int         server_match_spec_complete(ConnectionInfo *);
>>>
>>
>> 
>> ======================================================================
>> =============== diff -r
>> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/session.c
>> src/session.c
>> 
>> ======================================================================
>> ===============
>> 571d570
>> <
>> 825a825
>>>
>> 2089a2090
>>>    /* Searching for subsystem into the options repository */
>> 2091,2105c2092,2120
>> <        if (strcmp(subsys, options.subsystem_name[i]) == 0) {
>> <            prog = options.subsystem_command[i];
>> <            cmd = options.subsystem_args[i];
>> <            if (strcmp(INTERNAL_SFTP_NAME, prog) == 0) {
>> <                s->is_subsystem = SUBSYSTEM_INT_SFTP;
>> <                debug("subsystem: %s", prog);
>> <            } else {
>> <                if (stat(prog, &st) < 0)
>> <                    debug("subsystem: cannot stat %s: %s",
>> <                        prog, strerror(errno));
>> <                s->is_subsystem = SUBSYSTEM_EXT;
>> <                debug("subsystem: exec() %s", cmd);
>> <            }
>> <            success = do_exec(s, cmd) == 0;
>> <            break;
>> ---
>>>        if (strcmp(subsys, options.subsystem_name[i]) == 0)    
>>> break;
>>>    }
>>>
>>>    if (i < options.num_subsystems) { /* subsystem found */
>>>        ConnectionInfo connection_info;
>>>
>>>        connection_info.user = NULL;
>>>        connection_info.host = NULL;
>>>        connection_info.address = NULL;
>>>        connection_info.subsystem = subsys;
>>>
>>>        logit("subsystem request: Parsing server match config 
>>> options: user == '%s', host == '%s', address == '%s', subsystem == 
>>> '%s'",
>>>                connection_info.user, connection_info.host,
>>>                connection_info.address, connection_info.subsystem);
>>>
>>>        parse_server_match_config(&options, &connection_info);
>>>
>>>        prog = options.subsystem_command[i];
>>>        cmd = options.subsystem_args[i];
>>>
>>>        if (strcmp(INTERNAL_SFTP_NAME, prog) == 0) {
>>>            s->is_subsystem = SUBSYSTEM_INT_SFTP;
>>>            debug("subsystem: %s", prog);
>>>        } else {
>>>            if (stat(prog, &st) < 0)
>>>                debug("subsystem: cannot stat %s: %s",
>>>                    prog, strerror(errno));
>>>            s->is_subsystem = SUBSYSTEM_EXT;
>>>            debug("subsystem: exec() %s", cmd);
>> 2106a2122,2123
>>>
>>>        success = do_exec(s, cmd) == 0;
>>
>> 
>> ======================================================================
>> ========= diff -r
>> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd.8
>> src/sshd.8
>> 
>> ======================================================================
>> =========
>> 111c111
>> < that would apply to the specified user, host, and address will be
>> set before
>> ---
>>> that would apply to the specified user, host, address, and 
>>> subsystem
>>> will be set before
>> 116a117
>>> .Dq addr ,
>> 118,119c119,127
>> < .Dq addr .
>> < All are required and may be supplied in any order, either with
>> multiple
>> ---
>>> .Dq subsystem .
>>> Only
>>> .Dq user ,
>>> .Dq host ,
>>> and
>>> .Dq addr
>>> keywords are required;
>>> .Dq subsystem
>>> is optional. These parameters may be supplied in any order, either
>>> with multiple
>>
>> 
>> ======================================================================
>> ========= diff -r
>> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd.c
>> src/sshd.c
>> 
>> ======================================================================
>> =========
>> 1323d1322
>> <    char *test_user = NULL, *test_host = NULL, *test_addr = NULL;
>> 1325c1324
>> <    char *line, *p, *cp;
>> ---
>>>    char *line;
>> 1330a1330
>>>    ConnectionInfo connection_info;
>> 1359a1360,1362
>>>    connection_info.address = connection_info.host = 
>>> connection_info.subsystem =
>>>            connection_info.user = NULL;
>>>
>> 1452,1465c1455,1456
>> <            cp = optarg;
>> <            while ((p = strsep(&cp, ",")) && *p != '\0') {
>> <                if (strncmp(p, "addr=", 5) == 0)
>> <                    test_addr = xstrdup(p + 5);
>> <                else if (strncmp(p, "host=", 5) == 0)
>> <                    test_host = xstrdup(p + 5);
>> <                else if (strncmp(p, "user=", 5) == 0)
>> <                    test_user = xstrdup(p + 5);
>> <                else {
>> <                    fprintf(stderr, "Invalid test "
>> <                        "mode specification %s\n", p);
>> <                    exit(1);
>> <                }
>> <            }
>> ---
>>>            if (parse_server_match_testspec(&connection_info, 
>>> optarg) == -1)
>>>            exit(1);
>> 1477c1468
>> <                "command-line", 0, NULL, NULL, NULL, NULL) != 0)
>> ---
>>>                    "command-line", 0, NULL, NULL) != 0)
>> 1533,1540c1524,1529
>> <    if (test_flag >= 2 &&
>> <       (test_user != NULL || test_host != NULL || test_addr != 
>> NULL)
>> <        && (test_user == NULL || test_host == NULL || test_addr == 
>> NULL))
>> <        fatal("user, host and addr are all required when testing "
>> <           "Match configs");
>> <    if (test_flag < 2 && (test_user != NULL || test_host != NULL ||
>> <        test_addr != NULL))
>> <        fatal("Config test connection parameter (-C) provided 
>> without "
>> ---
>>>        if ((test_flag >= 2) && 
>>> (server_match_spec_complete(&connection_info) == 0))
>>>            fatal("user, host and addr are all required when testing 
>>> "
>>>                    "Match configs");
>>>
>>>        if ((test_flag < 2) && 
>>> (server_match_spec_complete(&connection_info) >= 0))
>>>            fatal("Config test connection parameter (-C) provided 
>>> without "
>> 1551c1540
>> <        &cfg, NULL, NULL, NULL);
>> ---
>>>            &cfg, NULL);
>> 1713,1715c1702,1703
>> <        if (test_user != NULL && test_addr != NULL && test_host != 
>> NULL)
>> <            parse_server_match_config(&options, test_user,
>> <                test_host, test_addr);
>> ---
>>>        if (server_match_spec_complete(&connection_info) == 1)
>>>            parse_server_match_config(&options, &connection_info);
>> 2005c1993
>> <  authenticated:
>> ---
>>>    authenticated:
>>
>> 
>> ======================================================================
>> ======================= diff -r
>> /home/qnicmut/Projects/OpenSSH-Portable/openssh-6.0p1/sshd_config.5
>> src/sshd_config.5
>> 
>> ======================================================================
>> =======================
>> 677a678
>>> .Cm Address ,
>> 679c680
>> < .Cm Address .
>> ---
>>> .Cm Subsystem .
>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From nicola.muto at cryptolab.net  Tue May 22 00:15:16 2012
From: nicola.muto at cryptolab.net (Nicola Muto)
Date: Mon, 21 May 2012 16:15:16 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <20120518052516.GA2753@gate.dtucker.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
Message-ID: <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>

> The problem with that is that Match is done at connection
> establishment time and Subsystem is not a property of the connection,
> it's a request type that can be sent zero or more times during the 
> life
> of the connection.

So, is it better not to use the ConnectionInfo structure to handle the
subsystem request?
If you like it, I can rearrange the code and remove the subsystem field
from the structure in the file servconf.h.


> What happens if I open a sftp subsytem then a normal
> shell session or vice versa?

All the sftp sessions should be chrooted and all shell session should 
not,
in any order they are opened.


> that's usually a pretty good indication that you're doing something
> wrong.

I do not know well how the sshd server works internally and what
are its execution code flows, so I added a lot of traces to understand
better what's happening around the privilege separation concept.
These traces are in the file sshd-traces.txt attached to this email.
Well, with the privilege separation active the main process forks and 
drops
privileges definitively before I can receive the subsystem request. So, 
as you
can see at line 2.11 in the traces, when the client send the subsystem 
request
the process has a no-root UID and it's too late to perform a 'chroot' 
syscall.
Am I right?
I do not like, as you I think, to extend the time-window where the sshd 
process
is running with root privilege. But I need some help on how to keep the 
privilege
separation active and trigger a Match Subsystem option to "chroot" the 
sshd process.


> I'd like to study your diff a bit more but it got mangled to the 
> point
> that patch denies there's even a diff in there.  Could you please 
> resend
> (a) using diff -u (unified) format and (b) as an text/plain 
> attachment.

Of course Darren. Please, see attachment part, now the diff should be 
in
the format you requested.

\\nm



On 2012-05-18 07:25, Darren Tucker wrote:
> On Thu, May 17, 2012 at 04:19:36PM +0200, Nicola Muto wrote:
>> Hello everybody,
>>
>> I'm a C/C++ consultant working for Ericsson.
>>
>> I changed the OpenSSH-Portable code to add a new criteria
>> into the Match sshd_config option read by the sshd server.
>>
>> The new criteria is "Subsystem"; so a conditional block based
>
> The problem with that is that Match is done at connection
> establishment time and Subsystem is not a property of the connection,
> it's a request type that can be sent zero or more times during the 
> life
> of the connection.  What happens if I open a sftp subsytem then a 
> normal
> shell session or vice versa?
>
>> you must also disable the privilege separation
>
> that's usually a pretty good indication that you're doing something
> wrong.
>
> I'd like to study your diff a bit more but it got mangled to the 
> point
> that patch denies there's even a diff in there.  Could you please 
> resend
> (a) using diff -u (unified) format and (b) as an text/plain 
> attachment.
>
> Thanks.
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the 
> experience
> usually comes from bad judgement.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sshd-traces.txt
Type: text/x-c
Size: 17979 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120521/d0e723e7/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff-out.txt
Type: text/x-diff
Size: 16494 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20120521/d0e723e7/attachment-0003.bin>

From keisial at gmail.com  Tue May 22 03:06:43 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Mon, 21 May 2012 19:06:43 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD2213F1E3@ESESSCMS0360.eemea.ericsson.se>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <13823066-F116-4C59-9EB1-F22CEAC38E88@doxpara.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD2213F1E3@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <4FBA7623.9050509@gmail.com>

On 21/05/12 09:12, John Olsson M wrote:
> I'm not sure what part you are referring to. What we need to be able to do is to place just the SFTP server in a chroot jail. But I'll give you some background so you can understand better what it is we want to do
>
> We have a box/node/machine/server/whatever that runs SLES as Nicola wrote. This server has two SSH servers running; one on port 22 and one on port 4422. When logging in to port 22 credentials are first verified against /etc/passwd and then an LDAP server is checked if /etc/passwd failed, for port 4422 it is only /etc/passwd that is checked and SFTP subsystem is disabled.
>
> If you just do a "normal" ssh login (without specifying any subsystem) you end up in what we call "COM CLI" which can be thought of as a text-based interface to an information model (you can navigate a tree structure, modify attributes and create objects, etc). This information model will also provide a branch showing a virtual filesystem. Thus this is a completely different animal compared to a Bash shell, it is purely a high level management interface for the server.
>
> Now when connecting to port 22 using an SFTP client, this client may only see the same virtual filesystem that is also visible via the information model. Thus the SFTP server must run in a chrooted environment, but SSH (COM CLI) may not since the COM CLI must be able to access the complete system.
> Connecting to port 4422 gives you a standard Bash shell.
>
> Did this answer your question, or did I answer some other question which you did not ask? :)
>
> /John
Dirty workaround: the port 22 shell is is a setuid wrapper which exits
from the chroot, drops permissions and execs the "COM CLI".

From kavya.vc at nsn.com  Tue May 22 18:49:30 2012
From: kavya.vc at nsn.com (Vc, Kavya (NSN - IN/Bangalore))
Date: Tue, 22 May 2012 16:49:30 +0800
Subject: regarding Openssh
Message-ID: <DE4F4E65EB03EF4689FF9C1D52D8A11001061596@SGSIEXC025.nsn-intra.net>

Hello,

  Currently we have Openssh 5.1. But  I m not able to perform  ssh to
cluster ip.
Please provide the analysis.


Regards,
Kavya VC

From peter at stuge.se  Tue May 22 19:54:46 2012
From: peter at stuge.se (Peter Stuge)
Date: Tue, 22 May 2012 11:54:46 +0200
Subject: regarding Openssh
In-Reply-To: <DE4F4E65EB03EF4689FF9C1D52D8A11001061596@SGSIEXC025.nsn-intra.net>
References: <DE4F4E65EB03EF4689FF9C1D52D8A11001061596@SGSIEXC025.nsn-intra.net>
Message-ID: <20120522095446.15177.qmail@stuge.se>

Vc, Kavya (NSN - IN/Bangalore) wrote:
> Currently we have Openssh 5.1. But  I m not able to perform  ssh to
> cluster ip.
> Please provide the analysis.

Actually *you* have to provide the analysis.

Please read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html


//Peter

From john.m.olsson at ericsson.com  Tue May 22 20:41:13 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Tue, 22 May 2012 12:41:13 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <4FBA7623.9050509@gmail.com>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <13823066-F116-4C59-9EB1-F22CEAC38E88@doxpara.com>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD2213F1E3@ESESSCMS0360.eemea.ericsson.se>
 <4FBA7623.9050509@gmail.com>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD2213F929@ESESSCMS0360.eemea.ericsson.se>

> Dirty workaround: the port 22 shell is is a setuid wrapper
> which exits from the chroot, drops permissions and execs the
> "COM CLI". 

That was indeed a very dirty solution. :)

Good to know about, but I would very much like to avoid it if possible.


/John

From dtucker at zip.com.au  Tue May 22 21:23:07 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 22 May 2012 21:23:07 +1000
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
Message-ID: <20120522112307.GA5880@gate.dtucker.net>

OK, so the way this works is that it reparses the config again when it
does the subsystem lookup.  I'm not convinced this is a good idea, and
there are a couple of problems with the existing implementation.

On Mon, May 21, 2012 at 04:15:16PM +0200, Nicola Muto wrote:
[...]
> +		connection_info.user = NULL;
[...]
> +		logit("subsystem request: Parsing server match config options: user == '%s', host == '%s', address == '%s', subsystem == '%s'",
> +				connection_info.user, connection_info.host,
> +				connection_info.address, connection_info.subsystem);

This will deref null pointers on most platforms.  glibc might save you,
but most libcs won't.

> +		parse_server_match_config(&options, &connection_info);

Because everything except the subsystem is nulled out a this point,
config lines like "Match User foo subsystem sftp" are syntactically
valid, but don't do what you'd think.

This reparsing could also change the server state in unexpected ways,
for example:

AllowTcpForwarding yes
Match Subsystem sftp
	AllowTcpForwarding no

would allow port fowarding until you sent an sftp subsystem request.

> +		prog = options.subsystem_command[i]

In order to understand it, I forward-ported the patch to HEAD and
removed all of the unrelated changes.  (I haven't tested it, I'm only
including it in case saves someone the work).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
-------------- next part --------------
Index: servconf.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/servconf.c,v
retrieving revision 1.223
diff -u -p -r1.223 servconf.c
--- servconf.c	19 May 2012 09:37:01 -0000	1.223
+++ servconf.c	22 May 2012 02:34:23 -0000
@@ -553,6 +553,7 @@ get_connection_info(int populate, int us
 	ci.address = get_remote_ipaddr();
 	ci.laddress = get_local_ipaddr(packet_get_connection_in());
 	ci.lport = get_local_port();
+	ci.subsystem = NULL;
 	return &ci;
 }
 
@@ -632,10 +633,12 @@ match_cfg_line(char **condition, int lin
 		debug3("checking syntax for 'Match %s'", cp);
 	else
 		debug3("checking match for '%s' user %s host %s addr %s "
-		    "laddr %s lport %d", cp, ci->user ? ci->user : "(null)",
+		    "laddr %s subsys %s lport %d", cp,
+		    ci->user ? ci->user : "(null)",
 		    ci->host ? ci->host : "(null)",
 		    ci->address ? ci->address : "(null)",
-		    ci->laddress ? ci->laddress : "(null)", ci->lport);
+		    ci->laddress ? ci->laddress : "(null)",
+		    ci->subsystem ? ci->subsystem : "(null)", ci->lport);
 
 	while ((attrib = strdelim(&cp)) && *attrib != '\0') {
 		if ((arg = strdelim(&cp)) == NULL || *arg == '\0') {
@@ -709,6 +712,17 @@ match_cfg_line(char **condition, int lin
 			case -2:
 				return -1;
 			}
+		} else if (strcasecmp(attrib, "subsystem") == 0) {
+			if (ci == NULL || ci->subsystem == NULL) {
+				result = 0;
+				continue;
+			}
+			if (match_pattern_list(ci->subsystem, arg, len, 0) != 1)
+				result = 0;
+			else
+				debug("subsystem %.100s matched 'Subsystem "
+				    "'%.100s' line %d", ci->subsystem, arg,
+				    line);
 		} else if (strcasecmp(attrib, "localport") == 0) {
 			if ((port = a2port(arg)) == -1) {
 				error("Invalid LocalPort '%s' on Match line",
@@ -1566,6 +1580,8 @@ int parse_server_match_testspec(struct c
 			ci->user = xstrdup(p + 5);
 		} else if (strncmp(p, "laddr=", 6) == 0) {
 			ci->laddress = xstrdup(p + 6);
+		} else if (strncmp(p, "subsystem=", 10) == 0) {
+			ci->subsystem = xstrdup(p + 10);
 		} else if (strncmp(p, "lport=", 6) == 0) {
 			ci->lport = a2port(p + 6);
 			if (ci->lport == -1) {
Index: servconf.h
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/servconf.h,v
retrieving revision 1.93
diff -u -p -r1.93 servconf.h
--- servconf.h	19 May 2012 09:37:01 -0000	1.93
+++ servconf.h	22 May 2012 01:37:23 -0000
@@ -176,6 +176,7 @@ struct connection_info {
 	const char *host;	/* possibly resolved hostname */
 	const char *address; 	/* remote address */
 	const char *laddress;	/* local address */
+	const char *subsystem; /* Subsystem service requested by the remote client application */
 	int lport;		/* local port */
 };
 
Index: session.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/session.c,v
retrieving revision 1.414
diff -u -p -r1.414 session.c
--- session.c	22 Apr 2012 01:08:10 -0000	1.414
+++ session.c	22 May 2012 01:55:02 -0000
@@ -2087,23 +2087,39 @@ session_subsystem_req(Session *s)
 	logit("subsystem request for %.100s by user %s", subsys,
 	    s->pw->pw_name);
 
+	/* Searching for subsystem into the options repository */
 	for (i = 0; i < options.num_subsystems; i++) {
-		if (strcmp(subsys, options.subsystem_name[i]) == 0) {
-			prog = options.subsystem_command[i];
-			cmd = options.subsystem_args[i];
-			if (strcmp(INTERNAL_SFTP_NAME, prog) == 0) {
-				s->is_subsystem = SUBSYSTEM_INT_SFTP;
-				debug("subsystem: %s", prog);
-			} else {
-				if (stat(prog, &st) < 0)
-					debug("subsystem: cannot stat %s: %s",
-					    prog, strerror(errno));
-				s->is_subsystem = SUBSYSTEM_EXT;
-				debug("subsystem: exec() %s", cmd);
-			}
-			success = do_exec(s, cmd) == 0;
-			break;
+		if (strcmp(subsys, options.subsystem_name[i]) == 0)	break;
+	}
+
+	if (i < options.num_subsystems) { /* subsystem found */
+		struct connection_info ci;
+
+		ci.user = NULL;
+		ci.host = NULL;
+		ci.address = NULL;
+		ci.subsystem = subsys;
+
+		logit("subsystem request: Parsing server match config options: user == '%s', host == '%s', address == '%s', subsystem == '%s'",
+		    ci.user, ci.host, ci.address, ci.subsystem);  /* XXX: SEGFAULT */
+
+		parse_server_match_config(&options, &ci);
+
+		prog = options.subsystem_command[i];
+		cmd = options.subsystem_args[i];
+
+		if (strcmp(INTERNAL_SFTP_NAME, prog) == 0) {
+			s->is_subsystem = SUBSYSTEM_INT_SFTP;
+			debug("subsystem: %s", prog);
+		} else {
+			if (stat(prog, &st) < 0)
+				debug("subsystem: cannot stat %s: %s",
+				    prog, strerror(errno));
+			s->is_subsystem = SUBSYSTEM_EXT;
+			debug("subsystem: exec() %s", cmd);
 		}
+
+		success = do_exec(s, cmd) == 0;
 	}
 
 	if (!success)
Index: sshd.8
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/sshd.8,v
retrieving revision 1.226
diff -u -p -r1.226 sshd.8
--- sshd.8	19 May 2012 09:37:01 -0000	1.226
+++ sshd.8	22 May 2012 01:56:37 -0000
@@ -108,17 +108,24 @@ extended test mode.
 If provided, any
 .Cm Match
 directives in the configuration file
-that would apply to the specified user, host, and address will be set before
+that would apply to the specified user, host, address, and subsystem will be set before
 the configuration is written to standard output.
 The connection parameters are supplied as keyword=value pairs.
 The keywords are
+.Dq addr,
 .Dq user ,
-.Dq host ,
-.Dq laddr ,
+.Dq host , ,
 .Dq lport ,
 and
-.Dq addr .
-All are required and may be supplied in any order, either with multiple
+.Dq subsystem .
+Only
+.Dq user ,
+.Dq host ,
+and
+.Dq addr 
+keywords are required;
+.Dq subsystem 
+is optional. These parameters may be supplied in any order, either with multiple
 .Fl C
 options or as a comma-separated list.
 .It Fl c Ar host_certificate_file
Index: sshd_config.5
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/sshd_config.5,v
retrieving revision 1.147
diff -u -p -r1.147 sshd_config.5
--- sshd_config.5	19 May 2012 09:37:33 -0000	1.147
+++ sshd_config.5	22 May 2012 11:03:38 -0000
@@ -677,10 +677,11 @@ The available criteria are
 .Cm User ,
 .Cm Group ,
 .Cm Host ,
+.Cm Address ,
 .Cm LocalAddress ,
 .Cm LocalPort ,
 and
-.Cm Address .
+.Cm Subsystem .
 The match patterns may consist of single entries or comma-separated
 lists and may use the wildcard and negation operators described in the
 .Sx PATTERNS

From nicola.muto at cryptolab.net  Wed May 23 02:01:17 2012
From: nicola.muto at cryptolab.net (Nicola Muto)
Date: Tue, 22 May 2012 18:01:17 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <20120522112307.GA5880@gate.dtucker.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
Message-ID: <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>

> OK, so the way this works is that it reparses the config again when 
> it
> does the subsystem lookup.

Yes.


> I'm not convinced this is a good idea, and
> there are a couple of problems with the existing implementation.

Why not? I'd like to understand what kind of problems you have with
the current implementation.
The Match Subsystem will be triggered when the client is sending a
subsystem request and this should be the last config file reparsing.


> [...]
>
> This will deref null pointers on most platforms.  glibc might save 
> you,
> but most libcs won't.

These are very minor problems and could be solved using the ?: 
operator, as usual,
to avoid segmentation faults:

     str_ptr ? str_ptr : "(null)"

or, using the GCC compact format

     str_ptr ?: "(null)"

For that one could also write a CPP macro.
Personally, I wish that the C library implementations all behave the 
same way, at
least in these small cases.


> Because everything except the subsystem is nulled out a this point,
> config lines like "Match User foo subsystem sftp" are syntactically
> valid, but don't do what you'd think.

Yes you are right. That issue was already in my mind.
Can it be solved defining a global instance of the ConnectionInfo 
structure
into the sshd.c file and importing it as extern into the other files so 
that
user, host, address, subsystem (and also lddress and lport) values can 
be
always available?


> This reparsing could also change the server state in unexpected ways,
> for example:
>
> AllowTcpForwarding yes
> Match Subsystem sftp
> 	AllowTcpForwarding no
>
> would allow port fowarding until you sent an sftp subsystem request.

Sorry Darren, but that's exactly what I expect the ssh server should 
do,
reading this config. So I know what I'm doing with this kind of 
configuration.

\\nm



On 2012-05-22 13:23, Darren Tucker wrote:
> OK, so the way this works is that it reparses the config again when 
> it
> does the subsystem lookup.  I'm not convinced this is a good idea, 
> and
> there are a couple of problems with the existing implementation.
>
> On Mon, May 21, 2012 at 04:15:16PM +0200, Nicola Muto wrote:
> [...]
>> +		connection_info.user = NULL;
> [...]
>> +		logit("subsystem request: Parsing server match config options: 
>> user == '%s', host == '%s', address == '%s', subsystem == '%s'",
>> +				connection_info.user, connection_info.host,
>> +				connection_info.address, connection_info.subsystem);
>
> This will deref null pointers on most platforms.  glibc might save 
> you,
> but most libcs won't.
>
>> +		parse_server_match_config(&options, &connection_info);
>
> Because everything except the subsystem is nulled out a this point,
> config lines like "Match User foo subsystem sftp" are syntactically
> valid, but don't do what you'd think.
>
> This reparsing could also change the server state in unexpected ways,
> for example:
>
> AllowTcpForwarding yes
> Match Subsystem sftp
> 	AllowTcpForwarding no
>
> would allow port fowarding until you sent an sftp subsystem request.
>
>> +		prog = options.subsystem_command[i]
>
> In order to understand it, I forward-ported the patch to HEAD and
> removed all of the unrelated changes.  (I haven't tested it, I'm only
> including it in case saves someone the work).
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the 
> experience
> usually comes from bad judgement.


From peter at stuge.se  Wed May 23 10:14:36 2012
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 May 2012 02:14:36 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
Message-ID: <20120523001436.18655.qmail@stuge.se>

Nicola Muto wrote:
>> This reparsing could also change the server state in unexpected ways,
>> for example:
>>
>> AllowTcpForwarding yes
>> Match Subsystem sftp
>> 	AllowTcpForwarding no
>>
>> would allow port fowarding until you sent an sftp subsystem request.
>
> Sorry Darren, but that's exactly what I expect the ssh server should
> do, reading this config. So I know what I'm doing with this kind of 
> configuration.

The discussion has nothing to do with you or the needs of Ericsson.
OpenSSH behaving like the above would be absolutely retarded.


//Peter

From john.m.olsson at ericsson.com  Wed May 23 13:37:16 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Wed, 23 May 2012 05:37:16 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <20120523001436.18655.qmail@stuge.se>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>,
 <20120523001436.18655.qmail@stuge.se>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD2248C360@ESESSCMS0360.eemea.ericsson.se>

> The discussion has nothing to do with you or the needs of Ericsson.
> OpenSSH behaving like the above would be absolutely retarded.

I agree!


>> would allow port fowarding until you sent an sftp subsystem request.

My interpretation (as an end user) of the construct shown below is that AllowTcpForwarding is not allowed for the SFTP subsystem, that is if you connect to the server using the SFTP subsystem. All other connection requests for other subsystems would still allow port forwarding.

Now I do not now how much sense the above makes.

Perhaps one should define a list of configuration statements that acts as a nop (no operation) when a match agaginst subsystem is done?


/John
________________________________________
From: openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org [openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org] On Behalf Of Peter Stuge [peter at stuge.se]
Sent: Wednesday, May 23, 2012 02:14
To: openssh-unix-dev at mindrot.org
Subject: Re: New Subsystem criteria for Match option block in OpenSSH server

Nicola Muto wrote:
>> This reparsing could also change the server state in unexpected ways,
>> for example:
>>
>> AllowTcpForwarding yes
>> Match Subsystem sftp
>>      AllowTcpForwarding no
>>
>> would allow port fowarding until you sent an sftp subsystem request.
>
> Sorry Darren, but that's exactly what I expect the ssh server should
> do, reading this config. So I know what I'm doing with this kind of
> configuration.

The discussion has nothing to do with you or the needs of Ericsson.
OpenSSH behaving like the above would be absolutely retarded.


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From dtucker at zip.com.au  Wed May 23 14:05:57 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 23 May 2012 14:05:57 +1000
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD2248C360@ESESSCMS0360.eemea.ericsson.se>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523001436.18655.qmail@stuge.se>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD2248C360@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <20120523040557.GA21707@gate.dtucker.net>

On Wed, May 23, 2012 at 05:37:16AM +0200, John Olsson M wrote:
[...]
> My interpretation (as an end user) of the construct shown below is
> that AllowTcpForwarding is not allowed for the SFTP subsystem, that is if
> you connect to the server using the SFTP subsystem. All other connection
> requests for other subsystems would still allow port forwarding.
> 
> Now I do not now how much sense the above makes.

It doesn't make sense.  subsystem requests, port forwarding requests
(and shell session requests for that matter) are all different request
types that may be sent in a single SSH connection.  There's no such
thing "connecting to the server using the sftp subsystem"; you connect
to the SSH server, then request zero or more of session, subsystem or
port forwarding requests an any order you please.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From dtucker at zip.com.au  Wed May 23 15:54:21 2012
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 23 May 2012 15:54:21 +1000
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
Message-ID: <20120523055421.GB21707@gate.dtucker.net>

On Tue, May 22, 2012 at 06:01:17PM +0200, Nicola Muto wrote:
> Darren Tucker write:
> >I'm not convinced this is a good idea
> 
> Why not? I'd like to understand what kind of problems you have with
> the current implementation.

I have two sets of problems with the patch.  The lesser of the two were
the implementation things I mentioned in my previous email.

The larger and thornier set is whether or not this is a sensible thing
to do at all.
1) right now, the Match rules do not change the behaviour after the
   username is supplied (very early in the logon process).  The proposed
   patch allows a whole bunch of things to change at run time in possibly
   unanticipated ways.
2) it doesn't (and can't work) with ChrootDirectory+PrivilegeSeparation,
   which negates a whole lot of the safety features in sshd.

#2 has obvious security implications, but #1 can too.  For example: do
you allow the user to write to the chroot directory itself?

You shouldn't (and there's a reason why there's a check for this), but
if you do, having ChrootDirectory on the list makes the exploit easy:
in a single SSH session, open one shell session where you hardlink a
setuid binary into the chroot, then use sftp to upload, say, a backdoored
libc into the chroot (and thereby activating ChrootDirectory), then a
second shell session to execute the setuid binary which will load the
backdoored libc from the chroot and do something nasty.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3ou do  86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From nicola.muto at cryptolab.net  Wed May 23 18:11:18 2012
From: nicola.muto at cryptolab.net (Nicola Muto)
Date: Wed, 23 May 2012 08:11:18 +0000
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <20120523001436.18655.qmail@stuge.se>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523001436.18655.qmail@stuge.se>
Message-ID: <254ee0f441ac9c57085892803cf053a4@cryptolab.net>

Sorry guys, there was a misunderstanding due to my wrong words.

Instead, what I wanted to say is that a system administrator that is
configuring the ssh server with the following config lines, for 
example,

   ...
   AllowTcpForwarding yes
   ...
   Match Subsystem sftp
     AllowTcpForwarding no

"should know what he is doing". That is, the AllowTcpForwarding option 
put at
global level is active until a client sent an sftp subsystem request.
This is what comes out by reading the above configuration file; I 
think.

Sorry again, I'm disappointed.

\\nm


On 2012-05-23 00:14, Peter Stuge wrote:
> Nicola Muto wrote:
>>> This reparsing could also change the server state in unexpected 
>>> ways,
>>> for example:
>>>
>>> AllowTcpForwarding yes
>>> Match Subsystem sftp
>>> 	AllowTcpForwarding no
>>>
>>> would allow port fowarding until you sent an sftp subsystem 
>>> request.
>>
>> Sorry Darren, but that's exactly what I expect the ssh server should
>> do, reading this config. So I know what I'm doing with this kind of
>> configuration.
>
> The discussion has nothing to do with you or the needs of Ericsson.
> OpenSSH behaving like the above would be absolutely retarded.
>
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From peter at stuge.se  Wed May 23 19:12:09 2012
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 May 2012 11:12:09 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <254ee0f441ac9c57085892803cf053a4@cryptolab.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523001436.18655.qmail@stuge.se>
 <254ee0f441ac9c57085892803cf053a4@cryptolab.net>
Message-ID: <20120523091209.28105.qmail@stuge.se>

Nicola Muto wrote:
> Sorry guys, there was a misunderstanding due to my wrong words.

Actually I think I understood.


> a system administrator that is configuring the ssh server with the
> following config lines, for example,
>
>   ...
>   AllowTcpForwarding yes
>   ...
>   Match Subsystem sftp
>     AllowTcpForwarding no
>
> "should know what he is doing".

My point is that this is extremely unintuitive and if the admin also
knows roughly how the SSH protocol works then it is directly
confusing. I am strongly opposed to introducing this kind of
indeterministic and inconsequent behavior into any program, and
into sshd in particular.


//Peter

From nicola.muto at cryptolab.net  Wed May 23 23:31:45 2012
From: nicola.muto at cryptolab.net (Nicola Muto)
Date: Wed, 23 May 2012 13:31:45 +0000
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <20120523055421.GB21707@gate.dtucker.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523055421.GB21707@gate.dtucker.net>
Message-ID: <a172036953d4a022b69e25aabedf6fba@cryptolab.net>

Ok Darren, you confirmed my doubts about adding Match-Subsystem
option to sshd, most of all for the ChrootDirectory+PrivilegeSeparation
problem.

Now I have a question. What's that sounds bad, the implementation of 
the
patch or the Match-Subsystem idea itself?
In other words. Is it possible to solve all of these issues providing 
another
implementation? Am I doing something wrong or forgetting something?

If so, a new implementation should be not so simple and have heavy 
impacts
on the source. Moreover, I think that the Peter's issue can't be solved
by whatever implementation is proposed. Am I right?

If not then the Match-Subsystem solution itself sounds not a good idea.

Please, let me know what you think about. Thank you in advance.

> #2 has obvious security implications, but #1 can too.  For example: 
> do
> you allow the user to write to the chroot directory itself?

No user can write to the chroot directory.

\\nm



On 2012-05-23 05:54, Darren Tucker wrote:
> On Tue, May 22, 2012 at 06:01:17PM +0200, Nicola Muto wrote:
>> Darren Tucker write:
>> >I'm not convinced this is a good idea
>>
>> Why not? I'd like to understand what kind of problems you have with
>> the current implementation.
>
> I have two sets of problems with the patch.  The lesser of the two 
> were
> the implementation things I mentioned in my previous email.
>
> The larger and thornier set is whether or not this is a sensible 
> thing
> to do at all.
> 1) right now, the Match rules do not change the behaviour after the
>    username is supplied (very early in the logon process).  The 
> proposed
>    patch allows a whole bunch of things to change at run time in 
> possibly
>    unanticipated ways.
> 2) it doesn't (and can't work) with 
> ChrootDirectory+PrivilegeSeparation,
>    which negates a whole lot of the safety features in sshd.
>
> #2 has obvious security implications, but #1 can too.  For example: 
> do
> you allow the user to write to the chroot directory itself?
>
> You shouldn't (and there's a reason why there's a check for this), 
> but
> if you do, having ChrootDirectory on the list makes the exploit easy:
> in a single SSH session, open one shell session where you hardlink a
> setuid binary into the chroot, then use sftp to upload, say, a 
> backdoored
> libc into the chroot (and thereby activating ChrootDirectory), then a
> second shell session to execute the setuid binary which will load the
> backdoored libc from the chroot and do something nasty.
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3ou do  86E9 7EEE AF4B B2D4  37C9 C982 80C7 
> 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the 
> experience
> usually comes from bad judgement.


From keisial at gmail.com  Thu May 24 00:57:37 2012
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Wed, 23 May 2012 16:57:37 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <a172036953d4a022b69e25aabedf6fba@cryptolab.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523055421.GB21707@gate.dtucker.net>
 <a172036953d4a022b69e25aabedf6fba@cryptolab.net>
Message-ID: <4FBCFAE1.8010709@gmail.com>

On 23/05/12 15:31, Nicola Muto wrote:
> Ok Darren, you confirmed my doubts about adding Match-Subsystem
> option to sshd, most of all for the ChrootDirectory+PrivilegeSeparation
> problem.
>
> Now I have a question. What's that sounds bad, the implementation of the
> patch or the Match-Subsystem idea itself?
> In other words. Is it possible to solve all of these issues providing
> another
> implementation? Am I doing something wrong or forgetting something?
>
> If so, a new implementation should be not so simple and have heavy
> impacts
> on the source. Moreover, I think that the Peter's issue can't be solved
> by whatever implementation is proposed. Am I right?
>
> If not then the Match-Subsystem solution itself sounds not a good idea.
>
> Please, let me know what you think about. Thank you in advance.
After reading Peter and Darren replies, I agree with them that a
Subsystem match to set forwarding makes no sense.

OTOH, I think you should be setting them globally.

Where you requested this setup:
>   Match Subsystem sftp
>       ChrootDirectory /path/to/sftp/data/jail/on/the/server
>       X11Forwarding no
>       AllowTcpForwarding no
>       ForceCommand internal-sftp 


What you need is probably this:
>   X11Forwarding no
>   AllowTcpForwarding no 
>   Match Subsystem sftp
>       ChrootDirectory /path/to/sftp/data/jail/on/the/server
>       ForceCommand internal-sftp 

Chroot and executed command *are* a property of the subsystem. It's a
bit weird to have different chroots, but that's what you require.
No special reason to use ForceCommand instead of "Subsystem sftp
internal-sftp", though.


From mouring at eviladmin.org  Thu May 24 01:05:31 2012
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Wed, 23 May 2012 10:05:31 -0500
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <a172036953d4a022b69e25aabedf6fba@cryptolab.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523055421.GB21707@gate.dtucker.net>
 <a172036953d4a022b69e25aabedf6fba@cryptolab.net>
Message-ID: <D5F997BE-B8DF-41F6-BE85-CC2AAAB86F8A@eviladmin.org>


On May 23, 2012, at 8:31 AM, Nicola Muto wrote:

> Ok Darren, you confirmed my doubts about adding Match-Subsystem
> option to sshd, most of all for the ChrootDirectory+PrivilegeSeparation
> problem.
> 
> Now I have a question. What's that sounds bad, the implementation of the
> patch or the Match-Subsystem idea itself?
> In other words. Is it possible to solve all of these issues providing another
> implementation? Am I doing something wrong or forgetting something?
> 
> If so, a new implementation should be not so simple and have heavy impacts
> on the source. Moreover, I think that the Peter's issue can't be solved
> by whatever implementation is proposed. Am I right?

I'm not sure any patch would be acceptable.  The heart of the issue is simple:

Setup a ControlMaster,  start a shell connection to the server,  then start
a sftp connection reusing that control.  If you set anything like "don't allow
forward, etc"  now forward is disabled for the shell and for sftp.   This isn't
logical behavior that someone would expect unless they understood the
ssh protocol.

So unless you limit the protocol so you can only setup a single session type
(subsystem, shell, etc) per connection then I can't see how this is a sane 
feature for admins to wrap their heads around.

- Ben

From john.m.olsson at ericsson.com  Thu May 24 16:57:50 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Thu, 24 May 2012 08:57:50 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <20120523091209.28105.qmail@stuge.se>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523001436.18655.qmail@stuge.se>
 <254ee0f441ac9c57085892803cf053a4@cryptolab.net>
 <20120523091209.28105.qmail@stuge.se>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0351@ESESSCMS0360.eemea.ericsson.se>

>> a system administrator that is configuring the ssh server
>> with the following config lines, for example,
>>
>>   ...
>>   AllowTcpForwarding yes
>>   ...
>>   Match Subsystem sftp
>>     AllowTcpForwarding no
>>
>> "should know what he is doing".
>
> My point is that this is extremely unintuitive and if the
> admin also knows roughly how the SSH protocol works then
> it is directly confusing. I am strongly opposed to
> introducing this kind of indeterministic and inconsequent
> behavior into any program, and into sshd in particular.

Don't you have the same problem with fopr instance other match statements?

What happens if you have

...
AllowTcpForwarding yes
...
Match User foo
  AllowTcpForwarding no

Wouldn't this cause the same behavior? That once user foo logs on TCP forwarding is denied? What is it that makes the subsystem so magical that it suddenly affects the whole server?


/John

-----Original Message-----
From: openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org [mailto:openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org] On Behalf Of Peter Stuge
Sent: den 23 maj 2012 11:12
To: openssh-unix-dev at mindrot.org
Subject: Re: New Subsystem criteria for Match option block in OpenSSH server

Nicola Muto wrote:
> Sorry guys, there was a misunderstanding due to my wrong words.

Actually I think I understood.


> a system administrator that is configuring the ssh server with the 
> following config lines, for example,
>
>   ...
>   AllowTcpForwarding yes
>   ...
>   Match Subsystem sftp
>     AllowTcpForwarding no
>
> "should know what he is doing".

My point is that this is extremely unintuitive and if the admin also knows roughly how the SSH protocol works then it is directly confusing. I am strongly opposed to introducing this kind of indeterministic and inconsequent behavior into any program, and into sshd in particular.


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From john.m.olsson at ericsson.com  Thu May 24 17:02:05 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Thu, 24 May 2012 09:02:05 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <20120523055421.GB21707@gate.dtucker.net>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523055421.GB21707@gate.dtucker.net>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0361@ESESSCMS0360.eemea.ericsson.se>

> #2 has obvious security implications, but #1 can too.
> For example: do you allow the user to write to the
> chroot directory itself?

If you mean chroot directory == "/" then root owns that directory ofcourse. You have the same problem as you describe below with the existing chroot directive, right?

If not, please explain why chroot:ing per subsystem creates a security hole.


> ChrootDirectory), then a second shell session to execute the setuid
> binary which will load the backdoored libc from the chroot and do something 
> nasty.

It is here I get lost. The chroot is configured per subsystem. So if you have the following hypothetical construct in SSHD config

Match Subsystem SFTP
  ChrootDirectory /foo/bar

You will only end up in the /foo/bar (as the new root) when you connect to the SFTP subsystem.

Thus you can't suddenly choose if you want to have a plain vanilla SSH to be chrooted or not. The idea was that the construct affects the whole subsystem, so how can you get a chroot:ed shell and do something nasty? Or what is it that I am missing? I want to understand. :)


/John

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: den 23 maj 2012 07:54
To: Nicola Muto
Cc: dtucker at zip.com.au; Nicola Muto; openssh-unix-dev at mindrot.org; John Olsson M; Hans Insulander
Subject: Re: New Subsystem criteria for Match option block in OpenSSH server

On Tue, May 22, 2012 at 06:01:17PM +0200, Nicola Muto wrote:
> Darren Tucker write:
> >I'm not convinced this is a good idea
> 
> Why not? I'd like to understand what kind of problems you have with 
> the current implementation.

I have two sets of problems with the patch.  The lesser of the two were the implementation things I mentioned in my previous email.

The larger and thornier set is whether or not this is a sensible thing to do at all.
1) right now, the Match rules do not change the behaviour after the
   username is supplied (very early in the logon process).  The proposed
   patch allows a whole bunch of things to change at run time in possibly
   unanticipated ways.
2) it doesn't (and can't work) with ChrootDirectory+PrivilegeSeparation,
   which negates a whole lot of the safety features in sshd.

#2 has obvious security implications, but #1 can too.  For example: do you allow the user to write to the chroot directory itself?

You shouldn't (and there's a reason why there's a check for this), but if you do, having ChrootDirectory on the list makes the exploit easy:
in a single SSH session, open one shell session where you hardlink a setuid binary into the chroot, then use sftp to upload, say, a backdoored libc into the chroot (and thereby activating ChrootDirectory), then a second shell session to execute the setuid binary which will load the backdoored libc from the chroot and do something nasty.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3ou do  86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.

From john.m.olsson at ericsson.com  Thu May 24 17:29:35 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Thu, 24 May 2012 09:29:35 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <D5F997BE-B8DF-41F6-BE85-CC2AAAB86F8A@eviladmin.org>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523055421.GB21707@gate.dtucker.net>
 <a172036953d4a022b69e25aabedf6fba@cryptolab.net>
 <D5F997BE-B8DF-41F6-BE85-CC2AAAB86F8A@eviladmin.org>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0381@ESESSCMS0360.eemea.ericsson.se>

> Setup a ControlMaster,  start a shell connection to the server,
> then start a sftp connection reusing that control.  If you set
> anything like "don't allow forward, etc"  now forward is disabled
> for the shell and for sftp.   This isn't logical behavior that
> someone would expect unless they understood the ssh protocol. 

I agree. :(

Would it be sane to add additional restrictions on which keywords can follow a "Match Subsystem" construct? I think so and it would be intuitive to do so as well.

I guess the following set of keywords should not be allowed when matching on subsystem

AllowAgentForwarding
AllowTcpForwarding 
GatewayPorts
MaxSessions
PermitOpen
X11DisplayOffset
X11Forwarding
X11UseLocalHost

which still leavs the following keywords to be allowed

Banner
ChrootDirectory
ForceCommand
GSSAPIAuthentication
HostbasedAuthentication
KbdInteractiveAuthentication
KerberosAuthentication
KerberosUseKuserok
MaxAuthTries
PubkeyAuthentication
AuthorizedKeysCommand
AuthorizedKeysCommandRunAs
PasswordAuthentication
PermitEmptyPasswords
PermitRootLogin
RhostsRSAAuthentication
RSAAuthentication


Any more that are not sane to allow when matching on subsystem?


/John

-----Original Message-----
From: openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org [mailto:openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org] On Behalf Of Ben Lindstrom
Sent: den 23 maj 2012 17:06
To: Nicola Muto
Cc: openssh-unix-dev at mindrot.org openssh
Subject: Re: New Subsystem criteria for Match option block in OpenSSH server


On May 23, 2012, at 8:31 AM, Nicola Muto wrote:

> Ok Darren, you confirmed my doubts about adding Match-Subsystem option 
> to sshd, most of all for the ChrootDirectory+PrivilegeSeparation
> problem.
> 
> Now I have a question. What's that sounds bad, the implementation of 
> the patch or the Match-Subsystem idea itself?
> In other words. Is it possible to solve all of these issues providing 
> another implementation? Am I doing something wrong or forgetting something?
> 
> If so, a new implementation should be not so simple and have heavy 
> impacts on the source. Moreover, I think that the Peter's issue can't 
> be solved by whatever implementation is proposed. Am I right?

I'm not sure any patch would be acceptable.  The heart of the issue is simple:

Setup a ControlMaster,  start a shell connection to the server,  then start a sftp connection reusing that control.  If you set anything like "don't allow
forward, etc"  now forward is disabled for the shell and for sftp.   This isn't
logical behavior that someone would expect unless they understood the ssh protocol.

So unless you limit the protocol so you can only setup a single session type (subsystem, shell, etc) per connection then I can't see how this is a sane feature for admins to wrap their heads around.

- Ben
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From peter at stuge.se  Thu May 24 18:13:36 2012
From: peter at stuge.se (Peter Stuge)
Date: Thu, 24 May 2012 10:13:36 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0381@ESESSCMS0360.eemea.ericsson.se>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0351@ESESSCMS0360.eemea.ericsson.se>
References: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0381@ESESSCMS0360.eemea.ericsson.se>
 <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523001436.18655.qmail@stuge.se>
 <254ee0f441ac9c57085892803cf053a4@cryptolab.net>
 <20120523091209.28105.qmail@stuge.se>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0351@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <20120524081336.17793.qmail@stuge.se>

John Olsson M wrote:
> Don't you have the same problem with fopr instance other match statements?

None of the currently supported ones.


> What happens if you have
> 
> ...
> AllowTcpForwarding yes
> ...
> Match User foo
>   AllowTcpForwarding no
> 
> Wouldn't this cause the same behavior?

It doesn't. Please read the SSH architecture RFC 4251. It's short.

http://ftp.sunet.se/pub/Internet-documents/rfc/rfc4251.txt

TCP forwarding is implemented through an SSH channel. SSH channels
can only ever be created after authentication, so it makes sense to
be able to limit what type of channels are allowed given the
information available to sshd after authentication.


> That once user foo logs on TCP forwarding is denied?

No, TCP forwarding channels are denied in all foo's sessions.


> What is it that makes the subsystem so magical that it suddenly
> affects the whole server?

The subsystem is only one of any number of channels that may be
opened in a single SSH session. Please see RFC 4251.


John Olsson M wrote:
> Would it be sane to add additional restrictions on which keywords
> can follow a "Match Subsystem" construct? I think so and it would
> be intuitive to do so as well.

Sure, not all keywords make sense.


> I guess the following set of keywords should not be allowed when
> matching on subsystem

Matching on subsystem should only be able to change things affecting
that single subsystem. Since a subsystem per definition has no
definition; it is simply an authenticated and encrypted 8-bit-clean
bidirectional channel, it's not really possible for sshd to know what
the subsystem will do. Indeed there exists only one subsystem which
sshd even knows about, by default; sftp. For sftp it does indeed make
sense to consider a chroot, as well as the other options that
sftp-server accepts on the command line. See sftp-server(8).


> which still leavs the following keywords to be allowed
> 
> Banner

The banner is no longer relevant at the time of subsystems.


> ChrootDirectory
> ForceCommand

These two are the only ones that possibly have meaning when matching
on subsystem.


> GSSAPIAuthentication
> HostbasedAuthentication
> KbdInteractiveAuthentication
> KerberosAuthentication
> KerberosUseKuserok
> MaxAuthTries
> PubkeyAuthentication
> AuthorizedKeysCommand
> AuthorizedKeysCommandRunAs
> PasswordAuthentication
> PermitEmptyPasswords
> PermitRootLogin
> RhostsRSAAuthentication
> RSAAuthentication

The above are all about authentication which is no longer relevant
at the time of subsystems. Please read RFC 4251 so that you see how
the SSH protocol actually works and by extension how you can find
solutions that will both work for you and benefit others. Thanks!


//Peter

From mouring at eviladmin.org  Thu May 24 23:22:41 2012
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Thu, 24 May 2012 08:22:41 -0500
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0351@ESESSCMS0360.eemea.ericsson.se>
References: <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523001436.18655.qmail@stuge.se>
 <254ee0f441ac9c57085892803cf053a4@cryptolab.net>
 <20120523091209.28105.qmail@stuge.se>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0351@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <25F1D665-64B8-4E85-8C8C-4FFDE59ECD70@eviladmin.org>


On May 24, 2012, at 1:57 AM, John Olsson M wrote:

[..]
> Don't you have the same problem with fopr instance other match statements?
> 
> What happens if you have
> 
> ...
> AllowTcpForwarding yes
> ...
> Match User foo
>  AllowTcpForwarding no
> 
> Wouldn't this cause the same behavior? That once user foo logs on TCP forwarding is denied? What is it that makes the subsystem so magical that it suddenly affects the whole server?
> 

Simple answer no.  

Because you can't forward TCP sessions pre-authentication.  And once you have authorized yourself the logic is simple, "Everyone, but foo can forward TCP connections."  Same is true for matching on addresses, groups, and hosts as all of those are static through the session and are known up front.  

- Ben

From john.m.olsson at ericsson.com  Thu May 24 23:46:44 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Thu, 24 May 2012 15:46:44 +0200
Subject: New Subsystem criteria for Match option block in OpenSSH server
In-Reply-To: <20120524081336.17793.qmail@stuge.se>
References: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0381@ESESSCMS0360.eemea.ericsson.se>
 <7f8a494de03e338d9a8a92d3c43267a2@cryptolab.net>
 <20120518052516.GA2753@gate.dtucker.net>
 <f058ec9a7a3d31870bb76f7e1bb8380a@cryptolab.net>
 <20120522112307.GA5880@gate.dtucker.net>
 <7ec0300913f8d0ee24e8ff5342077d40@cryptolab.net>
 <20120523001436.18655.qmail@stuge.se>
 <254ee0f441ac9c57085892803cf053a4@cryptolab.net>
 <20120523091209.28105.qmail@stuge.se>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0351@ESESSCMS0360.eemea.ericsson.se>
 <20120524081336.17793.qmail@stuge.se>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0665@ESESSCMS0360.eemea.ericsson.se>

Thank you very much Peter for taking your time to explain this in such detail instead of just refering to the relevant RFCs. :)

What you write is pretty much what I was eventually able to piece together based on the ongoing discussions and reading of the SSHD Config manual page. But nopw I do understnad much deeper the implications on what it is we request and I hope IU can give relevant comments and suggestions on a way forward. I would very much like this to be implemented and salvaged in a sane way for all stakeholders. :)


>> ChrootDirectory
>> ForceCommand
>
> These two are the only ones that possibly have meaning when
> matching on subsystem.

So if we for a minute assume that we restrict the number of keywords that are allowed to be used to the two ones above when matching on subsystem, would that be an acceptable way forward?

What implications would this have on the existing source code?

Is it feasible to do with a reasonable (for whatever "reasonable" is) amount of work?

Or is your message that we should start looking for Plan B?


/John

From matt at warnertechnology.com  Sat May 26 02:01:55 2012
From: matt at warnertechnology.com (Matt Warner)
Date: Fri, 25 May 2012 09:01:55 -0700
Subject: openssh-unix-dev Digest, Vol 109, Issue 19
In-Reply-To: <mailman.369.1337389832.1297.openssh-unix-dev@mindrot.org>
References: <mailman.369.1337389832.1297.openssh-unix-dev@mindrot.org>
Message-ID: <CAHXP6ihjpvGzK7u9zGKCmEamvUx73LxwsLavq9F2LptTDcr5KQ@mail.gmail.com>

> Date: Sat, 19 May 2012 03:10:03 +0200
> From: Peter Stuge <peter at stuge.se>
> To: openssh-unix-dev at mindrot.org
> Subject: Re: Syslog via UDP for chrooted environments
> Message-ID: <20120519011003.30837.qmail at stuge.se>
> Content-Type: text/plain; charset=us-ascii
>
> Matt Warner wrote:
>> I've written code to do this, but wanted to gauge the reaction of
>> the group before I attempt to submit anything.
>
> I'd suggest to submit it upstream, ie. OpenSSH in OpenBSD. I for one
> think there is a point to have it, especially for the chrooted case.
>
>
> //Peter

Thanks for getting back to me, and apologies for my delay in
responding. You've suggested submitting upstream to OpenBSD, but I'm
even less clear on how to do that than how to submit code to just the
OpenSSH project. Regarding the latter, I don't see an easy way to
submit new code for anyone to review. I think I saw a suggestion to
use CVS or Mercurial to create diffs and then commit back, but I'm
thinking I won't have permissions to check in code.

Is there a doc somewhere that covers submitting code to OpenSSH?

Thanks,

Matt

From openssh at roumenpetrov.info  Sat May 26 05:24:30 2012
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Fri, 25 May 2012 22:24:30 +0300
Subject: Announce: X.509 certificates support v7.2 for OpenSSH version 6.0p1
Message-ID: <4FBFDC6E.7060006@roumenpetrov.info>

Dear All,

X.509 certificates support for OpenSSH  version 6.0p1 was published.
I brief new version include :
- support for Android platform;
- engine implementation is now considered stable;
- various regression test improvements including fixes for OpenSSL FIPS 
enabled 1.0.1 stable release  and korn shell



Yours sincerely,
Roumen Petrov

-- 
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/

From john.m.olsson at ericsson.com  Mon May 28 17:19:56 2012
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Mon, 28 May 2012 09:19:56 +0200
Subject: Announce: X.509 certificates support v7.2 for OpenSSH version
 6.0p1
In-Reply-To: <4FBFDC6E.7060006@roumenpetrov.info>
References: <4FBFDC6E.7060006@roumenpetrov.info>
Message-ID: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0D71@ESESSCMS0360.eemea.ericsson.se>

What is blocking this from being merged into OpenSSH?

/John 

-----Original Message-----
From: openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org [mailto:openssh-unix-dev-bounces+john.m.olsson=ericsson.com at mindrot.org] On Behalf Of Roumen Petrov
Sent: den 25 maj 2012 21:25
To: OpenSSH Devel List
Subject: Announce: X.509 certificates support v7.2 for OpenSSH version 6.0p1

Dear All,

X.509 certificates support for OpenSSH  version 6.0p1 was published.
I brief new version include :
- support for Android platform;
- engine implementation is now considered stable;
- various regression test improvements including fixes for OpenSSL FIPS enabled 1.0.1 stable release  and korn shell



Yours sincerely,
Roumen Petrov

-- 
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From peter at stuge.se  Mon May 28 17:57:47 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 28 May 2012 09:57:47 +0200
Subject: Announce: X.509 certificates support v7.2 for OpenSSH version
 6.0p1
In-Reply-To: <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0D71@ESESSCMS0360.eemea.ericsson.se>
References: <4FBFDC6E.7060006@roumenpetrov.info>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0D71@ESESSCMS0360.eemea.ericsson.se>
Message-ID: <20120528075747.6818.qmail@stuge.se>

John Olsson M wrote:
> What is blocking this from being merged into OpenSSH?

Quite likely the diffstat:

$ curl -s http://roumenpetrov.info/openssh/x509-7.2/openssh-6.0p1+x509-7.2.diff.gz | zcat | diffstat
 INSTALL                           |   14 
 LICENCE                           |    3 
 Makefile.in                       |   79 ++
 README.x509v3                     |  622 +++++++++++++++++++
 aclocal.m4                        |    2 
 auth-passwd.c                     |    7 
 auth.c                            |    2 
 auth2-hostbased.c                 |   42 +
 auth2-jpake.c                     |   49 +
 auth2-pubkey.c                    |  159 ++++
 authfd.c                          |   23 
 authfile.c                        |   75 ++
 cipher.c                          |   67 ++
 cipher.h                          |    6 
 config.h.in                       |   67 ++
 configure                         | 1072 ++++++++++++++++++++++++++++++---
 configure.ac                      |  343 +++++++++-
 defines.h                         |    7 
 dns.c                             |  343 ++++++++++
 dns.h                             |   32 -
 evp-compat.h                      |  134 ++++
 hostfile.c                        |   17 
 jpake.c                           |    7 
 key-eng.c                         |  677 +++++++++++++++++++++
 key-eng.h                         |   45 +
 key.c                             |  194 +++++-
 key.h                             |    9 
 log.c                             |   24 
 log.h                             |    4 
 loginrec.c                        |   10 
 m4/ldap.m4                        |  217 ++++++
 mac.c                             |   52 +
 mac.h                             |    7 
 misc.c                            |    9 
 moduli.0                          |   18 
 moduli.5                          |   10 
 monitor.c                         |    8 
 monitor_wrap.c                    |   15 
 openbsd-compat/Makefile.in        |    8 
 openbsd-compat/bsd-arc4random.c   |   30 
 openbsd-compat/bsd-closefrom.c    |   23 
 openbsd-compat/openssl-compat.c   |   57 +
 openbsd-compat/openssl-compat.h   |   18 
 openbsd-compat/xcrypt.c           |   11 
 pathnames.h                       |   50 +
 readconf.c                        |  344 ++++++++++
 readconf.h                        |   50 +
 regress/Makefile                  |   12 
 regress/forwarding.sh             |    6 
 regress/multiplex.sh              |    7 
 regress/sftp-cmds.sh              |    6 
 regress/test-exec.sh              |   23 
 scp.0                             |   74 --
 scp.1                             |   67 --
 servconf.c                        |  300 +++++++++
 servconf.h                        |   44 +
 session.c                         |   32 +
 sftp-server.0                     |   15 
 sftp-server.8                     |   10 
 sftp.0                            |  160 +----
 sftp.1                            |   67 --
 ssh-add.0                         |   44 -
 ssh-add.1                         |   26 
 ssh-add.c                         |   20 
 ssh-agent.0                       |   68 +-
 ssh-agent.1                       |   18 
 ssh-agent.c                       |   57 +
 ssh-dss.c                         |  199 ++++++
 ssh-keygen.0                      |  193 +++---
 ssh-keygen.1                      |   51 +
 ssh-keygen.c                      |   36 +
 ssh-keyscan.0                     |   46 -
 ssh-keyscan.1                     |   53 +
 ssh-keyscan.c                     |  117 ++-
 ssh-keysign.0                     |   19 
 ssh-keysign.8                     |   12 
 ssh-keysign.c                     |    3 
 ssh-ocsp.c                        | 1045 ++++++++++++++++++++++++++++++++
 ssh-pkcs11-helper.0               |    6 
 ssh-pkcs11-helper.8               |   10 
 ssh-pkcs11-helper.c               |    5 
 ssh-pkcs11.c                      |   57 +
 ssh-rsa.c                         |  143 ++++
 ssh-x509.c                        | 1215 ++++++++++++++++++++++++++++++++++++++
 ssh-x509.h                        |   86 ++
 ssh-xkalg.c                       |  532 ++++++++++++++++
 ssh-xkalg.h                       |   58 +
 ssh.0                             |  554 ++++++++---------
 ssh.1                             |  196 +++---
 ssh.c                             |   76 ++
 ssh_config                        |   13 
 ssh_config.0                      |  632 +++++++++++--------
 ssh_config.5                      |  247 +++++++
 ssh_engine.0                      |   64 ++
 ssh_engine.5                      |  120 +++
 sshconnect.c                      |   69 +-
 sshconnect2.c                     |  121 +++
 sshd.0                            |  430 +++++++------
 sshd.8                            |   91 ++
 sshd.c                            |   57 +
 sshd_config                       |   68 ++
 sshd_config.0                     |  456 +++++++++-----
 sshd_config.5                     |  259 ++++++++
 tests/CA/1-cre_cadb.sh            |  417 +++++++++++++
 tests/CA/2-cre_cakeys.sh          |  382 +++++++++++
 tests/CA/2-cre_key.sh             |   33 +
 tests/CA/3-cre_certs.sh           |  343 ++++++++++
 tests/CA/4-cre_crls.sh            |  125 +++
 tests/CA/5-cre_ldap.sh            |  137 ++++
 tests/CA/Makefile.in              |  163 +++++
 tests/CA/config                   |  254 +++++++
 tests/CA/env.in                   |    7 
 tests/CA/functions                |  279 ++++++++
 tests/CA/openssh_tests.sh         |  374 +++++++++++
 tests/CA/shell.rc                 |   41 +
 tests/CA/test-agent.sh.inc        |  165 +++++
 tests/CA/test-alg.sh.inc          |  140 ++++
 tests/CA/test-algfmt.sh.inc       |  156 ++++
 tests/CA/test-blob_auth.sh.inc    |   84 ++
 tests/CA/test-by_ldap.sh.inc      |  299 +++++++++
 tests/CA/test-crl.sh.inc          |  266 ++++++++
 tests/CA/test-dn_auth_file.sh.inc |  119 +++
 tests/CA/test-dn_auth_path.sh.inc |  130 ++++
 tests/CA/test-ocsp.sh.inc         |  256 ++++++++
 tests/CA/test-self.sh.inc         |  183 +++++
 tests/CA/verify.sh                |   44 +
 umac.c                            |    4 
 x509_by_ldap.c                    |  874 +++++++++++++++++++++++++++
 x509_by_ldap.h                    |   98 +++
 x509_nm_cmp.c                     |  524 ++++++++++++++++
 x509store.c                       | 1034 ++++++++++++++++++++++++++++++++
 x509store.h                       |  123 +++
 132 files changed, 18689 insertions(+), 1822 deletions(-)
$ 


//Peter

From djm at mindrot.org  Tue May 29 14:55:43 2012
From: djm at mindrot.org (Damien Miller)
Date: Tue, 29 May 2012 14:55:43 +1000 (EST)
Subject: Announce: X.509 certificates support v7.2 for OpenSSH version
 6.0p1
In-Reply-To: <20120528075747.6818.qmail@stuge.se>
References: <4FBFDC6E.7060006@roumenpetrov.info>
 <A4ABB1C0A2EA784DA4EA6EDF7762E2DD224F0D71@ESESSCMS0360.eemea.ericsson.se>
 <20120528075747.6818.qmail@stuge.se>
Message-ID: <alpine.BSO.2.00.1205291454410.17584@natsu.mindrot.org>

On Mon, 28 May 2012, Peter Stuge wrote:

> John Olsson M wrote:
> > What is blocking this from being merged into OpenSSH?
> 
> Quite likely the diffstat:

No, we just don't trust X.509 (or ASN.1 at all) in the pre-authentication
attack surface. This is no reflection on Roumen's code, but on the
syntactic and semantic complexity of the standards themselves and their
vulnerability history.

-d

From seggelmann at fh-muenster.de  Thu May 31 00:43:44 2012
From: seggelmann at fh-muenster.de (Robin Seggelmann)
Date: Wed, 30 May 2012 16:43:44 +0200
Subject: SCTP support for OpenSSH
Message-ID: <682DA531-F64A-447C-A6E4-B2FB850D447B@fh-muenster.de>

Hi,

I have written a patch to add SCTP support for OpenSSH on systems with SCTP capabilities with the following features:

- SCTP support can be configured with --with-sctp, but is disabled by default
- use SCTP for SSH connections instead of TCP
- SCTP's multi-homing is activated for all available addresses by default, if SCTP is used
- the sshd can be configured to listen with TCP, SCTP, or both with the "Transport" keyword for sshd_config
- the sshd listens on single addresses given with each "ListenAddress" and on multiple addresses multi-homed given with each "ListenMultipleAddresses" (with SCTP)
- the ssh client can use SCTP to connected to a server with the -z cmd parameter or the "Transport" keyword for ssh_config
- updated man pages
- the patch is prepared to add multi-streaming support for SSH channels later

I would like to submit the patch if you're interested in SCTP support. Should the patch be created for the latest stable release or the current CVS version? Do you prefer the mailing list or the bug tracker for a submission?

Best regards
Robin






From saku at ytti.fi  Thu May 31 01:41:47 2012
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 30 May 2012 18:41:47 +0300
Subject: SCTP support for OpenSSH
In-Reply-To: <682DA531-F64A-447C-A6E4-B2FB850D447B@fh-muenster.de>
References: <682DA531-F64A-447C-A6E4-B2FB850D447B@fh-muenster.de>
Message-ID: <CAAeewD86sFqSrqSMpBnvQKvA71TT-5XC2Cj4xouCTwnvhwmLnQ@mail.gmail.com>

On 30 May 2012 17:43, Robin Seggelmann <seggelmann at fh-muenster.de> wrote:

> I have written a patch to add SCTP support for OpenSSH on systems with SCTP capabilities with the following features:

Cool. Forgive me if this is silly question. Does client dynamically
runtime add/remove SCTP sessions when end points come available and
unavailable? How about when DNS information changes runtime?

-- 
? ++ytti

From seggelmann at fh-muenster.de  Thu May 31 07:26:04 2012
From: seggelmann at fh-muenster.de (Robin Seggelmann)
Date: Wed, 30 May 2012 23:26:04 +0200
Subject: SCTP support for OpenSSH
In-Reply-To: <CAAeewD86sFqSrqSMpBnvQKvA71TT-5XC2Cj4xouCTwnvhwmLnQ@mail.gmail.com>
References: <682DA531-F64A-447C-A6E4-B2FB850D447B@fh-muenster.de>
 <CAAeewD86sFqSrqSMpBnvQKvA71TT-5XC2Cj4xouCTwnvhwmLnQ@mail.gmail.com>
Message-ID: <818AC52D-F559-425C-BDA6-28F2EB4736A1@fh-muenster.de>

On 30.05.2012, at 17:41, Saku Ytti wrote:

> On 30 May 2012 17:43, Robin Seggelmann <seggelmann at fh-muenster.de> wrote:
> 
>> I have written a patch to add SCTP support for OpenSSH on systems with SCTP capabilities with the following features:
> 
> Cool. Forgive me if this is silly question. Does client dynamically
> runtime add/remove SCTP sessions when end points come available and
> unavailable? How about when DNS information changes runtime?

I'm not sure what you meant to ask. The client uses all available IP addresses to connect to a server. After the connection establishment, all addresses are tested with a HEARTBEAT message to determine with which of them the other endpoint is reachable. If addresses are not available anymore during the connection lifetime, for example because the network interface went down, they are marked as inactive and aren't used for this connection until they are available again. In the meantime another address is used as a fallback. If new addresses are available, they won't be used. This is only possible by monitoring the interfaces and using the ADD-IP extension to add the additional address "manually".

Regarding DNS, if you're using a hostname to connect to a server, it will be resolved and the connection will be established. If the DNS information changes during the connection lifetime, this has no effect, because the connection is already up and running and so no additional DNS lookup will be done. To have changing DNS information affecting the SCTP connection, you have to look the hostname up periodically and use the ADD-IP extension to add new addresses and remove old ones.

While these things are basically possible, they are quite complex and partially system dependent. So if these are often requested features, I could add this functionality later on, but I currently don't consider them as high priority. The first step right now is to have SCTP support at all, i.e. the first patch with the basic support has to be applied to the official source.

Best regards
Robin



> -- 
>   ++ytti
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From saku at ytti.fi  Thu May 31 16:37:33 2012
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 31 May 2012 09:37:33 +0300
Subject: SCTP support for OpenSSH
In-Reply-To: <818AC52D-F559-425C-BDA6-28F2EB4736A1@fh-muenster.de>
References: <682DA531-F64A-447C-A6E4-B2FB850D447B@fh-muenster.de>
 <CAAeewD86sFqSrqSMpBnvQKvA71TT-5XC2Cj4xouCTwnvhwmLnQ@mail.gmail.com>
 <818AC52D-F559-425C-BDA6-28F2EB4736A1@fh-muenster.de>
Message-ID: <CAAeewD8_MLg3W20PrPYyC-+c-L_SqxbT0VEKhceDF0mZEG6wnw@mail.gmail.com>

On 31 May 2012 00:26, Robin Seggelmann <seggelmann at fh-muenster.de> wrote:

Hi Robin,

> If new addresses are available, they won't be used. This is only possible by monitoring the interfaces and using the ADD-IP extension to add the additional address "manually".

I think this would be exceptionally important to sell this feature.
This would allow you to traverse home<->office with WLAN->3G->WLAN
without getting disconnected.

Only thing that wouldn't work, is if client's last IP disappears, even
if new IP appears the second after. But that is SCTP short-coming.

> Regarding DNS, if you're using a hostname to connect to a server, it will be resolved and the connection will be established. If the DNS information changes during the connection lifetime, this has no effect, because the connection is already up and running and so no additional DNS lookup will be done. To have changing DNS information affecting the SCTP connection, you have to look the hostname up periodically and use the ADD-IP extension to add new addresses and remove old ones.

I think periodic DNS lookup would be interesting, you could do major
designs, without disrupting services. It doesn't have to be done
often, as it is always planned change.

> While these things are basically possible, they are quite complex and partially system dependent. So if these are often requested features, I could add this functionality later on, but I currently don't consider them as high priority. The first step right now is to have SCTP support at all, i.e. the first patch with the basic support has to be applied to the official source.

Fully agreed, release little, release often. But seeing how other
projects are lagging with SCTP, I think practical scenarios what the
new feature will give would help selling it. And without ADD-IP the
benefits are somewhat limited. The DNS definitely is just bonus.
But I understand that platform dependency (how will you learn about
new IP) is non-trivial problem.


-- 
? ++ytti

From djm at mindrot.org  Thu May 31 18:55:33 2012
From: djm at mindrot.org (Damien Miller)
Date: Thu, 31 May 2012 18:55:33 +1000 (EST)
Subject: SCTP support for OpenSSH
In-Reply-To: <682DA531-F64A-447C-A6E4-B2FB850D447B@fh-muenster.de>
References: <682DA531-F64A-447C-A6E4-B2FB850D447B@fh-muenster.de>
Message-ID: <alpine.BSO.2.00.1205311854320.12231@natsu.mindrot.org>



On Wed, 30 May 2012, Robin Seggelmann wrote:

> Hi,
> 
> I have written a patch to add SCTP support for OpenSSH on systems with SCTP capabilities with the following features:
> 
> - SCTP support can be configured with --with-sctp, but is disabled by default
> - use SCTP for SSH connections instead of TCP
> - SCTP's multi-homing is activated for all available addresses by default, if SCTP is used
> - the sshd can be configured to listen with TCP, SCTP, or both with the "Transport" keyword for sshd_config
> - the sshd listens on single addresses given with each "ListenAddress" and on multiple addresses multi-homed given with each "ListenMultipleAddresses" (with SCTP)
> - the ssh client can use SCTP to connected to a server with the -z cmd parameter or the "Transport" keyword for ssh_config
> - updated man pages
> - the patch is prepared to add multi-streaming support for SSH channels later
>
> I would like to submit the patch if you're interested in SCTP support.
> Should the patch be created for the latest stable release or the
> current CVS version? Do you prefer the mailing list or the bug tracker
> for a submission?

Cool - we strongly prefer https://bugzilla.mindrot.org/ for patch submissions.
If you upload it there then we will not lose it.

-d

From mattieu.b at gmail.com  Thu May 31 19:56:02 2012
From: mattieu.b at gmail.com (Mattieu Baptiste)
Date: Thu, 31 May 2012 11:56:02 +0200
Subject: ControlMaster, scp and current working directory
Message-ID: <CAHAkNs=S25_HppEeQBPZZcwsyPgvPGo=bfW+NEq+t3mcfrR7BQ@mail.gmail.com>

Hi,

It seems there is a problem regarding ControlMaster and scp'ing a file
depending on the current working directory:

$ cd ~/Personnel
$ scp -o ControlMaster=yes cox.jpg host.local:
muxserver_listen bind(): No such file or directory
lost connection
$ scp -o ControlMaster=no cox.jpg host.local:
cox.jpg                                          100%  222KB 222.1KB/s   00:00
$ cd
$ scp -o ControlMaster=yes Personnel/cox.jpg host.local:
cox.jpg                                          100%  222KB 222.1KB/s   00:00
$ scp -o ControlMaster=no Personnel/cox.jpg host.local:
cox.jpg                                          100%  222KB 222.1KB/s   00:00

This is on OpenBSD -current/amd64.


Regards,
-- 
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."

From bert.wesarg at googlemail.com  Thu May 31 20:22:35 2012
From: bert.wesarg at googlemail.com (Bert Wesarg)
Date: Thu, 31 May 2012 12:22:35 +0200
Subject: ControlMaster, scp and current working directory
In-Reply-To: <CAHAkNs=S25_HppEeQBPZZcwsyPgvPGo=bfW+NEq+t3mcfrR7BQ@mail.gmail.com>
References: <CAHAkNs=S25_HppEeQBPZZcwsyPgvPGo=bfW+NEq+t3mcfrR7BQ@mail.gmail.com>
Message-ID: <CAKPyHN2aSR-TQSX=D4Q418zTV0+Pp=qOTS7=0k067aO0_Z8NiQ@mail.gmail.com>

On Thu, May 31, 2012 at 11:56 AM, Mattieu Baptiste <mattieu.b at gmail.com> wrote:
> Hi,
>
> It seems there is a problem regarding ControlMaster and scp'ing a file
> depending on the current working directory:
>
> $ cd ~/Personnel
> $ scp -o ControlMaster=yes cox.jpg host.local:
> muxserver_listen bind(): No such file or directory
> lost connection
> $ scp -o ControlMaster=no cox.jpg host.local:
> cox.jpg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?100% ?222KB 222.1KB/s ? 00:00
> $ cd
> $ scp -o ControlMaster=yes Personnel/cox.jpg host.local:
> cox.jpg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?100% ?222KB 222.1KB/s ? 00:00
> $ scp -o ControlMaster=no Personnel/cox.jpg host.local:
> cox.jpg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?100% ?222KB 222.1KB/s ? 00:00
>

What is the value of your ControlPath? By default it is not set, and
therefore multiplexing is disabled.

Thanks.

Bert

> This is on OpenBSD -current/amd64.
>
>
> Regards,
> --
> Mattieu Baptiste

From mattieu.b at gmail.com  Thu May 31 23:35:05 2012
From: mattieu.b at gmail.com (Mattieu Baptiste)
Date: Thu, 31 May 2012 15:35:05 +0200
Subject: ControlMaster, scp and current working directory
In-Reply-To: <CAKPyHN2aSR-TQSX=D4Q418zTV0+Pp=qOTS7=0k067aO0_Z8NiQ@mail.gmail.com>
References: <CAHAkNs=S25_HppEeQBPZZcwsyPgvPGo=bfW+NEq+t3mcfrR7BQ@mail.gmail.com>
 <CAKPyHN2aSR-TQSX=D4Q418zTV0+Pp=qOTS7=0k067aO0_Z8NiQ@mail.gmail.com>
Message-ID: <CAHAkNsmo4autAoGzHA9wGGkofwanFzq8oSW+phbqD+0QPS3Kxw@mail.gmail.com>

On Thu, May 31, 2012 at 12:22 PM, Bert Wesarg
<bert.wesarg at googlemail.com> wrote:
> On Thu, May 31, 2012 at 11:56 AM, Mattieu Baptiste <mattieu.b at gmail.com> wrote:
>> Hi,
>>
>> It seems there is a problem regarding ControlMaster and scp'ing a file
>> depending on the current working directory:
>>
>> $ cd ~/Personnel
>> $ scp -o ControlMaster=yes cox.jpg host.local:
>> muxserver_listen bind(): No such file or directory
>> lost connection
>> $ scp -o ControlMaster=no cox.jpg host.local:
>> cox.jpg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?100% ?222KB 222.1KB/s ? 00:00
>> $ cd
>> $ scp -o ControlMaster=yes Personnel/cox.jpg host.local:
>> cox.jpg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?100% ?222KB 222.1KB/s ? 00:00
>> $ scp -o ControlMaster=no Personnel/cox.jpg host.local:
>> cox.jpg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?100% ?222KB 222.1KB/s ? 00:00
>>
>
> What is the value of your ControlPath? By default it is not set, and
> therefore multiplexing is disabled.

Thanks, that was my mistake. ControlPath was set to
".ssh/sockets/%r@%h:%p" which was only valid in my home directory.

-- 
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."