From sega01 at go-beyond.org Fri Feb 1 06:12:11 2013 From: sega01 at go-beyond.org (Teran McKinney) Date: Thu, 31 Jan 2013 19:12:11 +0000 Subject: OpenSSH NoPty patch Message-ID: <20130131191211.GA21468@blackmesa> Hey everyone, I wanted to add support for denying PTY allocation through OpenSSH. I'm not certain if this is quite thorough enough for all cases, but for me it might work for the moment. I know that you can currently do this through authorized_keys, but as far as I know that only works for an actual key. In my use case, I wanted a user with no password which is forced to run a specific command, and without a PTY. I didn't see any other good options for this, so I wrote my own based off of the X11Forwarding directive. This patch seems complete, but the man page stuff is not. I wrote in the sshd_config.0 for an example of how I think it could look, but I'm not very familiar with the syntax in sshd_config.5, so didn't do much there. I imagine the things I wrote in sshd_config.0 would be overwritten most of the time, anyways. I tested it as a server-wide directive and inside a Match clause. It works in both cases. Please let me know if you'd like me to clean up this patch further, if you can take it from here, or if why it's not a useful feature in the main distribution of OpenSSH. I'm happy to use it on my own either way, just thought I'd send it your way in case it's something you guys can use. Thanks, Teran PS: I hereby release my changes in the patch into the public domain, so you can do whatever you want with it. PPS: Please include me in all replies directly as I'm not on the list. -------------- next part -------------- diff -rupN openssh-6.1p1/servconf.c openssh-6.1p1-new/servconf.c --- openssh-6.1p1/servconf.c 2012-07-31 02:22:38.000000000 +0000 +++ openssh-6.1p1-new/servconf.c 2013-01-31 17:12:36.000000000 +0000 @@ -85,6 +85,7 @@ initialize_server_options(ServerOptions options->x11_forwarding = -1; options->x11_display_offset = -1; options->x11_use_localhost = -1; + options->no_pty = -1; options->xauth_location = NULL; options->strict_modes = -1; options->tcp_keep_alive = -1; @@ -201,6 +202,8 @@ fill_default_server_options(ServerOption options->x11_use_localhost = 1; if (options->xauth_location == NULL) options->xauth_location = _PATH_XAUTH; + if (options->no_pty == -1) + options->no_pty = 0; if (options->strict_modes == -1) options->strict_modes = 1; if (options->tcp_keep_alive == -1) @@ -314,7 +317,7 @@ typedef enum { sListenAddress, sAddressFamily, sPrintMotd, sPrintLastLog, sIgnoreRhosts, sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost, - sStrictModes, sEmptyPasswd, sTCPKeepAlive, + sNoPty, sStrictModes, sEmptyPasswd, sTCPKeepAlive, sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression, sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, @@ -411,6 +414,7 @@ static struct { { "x11displayoffset", sX11DisplayOffset, SSHCFG_ALL }, { "x11uselocalhost", sX11UseLocalhost, SSHCFG_ALL }, { "xauthlocation", sXAuthLocation, SSHCFG_GLOBAL }, + { "nopty", sNoPty, SSHCFG_ALL }, { "strictmodes", sStrictModes, SSHCFG_GLOBAL }, { "permitemptypasswords", sEmptyPasswd, SSHCFG_ALL }, { "permituserenvironment", sPermitUserEnvironment, SSHCFG_GLOBAL }, @@ -1075,6 +1079,10 @@ process_server_config_line(ServerOptions charptr = &options->xauth_location; goto parse_filename; + case sNoPty: + intptr = &options->no_pty; + goto parse_flag; + case sStrictModes: intptr = &options->strict_modes; goto parse_flag; @@ -1657,6 +1665,7 @@ copy_set_server_options(ServerOptions *d M_CP_INTOPT(x11_display_offset); M_CP_INTOPT(x11_forwarding); M_CP_INTOPT(x11_use_localhost); + M_CP_INTOPT(no_pty); M_CP_INTOPT(max_sessions); M_CP_INTOPT(max_authtries); M_CP_INTOPT(ip_qos_interactive); @@ -1883,6 +1892,7 @@ dump_config(ServerOptions *o) dump_cfg_fmtint(sPrintLastLog, o->print_lastlog); dump_cfg_fmtint(sX11Forwarding, o->x11_forwarding); dump_cfg_fmtint(sX11UseLocalhost, o->x11_use_localhost); + dump_cfg_fmtint(sNoPty, o->no_pty); dump_cfg_fmtint(sStrictModes, o->strict_modes); dump_cfg_fmtint(sTCPKeepAlive, o->tcp_keep_alive); dump_cfg_fmtint(sEmptyPasswd, o->permit_empty_passwd); diff -rupN openssh-6.1p1/servconf.h openssh-6.1p1-new/servconf.h --- openssh-6.1p1/servconf.h 2012-07-31 02:21:34.000000000 +0000 +++ openssh-6.1p1-new/servconf.h 2013-01-31 17:36:33.000000000 +0000 @@ -74,6 +74,7 @@ typedef struct { * searching at */ int x11_use_localhost; /* If true, use localhost for fake X11 server. */ char *xauth_location; /* Location of xauth program */ + int no_pty; /* If true, do not create ptys */ int strict_modes; /* If true, require string home dir modes. */ int tcp_keep_alive; /* If true, set SO_KEEPALIVE. */ int ip_qos_interactive; /* IP ToS/DSCP/class for interactive */ diff -rupN openssh-6.1p1/session.c openssh-6.1p1-new/session.c --- openssh-6.1p1/session.c 2012-04-22 01:08:10.000000000 +0000 +++ openssh-6.1p1-new/session.c 2013-01-31 17:07:50.000000000 +0000 @@ -2018,7 +2018,7 @@ session_pty_req(Session *s) u_int len; int n_bytes; - if (no_pty_flag) { + if (no_pty_flag || options.no_pty) { debug("Allocating a pty not permitted for this authentication."); return 0; } diff -rupN openssh-6.1p1/sshd_config openssh-6.1p1-new/sshd_config --- openssh-6.1p1/sshd_config 2012-07-31 02:21:34.000000000 +0000 +++ openssh-6.1p1-new/sshd_config 2013-01-31 17:15:15.000000000 +0000 @@ -95,6 +95,7 @@ AuthorizedKeysFile .ssh/authorized_keys #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes +#NoPty no #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes @@ -121,4 +122,5 @@ Subsystem sftp /usr/libexec/sftp-server #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no +# NoPty yes # ForceCommand cvs server diff -rupN openssh-6.1p1/sshd_config.0 openssh-6.1p1-new/sshd_config.0 --- openssh-6.1p1/sshd_config.0 2012-08-29 00:53:04.000000000 +0000 +++ openssh-6.1p1-new/sshd_config.0 2013-01-31 17:21:29.000000000 +0000 @@ -410,7 +410,7 @@ DESCRIPTION PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTunnel, PubkeyAuthentication, RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, - X11Forwarding and X11UseLocalHost. + X11Forwarding, X11UseLocalHost, and NoPty. MaxAuthTries Specifies the maximum number of authentication attempts permitted @@ -683,6 +683,10 @@ DESCRIPTION Specifies the full pathname of the xauth(1) program. The default is /usr/X11R6/bin/xauth. + NoPty + Specifies whether creation of PTYs is denied. The argument must be + ``yes'' or ``no''. The default is ``yes''. + TIME FORMATS sshd(8) command-line arguments and configuration file options that specify time may be expressed using a sequence of the form: diff -rupN openssh-6.1p1/sshd_config.5 openssh-6.1p1-new/sshd_config.5 --- openssh-6.1p1/sshd_config.5 2012-07-02 08:53:38.000000000 +0000 +++ openssh-6.1p1-new/sshd_config.5 2013-01-31 17:19:02.000000000 +0000 @@ -735,9 +735,10 @@ Available keywords are .Cm RhostsRSAAuthentication , .Cm RSAAuthentication , .Cm X11DisplayOffset , -.Cm X11Forwarding +.Cm X11Forwarding , +.Cm X11UseLocalHost , and -.Cm X11UseLocalHost . +.Cm NoPty . .It Cm MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From keisial at gmail.com Sat Feb 2 07:46:30 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 01 Feb 2013 21:46:30 +0100 Subject: OpenSSH NoPty patch In-Reply-To: <20130131191211.GA21468@blackmesa> References: <20130131191211.GA21468@blackmesa> Message-ID: <510C29A6.5020408@gmail.com> On 31/01/13 20:12, Teran McKinney wrote: > Please let me know if you'd like me to clean up this patch further, if > you can take it from here, or if why it's not a useful feature in the > main distribution of OpenSSH. I'm happy to use it on my own either way, > just thought I'd send it your way in case it's something you guys can > use. I would call the directive AllowPty. In fact, from your man page: ?Specifies whether creation of PTYs is denied. The argument must be ``yes'' or ``no''. The default is ``yes''.? seems that the default is to _deny_ creation of PTYs, whereas in the code it seems that the default is to _allow_ the ptys (which is the appropiate behavior). A name like AllowPty avoids the double-negation problems, and is also more consistent with other option names. From imorgan at nas.nasa.gov Sat Feb 2 08:46:44 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 1 Feb 2013 13:46:44 -0800 Subject: OpenSSH NoPty patch In-Reply-To: <20130131191211.GA21468@blackmesa> References: <20130131191211.GA21468@blackmesa> Message-ID: <20130201214644.GE3584@linux124.nas.nasa.gov> On Thu, Jan 31, 2013 at 13:12:11 -0600, Teran McKinney wrote: > Hey everyone, > > I wanted to add support for denying PTY allocation through OpenSSH. I'm > not certain if this is quite thorough enough for all cases, but for me > it might work for the moment. > > I know that you can currently do this through authorized_keys, but as > far as I know that only works for an actual key. In my use case, I > wanted a user with no password which is forced to run a specific > command, and without a PTY. I didn't see any other good options for > this, so I wrote my own based off of the X11Forwarding directive. > Without commenting on the details of the code, I would like to suggest using a different keyword than "NoPty." Although NoPty is consistent with the no-pty authorized_keys keyword, it goes against the grain of other sshd_config options. Also, the double-negative of "NoPty yes" is somewhat annoying. Instead, you might want to consider "PermitTTY" which would be consistent with existing sshd_config options (PermitOpen, PermitUserEnv, etc.) and would also be consistent with the ssh_config RequestTTY option. -- Iain Morgan From luto at amacapital.net Sat Feb 2 12:43:41 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Fri, 1 Feb 2013 17:43:41 -0800 Subject: Relaxing strict chroot checks on recent Linux kernels? Message-ID: At the risk of beating a dead horse, I'd like to see the chroot security checks relaxed a bit. On newer Linux kernels, there's a prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) that prevents privilege elevation (via setuid binaries, etc) for the caller and all of its descendants. That means that chroot(untrusted directory), prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0), setreuid(uid, uid), execve(a shell) is safe [1], even if the user can hardlink setuid programs into the target directory. Yes, this would be Linux-specific functionality (and hence somewhat odd for sshd), but it would be very useful. Here's why I want this: I have a server that has a bunch of data files on it. I want to create an account, used for sftp only, to allow other servers to download certain files off of a particular directory on this server. That directory *can't* be writable only by root; other users populate it. For the time being, I've hacked around it using ACLs -- there's a longstanding bug^Wfeature in openssh that causes it to ignore acls when "validating" permissions. But please consider allowing ForceCommand internal-sftp in conjunction with ChrootDirectory to safely skip permission checks on Linux kernels that are new enough to use PR_SET_NO_NEW_PRIVS. [1] Unless sshd itself is chrooted, in which case this might be usable to break out of that chroot. But the strict permission checks don't help prevent that at all, so this isn't new. Thanks, Andy P.S. openssh on Linux should probably set no_new_privs whenever running its internal sftp server, regardless of whether it's chrooting. From openssh at roumenpetrov.info Sun Feb 3 03:04:05 2013 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 02 Feb 2013 18:04:05 +0200 Subject: [PATCH] Android port In-Reply-To: <87vcag7p0m.fsf@gmail.com> References: <87vcag7p0m.fsf@gmail.com> Message-ID: <510D38F5.9050308@roumenpetrov.info> Dmitry Kurochkin wrote: > Hi all. > > I am experimenting with building OpenSSH server for Android. The > attached patch makes OpenSSH successfully build (at least) using Android > NDK with libldns. The patch is mostly trivial. The biggest change > perhaps is disabling password authentication code. and to keep android property workspace open. > I would like to receive feedback and hopefully get it accepted into the > mainline eventually. Please could you review https://bugzilla.mindrot.org/show_bug.cgi?id=2012 . I would like to improve Android support published with X.509 certificates support v7.2. > Regards, > Dmitry Regards, Roumen --- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From keisial at gmail.com Sun Feb 3 08:26:51 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sat, 02 Feb 2013 22:26:51 +0100 Subject: Relaxing strict chroot checks on recent Linux kernels? In-Reply-To: References: Message-ID: <510D849B.7040502@gmail.com> On 02/02/13 02:43, Andy Lutomirski wrote: > At the risk of beating a dead horse, I'd like to see the chroot > security checks relaxed a bit. On newer Linux kernels, there's a > prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) that prevents privilege > elevation (via setuid binaries, etc) for the caller and all of its > descendants. That means that chroot(untrusted directory), > prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0), setreuid(uid, uid), execve(a > shell) is safe [1], even if the user can hardlink setuid programs into > the target directory. I'm a bit concerned about a scenario where you have shell access both unchrooted and unsafe chroot + PR_SET_NO_NEW_PRIVS, and then you get into the chroot with setns(2). Although setns seems to require CAP_SYS_ADMIN, so it the vulnerability might be in such case in the application doing that. > Yes, this would be Linux-specific functionality (and hence somewhat > odd for sshd), but it would be very useful. I guess it could be added as a new flag, only honored on Linux for now (just as the sandboxing used is system-dependant). > Here's why I want this: I have a server that has a bunch of data files > on it. I want to create an account, used for sftp only, to allow > other servers to download certain files off of a particular directory > on this server. That directory *can't* be writable only by root; > other users populate it. I suspect there's another condition there, although not explicit in your mail: the sftp account shall not be able to write that directory. > For the time being, I've hacked around it using ACLs -- there's a > longstanding bug^Wfeature in openssh that causes it to ignore acls > when "validating" permissions. But please consider allowing > ForceCommand internal-sftp in conjunction with ChrootDirectory to > safely skip permission checks on Linux kernels that are new enough to > use PR_SET_NO_NEW_PRIVS. It is tempting to add an option to chroot to unsafe directories when using internal-sftp. After all, you are not executing programs placed there... However, even when using internal-sftp there's the problem of placing a malicious library which is then dynamically loaded by the internal-sftp process (eg. to perform an uid lookup). Not applicable to the read-only process, but if there was such option of untrusted-chroot for the sftp-only, it would be applied to rw-sftp account. Which per the above, even with PR_SET_NO_NEW_PRIVS, could be escalated from sftp-only to a remote shell. :( From djm at mindrot.org Mon Feb 4 08:55:53 2013 From: djm at mindrot.org (Damien Miller) Date: Mon, 4 Feb 2013 08:55:53 +1100 (EST) Subject: Relaxing strict chroot checks on recent Linux kernels? In-Reply-To: References: Message-ID: On Fri, 1 Feb 2013, Andy Lutomirski wrote: > Here's why I want this: I have a server that has a bunch of data files > on it. I want to create an account, used for sftp only, to allow > other servers to download certain files off of a particular directory > on this server. That directory *can't* be writable only by root; > other users populate it. You will be able to do this with sftp-server in CVS current. It support a flag to override the user's home directory, so you can do something like: Subsystem sftp internal-sftp -l verbose -d /files ChrootDirectory /chroot/%u The sftp session will start in /files (or /chroot/$USER/files objectively). IIRC the no-new-privs thing was only safe if you were also using seccomp, but I need to check. It seems like a reasonable thing to enable for sftp-server unconditionally. I probably wouldn't want to rely on it though, as there are probably bad things that can be done even without raising privs in the process that launches the attack. E.g. rewrite /etc/ld.so.preload. Remember that ChrootDirectory isn't just for sftp. -d From luto at amacapital.net Mon Feb 4 23:45:02 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Mon, 4 Feb 2013 04:45:02 -0800 Subject: Relaxing strict chroot checks on recent Linux kernels? In-Reply-To: References: Message-ID: On Sun, Feb 3, 2013 at 1:55 PM, Damien Miller wrote: > On Fri, 1 Feb 2013, Andy Lutomirski wrote: > >> Here's why I want this: I have a server that has a bunch of data files >> on it. I want to create an account, used for sftp only, to allow >> other servers to download certain files off of a particular directory >> on this server. That directory *can't* be writable only by root; >> other users populate it. > > You will be able to do this with sftp-server in CVS current. It > support a flag to override the user's home directory, so you can > do something like: > > Subsystem sftp internal-sftp -l verbose -d /files > ChrootDirectory /chroot/%u > > The sftp session will start in /files (or /chroot/$USER/files objectively). This dosn't really work -- I want to change the chroot target, not the home directory. Unless you mean that internal-sftp will pretend that /files is the root, blocking '..' and '/' as ways to escape. > > IIRC the no-new-privs thing was only safe if you were also using > seccomp, but I need to check. It seems like a reasonable thing to enable > for sftp-server unconditionally. If it's not sufficient for chroot, then it's IMO buggy. (I wrote it.) > I probably wouldn't want to rely on it > though, as there are probably bad things that can be done even without > raising privs in the process that launches the attack. E.g. rewrite > /etc/ld.so.preload. Remember that ChrootDirectory isn't just for sftp. > Sure it is -- I'm using ForceCommand internal-sftp. I agree that if there's any way to get a non-no_new_privs program in a writable chroot then there's a privilege escalation, but I only want sftp. --Andy From djm at mindrot.org Tue Feb 5 08:23:20 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 5 Feb 2013 08:23:20 +1100 (EST) Subject: Relaxing strict chroot checks on recent Linux kernels? In-Reply-To: References: Message-ID: On Mon, 4 Feb 2013, Andy Lutomirski wrote: > > I probably wouldn't want to rely on it > > though, as there are probably bad things that can be done even without > > raising privs in the process that launches the attack. E.g. rewrite > > /etc/ld.so.preload. Remember that ChrootDirectory isn't just for sftp. > > Sure it is -- I'm using ForceCommand internal-sftp. I agree that if > there's any way to get a non-no_new_privs program in a writable chroot > then there's a privilege escalation, but I only want sftp. You might only want sftp, but like I said: ChrootDirectory is more general and has to support other uses. -d From luto at amacapital.net Tue Feb 5 08:45:27 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Mon, 4 Feb 2013 13:45:27 -0800 Subject: Relaxing strict chroot checks on recent Linux kernels? In-Reply-To: References: Message-ID: On Mon, Feb 4, 2013 at 1:23 PM, Damien Miller wrote: > On Mon, 4 Feb 2013, Andy Lutomirski wrote: > >> > I probably wouldn't want to rely on it >> > though, as there are probably bad things that can be done even without >> > raising privs in the process that launches the attack. E.g. rewrite >> > /etc/ld.so.preload. Remember that ChrootDirectory isn't just for sftp. >> >> Sure it is -- I'm using ForceCommand internal-sftp. I agree that if >> there's any way to get a non-no_new_privs program in a writable chroot >> then there's a privilege escalation, but I only want sftp. > > You might only want sftp, but like I said: ChrootDirectory is more general > and has to support other uses. Do the permission checks have to the be same in the ForceCommand internal-sftp case, as compared to the general ChrootDirectory case? --Andy From luto at amacapital.net Tue Feb 5 08:49:39 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Mon, 4 Feb 2013 13:49:39 -0800 Subject: Relaxing strict chroot checks on recent Linux kernels? In-Reply-To: <510D849B.7040502@gmail.com> References: <510D849B.7040502@gmail.com> Message-ID: On Sat, Feb 2, 2013 at 1:26 PM, ?ngel Gonz?lez wrote: > On 02/02/13 02:43, Andy Lutomirski wrote: >> At the risk of beating a dead horse, I'd like to see the chroot >> security checks relaxed a bit. On newer Linux kernels, there's a >> prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) that prevents privilege >> elevation (via setuid binaries, etc) for the caller and all of its >> descendants. That means that chroot(untrusted directory), >> prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0), setreuid(uid, uid), execve(a >> shell) is safe [1], even if the user can hardlink setuid programs into >> the target directory. > I'm a bit concerned about a scenario where you have shell access both > unchrooted and unsafe chroot + PR_SET_NO_NEW_PRIVS, and then you > get into the chroot with setns(2). Although setns seems to require > CAP_SYS_ADMIN, so it the vulnerability might be in such case in the > application doing that. I don't think you can setns into someone else's fs context like that. You could setns into someone else's mount namespace (with appropriate privilege), but that shouldn't come with their choice of root directory. > > >> Yes, this would be Linux-specific functionality (and hence somewhat >> odd for sshd), but it would be very useful. > I guess it could be added as a new flag, only honored on Linux for now > (just as the sandboxing used is system-dependant). > > >> Here's why I want this: I have a server that has a bunch of data files >> on it. I want to create an account, used for sftp only, to allow >> other servers to download certain files off of a particular directory >> on this server. That directory *can't* be writable only by root; >> other users populate it. > I suspect there's another condition there, although not explicit in your > mail: > the sftp account shall not be able to write that directory. > Relying on that seems like it's asking for trouble -- what if the sftp account and the writer account colluded? I'd like to see this done in a way that it doesn't matter what's in the chroot directory. > >> For the time being, I've hacked around it using ACLs -- there's a >> longstanding bug^Wfeature in openssh that causes it to ignore acls >> when "validating" permissions. But please consider allowing >> ForceCommand internal-sftp in conjunction with ChrootDirectory to >> safely skip permission checks on Linux kernels that are new enough to >> use PR_SET_NO_NEW_PRIVS. > > It is tempting to add an option to chroot to unsafe directories when using > internal-sftp. After all, you are not executing programs placed there... > However, even when using internal-sftp there's the problem of placing a > malicious library which is then dynamically loaded by the internal-sftp > process (eg. to perform an uid lookup). Eek -- does that really happen? > > Not applicable to the read-only process, but if there was such option of > untrusted-chroot for the sftp-only, it would be applied to rw-sftp account. > Which per the above, even with PR_SET_NO_NEW_PRIVS, could be > escalated from sftp-only to a remote shell. :( > Not sure I understand this part. --Andy From djm at mindrot.org Tue Feb 5 09:45:48 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 5 Feb 2013 09:45:48 +1100 (EST) Subject: Relaxing strict chroot checks on recent Linux kernels? In-Reply-To: References: Message-ID: On Mon, 4 Feb 2013, Andy Lutomirski wrote: > > You might only want sftp, but like I said: ChrootDirectory is more general > > and has to support other uses. > > Do the permission checks have to the be same in the ForceCommand > internal-sftp case, as compared to the general ChrootDirectory case? That depends how much corner case code we want to carry. To my mind, not a lot, and especially so when it works only for one platform and it has to be surrounded by caveats. -d From keisial at gmail.com Wed Feb 6 00:31:11 2013 From: keisial at gmail.com (=?windows-1252?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 05 Feb 2013 14:31:11 +0100 Subject: Relaxing strict chroot checks on recent Linux kernels? In-Reply-To: References: <510D849B.7040502@gmail.com> Message-ID: <5111099F.30906@gmail.com> On 04/02/13 22:49, Andy Lutomirski wrote: > On Sat, Feb 2, 2013 at 1:26 PM, ?ngel Gonz?lez wrote: >> I'm a bit concerned about a scenario where you have shell access both >> unchrooted and unsafe chroot + PR_SET_NO_NEW_PRIVS, and then you >> get into the chroot with setns(2). Although setns seems to require >> CAP_SYS_ADMIN, so it the vulnerability might be in such case in the >> application doing that. > I don't think you can setns into someone else's fs context like that. > You could setns into someone else's mount namespace (with appropriate > privilege), but that shouldn't come with their choice of root > directory. Oh, good. You're right. I was considering joining the mount namespace as getting the whole view of the fs tree. >>> For the time being, I've hacked around it using ACLs -- there's a >>> longstanding bug^Wfeature in openssh that causes it to ignore acls >>> when "validating" permissions. But please consider allowing >>> ForceCommand internal-sftp in conjunction with ChrootDirectory to >>> safely skip permission checks on Linux kernels that are new enough to >>> use PR_SET_NO_NEW_PRIVS. >> It is tempting to add an option to chroot to unsafe directories when using >> internal-sftp. After all, you are not executing programs placed there... >> However, even when using internal-sftp there's the problem of placing a >> malicious library which is then dynamically loaded by the internal-sftp >> process (eg. to perform an uid lookup). > Eek -- does that really happen? I haven't tested, but I'm quite sure it could happen. Note how glibc uses dynamic name service switch libraries. If /etc/nsswitch.conf contained entries pointing to libraries not-yet-loaded, and you can trigger them to be loaded by the internal-stfp, I suspect it would load them from inside the chroot. >> Not applicable to the read-only process, but if there was such option of >> untrusted-chroot for the sftp-only, it would be applied to rw-sftp account. >> Which per the above, even with PR_SET_NO_NEW_PRIVS, could be >> escalated from sftp-only to a remote shell. :( > Not sure I understand this part. It could be summarised as ?Giving someone a sftp-only account shouldn't allow them to execute code? :) From jfree.e1 at gmail.com Wed Feb 6 09:38:00 2013 From: jfree.e1 at gmail.com (Jim Freeman) Date: Tue, 5 Feb 2013 15:38:00 -0700 Subject: auth.c comment nit : "an the" => "a" Message-ID: --- src/usr.bin/ssh/auth.c 2013/02/05 22:29:53 1.1 +++ src/usr.bin/ssh/auth.c 2013/02/05 22:30:19 @@ -331,7 +331,7 @@ * * XXX Should any specific check be done for sym links ? * - * Takes an the file name, its stat information (preferably from fstat() to + * Takes a file name, its stat information (preferably from fstat() to * avoid races), the uid of the expected owner, their home directory and an * error buffer plus max size as arguments. * From dtucker at zip.com.au Wed Feb 6 11:23:12 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 6 Feb 2013 11:23:12 +1100 Subject: auth.c comment nit : "an the" => "a" In-Reply-To: References: Message-ID: <20130206002312.GA22924@gate.dtucker.net> On Tue, Feb 05, 2013 at 03:38:00PM -0700, Jim Freeman wrote: > + * Takes a file name, its stat information (preferably from fstat() to applied, 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 imorgan at nas.nasa.gov Thu Feb 7 10:18:41 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 6 Feb 2013 15:18:41 -0800 Subject: Miscellaneous compiler warnings Message-ID: <20130206231841.GF3584@linux124.nas.nasa.gov> Hi, On RHEL 6.3 with gcc 4.4.6, a number of compiler warnings are emitted when building recent snapshots: These all seem to be harmless, but annoying. readpassphrase.c:127: warning: ignoring return value of ?write?, declared with attribute warn_unused_result readpassphrase.c:146: warning: ignoring return value of ?write?, declared with attribute warn_unused_result make[1]: Leaving directory `/u/wk/imorgan/src/openssh/warnings/openssh/openbsd-compat' log.c:432: warning: ignoring return value of ?write?, declared with attribute warn_unused_result schnorr.c:494: warning: ignoring return value of ?vasprintf?, declared with attribute warn_unused_result schnorr.c:519: warning: ignoring return value of ?vasprintf?, declared with attribute warn_unused_result krl.c:508: warning: format ?%llu? expects type ?long long unsigned int?, but argument 3 has type ?u_int64_t? krl.c:508: warning: format ?%llu? expects type ?long long unsigned int?, but argument 4 has type ?u_int64_t? krl.c:508: warning: format ?%llu? expects type ?long long unsigned int?, but argument 5 has type ?u_int64_t? krl.c:508: warning: format ?%llu? expects type ?long long unsigned int?, but argument 7 has type ?u_int64_t? krl.c:508: warning: format ?%llu? expects type ?long long unsigned int?, but argument 8 has type ?u_int64_t? krl.c:508: warning: format ?%llu? expects type ?long long unsigned int?, but argument 9 has type ?u_int64_t? krl.c:508: warning: format ?%llu? expects type ?long long unsigned int?, but argument 10 has type ?u_int64_t? krl.c:543: warning: format ?%llu? expects type ?long long unsigned int?, but argument 3 has type ?u_int64_t? krl.c:543: warning: format ?%llu? expects type ?long long unsigned int?, but argument 4 has type ?u_int64_t? krl.c:933: warning: format ?%llu? expects type ?long long unsigned int?, but argument 2 has type ?u_int64_t? sshd.c:1808: warning: ignoring return value of ?chdir?, declared with attribute warn_unused_result serverloop.c:151: warning: ignoring return value of ?write?, declared with attribute warn_unused_result ssh-agent.c:1323: warning: ignoring return value of ?chdir?, declared with attribute warn_unused_result scp.c:1328: warning: ignoring return value of ?write?, declared with attribute warn_unused_result sftp.c:222: warning: ignoring return value of ?write?, declared with attribute warn_unused_result -- Iain Morgan From djm at mindrot.org Wed Feb 13 10:27:52 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Feb 2013 10:27:52 +1100 (EST) Subject: Fwd: Re: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: <20130117225605.GC19962@linux124.nas.nasa.gov> References: <20130117225605.GC19962@linux124.nas.nasa.gov> Message-ID: On Thu, 17 Jan 2013, Iain Morgan wrote: > I applied the diff you supplied, along with the previous diff. The > regression tests got further along, but now fail in integrity.sh: > > run test integrity.sh ... > test integrity: hmac-sha1 @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. I think that the integrity test script might be fuzzing too early in the stream and messing up the host keys rather than channel data. Could you try increasing the "startoffset" in regress/integrity.sh a bit? You probably only need crank it by a couple of hundred bytes. FYI this is also on Darren's tinderbox: http://tinderbox.dtucker.net/cgi-bin/gunzip.cgi?tree=OpenSSH_Portable&full-log=1360685541.11111 I'd like to figure out what is making KEX complete later in the stream though (assuming my hypothesis is correct). -d From imorgan at nas.nasa.gov Thu Feb 14 06:18:14 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 13 Feb 2013 11:18:14 -0800 Subject: Fwd: Re: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: References: <20130117225605.GC19962@linux124.nas.nasa.gov> Message-ID: <20130213191814.GX19962@linux124.nas.nasa.gov> On Tue, Feb 12, 2013 at 17:27:52 -0600, Damien Miller wrote: > On Thu, 17 Jan 2013, Iain Morgan wrote: > > > I applied the diff you supplied, along with the previous diff. The > > regression tests got further along, but now fail in integrity.sh: > > > > run test integrity.sh ... > > test integrity: hmac-sha1 @2300 RSA_public_decrypt failed: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01. key_verify failed for server_host_key. > > I think that the integrity test script might be fuzzing too early in the > stream and messing up the host keys rather than channel data. Could you > try increasing the "startoffset" in regress/integrity.sh a bit? You > probably only need crank it by a couple of hundred bytes. > > FYI this is also on Darren's tinderbox: > > http://tinderbox.dtucker.net/cgi-bin/gunzip.cgi?tree=OpenSSH_Portable&full-log=1360685541.11111 > > I'd like to figure out what is making KEX complete later in the stream though > (assuming my hypothesis is correct). > > -d Hi Damien, I tried the 20130201 snapshot with startoffset set to 2500 and had the same results. I also tried 3000 without any success. The 20130214 snapshot with startoffset set to 2500 likewise fails. With the 0214 snapshot, the same errors are reported, but the overall test succeeds. It then fails for krl.sh. test integrity: hmac-sha2-512-etm at openssh.com @2507 Corrupted MAC on input. Disconnecting: Packet corrupt. test integrity: hmac-sha2-512-etm at openssh.com @2508 Corrupted MAC on input. Disconnecting: Packet corrupt. test integrity: hmac-sha2-512-etm at openssh.com @2509 Corrupted MAC on input. Disconnecting: Packet corrupt. test integrity: 10 errors: mac 10 padding 0 length 0 ok integrity run test krl.sh ... unknown key type ecdsa FATAL: /u/wk/imorgan/src/openssh/integrity/openssh/ssh-keygen CA failed make[1]: *** [t-exec] Error 1 The krl.sh issue does not occur when built against OpenSSL 1.0.1e. -- Iain Morgan From djm at mindrot.org Thu Feb 14 09:29:47 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Feb 2013 09:29:47 +1100 (EST) Subject: Fwd: Re: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: <20130213191814.GX19962@linux124.nas.nasa.gov> References: <20130117225605.GC19962@linux124.nas.nasa.gov> <20130213191814.GX19962@linux124.nas.nasa.gov> Message-ID: On Wed, 13 Feb 2013, Iain Morgan wrote: > With the 0214 snapshot, the same errors are reported, but the overall > test succeeds. It then fails for krl.sh. > > test integrity: hmac-sha2-512-etm at openssh.com @2507 Corrupted MAC on input. Disconnecting: Packet corrupt. > test integrity: hmac-sha2-512-etm at openssh.com @2508 Corrupted MAC on input. Disconnecting: Packet corrupt. > test integrity: hmac-sha2-512-etm at openssh.com @2509 Corrupted MAC on input. Disconnecting: Packet corrupt. > test integrity: 10 errors: mac 10 padding 0 length 0 > ok integrity Those errors are expected - this test fuzzes the stream between ssh and sshd to verify that integrity protection is working correctly. > run test krl.sh ... > unknown key type ecdsa > FATAL: /u/wk/imorgan/src/openssh/integrity/openssh/ssh-keygen CA failed Here's a patch for that: Index: regress/krl.sh =================================================================== RCS file: /var/cvs/openssh/regress/krl.sh,v retrieving revision 1.2 diff -u -p -r1.2 krl.sh --- regress/krl.sh 20 Jan 2013 11:58:52 -0000 1.2 +++ regress/krl.sh 13 Feb 2013 22:28:20 -0000 @@ -3,13 +3,19 @@ tid="key revocation lists" +# If we don't support ecdsa keys then this tell will be much slower. +ECDSA=ecdsa +if test "x$TEST_SSH_ECC" != "xyes"; then + $ECDSA=rsa +fi + # Do most testing with ssh-keygen; it uses the same verification code as sshd. # Old keys will interfere with ssh-keygen. rm -f $OBJ/revoked-* $OBJ/krl-* # Generate a CA key -$SSHKEYGEN -t ecdsa -f $OBJ/revoked-ca -C "" -N "" > /dev/null || +$SSHKEYGEN -t $ECDSA -f $OBJ/revoked-ca -C "" -N "" > /dev/null || fatal "$SSHKEYGEN CA failed" # A specification that revokes some certificates by serial numbers @@ -48,7 +54,7 @@ keygen() { N=$1 f=$OBJ/revoked-`printf "%04d" $N` # Vary the keytype. We use mostly ECDSA since this is fastest by far. - keytype=ecdsa + keytype=$ECDSA case $N in 2 | 10 | 510 | 1001) keytype=rsa;; 4 | 30 | 520 | 1002) keytype=dsa;; From imorgan at nas.nasa.gov Thu Feb 14 10:27:56 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 13 Feb 2013 15:27:56 -0800 Subject: Fwd: Re: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: References: <20130117225605.GC19962@linux124.nas.nasa.gov> <20130213191814.GX19962@linux124.nas.nasa.gov> Message-ID: <20130213232756.GY19962@linux124.nas.nasa.gov> On Wed, Feb 13, 2013 at 16:29:47 -0600, Damien Miller wrote: > On Wed, 13 Feb 2013, Iain Morgan wrote: > > > With the 0214 snapshot, the same errors are reported, but the overall > > test succeeds. It then fails for krl.sh. > > > > test integrity: hmac-sha2-512-etm at openssh.com @2507 Corrupted MAC on input. Disconnecting: Packet corrupt. > > test integrity: hmac-sha2-512-etm at openssh.com @2508 Corrupted MAC on input. Disconnecting: Packet corrupt. > > test integrity: hmac-sha2-512-etm at openssh.com @2509 Corrupted MAC on input. Disconnecting: Packet corrupt. > > test integrity: 10 errors: mac 10 padding 0 length 0 > > ok integrity > > Those errors are expected - this test fuzzes the stream between ssh and > sshd to verify that integrity protection is working correctly. > > > run test krl.sh ... > > unknown key type ecdsa > > FATAL: /u/wk/imorgan/src/openssh/integrity/openssh/ssh-keygen CA failed > > Here's a patch for that: > I had to make a minor tweak to your patch, s/$ECDSA=rsa/ECDSA=rsa/. With that, and using startoffset=2500, all tests pass for the 20130214 snapshot built against the vendor's OpenSSL 1.0.0-fips. -- Iain Morgan From djm at mindrot.org Thu Feb 14 10:32:51 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Feb 2013 10:32:51 +1100 (EST) Subject: Fwd: Re: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: <20130213232756.GY19962@linux124.nas.nasa.gov> References: <20130117225605.GC19962@linux124.nas.nasa.gov> <20130213191814.GX19962@linux124.nas.nasa.gov> <20130213232756.GY19962@linux124.nas.nasa.gov> Message-ID: On Wed, 13 Feb 2013, Iain Morgan wrote: > On Wed, Feb 13, 2013 at 16:29:47 -0600, Damien Miller wrote: > > On Wed, 13 Feb 2013, Iain Morgan wrote: > > > > > With the 0214 snapshot, the same errors are reported, but the overall > > > test succeeds. It then fails for krl.sh. > > > > > > test integrity: hmac-sha2-512-etm at openssh.com @2507 Corrupted MAC on input. Disconnecting: Packet corrupt. > > > test integrity: hmac-sha2-512-etm at openssh.com @2508 Corrupted MAC on input. Disconnecting: Packet corrupt. > > > test integrity: hmac-sha2-512-etm at openssh.com @2509 Corrupted MAC on input. Disconnecting: Packet corrupt. > > > test integrity: 10 errors: mac 10 padding 0 length 0 > > > ok integrity > > > > Those errors are expected - this test fuzzes the stream between ssh and > > sshd to verify that integrity protection is working correctly. > > > > > run test krl.sh ... > > > unknown key type ecdsa > > > FATAL: /u/wk/imorgan/src/openssh/integrity/openssh/ssh-keygen CA failed > > > > Here's a patch for that: > > > > I had to make a minor tweak to your patch, s/$ECDSA=rsa/ECDSA=rsa/. With > that, and using startoffset=2500, all tests pass for the 20130214 > snapshot built against the vendor's OpenSSL 1.0.0-fips. Excellent - thanks and committed ;) From sega01 at go-beyond.org Thu Feb 14 11:40:11 2013 From: sega01 at go-beyond.org (Teran McKinney) Date: Thu, 14 Feb 2013 00:40:11 +0000 Subject: OpenSSH NoPty patch In-Reply-To: <20130201214644.GE3584@linux124.nas.nasa.gov> References: <20130131191211.GA21468@blackmesa> <20130201214644.GE3584@linux124.nas.nasa.gov> Message-ID: <20130214004011.GA2681@blackmesa> Edit: Resending as I don't think this made it to the list. Taking out my PGP signature as I wonder if that is breaking it. Hi Iain and Angel! Thank you for your replies. On 2013-02-01 13-46-44 , Iain Morgan wrote: > Without commenting on the details of the code, I would like to suggest > using a different keyword than "NoPty." Although NoPty is consistent > with the no-pty authorized_keys keyword, it goes against the grain of > other sshd_config options. Also, the double-negative of "NoPty yes" is > somewhat annoying. > > Instead, you might want to consider "PermitTTY" which would be > consistent with existing sshd_config options (PermitOpen, PermitUserEnv, > etc.) and would also be consistent with the ssh_config RequestTTY > option. > > -- > Iain Morgan I've gone with Iain's suggestion of PermitTTY and have refactored the patch. I've also fixed the issues with the man page, and the alphabetical sorting. Only place where alphabetical sort is off is in the default sshd_config file, which I'm not sure if that's a problem or not. I've tested it and it works exactly the same as the last patch, except with a new default and name to the configuration option. I would appreciate it if anyone else can test this new patch or let me know of any next steps for hopefully including it into the mainstream OpenSSH code base. Thanks, Teran -------------- next part -------------- diff -rupN openssh-6.1p1/servconf.c openssh-6.1p1-permittty/servconf.c --- openssh-6.1p1/servconf.c 2012-07-31 02:22:38.000000000 +0000 +++ openssh-6.1p1-permittty/servconf.c 2013-02-12 01:49:18.907753826 +0000 @@ -85,6 +85,7 @@ initialize_server_options(ServerOptions options->x11_forwarding = -1; options->x11_display_offset = -1; options->x11_use_localhost = -1; + options->permit_tty = -1; options->xauth_location = NULL; options->strict_modes = -1; options->tcp_keep_alive = -1; @@ -201,6 +202,8 @@ fill_default_server_options(ServerOption options->x11_use_localhost = 1; if (options->xauth_location == NULL) options->xauth_location = _PATH_XAUTH; + if (options->permit_tty == -1) + options->permit_tty = 1; if (options->strict_modes == -1) options->strict_modes = 1; if (options->tcp_keep_alive == -1) @@ -314,7 +317,7 @@ typedef enum { sListenAddress, sAddressFamily, sPrintMotd, sPrintLastLog, sIgnoreRhosts, sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost, - sStrictModes, sEmptyPasswd, sTCPKeepAlive, + sPermitTTY, sStrictModes, sEmptyPasswd, sTCPKeepAlive, sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression, sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, @@ -443,6 +446,7 @@ static struct { { "useprivilegeseparation", sUsePrivilegeSeparation, SSHCFG_GLOBAL}, { "acceptenv", sAcceptEnv, SSHCFG_ALL }, { "permittunnel", sPermitTunnel, SSHCFG_ALL }, + { "permittty", sPermitTTY, SSHCFG_ALL }, { "match", sMatch, SSHCFG_ALL }, { "permitopen", sPermitOpen, SSHCFG_ALL }, { "forcecommand", sForceCommand, SSHCFG_ALL }, @@ -1075,6 +1079,10 @@ process_server_config_line(ServerOptions charptr = &options->xauth_location; goto parse_filename; + case sPermitTTY: + intptr = &options->permit_tty; + goto parse_flag; + case sStrictModes: intptr = &options->strict_modes; goto parse_flag; @@ -1657,6 +1665,7 @@ copy_set_server_options(ServerOptions *d M_CP_INTOPT(x11_display_offset); M_CP_INTOPT(x11_forwarding); M_CP_INTOPT(x11_use_localhost); + M_CP_INTOPT(permit_tty); M_CP_INTOPT(max_sessions); M_CP_INTOPT(max_authtries); M_CP_INTOPT(ip_qos_interactive); @@ -1883,6 +1892,7 @@ dump_config(ServerOptions *o) dump_cfg_fmtint(sPrintLastLog, o->print_lastlog); dump_cfg_fmtint(sX11Forwarding, o->x11_forwarding); dump_cfg_fmtint(sX11UseLocalhost, o->x11_use_localhost); + dump_cfg_fmtint(sPermitTTY, o->permit_tty); dump_cfg_fmtint(sStrictModes, o->strict_modes); dump_cfg_fmtint(sTCPKeepAlive, o->tcp_keep_alive); dump_cfg_fmtint(sEmptyPasswd, o->permit_empty_passwd); diff -rupN openssh-6.1p1/servconf.h openssh-6.1p1-permittty/servconf.h --- openssh-6.1p1/servconf.h 2012-07-31 02:21:34.000000000 +0000 +++ openssh-6.1p1-permittty/servconf.h 2013-02-12 01:35:53.204826498 +0000 @@ -74,6 +74,7 @@ typedef struct { * searching at */ int x11_use_localhost; /* If true, use localhost for fake X11 server. */ char *xauth_location; /* Location of xauth program */ + int permit_tty; /* If false, deny pty allocation */ int strict_modes; /* If true, require string home dir modes. */ int tcp_keep_alive; /* If true, set SO_KEEPALIVE. */ int ip_qos_interactive; /* IP ToS/DSCP/class for interactive */ diff -rupN openssh-6.1p1/session.c openssh-6.1p1-permittty/session.c --- openssh-6.1p1/session.c 2012-04-22 01:08:10.000000000 +0000 +++ openssh-6.1p1-permittty/session.c 2013-02-12 01:35:53.204826498 +0000 @@ -2018,7 +2018,7 @@ session_pty_req(Session *s) u_int len; int n_bytes; - if (no_pty_flag) { + if (no_pty_flag || !options.permit_tty) { debug("Allocating a pty not permitted for this authentication."); return 0; } diff -rupN openssh-6.1p1/sshd_config openssh-6.1p1-permittty/sshd_config --- openssh-6.1p1/sshd_config 2012-07-31 02:21:34.000000000 +0000 +++ openssh-6.1p1-permittty/sshd_config 2013-02-12 01:35:53.208826448 +0000 @@ -95,6 +95,7 @@ AuthorizedKeysFile .ssh/authorized_keys #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes +#PermitTTY yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes @@ -121,4 +122,5 @@ Subsystem sftp /usr/libexec/sftp-server #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no +# PermitTTY no # ForceCommand cvs server diff -rupN openssh-6.1p1/sshd_config.0 openssh-6.1p1-permittty/sshd_config.0 --- openssh-6.1p1/sshd_config.0 2012-08-29 00:53:04.000000000 +0000 +++ openssh-6.1p1-permittty/sshd_config.0 2013-02-12 01:47:46.937903605 +0000 @@ -408,9 +408,9 @@ DESCRIPTION HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication, KerberosAuthentication, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, - PermitRootLogin, PermitTunnel, PubkeyAuthentication, + PermitRootLogin, PermitTunnel, PermitTTY, PubkeyAuthentication, RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, - X11Forwarding and X11UseLocalHost. + X11Forwarding, and X11UseLocalHost. MaxAuthTries Specifies the maximum number of authentication attempts permitted @@ -481,6 +481,10 @@ DESCRIPTION ``ethernet'' (layer 2), or ``no''. Specifying ``yes'' permits both ``point-to-point'' and ``ethernet''. The default is ``no''. + PermitTTY + Specifies whether pty(7) allocation is permitted. The default is + ``yes''. + PermitUserEnvironment Specifies whether ~/.ssh/environment and environment= options in ~/.ssh/authorized_keys are processed by sshd(8). The default is diff -rupN openssh-6.1p1/sshd_config.5 openssh-6.1p1-permittty/sshd_config.5 --- openssh-6.1p1/sshd_config.5 2012-07-02 08:53:38.000000000 +0000 +++ openssh-6.1p1-permittty/sshd_config.5 2013-02-12 01:35:53.208826448 +0000 @@ -731,11 +731,12 @@ Available keywords are .Cm PermitOpen , .Cm PermitRootLogin , .Cm PermitTunnel , +.Cm PermitTTY , .Cm PubkeyAuthentication , .Cm RhostsRSAAuthentication , .Cm RSAAuthentication , .Cm X11DisplayOffset , -.Cm X11Forwarding +.Cm X11Forwarding , and .Cm X11UseLocalHost . .It Cm MaxAuthTries @@ -858,6 +859,12 @@ and .Dq ethernet . The default is .Dq no . +.It Cm PermitTTY +Specifies whether +.Xr pty 7 +allocation is permitted. +The default is +.Dq yes . .It Cm PermitUserEnvironment Specifies whether .Pa ~/.ssh/environment From djm at mindrot.org Thu Feb 14 16:02:08 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 14 Feb 2013 16:02:08 +1100 (EST) Subject: Fwd: Re: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: References: <20130117225605.GC19962@linux124.nas.nasa.gov> <20130213191814.GX19962@linux124.nas.nasa.gov> <20130213232756.GY19962@linux124.nas.nasa.gov> Message-ID: > On Wed, 13 Feb 2013, Iain Morgan wrote: > > > > I had to make a minor tweak to your patch, s/$ECDSA=rsa/ECDSA=rsa/. With > > that, and using startoffset=2500, all tests pass for the 20130214 > > snapshot built against the vendor's OpenSSL 1.0.0-fips. It has not fixed some of the tinderbox hosts: http://tinderbox.dtucker.net/cgi-bin/gunzip.cgi?tree=OpenSSH_Portable&brief-log=1360816617.20977 From plautrba at redhat.com Fri Feb 15 04:00:12 2013 From: plautrba at redhat.com (Petr Lautrbach) Date: Thu, 14 Feb 2013 18:00:12 +0100 Subject: auth2-pubkey.c - change an error message Message-ID: <511D181C.1020208@redhat.com> Hi. The error message 'AuthorizedKeyCommandUser \"%s\" not found' in user_key_command_allowed2() should inform about non-existing username, not about command. --- auth2-pubkey.c 14 Nov 2012 08:04:02 -0000 1.36 +++ auth2-pubkey.c 14 Feb 2013 16:50:04 -0000 @@ -480,7 +480,7 @@ pw = getpwnam(username); if (pw == NULL) { error("AuthorizedKeyCommandUser \"%s\" not found: %s", - options.authorized_keys_command, strerror(errno)); + username, strerror(errno)); free(username); return 0; } Petr From djm at mindrot.org Fri Feb 15 08:36:09 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 15 Feb 2013 08:36:09 +1100 (EST) Subject: auth2-pubkey.c - change an error message In-Reply-To: <511D181C.1020208@redhat.com> References: <511D181C.1020208@redhat.com> Message-ID: applied - thanks. This will make 6.2 On Thu, 14 Feb 2013, Petr Lautrbach wrote: > Hi. > > The error message 'AuthorizedKeyCommandUser \"%s\" not found' in > user_key_command_allowed2() > should inform about non-existing username, not about command. > > --- auth2-pubkey.c 14 Nov 2012 08:04:02 -0000 1.36 > +++ auth2-pubkey.c 14 Feb 2013 16:50:04 -0000 > @@ -480,7 +480,7 @@ > pw = getpwnam(username); > if (pw == NULL) { > error("AuthorizedKeyCommandUser \"%s\" not found: %s", > - options.authorized_keys_command, strerror(errno)); > + username, strerror(errno)); > free(username); > return 0; > } > > Petr > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Fri Feb 15 09:05:51 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 15 Feb 2013 09:05:51 +1100 (EST) Subject: OpenSSH NoPty patch In-Reply-To: <20130214004011.GA2681@blackmesa> References: <20130131191211.GA21468@blackmesa> <20130201214644.GE3584@linux124.nas.nasa.gov> <20130214004011.GA2681@blackmesa> Message-ID: On Thu, 14 Feb 2013, Teran McKinney wrote: > Edit: Resending as I don't think this made it to the list. Taking out > my PGP signature as I wonder if that is breaking it. The list strips non-text attachments. If you sent your email as anything but text/plain then it will be nuked, sorry. ... > I've gone with Iain's suggestion of PermitTTY and have refactored the > patch. I've also fixed the issues with the man page, and the > alphabetical sorting. Only place where alphabetical sort is off is in > the default sshd_config file, which I'm not sure if that's a problem or > not. > > I've tested it and it works exactly the same as the last patch, except > with a new default and name to the configuration option. > > I would appreciate it if anyone else can test this new patch or let me > know of any next steps for hopefully including it into the mainstream > OpenSSH code base. Please make a bug at https://bugzilla.mindrot.org/ and attach your patch to it. This will make sure it doesn't get lost and provides a good place to review it. Cheers, Damien Miller From sega01 at go-beyond.org Fri Feb 15 09:59:36 2013 From: sega01 at go-beyond.org (Teran McKinney) Date: Thu, 14 Feb 2013 22:59:36 +0000 Subject: OpenSSH NoPty patch In-Reply-To: References: <20130131191211.GA21468@blackmesa> <20130201214644.GE3584@linux124.nas.nasa.gov> <20130214004011.GA2681@blackmesa> Message-ID: <20130214225936.GA1937@blackmesa> On 2013-02-15 09-05-51 , Damien Miller wrote: > On Thu, 14 Feb 2013, Teran McKinney wrote: > > > Edit: Resending as I don't think this made it to the list. Taking out > > my PGP signature as I wonder if that is breaking it. > > The list strips non-text attachments. If you sent your email as anything > but text/plain then it will be nuked, sorry. > > ... > > I've gone with Iain's suggestion of PermitTTY and have refactored the > > patch. I've also fixed the issues with the man page, and the > > alphabetical sorting. Only place where alphabetical sort is off is in > > the default sshd_config file, which I'm not sure if that's a problem or > > not. > > > > I've tested it and it works exactly the same as the last patch, except > > with a new default and name to the configuration option. > > > > I would appreciate it if anyone else can test this new patch or let me > > know of any next steps for hopefully including it into the mainstream > > OpenSSH code base. > > Please make a bug at https://bugzilla.mindrot.org/ and attach your patch > to it. This will make sure it doesn't get lost and provides a good place > to review it. > > Cheers, > Damien Miller Hi Damien, Thank you for replying! I understand about anything not text/plain being excluded. Not certain how my first email made it through; perhaps I forgot to sign it or the MIME was set differently. I submitted the bug to Bugzilla. I appreciate your feedback. https://bugzilla.mindrot.org/show_bug.cgi?id=2070 Thanks again, Teran From dtucker at zip.com.au Fri Feb 15 11:33:47 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 15 Feb 2013 11:33:47 +1100 Subject: getpgrp Message-ID: <20130215003347.GA19379@gate.dtucker.net> These days, sshd.c has: static void grace_alarm_handler(int sig) { ... if (getpgid(0) == getpid()) { signal(SIGTERM, SIG_IGN); killpg(0, SIGTERM); } sigdie(...); } however (really) old BSDs do not have getpgid(). They do have getpgrp(), which does what we want here. The question is what to do if we have neither: return the pid (and thus terminate nothing) or return -1 and kill everything wihout getting to the sigdie(). I vote for the latter (since they're unlikely to be able to log anything in a signal-safe manner anyway). Index: configure.ac =================================================================== RCS file: /var/cvs/openssh/configure.ac,v retrieving revision 1.503 diff -u -p -r1.503 configure.ac --- configure.ac 10 Feb 2013 23:39:13 -0000 1.503 +++ configure.ac 15 Feb 2013 00:26:37 -0000 @@ -1550,6 +1550,8 @@ AC_CHECK_FUNCS([ \ getopt \ getpeereid \ getpeerucred \ + getpgid \ + getpgrp \ _getpty \ getrlimit \ getttyent \ Index: openbsd-compat/bsd-misc.c =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bsd-misc.c,v retrieving revision 1.36 diff -u -p -r1.36 bsd-misc.c --- openbsd-compat/bsd-misc.c 8 Nov 2010 22:26:23 -0000 1.36 +++ openbsd-compat/bsd-misc.c 15 Feb 2013 00:26:37 -0000 @@ -246,4 +246,18 @@ int isblank(int c) { return (c == ' ' || c == '\t'); } + +#ifndef HAVE_GETPGID +pid_t +getpgid(pid_t pid) +{ +#ifdef HAVE_GETPGRP + if (pid == 0) + return getpgrp(); +#endif + errno = ESRCH; + return -1; +} +#endif + #endif Index: openbsd-compat/bsd-misc.h =================================================================== RCS file: /var/cvs/openssh/openbsd-compat/bsd-misc.h,v retrieving revision 1.21 diff -u -p -r1.21 bsd-misc.h --- openbsd-compat/bsd-misc.h 3 Jul 2012 22:50:10 -0000 1.21 +++ openbsd-compat/bsd-misc.h 15 Feb 2013 00:26:37 -0000 @@ -102,4 +102,8 @@ mysig_t mysignal(int sig, mysig_t act); int isblank(int); #endif +#ifndef HAVE_GETPGID +pid_t getpgid(pid_t); +#endif + #endif /* _BSD_MISC_H */ -- 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 djm at mindrot.org Fri Feb 15 13:14:56 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 15 Feb 2013 13:14:56 +1100 (EST) Subject: getpgrp In-Reply-To: <20130215003347.GA19379@gate.dtucker.net> References: <20130215003347.GA19379@gate.dtucker.net> Message-ID: On Fri, 15 Feb 2013, Darren Tucker wrote: > These days, sshd.c has: > > static void > grace_alarm_handler(int sig) > { > ... > if (getpgid(0) == getpid()) { > signal(SIGTERM, SIG_IGN); > killpg(0, SIGTERM); > } > > sigdie(...); > } > > however (really) old BSDs do not have getpgid(). They do have > getpgrp(), which does what we want here. The question is what to do if > we have neither: return the pid (and thus terminate nothing) or return > -1 and kill everything wihout getting to the sigdie(). I vote for the > latter (since they're unlikely to be able to log anything in a > signal-safe manner anyway). Is killpg(-1, ...) defined to do anything? According to SUSv3, pgrp<=1 is undefined. Do you mean pgrp=0? The condition I worry about is terminating the listening sshd by accident. Maybe it would be best to disable AuthorizedKeysCommand on these hosts, since it was the motivation for the killpg IIRC. -d From djm at mindrot.org Fri Feb 15 14:00:47 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 15 Feb 2013 14:00:47 +1100 (EST) Subject: getpgrp In-Reply-To: <20130215003347.GA19379@gate.dtucker.net> References: <20130215003347.GA19379@gate.dtucker.net> Message-ID: On Fri, 15 Feb 2013, Darren Tucker wrote: > +#ifndef HAVE_GETPGID > +pid_t > +getpgid(pid_t pid) > +{ > +#ifdef HAVE_GETPGRP > + if (pid == 0) > + return getpgrp(); > +#endif getpgrp() takes an argument on BSDs. AC_FUNC_GETPGRP tests for this: http://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Particular-Functions.html#index-AC_005fFUNC_005fGETPGRP-376 -d From dtucker at zip.com.au Fri Feb 15 14:42:43 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 15 Feb 2013 14:42:43 +1100 Subject: getpgrp In-Reply-To: References: <20130215003347.GA19379@gate.dtucker.net> Message-ID: On Fri, Feb 15, 2013 at 2:00 PM, Damien Miller wrote: [...] > getpgrp() takes an argument on BSDs. Not all of them as it turns out. > AC_FUNC_GETPGRP tests for this: Sigh. I didn't go back far enough. It looks like it changed between 4.3BSD and 4.4lite: http://www.freebsd.org/cgi/man.cgi?query=getpgrp&manpath=4.3BSD+NET%2F2 http://www.freebsd.org/cgi/man.cgi?query=getpgrp&manpath=4.4BSD+Lite2 I'll add a check. -- 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 djm at mindrot.org Fri Feb 15 14:48:09 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 15 Feb 2013 14:48:09 +1100 (EST) Subject: getpgrp In-Reply-To: References: <20130215003347.GA19379@gate.dtucker.net> Message-ID: you are in a twisty maze of passages, all alike On Fri, 15 Feb 2013, Darren Tucker wrote: > On Fri, Feb 15, 2013 at 2:00 PM, Damien Miller wrote: > [...] > > getpgrp() takes an argument on BSDs. > > Not all of them as it turns out. > > > AC_FUNC_GETPGRP tests for this: > > Sigh. I didn't go back far enough. It looks like it changed between > 4.3BSD and 4.4lite: > > http://www.freebsd.org/cgi/man.cgi?query=getpgrp&manpath=4.3BSD+NET%2F2 > http://www.freebsd.org/cgi/man.cgi?query=getpgrp&manpath=4.4BSD+Lite2 > > I'll add a check. > > -- > 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 Fri Feb 15 15:03:33 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 15 Feb 2013 15:03:33 +1100 Subject: getpgrp In-Reply-To: References: <20130215003347.GA19379@gate.dtucker.net> Message-ID: On Fri, Feb 15, 2013 at 1:14 PM, Damien Miller wrote: [...] > Is killpg(-1, ...) defined to do anything? I don't know, but it's never going to do that. The I added getpgid but it's only used in the if() test, the killpg is a static argument. > The condition I worry about is terminating the listening sshd by accident. I don't think that can happen. We don't set grace_alarm_handler until after we've returned from server_accept_loop in a newly forked process. -- 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 Fri Feb 15 21:27:59 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 15 Feb 2013 11:27:59 +0100 Subject: OpenSSH NoPty patch In-Reply-To: <20130214225936.GA1937@blackmesa> References: <20130131191211.GA21468@blackmesa> <20130201214644.GE3584@linux124.nas.nasa.gov> <20130214004011.GA2681@blackmesa> <20130214225936.GA1937@blackmesa> Message-ID: <511E0DAF.7010604@gmail.com> On 14/02/13 23:59, Teran McKinney wrote: > Hi Damien, > > Thank you for replying! I understand about anything not text/plain being > excluded. Not certain how my first email made it through; perhaps I > forgot to sign it or the MIME was set differently. > > I submitted the bug to Bugzilla. I appreciate your feedback. > > https://bugzilla.mindrot.org/show_bug.cgi?id=2070 > > Thanks again, > Teran I did receive it (through the list, I wasn't in CC), and it did have the diff as text/plain, so I don't know why Damien would not have received the patch attached to your mail. Maybe he was simply giving additional advice about your problems sending to the list. From djm at mindrot.org Sat Feb 16 17:43:21 2013 From: djm at mindrot.org (Damien Miller) Date: Sat, 16 Feb 2013 17:43:21 +1100 (EST) Subject: Fwd: Re: Inconsisten declaration of ssh_aes_ctr_iv() In-Reply-To: References: <20130117225605.GC19962@linux124.nas.nasa.gov> <20130213191814.GX19962@linux124.nas.nasa.gov> <20130213232756.GY19962@linux124.nas.nasa.gov> Message-ID: On Thu, 14 Feb 2013, Damien Miller wrote: > > On Wed, 13 Feb 2013, Iain Morgan wrote: > > > > > > I had to make a minor tweak to your patch, s/$ECDSA=rsa/ECDSA=rsa/. With > > > that, and using startoffset=2500, all tests pass for the 20130214 > > > snapshot built against the vendor's OpenSSL 1.0.0-fips. > > It has not fixed some of the tinderbox hosts: > > http://tinderbox.dtucker.net/cgi-bin/gunzip.cgi?tree=OpenSSH_Portable&brief-log=1360816617.20977 With some help from Darren, we figured it out - hosts without ECC were failing since they used more byte-wise verbose KEX methods than the ecdh-* family. As there is nothing sinister going on, I've committed the obvious fix of cranking up fuzz offset past the end of the most longwinded KEX method (diffie-hellman-group-exchange-sha256). -d From cloos at jhcloos.com Sun Feb 17 16:32:42 2013 From: cloos at jhcloos.com (James Cloos) Date: Sun, 17 Feb 2013 00:32:42 -0500 Subject: getpgrp In-Reply-To: (Darren Tucker's message of "Fri, 15 Feb 2013 14:42:43 +1100") References: <20130215003347.GA19379@gate.dtucker.net> Message-ID: >>>>> "DT" == Darren Tucker writes: First, DT> ... really old BSDs ... Then, DT> Sigh. I didn't go back far enough. And, DT> It looks like it changed between 4.3BSD and 4.4lite: Does that mean 4.3 is older than really old? [SIGH] -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From sticker0 at mail.ru Tue Feb 19 18:02:02 2013 From: sticker0 at mail.ru (Nick Permyakov) Date: Tue, 19 Feb 2013 11:02:02 +0400 Subject: /openssh/donations.html word misspelling Message-ID: <5123236A.2090704@mail.ru> Hi, Please fix the misspelling of "separate" in "The people and organizations who have contributed money, equipment, or services to OpenSSH are not kept seperate" on http://www.openbsd.org/openssh/donations.html. Best regards, Nick Permyakov From v.olokhtonov at sirena2000.ru Thu Feb 21 02:17:34 2013 From: v.olokhtonov at sirena2000.ru (=?UTF-8?B?0J7Qu9C+0YXRgtC+0L3QvtCyINCS0LvQsNC00LjQvNC40YA=?=) Date: Wed, 20 Feb 2013 19:17:34 +0400 Subject: ssh "bash -c" bug Message-ID: <5124E90E.5050008@sirena2000.ru> The arguments of the first command given to "bash -c" over ssh is being ignored. xxx at yyy:~$ ssh xxx at localhost bash -c 'echo foo; echo bar' bar xxx at yyy:~$ ssh ova at localhost bash -c ':; echo foo; echo bar' foo bar -- ? ?????????, ????????? ????????????? ???????? ??????-? ????????? ???????? v.olokhtonov at sirena2000.ru From peter at stuge.se Thu Feb 21 03:00:11 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 20 Feb 2013 17:00:11 +0100 Subject: ssh "bash -c" bug In-Reply-To: <5124E90E.5050008@sirena2000.ru> References: <5124E90E.5050008@sirena2000.ru> Message-ID: <20130220160011.28701.qmail@stuge.se> ????????? ???????? wrote: > The arguments of the first command given to "bash -c" over ssh is > being ignored. > > xxx at yyy:~$ ssh xxx at localhost bash -c 'echo foo; echo bar' > > bar You should study shell quoting and the SSH protocol. The ssh command is being run in an interactive shell. Your quotes tell this shell that it should pass "echo foo; echo bar" excluding the quotes as a single parameter to the ssh command. As you can see in the SSH protocol, the command to be executed by the server is sent as a single string. In your example that string is "bash -c echo foo; echo bar" excluding the quotes. Try what happens when you run that command directly: $ bash -c echo foo; echo bar bar $ ..and notice that the result is the same. Try to understand why. Now think about what you must do to get your desired result. Understanding quoting is fundamental for actually using the shell, as opposed to copypaste commands from blogs or entering random characters and hoping for the best. There is plenty of good material on the subject, you can start with the bash man page. man bash then search for QUOTING in caps. Shell quoting is also covered in countless books, and probably also in some video tutorials on youtube if that is what you prefer. And of course you must always be aware of which shell is being used where, since quoting works differently in different shells. //Peter From phil.pennock at globnix.org Thu Feb 21 07:46:58 2013 From: phil.pennock at globnix.org (Phil Pennock) Date: Wed, 20 Feb 2013 15:46:58 -0500 Subject: ssh "bash -c" bug In-Reply-To: <5124E90E.5050008@sirena2000.ru> References: <5124E90E.5050008@sirena2000.ru> Message-ID: <20130220204658.GA86810@redoubt.spodhuis.org> On 2013-02-20 at 19:17 +0400, ????????? ???????? wrote: > The arguments of the first command given to "bash -c" over ssh is being > ignored. SSH does not send an array/vector in the protocol; instead, it joins together the options into one command-line, sent to be run on the remote side. When you write: bash -c 'echo foo; echo bar' this provides three parameters to the local command, joined back together *without* quoting to protect the original parameters. So you might as well have written: 'bash -c echo foo; echo bar' So treat the combination of the parameters you write as something to be parsed apart by shell again, since the client doesn't preserve the structure of the original command-line. With a perspective of "command prefices, and preserve the command array" (like "nice", "nohup", any other command-that-takes-a-command), ssh's behaviour is a bug. But it's long-standing, and changing it would break existing tools, so it's behaviour that you have to live with. Regards, -Phil From bob at proulx.com Thu Feb 21 11:48:26 2013 From: bob at proulx.com (Bob Proulx) Date: Wed, 20 Feb 2013 17:48:26 -0700 Subject: ssh "bash -c" bug In-Reply-To: <5124E90E.5050008@sirena2000.ru> References: <5124E90E.5050008@sirena2000.ru> Message-ID: <20130221004826.GB6008@hysteria.proulx.com> ????????? ???????? wrote: > The arguments of the first command given to "bash -c" over ssh is > being ignored. > > xxx at yyy:~$ ssh xxx at localhost bash -c 'echo foo; echo bar' Instead of confusing shell quoting I recommend piping the commands to the remote shell. Used judiciously it can avoid confusion. $ echo "echo foo; echo bar" | ssh xxx at example bash Or: $ ssh xxx at example bash <<'EOF' echo foo; echo bar EOF One of the useful features of this method is that the shell interpreter on the remote system is specified and does not use the default login shell from the password file. Useful when your login on some hosts is different than on others. Bob From peter at stuge.se Thu Feb 21 13:18:28 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 21 Feb 2013 03:18:28 +0100 Subject: ssh "bash -c" bug In-Reply-To: <20130221004826.GB6008@hysteria.proulx.com> References: <5124E90E.5050008@sirena2000.ru> <20130221004826.GB6008@hysteria.proulx.com> Message-ID: <20130221021828.14625.qmail@stuge.se> Bob Proulx wrote: > Instead of confusing shell quoting I recommend piping the commands ..must..avoid..learning.. //Peter From phil.pennock at globnix.org Thu Feb 21 19:15:41 2013 From: phil.pennock at globnix.org (Phil Pennock) Date: Thu, 21 Feb 2013 03:15:41 -0500 Subject: ssh "bash -c" bug In-Reply-To: <20130221021828.14625.qmail@stuge.se> References: <5124E90E.5050008@sirena2000.ru> <20130221004826.GB6008@hysteria.proulx.com> <20130221021828.14625.qmail@stuge.se> Message-ID: <20130221081541.GA98329@redoubt.spodhuis.org> On 2013-02-21 at 03:18 +0100, Peter Stuge wrote: > Bob Proulx wrote: > > Instead of confusing shell quoting I recommend piping the commands > > ..must..avoid..learning.. The OP's shell quoting was absolutely correct, for pretty much any command wrapper except OpenSSH's ssh (I haven't checked other implementations). If you join together an argument vector into a shell command-line, the tool doing that should be taking adequate steps to quote individual arguments as needed, so that they're preserved. That ssh does not do so is a bug. It's a bug that it's far too late to fix now, but that doesn't change that the ssh(1) client is flawed here. When there's a standard system, and one tool does things differently, folks can learn the idiosyncrasies of the odd tools, or they can learn that the tool is buggy and avoid the issue. I recommend just learning that it's different and avoiding the issue instead of trying to build up an encyclopaedic knowledge of variances. Bob's suggestions were good ones. -Phil From alex at alex.org.uk Thu Feb 21 20:48:26 2013 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 21 Feb 2013 09:48:26 +0000 Subject: ssh "bash -c" bug In-Reply-To: <20130220204658.GA86810@redoubt.spodhuis.org> References: <5124E90E.5050008@sirena2000.ru> <20130220204658.GA86810@redoubt.spodhuis.org> Message-ID: <7CB1F464-9CB6-41F9-92EC-3E7BB9B15A1F@alex.org.uk> On 20 Feb 2013, at 20:46, Phil Pennock wrote: > > With a perspective of "command prefices, and preserve the command > array" (like "nice", "nohup", any other command-that-takes-a-command), > ssh's behaviour is a bug. But it's long-standing, and changing it would > break existing tools, so it's behaviour that you have to live with. I'm not sure I'd go so far as a bug, but it is 'behaviour which is occasionally irrirating' having been bitten by it before. Personally, I'd like a command line flag that says 'take argv[] as separate parameters, do not fold spindle or mutilate, and pass those completely unchanged to exec on the remote end as separate parameters'. -- Alex Bligh From peter at stuge.se Fri Feb 22 00:54:21 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 21 Feb 2013 14:54:21 +0100 Subject: ssh "bash -c" bug In-Reply-To: <7CB1F464-9CB6-41F9-92EC-3E7BB9B15A1F@alex.org.uk> References: <5124E90E.5050008@sirena2000.ru> <20130220204658.GA86810@redoubt.spodhuis.org> <7CB1F464-9CB6-41F9-92EC-3E7BB9B15A1F@alex.org.uk> Message-ID: <20130221135421.2530.qmail@stuge.se> Alex Bligh wrote: > I'd like a command line flag that says 'take argv[] as separate > parameters, do not fold spindle or mutilate, and pass those > completely unchanged to exec on the remote end as separate > parameters'. Please study the SSH protocol. //Peter From peter at stuge.se Fri Feb 22 01:05:12 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 21 Feb 2013 15:05:12 +0100 Subject: ssh "bash -c" bug In-Reply-To: <20130221081541.GA98329@redoubt.spodhuis.org> References: <5124E90E.5050008@sirena2000.ru> <20130221004826.GB6008@hysteria.proulx.com> <20130221021828.14625.qmail@stuge.se> <20130221081541.GA98329@redoubt.spodhuis.org> Message-ID: <20130221140512.3677.qmail@stuge.se> Phil Pennock wrote: > > > Instead of confusing shell quoting I recommend piping the commands > > > > ..must..avoid..learning.. > > The OP's shell quoting was absolutely correct, The quoting was obviously NOT correct because things didn't work as intended. The incorrect quoting demonstrated a lack of understanding for the tools being used. That's an unneccessary waste of time. > for pretty much any command wrapper ssh is a shell, not a command wrapper. Please just learn how your shell's quoting works and reap the benefits of that instead of resisting something because it doesn't fit into a certain pattern. 101 exercise: sh -c echo $$; echo $$ sh -c 'echo $$; echo $$' 201 exercise: sh -c sh -c echo $$; echo $$ sh -c sh -c 'echo $$; echo $$' 301 exercise: sh -c "sh -c echo $$; echo $$" sh -c "sh -c 'echo $$; echo $$'" Compare the exercises with using "ssh somehost" instead of "sh -c". //Peter From alex at alex.org.uk Fri Feb 22 02:38:35 2013 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 21 Feb 2013 15:38:35 +0000 Subject: ssh "bash -c" bug In-Reply-To: <20130221135421.2530.qmail@stuge.se> References: <5124E90E.5050008@sirena2000.ru> <20130220204658.GA86810@redoubt.spodhuis.org> <7CB1F464-9CB6-41F9-92EC-3E7BB9B15A1F@alex.org.uk> <20130221135421.2530.qmail@stuge.se> Message-ID: <08A535A0-3083-4085-A363-F56A496DA873@alex.org.uk> On 21 Feb 2013, at 13:54, Peter Stuge wrote: > Alex Bligh wrote: >> I'd like a command line flag that says 'take argv[] as separate >> parameters, do not fold spindle or mutilate, and pass those >> completely unchanged to exec on the remote end as separate >> parameters'. > > Please study the SSH protocol. I'm unaware of anything in the ssh protocol which would prevent this (assuming I want to do exactly what I said, just exec a command) and indeed I'm pretty sure one could write it as a trivial wrapper. For instance I could run a program which takes a NULL terminated set of argv[] entries, followed by a further NULL, on stdin, then passes the fd to the exec()'d program. The client side wrapper would to do the opposite. ssh itself would just see the wrapper being executed. Why would my proposal require a change to the ssh protocol? It's executing one binary, which snarfs something from stdin then runs exec(). If the answer is 'it doesn't, then why would this be impossible using a flag plus helper binary server side? -- Alex Bligh From peter at stuge.se Fri Feb 22 02:55:54 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 21 Feb 2013 16:55:54 +0100 Subject: ssh "bash -c" bug In-Reply-To: <08A535A0-3083-4085-A363-F56A496DA873@alex.org.uk> References: <5124E90E.5050008@sirena2000.ru> <20130220204658.GA86810@redoubt.spodhuis.org> <7CB1F464-9CB6-41F9-92EC-3E7BB9B15A1F@alex.org.uk> <20130221135421.2530.qmail@stuge.se> <08A535A0-3083-4085-A363-F56A496DA873@alex.org.uk> Message-ID: <20130221155554.17450.qmail@stuge.se> Alex Bligh wrote: > >> I'd like a command line flag that says 'take argv[] as separate > >> parameters, do not fold spindle or mutilate, and pass those > >> completely unchanged to exec on the remote end as separate > >> parameters'. > > > > Please study the SSH protocol. > > I'm unaware of anything in the ssh protocol which would prevent > this (assuming I want to do exactly what I said, just exec > a command) and indeed I'm pretty sure one could write it > as a trivial wrapper. Sure! If it's OK to require a special server-side install in order to support this new service then no problem. The easiest by far would be to use a subsystem. The flag for that is already there. :) > why would this be impossible using a flag plus helper binary server side? A helper binary is acceptable in your case, but that is something quite different from a flag on the client side. //Peter From phil.pennock at globnix.org Fri Feb 22 05:17:56 2013 From: phil.pennock at globnix.org (Phil Pennock) Date: Thu, 21 Feb 2013 13:17:56 -0500 Subject: ssh "bash -c" bug In-Reply-To: <20130221140512.3677.qmail@stuge.se> References: <5124E90E.5050008@sirena2000.ru> <20130221004826.GB6008@hysteria.proulx.com> <20130221021828.14625.qmail@stuge.se> <20130221081541.GA98329@redoubt.spodhuis.org> <20130221140512.3677.qmail@stuge.se> Message-ID: <20130221181756.GA22833@redoubt.spodhuis.org> I almost didn't send this, to avoid bothering the list, since the first three paragraphs of my reply text below don't fix anything for ssh; there's just enough value left that I'm sending anyway, but I'm unlikely to waste everyone's time by responding further since I think I've made my point. On 2013-02-21 at 15:05 +0100, Peter Stuge wrote: > Phil Pennock wrote: > > > > Instead of confusing shell quoting I recommend piping the commands > > > > > > ..must..avoid..learning.. > > > > The OP's shell quoting was absolutely correct, > > The quoting was obviously NOT correct because things didn't work as Quoting part of a reply to treat it out of context and attack something I didn't say is an interesting approach to civilised discourse. > ssh is a shell, not a command wrapper. Please just learn how your > shell's quoting works and reap the benefits of that instead of > resisting something because it doesn't fit into a certain pattern. Please note: I have commit-bit on the widely-used shell I have been using for 18 years and am more than familiar with the various forms of quoting it offers. Heck, I've even added features to it (zsh) for bash compatibility to ease problems caused by folks using simple ssh recipes they don't fully understand. ssh takes some command and runs it on a remote host. It is taking an argument vector to be run. It does not protect the individual parameters and instead joins them naively with just a single space between them, flattening argv badly. It's far too late to fix it, but it's still both different and broken; the OP's expectations were sane. Bob proposed work-arounds which are sane for people to take to avoid having to learn the precise ways in which ssh is buggy and that's a good thing. With his work-arounds, folks client code is robust and understandable. Avoiding a good solution for one which demonstrates intimate protocol knowledge is a questionable trade-off to demand of others, and will lead to more fragility in practice as code has to be maintained by people of varying skill levels:. It's good practice to set up programming styles of handling something which are hard to break, even when well-intentioned people try to fix something that looks broken. Adjusting your coding approach to something that's easier to maintain and easier to protect is a sign of Bob's apparent experience in dealing with real world script maintenance. Maintainability trumps ego in showing off what you know. Regards, -Phil From peter at stuge.se Sun Feb 24 03:35:35 2013 From: peter at stuge.se (Peter Stuge) Date: Sat, 23 Feb 2013 17:35:35 +0100 Subject: ssh "bash -c" bug In-Reply-To: <20130221181756.GA22833@redoubt.spodhuis.org> References: <5124E90E.5050008@sirena2000.ru> <20130221004826.GB6008@hysteria.proulx.com> <20130221021828.14625.qmail@stuge.se> <20130221081541.GA98329@redoubt.spodhuis.org> <20130221140512.3677.qmail@stuge.se> <20130221181756.GA22833@redoubt.spodhuis.org> Message-ID: <20130223163535.17972.qmail@stuge.se> Phil Pennock wrote: > > > > > Instead of confusing shell quoting I recommend piping the commands > > > > > > > > ..must..avoid..learning.. > > > > > > The OP's shell quoting was absolutely correct, > > > > The quoting was obviously NOT correct because things didn't work as > > Quoting part of a reply to treat it out of context and attack something > I didn't say is an interesting approach to civilised discourse. I'm very sorry if you feel that I attacked what you said - my point is that since the quoting didn't accomplish what was intended it can't really be considered correct in the grand scheme of things. I know that you meant that the quoting was correct in the *first* shell. The while problem is that successful use of sh -c or a remote equivalent requires taking care of *every* layer, not only the first. > > ssh is a shell, not a command wrapper. Please just learn how your > > shell's quoting works and reap the benefits of that instead of > > resisting something because it doesn't fit into a certain pattern. > > Please note: I have commit-bit Yes, yourself and Bob both know quoting. The "you" I used was the indeterminate third person, recommending them not to settle for avoidance and encouraging them to learn more. > ssh takes some command and runs it on a remote host. It is taking > an argument vector to be run. But [command] in man ssh looks like a single argument to me, and the man page doesn't mention anywhere that arguments will be concatenated, so that behavior seems almost accidental. Of course I also use it, and it's a handy optimization for the common case, but I wouldn't mind terribly if OpenSSH changed to always use only the first argument as the channel command. > It does not protect the individual parameters and instead joins > them naively with just a single space between them, flattening > argv badly. Comparing documentation to expectation I don't think that ssh is doing anything wrong. The concatenation seems to be a perk, so I don't think it makes sense to complain about it. The documented syntax seems to be a single argument, which makes perfect sense considering the protocol on the wire, which I guess was inspired by how -c works for local shells (by way of rsh). > It's far too late to fix it, but it's still both different and broken; I don't see how it's different from sh -c (except that ssh optimizes away that one level of quoting in the common case, which might actually be doing new users a disservice) and I don't agree that it's broken. > the OP's expectations were sane. Again I disagree, especially considering the man page and how -c works with local shells. Follows a more philosophical - but still interesting - discussion. Feel free to reply off the list! > Bob proposed work-arounds which are sane for people to take to > avoid having to learn Yes! However I strongly disagree that avoiding learning about details (maybe especially those that some consider to be bugs!) is a good thing. More people should learn about more details, not avoid them. > Maintainability trumps ego in showing off what you know. It's not about ego - it's about efficiency and about preempting problems by noticing them before the fact. Does such ability boost ego? Sure. Is that a bad thing? I don't think so. Do you honestly prefer lower efficiency and merely being reactive? Why settle for mediocre like that? It scales better, but why not promote excellence as part of scaling up? No time? Of course it's safer not to, but I think that's a dead end for the entire organisation. A negative spiral, instead of a positive one. I've programmed C for decades and I am always equally grateful when I come across someone's code which makes me learn something new. That happens only rarely now, just once in the last years, and admittedly it was "just" a GCC extension, but anyway I think it is absolutely fantastic to learn that way - discovering knowledge as a side effect, while actually on a path of doing something else. The cost of learning the constraints of that new thing is usually low, although of course a more complex topic like shell quoting or regular expressions can take years to master. I think those techniques are still very much worth learning. It's not like multiple levels of shell quoting is useful only with ssh. On a more general note I find it depressingly common for people to resist learning about layers below where they primarily operate, depressing because it would allow them to make the most of the tools at hand. I like to argue for "learning down the layers", and there are often people who fiercely resist the mere idea.. Sad face. //Peter From keisial at gmail.com Sun Feb 24 05:59:28 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sat, 23 Feb 2013 19:59:28 +0100 Subject: ssh "bash -c" bug In-Reply-To: <20130223163535.17972.qmail@stuge.se> References: <5124E90E.5050008@sirena2000.ru> <20130221004826.GB6008@hysteria.proulx.com> <20130221021828.14625.qmail@stuge.se> <20130221081541.GA98329@redoubt.spodhuis.org> <20130221140512.3677.qmail@stuge.se> <20130221181756.GA22833@redoubt.spodhuis.org> <20130223163535.17972.qmail@stuge.se> Message-ID: <51291190.9040306@gmail.com> The compatibility argument seemed to me strong enough not to change anything on the command line, but as I was reading this mail, I noticed another benefit of doing the command line processing only at the client shell, which is the added difficulty when coding a wrapper script which calls ssh, as you not only need to ensure the correct quoting inside the shell script, but also that the user parameters won't become a metacharacter when processed as a command line in the remote shell. Needing to filter them with commands such as: sed -e 's!\(["$\\]\)!\\\1!g' -e 's!^\(.*\)$!"\1"!' From peter at stuge.se Sun Feb 24 10:42:48 2013 From: peter at stuge.se (Peter Stuge) Date: Sun, 24 Feb 2013 00:42:48 +0100 Subject: ssh "bash -c" bug In-Reply-To: <51291190.9040306@gmail.com> References: <5124E90E.5050008@sirena2000.ru> <20130221004826.GB6008@hysteria.proulx.com> <20130221021828.14625.qmail@stuge.se> <20130221081541.GA98329@redoubt.spodhuis.org> <20130221140512.3677.qmail@stuge.se> <20130221181756.GA22833@redoubt.spodhuis.org> <20130223163535.17972.qmail@stuge.se> <51291190.9040306@gmail.com> Message-ID: <20130223234248.18732.qmail@stuge.se> ?ngel Gonz?lez wrote: > I noticed another benefit of doing the command line processing only > at the client shell I agree that it has benefits! If you want to take a stab, why not create that subsystem to do it? //Peter From Vjacheslav.Fyodorov at chtd.ru Sun Feb 24 19:47:37 2013 From: Vjacheslav.Fyodorov at chtd.ru (Vjacheslav Fyodorov) Date: Sun, 24 Feb 2013 12:47:37 +0400 Subject: scp progress bar: wrong truncation of long multibyte file names Message-ID: <5129D3A9.8070300@chtd.ru> Hi. I have: [fva at localhost ~]$ rpm -qi openssh-clients Name : openssh-clients Version : 6.1p1 Release : 5.fc18 Architecture: x86_64 Install Date: ??. 13 ????. 2013 16:15:25 Group : Applications/Internet Size : 1331287 License : BSD Signature : RSA/SHA256, ??. 09 ????. 2013 01:34:32, Key ID ff01125cde7f38bd Source RPM : openssh-6.1p1-5.fc18.src.rpm Build Date : ??. 08 ????. 2013 18:18:58 Build Host : buildvm-11.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project Locale set to ru_RU.UTF-8, so file names are in utf-8 coding. It seems, file names truncated by counting bytes, not characters. Best wishes, Vjacheslav. From imorgan at nas.nasa.gov Tue Feb 26 08:30:36 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 25 Feb 2013 13:30:36 -0800 Subject: Definition of DATA in regress/cipher-speed.sh Message-ID: <20130225213035.GJ3584@linux124.nas.nasa.gov> Hi, I noticed that DATA is defined twice in regress/cipher-speed.sh: % grep -n DATA cipher-speed.sh 12:DATA=/bin/ls 13:DATA=/bsd 33: < ${DATA} ) 2>&1 | getbytes 54: < ${DATA} ) 2>&1 | getbytes % The second definition will override the first, however /bsd is not present on all operating systems. Perhaps using something like $OBJ/sshd would be more portable. -- Iain Morgan From djm at mindrot.org Wed Feb 27 09:09:29 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Feb 2013 09:09:29 +1100 (EST) Subject: Call for testing: OpenSSH-6.2 Message-ID: Hi, It's that time again... OpenSSH 6.2 is almost ready for release, so we would appreciate testing on as many platforms and systems as possible. This release contains some substantial new features and a number of bugfixes. Snapshot releases for portable OpenSSH are available from http://www.mindrot.org/openssh_snap/ The OpenBSD version is available in CVS HEAD: http://www.openbsd.org/anoncvs.html Portable OpenSSH is also available via anonymous CVS using the instructions at http://www.openssh.com/portable.html#cvs or via Mercurial at http://hg.mindrot.org/openssh Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: $ ./configure && make tests Live testing on suitable non-production systems is also appreciated. Please send reports of success or failure to openssh-unix-dev at mindrot.org. Below is a summary of changes. More detail may be found in the ChangeLog in the portable OpenSSH tarballs. Thanks to the many people who contributed to this release. Changes since OpenSSH 6.1 ========================= Features: * ssh(1)/sshd(8): Added support for AES-GCM authenticated encryption in SSH protocol 2. The new cipher is available as aes128-gcm at openssh.com and aes256-gcm at openssh.com. It uses an identical packet format to the AES-GCM mode specified in RFC 5647, but uses simpler and different selection rules during key exchange. * ssh(1)/sshd(8): Added support for encrypt-then-mac (EtM) MAC modes for SSH protocol 2. These modes alter the packet format and compute the MAC over the packet length and encrypted packet rather than over the plaintext data. These modes are considered more secure and are used by default when available. * ssh(1)/sshd(8): Added support for the UMAC-128 MAC as "umac-128 at openssh.com" and "umac-128-etm at openssh.com". The latter being an encrypt-then-mac mode. * sshd(8): Added support for multiple required authentication in SSH protocol 2 via an AuthenticationMethods option. This option lists one or more comma-separated lists of authentication method names. Successful completion of all the methods in any list is required for authentication to complete. This allows, for example, requiring a user having to authenticate via public key or GSSAPI before they are offered password authentication. * sshd(8)/ssh-keygen(1): Added support for Key Revocation Lists (KRLs), a compact binary format to represent lists of revoked keys and certificates that take as little as one bit per certificate when revoking by serial number. KRLs may be generated using ssh-keygen(1) and are loaded into sshd(8) via the existing RevokedKeys sshd_config option. * ssh(1): IdentitiesOnly now applies to keys obtained from a PKCS11Provider. This allows control of which keys are offered from tokens using IdentityFile. * sshd(8): sshd_config(5)'s AllowTcpForwarding now accepts "local" and "remote" in addition to its previous "yes"/"no" keywords to allow the server to specify whether just local or remote TCP forwarding is enabled. * sshd(8): Added a sshd_config(5) option AuthorizedKeysCommand to support fetching authorized_keys from a command in addition to (or instead of) from the filesystem. The command is run under an account specified by an AuthorizedKeysCommandUser sshd_config(5) option. * sftp-server(8): Now supports a -d option to allow the starting directory to be something other than the user's home directory. * ssh-keygen(1): Now allows fingerprinting of keys hosted in PKCS#11 tokens using "ssh-keygen -lD pkcs11_provider". * ssh(1): When SSH protocol 2 only is selected (the default), ssh(1) now immediately sends its SSH protocol banner to the server without waiting to receive the server's banner, saving time when connecting. * ssh(1): Added ~v and ~V escape sequences to raise and lower the logging level respectively. * ssh(1): Made the escape command help (~?) context sensitive so that only commands that will work in the current session are shown. * ssh-keygen(1): When deleting host lines from known_hosts using "ssh-keygen -R host", ssh-keygen(1) now prints details of which lines were removed. Bugfixes: * ssh(1): Force a clean shutdown of ControlMaster client sessions when the ~. escape sequence is used. This means that ~. should now work in mux clients even if the server is no longer responding. * ssh(1): Correctly detect errors during local TCP forward setup in multiplexed clients. bz#2055 * ssh-add(1): Made deleting explicit keys "ssh-add -d" symmetric with adding keys with respect to certificates. It now tries to delete the corresponding certificate and respects the -k option to allow deleting of the key only. * sftp(1): Fix a number of parsing and command-editing bugs, including bz#1956 * ssh(1): When muxmaster is run with -N, ensured that it shuts down gracefully when a client sends it "-O stop" rather than hanging around. bz#1985 * ssh-keygen(1): When screening moduli candidates, append to the file rather than overwriting to allow resumption. bz#1957 * ssh(1): Record "Received disconnect" messages at ERROR rather than INFO priority. bz#2057. * ssh(1): Loudly warn if explicitly-provided private key is unreadable. bz#1981 Portable OpenSSH: * sshd(8): The Linux seccomp-filter sandbox is now supported on ARM platforms where the kernel supports it. * sshd(8): The seccomp-filter sandbox will not be enabled if the system headers support it at compile time, regardless of whether it can be enabled then. If the run-time system does not support seccomp-filter, sshd will fall back to the rlimit pseudo-sandbox. * ssh(1): Don't link in the Kerberos libraries. They aren't necessary on the client, just on sshd(8). bz#2072 * Fix GSSAPI linking on Solaris, which uses a differently-named GSSAPI library. bz#2073 * Fix compilation on systems with openssl-1.0.0-fips. * Fix a number of errors in the RPM spec files. Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From imorgan at nas.nasa.gov Wed Feb 27 10:43:47 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 26 Feb 2013 15:43:47 -0800 Subject: Call for testing: OpenSSH-6.2 In-Reply-To: References: Message-ID: <20130226234346.GK3584@linux124.nas.nasa.gov> On Tue, Feb 26, 2013 at 16:09:29 -0600, Damien Miller wrote: > Hi, > > It's that time again... > > OpenSSH 6.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains > some substantial new features and a number of bugfixes. > Hi Damien, One minor nit; the version numbers in contrib/{caldera,redhat,suse}/openssh.spec need to be cranked up to 6.2p1. -- Iain Morgan From djm at mindrot.org Wed Feb 27 10:48:52 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Feb 2013 10:48:52 +1100 (EST) Subject: Call for testing: OpenSSH-6.2 In-Reply-To: <20130226234346.GK3584@linux124.nas.nasa.gov> References: <20130226234346.GK3584@linux124.nas.nasa.gov> Message-ID: On Tue, 26 Feb 2013, Iain Morgan wrote: > On Tue, Feb 26, 2013 at 16:09:29 -0600, Damien Miller wrote: > > Hi, > > > > It's that time again... > > > > OpenSSH 6.2 is almost ready for release, so we would appreciate testing > > on as many platforms and systems as possible. This release contains > > some substantial new features and a number of bugfixes. > > > > Hi Damien, > > One minor nit; the version numbers in > contrib/{caldera,redhat,suse}/openssh.spec need to be cranked up to > 6.2p1. Done. I usually do this just before I make the release, but there is no harm in doing it now. -d From imorgan at nas.nasa.gov Wed Feb 27 13:22:13 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 26 Feb 2013 18:22:13 -0800 Subject: Call for testing: OpenSSH-6.2 In-Reply-To: References: Message-ID: <20130227022213.GL3584@linux124.nas.nasa.gov> On Tue, Feb 26, 2013 at 16:09:29 -0600, Damien Miller wrote: > Hi, > > It's that time again... > > OpenSSH 6.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains > some substantial new features and a number of bugfixes. > The 20130227 snaphsot builds and tests OK for the following platforms: RHEL 6.4/x86_64, OpenSSL 1.0.0-fips RHEL 6.4/x86_64, OpenSSL 1.0.1e SLES 11SP1/x86_64, OpenSSL 1.0.1c Mac OS X 10.7.5, OpenSSL 0.9.8r -- Iain Morgan From jdvf at optonline.net Wed Feb 27 14:21:12 2013 From: jdvf at optonline.net (John Devitofranceschi) Date: Tue, 26 Feb 2013 22:21:12 -0500 Subject: Call for testing: OpenSSH-6.2 In-Reply-To: References: Message-ID: <264D863E-F25E-40B7-84C5-7BC84D7EFF4B@optonline.net> On Feb 26, 2013, at 5:09 PM, Damien Miller wrote: > Hi, > > It's that time again... > > OpenSSH 6.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains > some substantial new features and a number of bugfixes. > For OpenSSH_6.2p1-snap20130227 all tests passed on: Mac OS X 10.8.2, OpenSSL 0.9.8r Fedora 18, OpenSSL 1.0.1c-fips jd From vinschen at redhat.com Wed Feb 27 20:57:35 2013 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 27 Feb 2013 10:57:35 +0100 Subject: Call for testing: OpenSSH-6.2 In-Reply-To: References: Message-ID: <20130227095735.GE13185@calimero.vinschen.de> On Feb 27 09:09, Damien Miller wrote: > Hi, > > It's that time again... > > OpenSSH 6.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains > some substantial new features and a number of bugfixes. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > The OpenBSD version is available in CVS HEAD: > http://www.openbsd.org/anoncvs.html > > Portable OpenSSH is also available via anonymous CVS using the > instructions at http://www.openssh.com/portable.html#cvs or > via Mercurial at http://hg.mindrot.org/openssh > > Running the regression tests supplied with Portable OpenSSH does not > require installation and is a simply: > > $ ./configure && make tests Builds fine and all tests pass on Cygwin 1.7.18(*) w/ OpenSSL 1.0.1e. Corinna (*) Upcoming release. -- Corinna Vinschen Cygwin Maintainer Red Hat From fredports at mufley.com Wed Feb 27 20:56:44 2013 From: fredports at mufley.com (Frederico Costa) Date: Wed, 27 Feb 2013 09:56:44 +0000 Subject: Call for testing: OpenSSH-6.2 In-Reply-To: <264D863E-F25E-40B7-84C5-7BC84D7EFF4B@optonline.net> References: <264D863E-F25E-40B7-84C5-7BC84D7EFF4B@optonline.net> Message-ID: <2c191c5dfc55b9734145b89ed2411810@www.mufley.com> Hi.... Used OpenSSH_6.2p1-snap20130227 and in my 2 systems based on FreeBSD 9.1-RELEASE-p1 and OpenSSL 1.0.1e: 1. Intel(R) Core(TM)2 Duo CPU E6550 All tests passed 2. 2x Dual-Core AMD Opteron(tm) Processor 2216 All tests passed Fred On 2013-02-27 03:21, John Devitofranceschi wrote: > On Feb 26, 2013, at 5:09 PM, Damien Miller wrote: > >> Hi, >> >> It's that time again... >> >> OpenSSH 6.2 is almost ready for release, so we would appreciate >> testing >> on as many platforms and systems as possible. This release contains >> some substantial new features and a number of bugfixes. >> > > > For OpenSSH_6.2p1-snap20130227 all tests passed on: > > Mac OS X 10.8.2, OpenSSL 0.9.8r > Fedora 18, OpenSSL 1.0.1c-fips > > jd > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From guly at luv.guly.org Thu Feb 28 01:04:05 2013 From: guly at luv.guly.org (Sandro guly Zaccarini) Date: Wed, 27 Feb 2013 15:04:05 +0100 Subject: openssh tunnel log info Message-ID: <20130227140405.GC1328@shivaya.guly.org> hi list, i'm currently working on audit for some servers that also act as proxy using ssh tunnel feature and i noticed that tunnel connections don't log very much information. googling i've found an old patch from rootshell[1] which seems to work for latest release. do you think this can be merged to mainstream release? thanks [1] http://blog.rootshell.be/2009/03/01/keep-an-eye-on-ssh-forwarding/ sz -- /"\ taste your favourite IT consultant \ / gpg: http://www.guly.org/guly.asc X / \ From peter at stuge.se Thu Feb 28 02:42:34 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 27 Feb 2013 16:42:34 +0100 Subject: Call for testing: OpenSSH-6.2 In-Reply-To: References: Message-ID: <20130227154234.6437.qmail@stuge.se> Damien Miller wrote: > $ ./configure && make tests Warnings on Gentoo Linux x86_64 gcc-4.7.2 in 20130228 snapshot build: krl.c: In function 'choose_next_state': krl.c:507:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'u_int64_t' [-Wformat] krl.c:507:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'u_int64_t' [-Wformat] krl.c:507:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 5 has type 'u_int64_t' [-Wformat] krl.c:507:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 7 has type 'u_int64_t' [-Wformat] krl.c:507:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'u_int64_t' [-Wformat] krl.c:507:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 9 has type 'u_int64_t' [-Wformat] krl.c:507:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 10 has type 'u_int64_t' [-Wformat] krl.c: In function 'revoked_certs_generate': krl.c:542:7: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'u_int64_t' [-Wformat] krl.c:542:7: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'u_int64_t' [-Wformat] krl.c: In function 'ssh_krl_from_blob': krl.c:932:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 2 has type 'u_int64_t' [-Wformat] This one for every single file: :0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default] bsd-arc4random.c:1:0: note: this is the location of the previous definition Additionally, during plain make: auth2-chall.c: In function 'auth2_challenge_start': auth2-chall.c:172:22: warning: array subscript is above array bounds [-Warray-bounds] line 64: KbdintDevice *devices[] = { line 172: for (i = 0; devices[i]; i++) This from make tests: regress/modpipe.c: In function 'parse_modification': regress/modpipe.c:81:6: warning: format '%lli' expects argument of type 'long long int *', but argument 4 has type 'u_int64_t *' [-Wformat] And a failed test, run as regular user: run test agent.sh ... Permission denied. agent fwd proto 1 failed (exit code 0) Permission denied (publickey,password,keyboard-interactive). agent fwd proto 2 failed (exit code 0) failed simple agent test make[1]: *** [t-exec] Error 1 I ran make clean, make, and make tests separately, the test fails again, though slightly less verbosely: run test agent.sh ... Permission denied. Permission denied (publickey,password,keyboard-interactive). make[1]: *** [t-exec] Error 1 Running the test manually with -x as such: cd regress && \ export TEST_SHELL=sh && \ export TEST_ENV=MALLOC_OPTIONS=AFGJPRX && \ export TEST_SSH_SSH=/tmp/openssh/ssh && \ export TEST_SSH_SSHD=/tmp/openssh/sshd && \ export TEST_SSH_SSHADD=/tmp/openssh/ssh-add && \ export TEST_SSH_SSHAGENT=/tmp/openssh/ssh-agent && \ sh -x $(pwd)/test-exec.sh $(pwd) $(pwd)/agent.sh Gives: ++ trace 'agent forwarding' ++ echo 'trace: agent forwarding' ++ '[' X = Xyes ']' ++ for p in 1 2 ++ /tmp/openssh/ssh -A -1 -F /tmp/openssh/regress/ssh_proxy somehost ssh-add -l ++ '[' 0 -ne 0 ']' ++ /tmp/openssh/ssh -A -1 -F /tmp/openssh/regress/ssh_proxy somehost '/tmp/openssh/ssh -1 -F /tmp/openssh/regress/ssh_proxy somehost exit 51' Permission denied. ++ '[' 255 -ne 51 ']' ++ fail 'agent fwd proto 1 failed (exit code 0)' ++ echo 'FAIL: agent fwd proto 1 failed (exit code 0)' ++ RESULT=1 ++ echo 'agent fwd proto 1 failed (exit code 0)' agent fwd proto 1 failed (exit code 0) ++ for p in 1 2 ++ /tmp/openssh/ssh -A -2 -F /tmp/openssh/regress/ssh_proxy somehost ssh-add -l ++ '[' 0 -ne 0 ']' ++ /tmp/openssh/ssh -A -2 -F /tmp/openssh/regress/ssh_proxy somehost '/tmp/openssh/ssh -2 -F /tmp/openssh/regress/ssh_proxy somehost exit 52' Permission denied (publickey,password,keyboard-interactive). ++ '[' 255 -ne 52 ']' ++ fail 'agent fwd proto 2 failed (exit code 0)' ++ echo 'FAIL: agent fwd proto 2 failed (exit code 0)' ++ RESULT=1 ++ echo 'agent fwd proto 2 failed (exit code 0)' agent fwd proto 2 failed (exit code 0) Running: $ unset SSH_AGENT_PID SSH_AUTH_SOCK makes no difference. //Peter From andyb1 at andy-t.org Thu Feb 28 04:04:39 2013 From: andyb1 at andy-t.org (Andy Tsouladze) Date: Wed, 27 Feb 2013 11:04:39 -0600 (CST) Subject: Call for testing: OpenSSH-6.2 In-Reply-To: References: Message-ID: openssh-SNAP-20130228.tar.gz builds cleanly, with all tests passed on: Slackware-14.0 64-bit (gcc-4.7.1, openssl-1.0.1c) Slackware-13.0 32-bit (gcc-4.3.3, openssl-0.9.8k) Regards, Andy On Wed, 27 Feb 2013, Damien Miller wrote: > Hi, > > It's that time again... > > OpenSSH 6.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains > some substantial new features and a number of bugfixes. > > Snapshot releases for portable OpenSSH are available from > http://www.mindrot.org/openssh_snap/ > > The OpenBSD version is available in CVS HEAD: > http://www.openbsd.org/anoncvs.html > > Portable OpenSSH is also available via anonymous CVS using the > instructions at http://www.openssh.com/portable.html#cvs or > via Mercurial at http://hg.mindrot.org/openssh > > Running the regression tests supplied with Portable OpenSSH does not > require installation and is a simply: > > $ ./configure && make tests > > Live testing on suitable non-production systems is also > appreciated. Please send reports of success or failure to > openssh-unix-dev at mindrot.org. > > Below is a summary of changes. More detail may be found in the ChangeLog > in the portable OpenSSH tarballs. > > Thanks to the many people who contributed to this release. > > Changes since OpenSSH 6.1 > ========================= > > Features: > > * ssh(1)/sshd(8): Added support for AES-GCM authenticated encryption in > SSH protocol 2. The new cipher is available as aes128-gcm at openssh.com > and aes256-gcm at openssh.com. It uses an identical packet format to the > AES-GCM mode specified in RFC 5647, but uses simpler and different > selection rules during key exchange. > > * ssh(1)/sshd(8): Added support for encrypt-then-mac (EtM) MAC modes > for SSH protocol 2. These modes alter the packet format and compute > the MAC over the packet length and encrypted packet rather than over > the plaintext data. These modes are considered more secure and are > used by default when available. > > * ssh(1)/sshd(8): Added support for the UMAC-128 MAC as > "umac-128 at openssh.com" and "umac-128-etm at openssh.com". The latter > being an encrypt-then-mac mode. > > * sshd(8): Added support for multiple required authentication in SSH > protocol 2 via an AuthenticationMethods option. This option lists > one or more comma-separated lists of authentication method names. > Successful completion of all the methods in any list is required for > authentication to complete. This allows, for example, requiring a > user having to authenticate via public key or GSSAPI before they > are offered password authentication. > > * sshd(8)/ssh-keygen(1): Added support for Key Revocation Lists > (KRLs), a compact binary format to represent lists of revoked keys > and certificates that take as little as one bit per certificate when > revoking by serial number. KRLs may be generated using ssh-keygen(1) > and are loaded into sshd(8) via the existing RevokedKeys sshd_config > option. > > * ssh(1): IdentitiesOnly now applies to keys obtained from a > PKCS11Provider. This allows control of which keys are offered from > tokens using IdentityFile. > > * sshd(8): sshd_config(5)'s AllowTcpForwarding now accepts "local" > and "remote" in addition to its previous "yes"/"no" keywords to allow > the server to specify whether just local or remote TCP forwarding is > enabled. > > * sshd(8): Added a sshd_config(5) option AuthorizedKeysCommand to > support fetching authorized_keys from a command in addition to (or > instead of) from the filesystem. The command is run under an account > specified by an AuthorizedKeysCommandUser sshd_config(5) option. > > * sftp-server(8): Now supports a -d option to allow the starting > directory to be something other than the user's home directory. > > * ssh-keygen(1): Now allows fingerprinting of keys hosted in PKCS#11 > tokens using "ssh-keygen -lD pkcs11_provider". > > * ssh(1): When SSH protocol 2 only is selected (the default), ssh(1) > now immediately sends its SSH protocol banner to the server without > waiting to receive the server's banner, saving time when connecting. > > * ssh(1): Added ~v and ~V escape sequences to raise and lower the > logging level respectively. > > * ssh(1): Made the escape command help (~?) context sensitive so that > only commands that will work in the current session are shown. > > * ssh-keygen(1): When deleting host lines from known_hosts using > "ssh-keygen -R host", ssh-keygen(1) now prints details of which lines > were removed. > > Bugfixes: > > * ssh(1): Force a clean shutdown of ControlMaster client sessions when > the ~. escape sequence is used. This means that ~. should now work in > mux clients even if the server is no longer responding. > > * ssh(1): Correctly detect errors during local TCP forward setup in > multiplexed clients. bz#2055 > > * ssh-add(1): Made deleting explicit keys "ssh-add -d" symmetric with > adding keys with respect to certificates. It now tries to delete the > corresponding certificate and respects the -k option to allow deleting > of the key only. > > * sftp(1): Fix a number of parsing and command-editing bugs, including > bz#1956 > > * ssh(1): When muxmaster is run with -N, ensured that it shuts down > gracefully when a client sends it "-O stop" rather than hanging around. > bz#1985 > > * ssh-keygen(1): When screening moduli candidates, append to the file > rather than overwriting to allow resumption. bz#1957 > > * ssh(1): Record "Received disconnect" messages at ERROR rather than > INFO priority. bz#2057. > > * ssh(1): Loudly warn if explicitly-provided private key is unreadable. > bz#1981 > > Portable OpenSSH: > > * sshd(8): The Linux seccomp-filter sandbox is now supported on ARM > platforms where the kernel supports it. > > * sshd(8): The seccomp-filter sandbox will not be enabled if the system > headers support it at compile time, regardless of whether it can be > enabled then. If the run-time system does not support seccomp-filter, > sshd will fall back to the rlimit pseudo-sandbox. > > * ssh(1): Don't link in the Kerberos libraries. They aren't necessary > on the client, just on sshd(8). bz#2072 > > * Fix GSSAPI linking on Solaris, which uses a differently-named GSSAPI > library. bz#2073 > > * Fix compilation on systems with openssl-1.0.0-fips. > > * Fix a number of errors in the RPM spec files. > > Reporting Bugs: > =============== > > - Please read http://www.openssh.com/report.html > Security bugs should be reported directly to openssh at openssh.com > > OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, > Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and > Ben Lindstrom. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > Dr Andy Tsouladze Sr Unix/Storage SysAdmin From dtucker at zip.com.au Thu Feb 28 12:17:34 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 28 Feb 2013 12:17:34 +1100 Subject: Call for testing: OpenSSH-6.2 In-Reply-To: <20130227154234.6437.qmail@stuge.se> References: <20130227154234.6437.qmail@stuge.se> Message-ID: <20130228011734.GA12811@gate.dtucker.net> On Wed, Feb 27, 2013 at 04:42:34PM +0100, Peter Stuge wrote: [...] thanks, I'll take a look at the warnings, but first a suggestion. > And a failed test, run as regular user: > > run test agent.sh ... > Permission denied. My guess is that running it with a world-writeable parent directory (/tmp) is falling foul of one of the permission checks. Can you try it in another directory? as an aside: I know debugging test failures is a pain. I'm planning some logging changes that should make it a lot easier in most cases, however it needs some changes to ssh and sshd and it's too close to release for those right now. -- 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 Thu Feb 28 13:51:15 2013 From: peter at stuge.se (Peter Stuge) Date: Thu, 28 Feb 2013 03:51:15 +0100 Subject: Call for testing: OpenSSH-6.2 In-Reply-To: <20130228011734.GA12811@gate.dtucker.net> References: <20130227154234.6437.qmail@stuge.se> <20130228011734.GA12811@gate.dtucker.net> Message-ID: <20130228025115.29895.qmail@stuge.se> Darren Tucker wrote: > > And a failed test, run as regular user: > > > > run test agent.sh ... > > Permission denied. > > My guess is that running it with a world-writeable parent directory > (/tmp) is falling foul of one of the permission checks. Can you try it > in another directory? Same thing under the home directory. //Peter From dtucker at zip.com.au Thu Feb 28 14:44:44 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 28 Feb 2013 14:44:44 +1100 Subject: Call for testing: OpenSSH-6.2 In-Reply-To: <20130228025115.29895.qmail@stuge.se> References: <20130227154234.6437.qmail@stuge.se> <20130228011734.GA12811@gate.dtucker.net> <20130228025115.29895.qmail@stuge.se> Message-ID: <20130228034444.GA26256@gate.dtucker.net> On Thu, Feb 28, 2013 at 03:51:15AM +0100, Peter Stuge wrote: > Darren Tucker wrote: > > > And a failed test, run as regular user: > > > > > > run test agent.sh ... > > > Permission denied. > > > > My guess is that running it with a world-writeable parent directory > > (/tmp) is falling foul of one of the permission checks. Can you try it > > in another directory? > > Same thing under the home directory. Hm. What I normally do is stick "set -x" at the top of test-exec.sh, "exit 1" at the end of the "fail" function, then re-run the failing ssh command with -vvv. In the example you posted, that'd be something like /tmp/openssh/ssh -vvv -A -1 -F /tmp/openssh/regress/ssh_proxy somehost '/tmp/openssh/ssh -1 -F /tmp/openssh/regress/ssh_proxy somehost exit 51 (the "exit 1" in fail() causes it to exit leaving the keys all set up). -- 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 cjwatson at debian.org Thu Feb 28 21:02:59 2013 From: cjwatson at debian.org (Colin Watson) Date: Thu, 28 Feb 2013 10:02:59 +0000 (GMT) Subject: Call for testing: OpenSSH-6.2 In-Reply-To: Message-ID: <20130228100259.DC1663E4041@sarantium.pelham.vpn.ucam.org> Damien Miller wrote: >OpenSSH 6.2 is almost ready for release, so we would appreciate testing >on as many platforms and systems as possible. This release contains >some substantial new features and a number of bugfixes. [...] >$ ./configure && make tests On Ubuntu raring with Linux 3.8-rc6 and OpenSSL 1.0.1c, this builds fine but I get this test failure: run test connect-privsep.sh ... Connection closed by UNKNOWN WARNING: ssh privsep/sandbox+proxyconnect protocol 1 failed Connection closed by UNKNOWN WARNING: ssh privsep/sandbox+proxyconnect protocol 2 failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt '' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt '' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'A' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'A' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'F' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'F' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'G' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'G' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'H' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'H' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'J' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'J' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'P' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'P' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'R' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'R' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'S' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'S' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'X' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'X' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt 'Z' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt 'Z' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt '<' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt '<' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 1 mopt '>' failed Connection closed by UNKNOWN ssh privsep/sandbox+proxyconnect protocol 2 mopt '>' failed failed proxy connect with privsep Advice welcome on how to debug this. -- Colin Watson [cjwatson at debian.org] From phil at hands.com Thu Feb 28 22:32:01 2013 From: phil at hands.com (Philip Hands) Date: Thu, 28 Feb 2013 11:32:01 +0000 Subject: Call for testing: OpenSSH-6.2 In-Reply-To: References: Message-ID: <874ngwisi6.fsf@poker.hands.com> Damien Miller writes: > Hi, > > It's that time again... > > OpenSSH 6.2 is almost ready for release, so we would appreciate testing > on as many platforms and systems as possible. This release contains > some substantial new features and a number of bugfixes. Hi, I'd hoped to see the new version of ssh-copy-id included in 6.2, particularly given that the associated bug is tagged as blocking V_6_2 https://bugzilla.mindrot.org/show_bug.cgi?id=1980 is the fact that it's not in yet an oversight, or were you still waiting on me to do something before you're ready to include it? As mentioned in my last comment on that bug, I added the -o option 12 days ago, so the version to use would be available here: http://git.hands.com/ssh-copy-id =-=-=- BTW if anyone's got access to systems with particularly ancient or deranged shells, where they would realistically like to run this script, then bug reports telling me that there are still people using shells that don't understand $(...) and/or ${FOO:+BAR}, for instance, would be interesting -- although if the machine in question is going to get powered up for the first time this millennium in order to do the test, then I'm less interested. ;-) Please grab a copy of the script from here, and give it a go: http://git.hands.com/ssh-copy-id?p=ssh-copy-id.git;a=blob_plain;f=ssh-copy-id;hb=HEAD the man page is here -- proof reading would be welcome: http://git.hands.com/ssh-copy-id?p=ssh-copy-id.git;a=blob_plain;f=ssh-copy-id.1;hb=HEAD (of course I just found a couple of things to tweak on the man page :-) ) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From djm at mindrot.org Thu Feb 28 23:37:06 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 28 Feb 2013 23:37:06 +1100 (EST) Subject: Call for testing: OpenSSH-6.2 In-Reply-To: <20130228100259.DC1663E4041@sarantium.pelham.vpn.ucam.org> References: <20130228100259.DC1663E4041@sarantium.pelham.vpn.ucam.org> Message-ID: On Thu, 28 Feb 2013, Colin Watson wrote: > Damien Miller wrote: > >OpenSSH 6.2 is almost ready for release, so we would appreciate testing > >on as many platforms and systems as possible. This release contains > >some substantial new features and a number of bugfixes. > [...] > >$ ./configure && make tests > > On Ubuntu raring with Linux 3.8-rc6 and OpenSSL 1.0.1c, this builds fine > but I get this test failure: > > run test connect-privsep.sh ... > Connection closed by UNKNOWN > WARNING: ssh privsep/sandbox+proxyconnect protocol 1 failed > Connection closed by UNKNOWN > WARNING: ssh privsep/sandbox+proxyconnect protocol 2 failed Please rerun the failed test with: make tests LTESTS=connect-privsep TEST_SSH_LOGFILE=/tmp/regress.log If /tmp/regress.log doesn't shed any light, then edit regress/test-exec.sh to change the sshd_config LogLevel to debug3 and/or follow the instructions at the top of sandbox-seccomp-filter.c to enable sandbox debugging. -d