From rogan at dawes.za.net Tue May 3 21:48:28 2016 From: rogan at dawes.za.net (Rogan Dawes) Date: Tue, 03 May 2016 11:48:28 +0000 Subject: StreamLocal forwarding In-Reply-To: References: Message-ID: Hi folks, Can nobody help me to figure out why this is not working? I'd like to think that I have given it a good attempt at figuring it out for myself, but everything I see says my configuration *should* be working. Many thanks! Rogan On Sat, Apr 23, 2016 at 9:07 PM Rogan Dawes wrote: > Hi folks, > > (3rd time I am sending this message, none of the other appear to have > made it through!) > > Using "OpenSSH_6.9p1 Ubuntu-2ubuntu0.1, OpenSSL 1.0.2d 9 Jul 2015" on > the server, "OpenSSH_7.2p2, OpenSSL 1.0.2g 1 Mar 2016" on the client. > > I am trying to use sshtunnel with StreamLocal forwarding to enable me > to connect back to the client's ssh port, without having to arbitrate > ports between clients. > > The idea is to configure the server to allow StreamLocalForwarding via > a unique Unix socket on the host, that relays back to the client. > > i.e. on the client (named gateway for this example, but will be unique > once deployed in volume): > > /usr/bin/ssh -o CheckHostIP=yes -o LogLevel=INFO -o > ServerAliveCountMax=3 -o ServerAliveInterval=5 -o > StrictHostKeyChecking=yes -o TCPKeepAlive=yes -o > StreamLocalBindUnlink=yes -o ExitOnForwardFailure=yes -o BatchMode=yes > -nN -R /sshvpn/gateway:127.0.0.1:22 -p 52221 sshvpn at host > > On the server: > > Match User sshvpn > ChrootDirectory /var/sshvpn/ > AllowTCPForwarding no > AllowStreamLocalForwarding yes > StreamLocalBindUnlink yes > > Then to connect to the client: > > $ ssh -o ProxyCommand='socat /var/sshvpn/sshvpn/gateway' root at gateway > > So, it works fine the first time, when the socket does not exist. Once > the connection terminates, and the client attempts to log in again, it > fails because the socket already exists: > > debug1: user sshvpn matched 'User sshvpn' at line 89 > debug3: match found > debug3: reprocess config:90 setting ChrootDirectory /var/sshvpn/ > debug3: reprocess config:91 setting AllowTCPForwarding no > debug3: reprocess config:92 setting AllowStreamLocalForwarding yes > debug3: reprocess config:93 setting StreamLocalBindUnlink yes > [...snip...] > debug1: server_input_global_request: rtype > streamlocal-forward at openssh.com want_reply 1 > debug1: server_input_global_request: streamlocal-forward listen path > /sshvpn/gateway > debug3: channel_setup_fwd_listener_streamlocal: type 19 path > /sshvpn/gateway > bind: Address already in use > unix_listener: cannot bind to path: /sshvpn/gateway > > I am aware of the StreamLocalBindUnlink option, and you can see that > it is set on both the client and the server, but it doesn't seem to be > effective. > > I also ran it under ltrace, and got the following: > > 24079 write(2, "debug3: channel_setup_fwd_listen"..., 78) = 78 > 24079 umask(0177) = 02 > 24079 socket(1, 1, 0) = 8 > 24079 bind(8, 0x7ffc4f8915c0, 110, -1) = -1 > 24079 __errno_location() = 0x7f03f55a5710 > 24079 strerror(98) = "Address > already in use" > > From this, it appears that there is no attempt to unlink the socket if > it already exists, as would be expected from this code > ( > https://github.com/openssh/openssh-portable/blob/7de4b03a6e4071d454b72927ffaf52949fa34545/misc.c#L1083 > ): > > sock = socket(PF_UNIX, SOCK_STREAM, 0); > if (sock < 0) { > saved_errno = errno; > error("socket: %.100s", strerror(errno)); > errno = saved_errno; > return -1; > } > if (unlink_first == 1) { > if (unlink(path) != 0 && errno != ENOENT) > error("unlink(%s): %.100s", path, strerror(errno)); > } > if (bind(sock, (struct sockaddr *)&sunaddr, sizeof(sunaddr)) < 0) { > saved_errno = errno; > error("bind: %.100s", strerror(errno)); > close(sock); > error("%s: cannot bind to path: %s", __func__, path); > errno = saved_errno; > return -1; > } > > What am I missing? > > Rogan > From djm at mindrot.org Tue May 3 22:21:25 2016 From: djm at mindrot.org (Damien Miller) Date: Tue, 3 May 2016 22:21:25 +1000 (AEST) Subject: StreamLocal forwarding In-Reply-To: References: Message-ID: Hi, The code definitely attempts to unlink any old listener beforehand (see misc.c:unix_listener()) so I don't understand why that isn't being called. You might try simulating your configuration using sshd's -T and -C to make sure the flag is correctly being set. Could chroot be interfering? Some platforms implement additional restrictions on devices and sockets inside chroot. -d On Tue, 3 May 2016, Rogan Dawes wrote: > Hi folks, > > Can nobody help me to figure out why this is not working? I'd like to think > that I have given it a good attempt at figuring it out for myself, but > everything I see says my configuration *should* be working. > > Many thanks! > > Rogan > > > On Sat, Apr 23, 2016 at 9:07 PM Rogan Dawes wrote: > > > Hi folks, > > > > (3rd time I am sending this message, none of the other appear to have > > made it through!) > > > > Using "OpenSSH_6.9p1 Ubuntu-2ubuntu0.1, OpenSSL 1.0.2d 9 Jul 2015" on > > the server, "OpenSSH_7.2p2, OpenSSL 1.0.2g 1 Mar 2016" on the client. > > > > I am trying to use sshtunnel with StreamLocal forwarding to enable me > > to connect back to the client's ssh port, without having to arbitrate > > ports between clients. > > > > The idea is to configure the server to allow StreamLocalForwarding via > > a unique Unix socket on the host, that relays back to the client. > > > > i.e. on the client (named gateway for this example, but will be unique > > once deployed in volume): > > > > /usr/bin/ssh -o CheckHostIP=yes -o LogLevel=INFO -o > > ServerAliveCountMax=3 -o ServerAliveInterval=5 -o > > StrictHostKeyChecking=yes -o TCPKeepAlive=yes -o > > StreamLocalBindUnlink=yes -o ExitOnForwardFailure=yes -o BatchMode=yes > > -nN -R /sshvpn/gateway:127.0.0.1:22 -p 52221 sshvpn at host > > > > On the server: > > > > Match User sshvpn > > ChrootDirectory /var/sshvpn/ > > AllowTCPForwarding no > > AllowStreamLocalForwarding yes > > StreamLocalBindUnlink yes > > > > Then to connect to the client: > > > > $ ssh -o ProxyCommand='socat /var/sshvpn/sshvpn/gateway' root at gateway > > > > So, it works fine the first time, when the socket does not exist. Once > > the connection terminates, and the client attempts to log in again, it > > fails because the socket already exists: > > > > debug1: user sshvpn matched 'User sshvpn' at line 89 > > debug3: match found > > debug3: reprocess config:90 setting ChrootDirectory /var/sshvpn/ > > debug3: reprocess config:91 setting AllowTCPForwarding no > > debug3: reprocess config:92 setting AllowStreamLocalForwarding yes > > debug3: reprocess config:93 setting StreamLocalBindUnlink yes > > [...snip...] > > debug1: server_input_global_request: rtype > > streamlocal-forward at openssh.com want_reply 1 > > debug1: server_input_global_request: streamlocal-forward listen path > > /sshvpn/gateway > > debug3: channel_setup_fwd_listener_streamlocal: type 19 path > > /sshvpn/gateway > > bind: Address already in use > > unix_listener: cannot bind to path: /sshvpn/gateway > > > > I am aware of the StreamLocalBindUnlink option, and you can see that > > it is set on both the client and the server, but it doesn't seem to be > > effective. > > > > I also ran it under ltrace, and got the following: > > > > 24079 write(2, "debug3: channel_setup_fwd_listen"..., 78) = 78 > > 24079 umask(0177) = 02 > > 24079 socket(1, 1, 0) = 8 > > 24079 bind(8, 0x7ffc4f8915c0, 110, -1) = -1 > > 24079 __errno_location() = 0x7f03f55a5710 > > 24079 strerror(98) = "Address > > already in use" > > > > From this, it appears that there is no attempt to unlink the socket if > > it already exists, as would be expected from this code > > ( > > https://github.com/openssh/openssh-portable/blob/7de4b03a6e4071d454b72927ffaf52949fa34545/misc.c#L1083 > > ): > > > > sock = socket(PF_UNIX, SOCK_STREAM, 0); > > if (sock < 0) { > > saved_errno = errno; > > error("socket: %.100s", strerror(errno)); > > errno = saved_errno; > > return -1; > > } > > if (unlink_first == 1) { > > if (unlink(path) != 0 && errno != ENOENT) > > error("unlink(%s): %.100s", path, strerror(errno)); > > } > > if (bind(sock, (struct sockaddr *)&sunaddr, sizeof(sunaddr)) < 0) { > > saved_errno = errno; > > error("bind: %.100s", strerror(errno)); > > close(sock); > > error("%s: cannot bind to path: %s", __func__, path); > > errno = saved_errno; > > return -1; > > } > > > > What am I missing? > > > > Rogan > > > _______________________________________________ > 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 Tue May 3 22:33:29 2016 From: djm at mindrot.org (Damien Miller) Date: Tue, 3 May 2016 22:33:29 +1000 (AEST) Subject: An update on SSH protocol 1 Message-ID: Hi, At this stage, we're most of the way towards fully deprecating SSH protocol 1 - this outlines our plans to complete this task. We've had this old protocol in various stages of deprecation for almost 10 years and it has been compile-time disabled for about a year. Downstream vendors, to their credit, have included this change in recent OS releases by shipping OpenSSH packages that disable protocol 1 by default and/or offering separate, non-default packages to enable it. This seems to have proceeded far more smootly than even my most optimisitic hopes, so this gives us greater confidence that we can complete the removal of protocol 1 soon. We want to do this partly to hasten the demise of this cryptographic trainwreck, but also because doing so removes a lot of legacy code from OpenSSH that inflates our attack surface. Having it gone will make our jobs quite a bit easier as we maintain and refactor. So here are our plans. Dates are estimates only. * June 2016 Release OpenSSH 7.3. SSH protocol 1 is unchanged. We start mention these plans in the release notes to give them wider publicity. * August 2016 Release OpenSSH 7.4. Server-side support for SSHv1 is removed from our codebase. Client support remains disabled by default. * June 2017 OpenSSH removes all SSH protocol 1 support. -- So this is just over a year of notice ahead of final deprecation. After we release OpenSSH without SSHv1 support, users who absolutely need it would have to use a prior version of OpenSSH or some other implementation. We recognise that this may leave some users without a supported client for their protocol v1 hosts, but we feel that >10 years of transition is time enough. Feedback is welcome. Cheers, Damien Miller (on behalf of the team) From cjwatson at debian.org Wed May 4 00:09:22 2016 From: cjwatson at debian.org (Colin Watson) Date: Tue, 3 May 2016 15:09:22 +0100 Subject: An update on SSH protocol 1 In-Reply-To: References: Message-ID: <20160503140922.GA9034@riva.ucam.org> On Tue, May 03, 2016 at 10:33:29PM +1000, Damien Miller wrote: > We've had this old protocol in various stages of deprecation for almost > 10 years and it has been compile-time disabled for about a year. > Downstream vendors, to their credit, have included this change in recent > OS releases by shipping OpenSSH packages that disable protocol 1 by > default and/or offering separate, non-default packages to enable it. Debian takes the latter approach. Specifically, we have an "openssh-client-ssh1" binary package that includes only scp1, ssh1, and ssh-keygen1 binaries; we do not ship any server-side SSHv1 support. I modelled this on Fedora's approach, which is basically the same aside from a slightly different package name. A number of our users are basically stuck needing to interoperate with SSHv1-only servers that they can't update for one reason or another. Obviously this is a pretty broken world, but maybe they're at least behind a VPN or firewalled to the local network or something and at any rate I'm rather glad that none of those things are directly my problem. My plan for Debian (and thus Ubuntu etc.) is therefore that, once SSHv1 is entirely removed from OpenSSH, I will split out the openssh-client-ssh1 binary package to be built from a separate source package which will remain frozen at the last OpenSSH release that supported SSHv1. As before, this will ship only scp1, ssh1, and ssh-keygen1 binaries. If I notice any fixes for client-side vulnerabilities that might affect SSHv1, then I'll backport them on a best-effort basis, but I expect this to be rare. The protocol is sufficiently broken anyway that I'm not going to lose much sleep over it. I've had it suggested to me that I should try to strip it down further (e.g. removing X forwarding capability), but on the whole I think the chances of accidentally breaking something as a result in something I don't myself use outweigh the expected benefits. Any comments on this? Feedback from the changes in 7.0 has convinced me that Debian does need to keep shipping basic client-side support in some form, but it can be very minimal and I'm happy to put whatever dire warnings on it seem useful and appropriate. Notwithstanding all this, the plan of removing all this obsolete code from OpenSSH proper makes a lot of sense to me and I have no complaints there. -- Colin Watson [cjwatson at debian.org] From djm at mindrot.org Wed May 4 00:14:59 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 4 May 2016 00:14:59 +1000 (AEST) Subject: An update on SSH protocol 1 In-Reply-To: <20160503140922.GA9034@riva.ucam.org> References: <20160503140922.GA9034@riva.ucam.org> Message-ID: On Tue, 3 May 2016, Colin Watson wrote: > Debian takes the latter approach. Specifically, we have an > "openssh-client-ssh1" binary package that includes only scp1, ssh1, and > ssh-keygen1 binaries; we do not ship any server-side SSHv1 support. I > modelled this on Fedora's approach, which is basically the same aside > from a slightly different package name. > > A number of our users are basically stuck needing to interoperate with > SSHv1-only servers that they can't update for one reason or another. > Obviously this is a pretty broken world, but maybe they're at least > behind a VPN or firewalled to the local network or something and at any > rate I'm rather glad that none of those things are directly my problem. > > My plan for Debian (and thus Ubuntu etc.) is therefore that, once SSHv1 > is entirely removed from OpenSSH, I will split out the > openssh-client-ssh1 binary package to be built from a separate source > package which will remain frozen at the last OpenSSH release that > supported SSHv1. As before, this will ship only scp1, ssh1, and > ssh-keygen1 binaries. > > If I notice any fixes for client-side vulnerabilities that might affect > SSHv1, then I'll backport them on a best-effort basis, but I expect this > to be rare. The protocol is sufficiently broken anyway that I'm not > going to lose much sleep over it. I've had it suggested to me that I > should try to strip it down further (e.g. removing X forwarding > capability), but on the whole I think the chances of accidentally > breaking something as a result in something I don't myself use outweigh > the expected benefits. > > Any comments on this? Feedback from the changes in 7.0 has convinced me > that Debian does need to keep shipping basic client-side support in some > form, but it can be very minimal and I'm happy to put whatever dire > warnings on it seem useful and appropriate. > > Notwithstanding all this, the plan of removing all this obsolete code > from OpenSSH proper makes a lot of sense to me and I have no complaints > there. Your plan sounds emminently reasonable and I'll repeat my thanks for your helping the transition by making separate -ssh1 packages. -d From rogan at dawes.za.net Wed May 4 01:14:44 2016 From: rogan at dawes.za.net (Rogan Dawes) Date: Tue, 03 May 2016 15:14:44 +0000 Subject: StreamLocal forwarding In-Reply-To: References: Message-ID: Hi Damien, Thanks for the response! I tried moving the StreamLocalBindUnlink directive outside of the Match rule, and it worked. But that doesn't explain why the Match was not correctly setting the directive: This is running on an alternate port with -ddd: debug3: checking match for 'User sshvpn' user sshvpn host 196.209.244.243 addr 196.209.244.243 laddr 176.9.9.247 lport 52221 debug1: user sshvpn matched 'User sshvpn' at line 91 debug3: match found debug3: reprocess config:92 setting ChrootDirectory /var/sshvpn/ debug3: reprocess config:93 setting AllowTCPForwarding no debug3: reprocess config:94 setting AllowStreamLocalForwarding yes debug3: reprocess config:95 setting StreamLocalBindUnlink yes And, surprisingly, even having set the directive outside the Match block, the following command still doesn't show streamlocalbindunlink set: sshd -T -C "user=sshvpn,host=196.209.244.243,addr=196.209.244.243" | grep -i stream streamlocalbindmask 0177 allowstreamlocalforwarding yes That just looks like default settings. Confusing! Anyway, thank you for the help, I now have it working, although I wonder about the other Matched directives. At least I know that the chroot is working! Rogan On Tue, May 3, 2016 at 2:21 PM Damien Miller wrote: > Hi, > > The code definitely attempts to unlink any old listener > beforehand (see misc.c:unix_listener()) so I don't understand why > that isn't being called. You might try simulating your configuration > using sshd's -T and -C to make sure the flag is correctly being set. > > Could chroot be interfering? Some platforms implement additional > restrictions on devices and sockets inside chroot. > > -d > > On Tue, 3 May 2016, Rogan Dawes wrote: > > > Hi folks, > > > > Can nobody help me to figure out why this is not working? I'd like to > think > > that I have given it a good attempt at figuring it out for myself, but > > everything I see says my configuration *should* be working. > > > > Many thanks! > > > > Rogan > > > > > > On Sat, Apr 23, 2016 at 9:07 PM Rogan Dawes wrote: > > > > > Hi folks, > > > > > > (3rd time I am sending this message, none of the other appear to have > > > made it through!) > > > > > > Using "OpenSSH_6.9p1 Ubuntu-2ubuntu0.1, OpenSSL 1.0.2d 9 Jul 2015" on > > > the server, "OpenSSH_7.2p2, OpenSSL 1.0.2g 1 Mar 2016" on the client. > > > > > > I am trying to use sshtunnel with StreamLocal forwarding to enable me > > > to connect back to the client's ssh port, without having to arbitrate > > > ports between clients. > > > > > > The idea is to configure the server to allow StreamLocalForwarding via > > > a unique Unix socket on the host, that relays back to the client. > > > > > > i.e. on the client (named gateway for this example, but will be unique > > > once deployed in volume): > > > > > > /usr/bin/ssh -o CheckHostIP=yes -o LogLevel=INFO -o > > > ServerAliveCountMax=3 -o ServerAliveInterval=5 -o > > > StrictHostKeyChecking=yes -o TCPKeepAlive=yes -o > > > StreamLocalBindUnlink=yes -o ExitOnForwardFailure=yes -o BatchMode=yes > > > -nN -R /sshvpn/gateway:127.0.0.1:22 -p 52221 sshvpn at host > > > > > > On the server: > > > > > > Match User sshvpn > > > ChrootDirectory /var/sshvpn/ > > > AllowTCPForwarding no > > > AllowStreamLocalForwarding yes > > > StreamLocalBindUnlink yes > > > > > > Then to connect to the client: > > > > > > $ ssh -o ProxyCommand='socat /var/sshvpn/sshvpn/gateway' root at gateway > > > > > > So, it works fine the first time, when the socket does not exist. Once > > > the connection terminates, and the client attempts to log in again, it > > > fails because the socket already exists: > > > > > > debug1: user sshvpn matched 'User sshvpn' at line 89 > > > debug3: match found > > > debug3: reprocess config:90 setting ChrootDirectory /var/sshvpn/ > > > debug3: reprocess config:91 setting AllowTCPForwarding no > > > debug3: reprocess config:92 setting AllowStreamLocalForwarding yes > > > debug3: reprocess config:93 setting StreamLocalBindUnlink yes > > > [...snip...] > > > debug1: server_input_global_request: rtype > > > streamlocal-forward at openssh.com want_reply 1 > > > debug1: server_input_global_request: streamlocal-forward listen path > > > /sshvpn/gateway > > > debug3: channel_setup_fwd_listener_streamlocal: type 19 path > > > /sshvpn/gateway > > > bind: Address already in use > > > unix_listener: cannot bind to path: /sshvpn/gateway > > > > > > I am aware of the StreamLocalBindUnlink option, and you can see that > > > it is set on both the client and the server, but it doesn't seem to be > > > effective. > > > > > > I also ran it under ltrace, and got the following: > > > > > > 24079 write(2, "debug3: channel_setup_fwd_listen"..., 78) = 78 > > > 24079 umask(0177) = 02 > > > 24079 socket(1, 1, 0) = 8 > > > 24079 bind(8, 0x7ffc4f8915c0, 110, -1) = -1 > > > 24079 __errno_location() = > 0x7f03f55a5710 > > > 24079 strerror(98) = "Address > > > already in use" > > > > > > From this, it appears that there is no attempt to unlink the socket if > > > it already exists, as would be expected from this code > > > ( > > > > https://github.com/openssh/openssh-portable/blob/7de4b03a6e4071d454b72927ffaf52949fa34545/misc.c#L1083 > > > ): > > > > > > sock = socket(PF_UNIX, SOCK_STREAM, 0); > > > if (sock < 0) { > > > saved_errno = errno; > > > error("socket: %.100s", strerror(errno)); > > > errno = saved_errno; > > > return -1; > > > } > > > if (unlink_first == 1) { > > > if (unlink(path) != 0 && errno != ENOENT) > > > error("unlink(%s): %.100s", path, strerror(errno)); > > > } > > > if (bind(sock, (struct sockaddr *)&sunaddr, sizeof(sunaddr)) < 0) { > > > saved_errno = errno; > > > error("bind: %.100s", strerror(errno)); > > > close(sock); > > > error("%s: cannot bind to path: %s", __func__, path); > > > errno = saved_errno; > > > return -1; > > > } > > > > > > What am I missing? > > > > > > Rogan > > > > > _______________________________________________ > > 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 Wed May 4 01:23:40 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 4 May 2016 01:23:40 +1000 (AEST) Subject: StreamLocal forwarding In-Reply-To: References: Message-ID: On Tue, 3 May 2016, Rogan Dawes wrote: > Hi Damien, > Thanks for the response! > > I tried moving the StreamLocalBindUnlink directive outside of the Match > rule, and it worked. But that doesn't explain why the Match was not > correctly setting the directive: > > This is running on an alternate port with -ddd: > > debug3: checking match for 'User sshvpn' user sshvpn host 196.209.244.243 > addr 196.209.244.243 laddr 176.9.9.247 lport 52221 > debug1: user sshvpn matched 'User sshvpn' at line 91 > debug3: match found > debug3: reprocess config:92 setting ChrootDirectory /var/sshvpn/ > debug3: reprocess config:93 setting AllowTCPForwarding no > debug3: reprocess config:94 setting AllowStreamLocalForwarding yes > debug3: reprocess config:95 setting StreamLocalBindUnlink yes > > And, surprisingly, even having set the directive outside the Match block, > the following command still doesn't show streamlocalbindunlink set: > > sshd -T -C "user=sshvpn,host=196.209.244.243,addr=196.209.244.243" | grep -i > stream > streamlocalbindmask 0177 > allowstreamlocalforwarding yes oh, that's a bug in the config dump support. diff --git a/servconf.c b/servconf.c index 6111c5a..2094c48 100644 --- a/servconf.c +++ b/servconf.c @@ -2293,6 +2293,7 @@ dump_config(ServerOptions *o) dump_cfg_fmtint(sAllowTcpForwarding, o->allow_tcp_forwarding); dump_cfg_fmtint(sAllowAgentForwarding, o->allow_agent_forwarding); dump_cfg_fmtint(sAllowStreamLocalForwarding, o->allow_streamlocal_forwarding); + dump_cfg_fmtint(sStreamLocalBindUnlink, o->fwd_opts.streamlocal_bind_unlink); dump_cfg_fmtint(sUsePrivilegeSeparation, use_privsep); dump_cfg_fmtint(sFingerprintHash, o->fingerprint_hash); From djm at mindrot.org Wed May 4 01:49:08 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 4 May 2016 01:49:08 +1000 (AEST) Subject: StreamLocal forwarding In-Reply-To: References: Message-ID: On Wed, 4 May 2016, Damien Miller wrote: > On Tue, 3 May 2016, Rogan Dawes wrote: > > > And, surprisingly, even having set the directive outside the Match block, > > the following command still doesn't show streamlocalbindunlink set: > > > > sshd -T -C "user=sshvpn,host=196.209.244.243,addr=196.209.244.243" | grep -i > > stream > > streamlocalbindmask 0177 > > allowstreamlocalforwarding yes > > oh, that's a bug in the config dump support. ... and with that fixed the real bug reveals itself: diff --git a/servconf.c b/servconf.c index 6111c5a..5e8b7ca 100644 --- a/servconf.c +++ b/servconf.c @@ -1994,6 +1994,7 @@ copy_set_server_options(ServerOptions *dst, ServerOptions *src, int preauth) M_CP_INTOPT(allow_agent_forwarding); M_CP_INTOPT(permit_tun); M_CP_INTOPT(fwd_opts.gateway_ports); + M_CP_INTOPT(fwd_opts.streamlocal_bind_unlink); M_CP_INTOPT(x11_display_offset); M_CP_INTOPT(x11_forwarding); M_CP_INTOPT(x11_use_localhost); @@ -2006,6 +2007,12 @@ copy_set_server_options(ServerOptions *dst, ServerOptions *src, int preauth) M_CP_INTOPT(rekey_limit); M_CP_INTOPT(rekey_interval); + /* This is a mode_t, so can't use M_CP_INTOPT */ + if (src->fwd_opts.streamlocal_bind_mask == (mode_t)-1) { + dst->fwd_opts.streamlocal_bind_mask = + src->fwd_opts.streamlocal_bind_mask; + } + /* M_CP_STROPT and M_CP_STRARRAYOPT should not appear before here */ #define M_CP_STROPT(n) do {\ if (src->n != NULL && dst->n != src->n) { \ From djm at mindrot.org Wed May 4 01:59:57 2016 From: djm at mindrot.org (Damien Miller) Date: Wed, 4 May 2016 01:59:57 +1000 (AEST) Subject: StreamLocal forwarding In-Reply-To: References: Message-ID: On Wed, 4 May 2016, Damien Miller wrote: > On Wed, 4 May 2016, Damien Miller wrote: > > > On Tue, 3 May 2016, Rogan Dawes wrote: > > > > > And, surprisingly, even having set the directive outside the Match block, > > > the following command still doesn't show streamlocalbindunlink set: > > > > > > sshd -T -C "user=sshvpn,host=196.209.244.243,addr=196.209.244.243" | grep -i > > > stream > > > streamlocalbindmask 0177 > > > allowstreamlocalforwarding yes > > > > oh, that's a bug in the config dump support. > > ... and with that fixed the real bug reveals itself: both fixes committed and in HEAD: commit cfefbcea1057c2623e76c579174a4107a0b6e6cd Author: djm at openbsd.org Date: Tue May 3 15:57:39 2016 +0000 upstream commit fix overriding of StreamLocalBindMask and StreamLocalBindUnlink in Match blocks; found the hard way by Rogan Dawes Upstream-ID: 940bc69ec0249ab428d24ccd0722ce35cb932ee2 commit 771c2f51ffc0c9a2877b7892fada0c77bd1f6549 Author: djm at openbsd.org Date: Tue May 3 15:25:06 2016 +0000 upstream commit don't forget to include StreamLocalBindUnlink in the config dump output Upstream-ID: 14a6d970b3b45c8e94272e3c661e9a0b2a0ee7cb From rogan at dawes.za.net Wed May 4 02:05:56 2016 From: rogan at dawes.za.net (Rogan Dawes) Date: Tue, 03 May 2016 16:05:56 +0000 Subject: StreamLocal forwarding In-Reply-To: References: Message-ID: Haha! Glad to know i wasn't just doing something stupid! Thanks for your help! Rogan On Tue, 03 May 2016 at 5:49 PM Damien Miller wrote: > On Wed, 4 May 2016, Damien Miller wrote: > > > On Tue, 3 May 2016, Rogan Dawes wrote: > > > > > And, surprisingly, even having set the directive outside the Match > block, > > > the following command still doesn't show streamlocalbindunlink set: > > > > > > sshd -T -C "user=sshvpn,host=196.209.244.243,addr=196.209.244.243" | > grep -i > > > stream > > > streamlocalbindmask 0177 > > > allowstreamlocalforwarding yes > > > > oh, that's a bug in the config dump support. > > ... and with that fixed the real bug reveals itself: > > diff --git a/servconf.c b/servconf.c > index 6111c5a..5e8b7ca 100644 > --- a/servconf.c > +++ b/servconf.c > @@ -1994,6 +1994,7 @@ copy_set_server_options(ServerOptions *dst, > ServerOptions *src, int preauth) > M_CP_INTOPT(allow_agent_forwarding); > M_CP_INTOPT(permit_tun); > M_CP_INTOPT(fwd_opts.gateway_ports); > + M_CP_INTOPT(fwd_opts.streamlocal_bind_unlink); > M_CP_INTOPT(x11_display_offset); > M_CP_INTOPT(x11_forwarding); > M_CP_INTOPT(x11_use_localhost); > @@ -2006,6 +2007,12 @@ copy_set_server_options(ServerOptions *dst, > ServerOptions *src, int preauth) > M_CP_INTOPT(rekey_limit); > M_CP_INTOPT(rekey_interval); > > + /* This is a mode_t, so can't use M_CP_INTOPT */ > + if (src->fwd_opts.streamlocal_bind_mask == (mode_t)-1) { > + dst->fwd_opts.streamlocal_bind_mask = > + src->fwd_opts.streamlocal_bind_mask; > + } > + > /* M_CP_STROPT and M_CP_STRARRAYOPT should not appear before here > */ > #define M_CP_STROPT(n) do {\ > if (src->n != NULL && dst->n != src->n) { \ > From nkadel at gmail.com Wed May 4 22:22:58 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 4 May 2016 08:22:58 -0400 Subject: An update on SSH protocol 1 In-Reply-To: References: <20160503140922.GA9034@riva.ucam.org> Message-ID: On Tue, May 3, 2016 at 10:14 AM, Damien Miller wrote: > On Tue, 3 May 2016, Colin Watson wrote: >> My plan for Debian (and thus Ubuntu etc.) is therefore that, once SSHv1 >> is entirely removed from OpenSSH, I will split out the >> openssh-client-ssh1 binary package to be built from a separate source >> package which will remain frozen at the last OpenSSH release that >> supported SSHv1. As before, this will ship only scp1, ssh1, and >> ssh-keygen1 binaries. >> Notwithstanding all this, the plan of removing all this obsolete code >> from OpenSSH proper makes a lot of sense to me and I have no complaints >> there. > > Your plan sounds emminently reasonable and I'll repeat my thanks > for your helping the transition by making separate -ssh1 packages. It's also pretty funny to see a reversal of the old says when ssh-1 and ssh-2 were originally published, separately, and OpenSSH was able to integrate the code bases to provide one set of binaries. Pulling SSH-1 out of the server codebase is very sensible at this point. I'm slightly concerned that people with older hardware, such as various older firewalls, may find themselves with a problem. From mstone at mathom.us Wed May 4 23:46:01 2016 From: mstone at mathom.us (Michael Stone) Date: Wed, 4 May 2016 09:46:01 -0400 Subject: An update on SSH protocol 1 In-Reply-To: References: <20160503140922.GA9034@riva.ucam.org> Message-ID: <75dc175e-11fd-11e6-9b6a-00163eeb5320@msgid.mathom.us> On Wed, May 04, 2016 at 08:22:58AM -0400, Nico Kadel-Garcia wrote: >Pulling SSH-1 out of the server codebase is very sensible at this >point. I'm slightly concerned that people with older hardware, such as >various older firewalls, may find themselves with a problem. If their security device is so old/unsupported that it only supports ssh1, they probably already have problems--and using an old ssh1 client binary probably isn't the biggest of them. Mike Stone From rogan at dawes.za.net Thu May 5 07:32:53 2016 From: rogan at dawes.za.net (Rogan Dawes) Date: Wed, 04 May 2016 21:32:53 +0000 Subject: Dynamic Remote Port forward? Message-ID: Hi folks, I'm wondering if it is possible to set up a dynamic port forward (i.e. socks proxy), where the listening socket is actually on the server rather than the client as is currently the case for -D ? A possible use case is providing a deeply firewalled box with an outbound SOCKS proxy, but only while an inbound ssh connection is active. Or, in my particular case, I have many routers running OpenWRT, using sshtunnel to establish a persistent connection to my central server. I want to be able to reach systems behind the gateways. I currently have the sshtunnel configuration set up as follows: On the router: ssh StreamLocalBindUnlink=yes -nN -R /sshvpn/gateway-xxxx:127.0.0.1:22 sshvpn at central In this way, should I want to connect to a system behind the router, I can first establish a new SSH connection back to the router itself, from the central server: ssh -o ProxyCommand='socat UNIX:/sshvpn/gateway-xxxx -' -D 1080 root at gateway-xxxx and then use the socks proxy on port 1080 to reach the remote devices. This is workable, but somewhat clumsy, in my opinion. My ideal scenario would be something like the following, run on the router: ssh StreamLocalBindUnlink=yes -nN -RD /sshvpn/gateway-xxxx sshvpn at central which would allow a process on the central server to establish a connection through the socks server listening at /sshvpn/gateway-xxxx, with connections outbound from the router itself. Obviously the "-DR" option is nonsense, and should be changed to a suitable single character option, I'm just not sure what is available right now! :-) Thoughts? Rogan From sunilckhatri at yahoo.com Sat May 7 05:55:59 2016 From: sunilckhatri at yahoo.com (SCK) Date: Fri, 6 May 2016 19:55:59 +0000 (UTC) Subject: CBC Ciphers removal from AIX Servers References: <1093380363.985.1462564559819.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1093380363.985.1462564559819.JavaMail.yahoo@mail.yahoo.com> Hi, Nessus tool identified AIX servers are configured with vulnerable ciphers.As a remediation I have made proper changes in sshd_config file. Stop the sshd daemon and start sshd? Still Issue persist. I have checked on one system post system reboot vulnerabilities went off.? Is there any other way by which I can remove the vulnerabilities without rebooting the servers. Sunil From flavien-ssh at lebarbe.net Sat May 7 07:09:11 2016 From: flavien-ssh at lebarbe.net (Flavien) Date: Fri, 6 May 2016 23:09:11 +0200 Subject: CBC Ciphers removal from AIX Servers In-Reply-To: <1093380363.985.1462564559819.JavaMail.yahoo@mail.yahoo.com> References: <1093380363.985.1462564559819.JavaMail.yahoo.ref@mail.yahoo.com> <1093380363.985.1462564559819.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20160506210911.GA29639@srv4.flavien.org> SCK wrote : > Hi, > Nessus tool identified AIX servers are configured with vulnerable ciphers.As a remediation I have made proper changes in sshd_config file. Stop the sshd daemon and start sshd? > Still Issue persist. I have checked on one system post system reboot vulnerabilities went off.? > Is there any other way by which I can remove the vulnerabilities without rebooting the servers. > Sunil >From what you write, it looks like "something" needs to be restarted, not only the sshd daemon. I remember hitting a bug on AIX a few years ago [1]. It was linked to CryptoLite library (some acceleration lib for crypto operation). That library came with a kernel module. May be you should have a look there ? Just an idea. HTH, Flavien. [1] : http://thread.gmane.org/gmane.network.openssh.devel/19176 From mfriedl at gmail.com Mon May 9 05:04:04 2016 From: mfriedl at gmail.com (Markus Friedl) Date: Sun, 8 May 2016 21:04:04 +0200 Subject: Dynamic Remote Port forward? In-Reply-To: References: Message-ID: I have an ugly patch for that feature that requires protocol modification. > Am 04.05.2016 um 23:32 schrieb Rogan Dawes : > > Hi folks, > > I'm wondering if it is possible to set up a dynamic port forward (i.e. > socks proxy), where the listening socket is actually on the server rather > than the client as is currently the case for -D ? > > A possible use case is providing a deeply firewalled box with an outbound > SOCKS proxy, but only while an inbound ssh connection is active. > > Or, in my particular case, I have many routers running OpenWRT, using > sshtunnel to establish a persistent connection to my central server. I want > to be able to reach systems behind the gateways. > > I currently have the sshtunnel configuration set up as follows: > > On the router: > > ssh StreamLocalBindUnlink=yes -nN -R /sshvpn/gateway-xxxx:127.0.0.1:22 > sshvpn at central > > In this way, should I want to connect to a system behind the router, I can > first establish a new SSH connection back to the router itself, from the > central server: > > ssh -o ProxyCommand='socat UNIX:/sshvpn/gateway-xxxx -' -D 1080 > root at gateway-xxxx > > and then use the socks proxy on port 1080 to reach the remote devices. > > This is workable, but somewhat clumsy, in my opinion. > > My ideal scenario would be something like the following, run on the router: > > ssh StreamLocalBindUnlink=yes -nN -RD /sshvpn/gateway-xxxx sshvpn at central > > which would allow a process on the central server to establish a connection > through the socks server listening at /sshvpn/gateway-xxxx, with > connections outbound from the router itself. > > Obviously the "-DR" option is nonsense, and should be changed to a suitable > single character option, I'm just not sure what is available right now! :-) > > Thoughts? > > Rogan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Mon May 9 05:27:31 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 8 May 2016 21:27:31 +0200 Subject: Dynamic Remote Port forward? In-Reply-To: References: Message-ID: On Sun, May 8, 2016 at 9:04 PM, Markus Friedl wrote: > I have an ugly patch for that feature that requires protocol modification. Why does it require a protocol modification? Couldn't the client request regular forwarded-tcpip from the server then decode SOCKS entirely within the client? -- 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 Mon May 9 05:59:24 2016 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 08 May 2016 21:59:24 +0200 Subject: Dynamic Remote Port forward? In-Reply-To: References: Message-ID: <572F9A9C.9000802@gmail.com> I think this would be doable with: ssh -oProxyCommand="ssh -D 1080 localhost -W %h:%p" -R /sshvpn/gateway-xxxx:localhost:1080 sshvpn at central -D doesn't support local_socket, so a regular port is used. From rogan at dawes.za.net Mon May 9 06:04:45 2016 From: rogan at dawes.za.net (Rogan Dawes) Date: Sun, 08 May 2016 20:04:45 +0000 Subject: Dynamic Remote Port forward? In-Reply-To: References: Message-ID: That's pretty much what I was thinking. The most significant change will be that the client has to include the socks server code, which it doesn't currently (I suppose!). Or am I mistaken? Rogan On Sun, 8 May 2016, 21:27 Darren Tucker, wrote: > On Sun, May 8, 2016 at 9:04 PM, Markus Friedl wrote: > > I have an ugly patch for that feature that requires protocol > modification. > > Why does it require a protocol modification? Couldn't the client > request regular forwarded-tcpip from the server then decode SOCKS > entirely within the client? > > -- > 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 Mon May 9 06:17:18 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 8 May 2016 22:17:18 +0200 Subject: Dynamic Remote Port forward? In-Reply-To: References: Message-ID: On Sun, May 8, 2016 at 10:04 PM, Rogan Dawes wrote: > That's pretty much what I was thinking. Me too, but Markus is smarter than I am so I fear I've overlooked something :-) > The most significant change will be > that the client has to include the socks server code, which it doesn't > currently (I suppose!). The client has (and uses) the socks code. On most platforms it'll also get linked into the server (and anything else that links the channel code). $ nm ssh | grep socks5 00030450 t channel_decode_socks5.isra.11 $ nm sshd | grep socks5 0003a930 t channel_decode_socks5.isra.11 -- 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 mfriedl at gmail.com Mon May 9 06:34:10 2016 From: mfriedl at gmail.com (Markus Friedl) Date: Sun, 8 May 2016 22:34:10 +0200 Subject: Dynamic Remote Port forward? In-Reply-To: References: Message-ID: <831BEE83-939E-4797-8927-D2D687D3CA51@gmail.com> > Am 08.05.2016 um 21:27 schrieb Darren Tucker : > >> On Sun, May 8, 2016 at 9:04 PM, Markus Friedl wrote: >> I have an ugly patch for that feature that requires protocol modification. > > Why does it require a protocol modification? Couldn't the client > request regular forwarded-tcpip from the server then decode SOCKS > entirely within the client? > Yes. That's better and the reason why my patch is ugly ;). I'll look into doing this. > -- > 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 rogan at dawes.za.net Mon May 9 16:08:53 2016 From: rogan at dawes.za.net (Rogan Dawes) Date: Mon, 09 May 2016 06:08:53 +0000 Subject: Dynamic Remote Port forward? In-Reply-To: <831BEE83-939E-4797-8927-D2D687D3CA51@gmail.com> References: <831BEE83-939E-4797-8927-D2D687D3CA51@gmail.com> Message-ID: That's what I thought! As mentioned, it would be awesome if this could be exposed as a Unix socket as well as a TCP port. I guess if you simply reuse the existing "port forward" code, that should come automatically? Rogan On Sun, May 8, 2016 at 10:34 PM Markus Friedl wrote: > > > > Am 08.05.2016 um 21:27 schrieb Darren Tucker : > > > >> On Sun, May 8, 2016 at 9:04 PM, Markus Friedl > wrote: > >> I have an ugly patch for that feature that requires protocol > modification. > > > > Why does it require a protocol modification? Couldn't the client > > request regular forwarded-tcpip from the server then decode SOCKS > > entirely within the client? > > > > Yes. That's better and the reason why my patch is ugly ;). > I'll look into doing this. > > > > -- > > 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 bert.wesarg at googlemail.com Mon May 9 16:21:16 2016 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Mon, 9 May 2016 08:21:16 +0200 Subject: Dynamic Remote Port forward? In-Reply-To: <572F9A9C.9000802@gmail.com> References: <572F9A9C.9000802@gmail.com> Message-ID: On Sun, May 8, 2016 at 9:59 PM, ?ngel Gonz?lez wrote: > I think this would be doable with: > > ssh -oProxyCommand="ssh -D 1080 localhost -W %h:%p" -R > /sshvpn/gateway-xxxx:localhost:1080 sshvpn at central AFAIK -W forces ClearAllForwardings=1, which makes -D a no-op. > > -D doesn't support local_socket, so a regular port is used. > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From rogan at dawes.za.net Mon May 9 16:19:35 2016 From: rogan at dawes.za.net (Rogan Dawes) Date: Mon, 09 May 2016 06:19:35 +0000 Subject: Dynamic Remote Port forward? In-Reply-To: References: <831BEE83-939E-4797-8927-D2D687D3CA51@gmail.com> Message-ID: Sorry, just wanted to add a Thank you. I appreciate you taking the time to respond to my ramblings! Rogan On Mon, May 9, 2016 at 8:08 AM Rogan Dawes wrote: > That's what I thought! As mentioned, it would be awesome if this could be > exposed as a Unix socket as well as a TCP port. I guess if you simply reuse > the existing "port forward" code, that should come automatically? > > Rogan > > > On Sun, May 8, 2016 at 10:34 PM Markus Friedl wrote: > >> >> >> > Am 08.05.2016 um 21:27 schrieb Darren Tucker : >> > >> >> On Sun, May 8, 2016 at 9:04 PM, Markus Friedl >> wrote: >> >> I have an ugly patch for that feature that requires protocol >> modification. >> > >> > Why does it require a protocol modification? Couldn't the client >> > request regular forwarded-tcpip from the server then decode SOCKS >> > entirely within the client? >> > >> >> Yes. That's better and the reason why my patch is ugly ;). >> I'll look into doing this. >> >> >> > -- >> > 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 da_audiophile at yahoo.com Tue May 10 02:10:25 2016 From: da_audiophile at yahoo.com (John) Date: Mon, 9 May 2016 16:10:25 +0000 (UTC) Subject: Cannot get sftp transfers to log in the systemd journal References: <2081131567.1214906.1462810225027.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <2081131567.1214906.1462810225027.JavaMail.yahoo@mail.yahoo.com> I'd like to have sshd write entries into the systemd journal logging sftp transfers. From googling, it seems that one needs to edit /etc/ssh/sshd_config adding this line: Subsystem sftp /usr/lib/ssh/sftp-server -f AUTH -l VERBOSE I can transfer files via filezilla (sftp) but I don't get anything in `journalctl -u sshd` that shows these transfers, just a few lines showing I connected. What am I doing wrong? I am using version 7.2p2 on Arch Linux. Thanks in advance! From jjelen at redhat.com Tue May 10 18:52:33 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 10 May 2016 10:52:33 +0200 Subject: Cannot get sftp transfers to log in the systemd journal In-Reply-To: <2081131567.1214906.1462810225027.JavaMail.yahoo@mail.yahoo.com> References: <2081131567.1214906.1462810225027.JavaMail.yahoo.ref@mail.yahoo.com> <2081131567.1214906.1462810225027.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5731A151.5070109@redhat.com> On 05/09/2016 06:10 PM, John wrote: > I'd like to have sshd write entries into the systemd journal logging sftp transfers. From googling, it seems that one needs to edit /etc/ssh/sshd_config adding this line: > > Subsystem sftp /usr/lib/ssh/sftp-server -f AUTH -l VERBOSE > > > I can transfer files via filezilla (sftp) but I don't get anything in `journalctl -u sshd` that shows these transfers, just a few lines showing I connected. What am I doing wrong? I am using version 7.2p2 on Arch Linux. Thanks in advance! These logs are logged under different "user" than sshd. It should be logged under "sftp-server" process name. It certainly works on Fedora/RHEL, unless: * you are in chroot -- this requires a bit different approach * your user is blocked from opening or writing to /dev/log or however is syslog configured to accept logs Note, that using above settings logs under the user logging in and not under root so you need appropriate access. Regards, -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat From dtucker at dtucker.net Tue May 10 18:58:59 2016 From: dtucker at dtucker.net (Darren Tucker) Date: Tue, 10 May 2016 10:58:59 +0200 Subject: Cannot get sftp transfers to log in the systemd journal In-Reply-To: <2081131567.1214906.1462810225027.JavaMail.yahoo@mail.yahoo.com> References: <2081131567.1214906.1462810225027.JavaMail.yahoo.ref@mail.yahoo.com> <2081131567.1214906.1462810225027.JavaMail.yahoo@mail.yahoo.com> Message-ID: Maybe try the internal-sftp subsystem instead of sftp? That runs inside sshd which has provisions for syslogging from inside a chroot (instead of as a separate executable). On May 9, 2016 18:11, "John" wrote: > I'd like to have sshd write entries into the systemd journal logging sftp > transfers. From googling, it seems that one needs to edit > /etc/ssh/sshd_config adding this line: > > Subsystem sftp /usr/lib/ssh/sftp-server -f AUTH -l VERBOSE > > > I can transfer files via filezilla (sftp) but I don't get anything in > `journalctl -u sshd` that shows these transfers, just a few lines showing I > connected. What am I doing wrong? I am using version 7.2p2 on Arch > Linux. Thanks in advance! > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From da_audiophile at yahoo.com Tue May 10 20:57:13 2016 From: da_audiophile at yahoo.com (John) Date: Tue, 10 May 2016 10:57:13 +0000 (UTC) Subject: Cannot get sftp transfers to log in the systemd journal In-Reply-To: <5731A151.5070109@redhat.com> References: <5731A151.5070109@redhat.com> Message-ID: <896879824.1716377.1462877833583.JavaMail.yahoo@mail.yahoo.com> > On 05/09/2016 06:10 PM, John wrote: > >> I'd like to have sshd write entries into the systemd journal logging > sftp transfers. From googling, it seems that one needs to edit > /etc/ssh/sshd_config adding this line: >> >> Subsystem sftp /usr/lib/ssh/sftp-server -f AUTH -l VERBOSE >> >> >> I can transfer files via filezilla (sftp) but I don't get anything in > `journalctl -u sshd` that shows these transfers, just a few lines showing I > connected. What am I doing wrong? I am using version 7.2p2 on Arch Linux. > Thanks in advance! > These logs are logged under different "user" than sshd. It should be > logged under "sftp-server" process name. It certainly works on > Fedora/RHEL, unless: > > * you are in chroot -- this requires a bit different approach > * your user is blocked from opening or writing to /dev/log or however > is syslog configured to accept logs > > Note, that using above settings logs under the user logging in and not > under root so you need appropriate access. Thank you for the reply. Indeed, I see entries for the entries in my journalctl output under 'sftp-server' if I transfer a file from a normal user on my system. I also setup a chroot-jail but as you mentioned, no logs are written for these. What is the different approach I need to use? To help, here is the relevant section of my sshd_config: Match group sshusers ChrootDirectory %h X11Forwarding no AllowTcpForwarding no PasswordAuthentication yes ForceCommand internal-sftp From jjelen at redhat.com Tue May 10 21:15:35 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 10 May 2016 13:15:35 +0200 Subject: Cannot get sftp transfers to log in the systemd journal In-Reply-To: <896879824.1716377.1462877833583.JavaMail.yahoo@mail.yahoo.com> References: <5731A151.5070109@redhat.com> <896879824.1716377.1462877833583.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5731C2D7.2080404@redhat.com> On 05/10/2016 12:57 PM, John wrote: > Thank you for the reply. Indeed, I see entries for the entries in my journalctl output under 'sftp-server' if I transfer a file from a normal user on my system. I also setup a chroot-jail but as you mentioned, no logs are written for these. What is the different approach I need to use? There are two possibilities. Either you set up logging socket in chroot and set up syslog/journal to receive message from it, or there is some possibility to log over the socket opened by the parent (before going into chroot), which is a bit hacky solution (and not upstream for some reason). We have got the patch in our git [1], but there will probably be some bug in upstream bugzilla. [1] http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-6.6.1p1-log-in-chroot.patch Regards, -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat From jjelen at redhat.com Tue May 10 22:22:30 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 10 May 2016 14:22:30 +0200 Subject: Cannot get sftp transfers to log in the systemd journal In-Reply-To: <1999708541.1702521.1462882778665.JavaMail.yahoo@mail.yahoo.com> References: <5731C2D7.2080404@redhat.com> <1999708541.1702521.1462882778665.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5731D286.2020100@redhat.com> On 05/10/2016 02:19 PM, John wrote: > >> There are two possibilities. Either you set up logging socket in chroot >> and set up syslog/journal to receive message from it, or there is some >> possibility to log over the socket opened by the parent (before going >> into chroot), which is a bit hacky solution (and not upstream for some >> reason). We have got the patch in our git [1], but there will probably >> be some bug in upstream bugzilla. >> >> >> [1] >> http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-6.6.1p1-log-in-chroot.patch >> >> Regards, > Thanks for the reply, Jakub. The patch you pointed me to does not apply to the current release of openssh unfortunately (v7.2p2). Do you have a more contemporary version of the patch I can try? It applies, but there are also other conflicting patches in Fedora probably. We use exactly this one for openssh-7.2 > I can google around for a logging socket... I assume this can be implemented without the patch you referenced and on the current version 7.2p2? Yes. The logging socket in chroot solution should work without the above patch. -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat From da_audiophile at yahoo.com Tue May 10 22:19:38 2016 From: da_audiophile at yahoo.com (John) Date: Tue, 10 May 2016 12:19:38 +0000 (UTC) Subject: Cannot get sftp transfers to log in the systemd journal In-Reply-To: <5731C2D7.2080404@redhat.com> References: <5731C2D7.2080404@redhat.com> Message-ID: <1999708541.1702521.1462882778665.JavaMail.yahoo@mail.yahoo.com> > There are two possibilities. Either you set up logging socket in chroot > and set up syslog/journal to receive message from it, or there is some > possibility to log over the socket opened by the parent (before going > into chroot), which is a bit hacky solution (and not upstream for some > reason). We have got the patch in our git [1], but there will probably > be some bug in upstream bugzilla. > > > [1] > http://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-6.6.1p1-log-in-chroot.patch > > Regards, Thanks for the reply, Jakub. The patch you pointed me to does not apply to the current release of openssh unfortunately (v7.2p2). Do you have a more contemporary version of the patch I can try? I can google around for a logging socket... I assume this can be implemented without the patch you referenced and on the current version 7.2p2? From raubvogel at gmail.com Thu May 12 00:17:35 2016 From: raubvogel at gmail.com (Mauricio Tavares) Date: Wed, 11 May 2016 10:17:35 -0400 Subject: ssh 6.6.1, PubkeyAcceptedKeyTypes Message-ID: So I add the line PubkeyAcceptedKeyTypes +ssh-dss to my opensshd_config file. When I restart sshd, I am told that May 11 09:33:14 pickles systemd: Started OpenSSH Server Key Generation. May 11 09:33:14 pickles systemd: Started OpenSSH server daemon. May 11 09:33:14 pickles systemd: Starting OpenSSH server daemon... May 11 09:33:14 pickles sshd: /etc/ssh/sshd_config: line 156: Bad configuration option: PubkeyAcceptedKeyTypes May 11 09:33:14 pickles sshd: /etc/ssh/sshd_config: terminating, 1 bad configuration options May 11 09:33:14 pickles systemd: sshd.service: main process exited, code=exited, status=255/n/a May 11 09:33:14 pickles systemd: Unit sshd.service entered failed state. May 11 09:33:14 pickles systemd: sshd.service failed. Don't think I made a typo but that has not been the first time. What else could I be missing here? This is openssh 6.6.1 in RHELS 7.2 From mouring at eviladmin.org Thu May 12 00:56:40 2016 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 11 May 2016 09:56:40 -0500 Subject: ssh 6.6.1, PubkeyAcceptedKeyTypes In-Reply-To: References: Message-ID: <57334828.1010306@eviladmin.org> Unless it was backported "PubkeyAcceptedKeyTypes" it only exists in 7.0+ OpenSSH. From OpenSSH 7.0 release notes: "New Features ------------ * ssh_config(5): add PubkeyAcceptedKeyTypes option to control which public key types are available for user authentication." - Ben Mauricio Tavares wrote: > So I add the line > > PubkeyAcceptedKeyTypes +ssh-dss > > to my opensshd_config file. When I restart sshd, I am told that > > May 11 09:33:14 pickles systemd: Started OpenSSH Server Key Generation. > May 11 09:33:14 pickles systemd: Started OpenSSH server daemon. > May 11 09:33:14 pickles systemd: Starting OpenSSH server daemon... > May 11 09:33:14 pickles sshd: /etc/ssh/sshd_config: line 156: Bad > configuration option: PubkeyAcceptedKeyTypes > May 11 09:33:14 pickles sshd: /etc/ssh/sshd_config: terminating, 1 bad > configuration options > May 11 09:33:14 pickles systemd: sshd.service: main process exited, > code=exited, status=255/n/a > May 11 09:33:14 pickles systemd: Unit sshd.service entered failed state. > May 11 09:33:14 pickles systemd: sshd.service failed. > > Don't think I made a typo but that has not been the first time. What > else could I be missing here? This is openssh 6.6.1 in RHELS 7.2 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From raubvogel at gmail.com Thu May 12 01:00:29 2016 From: raubvogel at gmail.com (Mauricio Tavares) Date: Wed, 11 May 2016 11:00:29 -0400 Subject: ssh 6.6.1, PubkeyAcceptedKeyTypes In-Reply-To: <57334828.1010306@eviladmin.org> References: <57334828.1010306@eviladmin.org> Message-ID: On Wed, May 11, 2016 at 10:56 AM, Ben Lindstrom wrote: > Unless it was backported "PubkeyAcceptedKeyTypes" it only exists in 7.0+ > OpenSSH. > Another mystery solved. Thanks! Is there a way to fake that in 6.6, specially within a match block? > From OpenSSH 7.0 release notes: > > "New Features > ------------ > > * ssh_config(5): add PubkeyAcceptedKeyTypes option to control which > public key types are available for user authentication." > > > - Ben > > Mauricio Tavares wrote: >> >> So I add the line >> >> PubkeyAcceptedKeyTypes +ssh-dss >> >> to my opensshd_config file. When I restart sshd, I am told that >> >> May 11 09:33:14 pickles systemd: Started OpenSSH Server Key Generation. >> May 11 09:33:14 pickles systemd: Started OpenSSH server daemon. >> May 11 09:33:14 pickles systemd: Starting OpenSSH server daemon... >> May 11 09:33:14 pickles sshd: /etc/ssh/sshd_config: line 156: Bad >> configuration option: PubkeyAcceptedKeyTypes >> May 11 09:33:14 pickles sshd: /etc/ssh/sshd_config: terminating, 1 bad >> configuration options >> May 11 09:33:14 pickles systemd: sshd.service: main process exited, >> code=exited, status=255/n/a >> May 11 09:33:14 pickles systemd: Unit sshd.service entered failed state. >> May 11 09:33:14 pickles systemd: sshd.service failed. >> >> Don't think I made a typo but that has not been the first time. What >> else could I be missing here? This is openssh 6.6.1 in RHELS 7.2 >> _______________________________________________ >> 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 Thu May 12 11:45:18 2016 From: djm at mindrot.org (Damien Miller) Date: Thu, 12 May 2016 11:45:18 +1000 (AEST) Subject: ssh 6.6.1, PubkeyAcceptedKeyTypes In-Reply-To: References: <57334828.1010306@eviladmin.org> Message-ID: On Wed, 11 May 2016, Mauricio Tavares wrote: > On Wed, May 11, 2016 at 10:56 AM, Ben Lindstrom wrote: > > Unless it was backported "PubkeyAcceptedKeyTypes" it only exists in 7.0+ > > OpenSSH. > > > Another mystery solved. Thanks! > > Is there a way to fake that in 6.6, specially within a match block? No - we didn't offer control of that until 7.1p1 and there was a bug in the Match support for PubkeyAcceptedKeyTypes until 7.2p1. -d From sanumesh at in.ibm.com Fri May 13 15:23:19 2016 From: sanumesh at in.ibm.com (Sandeep Umesh) Date: Fri, 13 May 2016 10:53:19 +0530 Subject: Need information on CVE-2015-8325 Message-ID: <201605130523.u4D5NOLK27263088@d28relay08.in.ibm.com> Hello Can anyone please provide information on CVE-2015-8325? Looks like a recent commit has been done for this, but it is not part of OpenSSH 7.2p2. Is it targeted for next release ? Thanks Regards Sandeep From lauri.vosandi at gmail.com Fri May 13 18:15:49 2016 From: lauri.vosandi at gmail.com (lauri) Date: Fri, 13 May 2016 11:15:49 +0300 Subject: [PATCH] Expand tilde for UNIX domain socket forwards. In-Reply-To: References: <1439835793-30017-1-git-send-email-lauri.vosandi@gmail.com> Message-ID: Hello, any updates on this? We're preparing for upgrade to Ubuntu 16.04 and I was hoping I don't have to patch OpenSSH again :D 2015-08-19 5:31 GMT+03:00 Todd C. Miller : > On Tue, 18 Aug 2015 09:41:47 +1000, Damien Miller wrote: > >> Yeah, we should refactor it into a version that returns a ssherr.h code >> and (perhaps) leave the existing tilde_expand_filename() as a wrapper. > > We could do something like this. The name stinks but... > > - todd > > Index: misc.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/misc.c,v > retrieving revision 1.97 > diff -u -p -u -r1.97 misc.c > --- misc.c 24 Apr 2015 01:36:00 -0000 1.97 > +++ misc.c 19 Aug 2015 02:28:18 -0000 > @@ -50,6 +50,7 @@ > #include "xmalloc.h" > #include "misc.h" > #include "log.h" > +#include "ssherr.h" > #include "ssh.h" > > /* remove newline at end of string */ > @@ -499,29 +500,31 @@ freeargs(arglist *args) > * Expands tildes in the file name. Returns data allocated by xmalloc. > * Warning: this calls getpw*. > */ > -char * > -tilde_expand_filename(const char *filename, uid_t uid) > +int > +tilde_expand_filename2(const char *filename, char **expanded, uid_t uid) > { > const char *path, *sep; > char user[128], *ret; > struct passwd *pw; > - u_int len, slash; > + size_t len, slash; > > - if (*filename != '~') > - return (xstrdup(filename)); > + if (*filename != '~') { > + *expanded = xstrdup(filename); > + return SSH_ERR_SUCCESS; > + } > filename++; > > path = strchr(filename, '/'); > if (path != NULL && path > filename) { /* ~user/path */ > slash = path - filename; > if (slash > sizeof(user) - 1) > - fatal("tilde_expand_filename: ~username too long"); > + return SSH_ERR_PATH_TOO_LONG; > memcpy(user, filename, slash); > user[slash] = '\0'; > if ((pw = getpwnam(user)) == NULL) > - fatal("tilde_expand_filename: No such user %s", user); > + return SSH_ERR_UNKNOWN_USER; > } else if ((pw = getpwuid(uid)) == NULL) /* ~/path */ > - fatal("tilde_expand_filename: No such uid %ld", (long)uid); > + return SSH_ERR_UNKNOWN_USER; > > /* Make sure directory has a trailing '/' */ > len = strlen(pw->pw_dir); > @@ -534,10 +537,29 @@ tilde_expand_filename(const char *filena > if (path != NULL) > filename = path + 1; > > - if (xasprintf(&ret, "%s%s%s", pw->pw_dir, sep, filename) >= PATH_MAX) > - fatal("tilde_expand_filename: Path too long"); > + if (xasprintf(ret, "%s%s%s", pw->pw_dir, sep, filename) >= PATH_MAX) { > + free(ret); > + return SSH_ERR_PATH_TOO_LONG; > + } > + > + *expanded = ret; > + return SSH_ERR_SUCCESS; > +} > + > +/* > + * Expands tildes in the file name. Returns data allocated by xmalloc. > + * Warning: this calls getpw*. > + */ > +char * > +tilde_expand_filename(const char *filename, uid_t uid) > +{ > + char *ret; > + int rc; > > - return (ret); > + rc = tilde_expand_filename2(filename, &ret, uid); > + if (rc != SSH_ERR_SUCCESS) > + fatal("%s: %s", __func__, ssh_err(rc)); > + return ret; > } > > /* > Index: misc.h > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/misc.h,v > retrieving revision 1.54 > diff -u -p -u -r1.54 misc.h > --- misc.h 15 Jul 2014 15:54:14 -0000 1.54 > +++ misc.h 19 Aug 2015 02:27:37 -0000 > @@ -49,6 +49,7 @@ char *cleanhostname(char *); > char *colon(char *); > long convtime(const char *); > char *tilde_expand_filename(const char *, uid_t); > +int tilde_expand_filename2(const char *, char **, uid_t); > char *percent_expand(const char *, ...) __attribute__((__sentinel__)); > char *tohex(const void *, size_t); > void sanitise_stdfd(void); > Index: ssherr.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/ssherr.c,v > retrieving revision 1.4 > diff -u -p -u -r1.4 ssherr.c > --- ssherr.c 16 Feb 2015 22:13:32 -0000 1.4 > +++ ssherr.c 19 Aug 2015 02:19:05 -0000 > @@ -135,6 +135,10 @@ ssh_err(int n) > return "Connection corrupted"; > case SSH_ERR_PROTOCOL_ERROR: > return "Protocol error"; > + case SSH_ERR_UNKNOWN_USER: > + return "Unknown user"; > + case SSH_ERR_PATH_TOO_LONG: > + return "Path too long"; > default: > return "unknown error"; > } > Index: ssherr.h > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/ssherr.h,v > retrieving revision 1.3 > diff -u -p -u -r1.3 ssherr.h > --- ssherr.h 30 Jan 2015 01:13:33 -0000 1.3 > +++ ssherr.h 19 Aug 2015 02:18:29 -0000 > @@ -77,6 +77,8 @@ > #define SSH_ERR_CONN_TIMEOUT -53 > #define SSH_ERR_CONN_CORRUPT -54 > #define SSH_ERR_PROTOCOL_ERROR -55 > +#define SSH_ERR_UNKNOWN_USER -56 > +#define SSH_ERR_PATH_TOO_LONG -57 > > /* Translate a numeric error code to a human-readable error string */ > const char *ssh_err(int n); -- Lauri V?sandi tel: +372 53329412 e-mail: lauri.vosandi at gmail.com blog: http://lauri.vosandi.com/ From barry.brickell at gmail.com Mon May 16 06:24:19 2016 From: barry.brickell at gmail.com (Barry Brickell) Date: Sun, 15 May 2016 21:24:19 +0100 Subject: sftp quiet mode being enforced in batch mode (openssh-6.3) Message-ID: Hi, sftp batch mode has been enforcing quiet mode since 6.3p1 (I've checked 7.2p2). < /* $OpenBSD: sftp.c,v 1.142 2013/02/08 00:41:12 djm Exp $ */ --- > /* $OpenBSD: sftp.c,v 1.148 2013/07/25 00:56:52 djm Exp $ */ 2181c2224 < batchmode = 1; --- > quiet = batchmode = 1; This means that successful commands are not being acknowledged in stdout. OpenSSH_6.2p1, OpenSSL 1.0.1e-fips 11 Feb 2013 $ sftp -b test.sftp localhost 2>stderr.log sftp> put testfrom/test1.txt testto/test1.txt Uploading testfrom/test1.txt to /home/user/testto/test1.txt sftp> rm testto/test.txt Removing /home/user/testto/test.txt OpenSSH_6.3, OpenSSL 1.0.1e-fips 11 Feb 2013 $ sftp -b test.sftp localhost 2>stderr.log sftp> put testfrom/test1.txt testto/test1.txt sftp> rm testto/test.txt Additionally, if the "progress" command is used, this successfully enables the progress output. OpenSSH_6.2p1, OpenSSL 1.0.1e-fips 11 Feb 2013 $ sftp -b test.sftp localhost 2>stderr.log sftp> progress Progress meter enabled sftp> put testfrom/test1.txt testto/test1.txt Uploading testfrom/test1.txt to /home/user/testto/test1.txt testfrom/test1.txt 100% 158 0.2KB/s 00:00 sftp> rm testto/test.txt Removing /home/user/testto/test.txt OpenSSH_6.3, OpenSSL 1.0.1e-fips 11 Feb 2013 $ sftp -b test.sftp localhost 2>stderr.log sftp> progress Progress meter enabled sftp> put testfrom/test1.txt testto/test1.txt testfrom/test1.txt 100% 158 0.2KB/s 00:00 sftp> rm testto/test.txt Could batch mode not enforce quiet mode or possibly a "quiet" command be introduced (like progress) which toggles the flag? Regards, Barry. From dkg at fifthhorseman.net Wed May 18 21:52:45 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 18 May 2016 07:52:45 -0400 Subject: [PATCH] Document transfer of ed25519 secret keys to the ssh-agent Message-ID: <1463572365-2139-1-git-send-email-dkg@fifthhorseman.net> This documentation is based on sshkey_private_serialize() in sshkey.c, which is eventually called by ssh-add. --- PROTOCOL.agent | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/PROTOCOL.agent b/PROTOCOL.agent index c386d16..5188225 100644 --- a/PROTOCOL.agent +++ b/PROTOCOL.agent @@ -252,13 +252,34 @@ RSA certificates may be added with this request: string key_comment constraint[] key_constraints +ED25519 keys may be added with this request: + + byte SSH2_AGENTC_ADD_IDENTITY or + SSH2_AGENTC_ADD_ID_CONSTRAINED + string "ssh-ed25519" + mpint ed25519_pk + mpint ed25519_sk + string key_comment + constraint[] key_constraints + +ED25519 certificates may be added with this request: + + byte SSH2_AGENTC_ADD_IDENTITY or + SSH2_AGENTC_ADD_ID_CONSTRAINED + string "ssh-ed25519-cert-v01 at openssh.com" + string certificate + mpint ed25519_pk + mpint ed25519_sk + string key_comment + constraint[] key_constraints + Note that the 'rsa_p' and 'rsa_q' parameters are sent in the reverse order to the protocol 1 add keys message. As with the corresponding protocol 1 "add key" request, the private key is overspecified to avoid redundant processing. -For DSA, ECDSA and RSA key add requests, "key_constraints" may only be -present if the request type is SSH2_AGENTC_ADD_ID_CONSTRAINED. +For DSA, ECDSA, RSA, and ED25519 key add requests, "key_constraints" may +only be present if the request type is SSH2_AGENTC_ADD_ID_CONSTRAINED. The agent will reply with a SSH_AGENT_SUCCESS if the key has been successfully added or a SSH_AGENT_FAILURE if an error occurred. -- 2.8.1 From regmemail at gmail.com Thu May 19 06:21:21 2016 From: regmemail at gmail.com (Sileshi Kassa) Date: Wed, 18 May 2016 15:21:21 -0500 Subject: Remote ssh intermittent failure with exit status 143 Message-ID: I use remote ssh echo command as heartbeat to probe remote server is alive. After days of running, I get an intermittent ssh exit status 143 (143 - 128 = 15 ) which is SIGTERM. The remote echo command over ssh runs every minute using public key authentication: /usr/bin/ssh -v -o ServerAliveInterval=60 -i ~/.ssh/public-key.rsa -l foo echo Using openssh client/server version 7.1.P2, both hosts are running CentOS 5.x I am unable to recreate it in standalone script, but happens in production. Any help in this regard is appreciated. I have checked that ssh session is not killed by kernel OOM-killer, but it seems to fail when the system is stressed. #!/bin/bash # secondary network interfaces: 10.0.0.1 and 10.0.0.2 if [ -z "$1" ] then echo "missing required peer IP address" exit fi peeripaddr=$1 while : do /usr/bin/ssh -v -o ServerAliveInterval=60 -i ~/.ssh/public-key.rsa -l foo $peeripaddr echo rc=$? if [ $rc -gt 0 ] then echo "ssh echo command has failed rc=$rc" exit fi sleep 5 From djm at mindrot.org Thu May 19 17:51:32 2016 From: djm at mindrot.org (Damien Miller) Date: Thu, 19 May 2016 17:51:32 +1000 (AEST) Subject: [PATCH] Document transfer of ed25519 secret keys to the ssh-agent In-Reply-To: <1463572365-2139-1-git-send-email-dkg@fifthhorseman.net> References: <1463572365-2139-1-git-send-email-dkg@fifthhorseman.net> Message-ID: you're too late :) https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.agent#L209 Also, work-in-progress: https://github.com/djmdjm/drafts/blob/master/draft-miller-ssh-agent.txt On Wed, 18 May 2016, Daniel Kahn Gillmor wrote: > This documentation is based on sshkey_private_serialize() in sshkey.c, > which is eventually called by ssh-add. > --- > PROTOCOL.agent | 25 +++++++++++++++++++++++-- > 1 file changed, 23 insertions(+), 2 deletions(-) > > diff --git a/PROTOCOL.agent b/PROTOCOL.agent > index c386d16..5188225 100644 > --- a/PROTOCOL.agent > +++ b/PROTOCOL.agent > @@ -252,13 +252,34 @@ RSA certificates may be added with this request: > string key_comment > constraint[] key_constraints > > +ED25519 keys may be added with this request: > + > + byte SSH2_AGENTC_ADD_IDENTITY or > + SSH2_AGENTC_ADD_ID_CONSTRAINED > + string "ssh-ed25519" > + mpint ed25519_pk > + mpint ed25519_sk > + string key_comment > + constraint[] key_constraints > + > +ED25519 certificates may be added with this request: > + > + byte SSH2_AGENTC_ADD_IDENTITY or > + SSH2_AGENTC_ADD_ID_CONSTRAINED > + string "ssh-ed25519-cert-v01 at openssh.com" > + string certificate > + mpint ed25519_pk > + mpint ed25519_sk > + string key_comment > + constraint[] key_constraints > + > Note that the 'rsa_p' and 'rsa_q' parameters are sent in the reverse > order to the protocol 1 add keys message. As with the corresponding > protocol 1 "add key" request, the private key is overspecified to avoid > redundant processing. > > -For DSA, ECDSA and RSA key add requests, "key_constraints" may only be > -present if the request type is SSH2_AGENTC_ADD_ID_CONSTRAINED. > +For DSA, ECDSA, RSA, and ED25519 key add requests, "key_constraints" may > +only be present if the request type is SSH2_AGENTC_ADD_ID_CONSTRAINED. > > The agent will reply with a SSH_AGENT_SUCCESS if the key has been > successfully added or a SSH_AGENT_FAILURE if an error occurred. > -- > 2.8.1 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From klara.mall at kit.edu Fri May 20 00:49:28 2016 From: klara.mall at kit.edu (Klara Mall) Date: Thu, 19 May 2016 16:49:28 +0200 Subject: ssh-keyscan of an sshd with legacy kex alg only Message-ID: <20160519144928.GA21594@shostakovich.local> Hi, with openssh client version 7.2 it's not possible to use ssh-keyscan to scan ssh servers that support diffie-hellman-group1-sha1 only. It is because for ssh-keyscan KEX_CLIENT_KEX is hard coded. ssh by itself is working because you can specify additional kex algorithms with -o which is not available for ssh-keyscan. Hence I think ssh-keyscan should still support the old ciphers. diffie-hellman-group1-sha1 was removed from KEX_CLIENT_KEX here: https://github.com/openssh/openssh-portable/commit/bdfd29f60b74f3e678297269dc6247a5699583c1 Regards Klara From marcus.hann at dexdyne.com Sat May 21 01:07:37 2016 From: marcus.hann at dexdyne.com (Marcus Hann) Date: Fri, 20 May 2016 15:07:37 +0000 (UTC) Subject: Directory listing fails for specific user In-Reply-To: <835265320.187641.1463756636021.JavaMail.root@dexdyne.com> Message-ID: <1161156140.187778.1463756857120.JavaMail.root@dexdyne.com> Hello, We have recently had a new problem with one of the users on one of our servers. Filezilla claims it connects and authenticates, but then fails to list the directory (although no error message is output, it just eventually times out. There is the full output of filezilla located here: http://pastebin.com/tAVcSP8Y. >From the server side, the most verbose output I can make it print can be found here: http://pastebin.com/iW4BqALf. I have set the debug level to DEBUG3 in the /etc/ssh/sshd_config line which now looks like: Subsystem sftp /usr/libexec/openssh/sftp-server -l DEBUG3 And that is what came out. SSH works as expected for the user and I cannot think of anything that has changed that would cause it to stop working. I do not get the same issue for other users on the same server. For example, the output of a working user connecting to the same server is: http://pastebin.com/6VtcCPhg (filezilla) and http://pastebin.com/9ETc8JSS (openssh). I'm at a complete loss as to what may be causing this and cannot find anyone on t'internet with the same issue. Thanks in advance, Marcus From philipp.marek at linbit.com Mon May 23 15:37:03 2016 From: philipp.marek at linbit.com (Philipp Marek) Date: Mon, 23 May 2016 07:37:03 +0200 Subject: Directory listing fails for specific user In-Reply-To: <1161156140.187778.1463756857120.JavaMail.root@dexdyne.com> References: <835265320.187641.1463756636021.JavaMail.root@dexdyne.com> <1161156140.187778.1463756857120.JavaMail.root@dexdyne.com> Message-ID: <20160523053702.GJ20243@cacao.linbit> > We have recently had a new problem with one of the users on one of our servers. > > Filezilla claims it connects and authenticates, but then fails to list > the directory (although no error message is output, it just eventually > times out. There is the full output of filezilla located here: > http://pastebin.com/tAVcSP8Y. ... > I do not get the same issue for other users on the same server. For > example, the output of a working user connecting to the same server is: > http://pastebin.com/6VtcCPhg (filezilla) and http://pastebin.com/9ETc8JSS > (openssh). I'm at a complete loss as to what may be causing this and > cannot find anyone on t'internet with the same issue. PMTU detection goes wrong, and the specific user has a directory with too many entries? Try to list /usr/bin/ as various users, and/or reduce the MTU for testing. From dtucker at zip.com.au Mon May 23 15:49:20 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 23 May 2016 15:49:20 +1000 Subject: Directory listing fails for specific user In-Reply-To: <20160523053702.GJ20243@cacao.linbit> References: <835265320.187641.1463756636021.JavaMail.root@dexdyne.com> <1161156140.187778.1463756857120.JavaMail.root@dexdyne.com> <20160523053702.GJ20243@cacao.linbit> Message-ID: On Mon, May 23, 2016 at 3:37 PM, Philipp Marek wrote: > [...] > PMTU detection goes wrong, and the specific user has a directory with too > many entries? > > Try to list /usr/bin/ as various users, and/or reduce the MTU for testing. > Another useful indicator: while the connection is in the hung state, run "netstat" on both ends and figure out which line corresponds to the hung connection. If the "SendQ" entry (on the server side, probably) is non-zero and non-decreasing that indicates that TCP can't deliver the packets, in which case it's probably an MTU black hole. -- 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 hecht at hlrs.de Wed May 25 03:54:00 2016 From: hecht at hlrs.de (Martin Hecht) Date: Tue, 24 May 2016 19:54:00 +0200 Subject: Directory listing fails for specific user In-Reply-To: <1161156140.187778.1463756857120.JavaMail.root@dexdyne.com> References: <1161156140.187778.1463756857120.JavaMail.root@dexdyne.com> Message-ID: <57449538.2000609@hlrs.de> Hi, we had a similar issue when one of our users has modified his .bashrc such that it was supposed to execute commands upon login, but they were called without absolute path and stored in non-default locations (i.e. a prior modification of the $PATH by profile.d was required). In an interactive bash a full profile was loaded and therefore it worked, but transferring files did not work, because that was not a login shell and thus the commands were not found and caused the error. Putting the commands into .profile instead of .bashrc solved the problem. That was Scientific Linux 6 (a RHEL clone), and I think it was with scp and not with sftp, but it might be related). Martin On 20.05.2016 17:07, Marcus Hann wrote: > Hello, > > We have recently had a new problem with one of the users on one of our servers. > > Filezilla claims it connects and authenticates, but then fails to list the directory (although no error message is output, it just eventually times out. There is the full output of filezilla located here: http://pastebin.com/tAVcSP8Y. > > From the server side, the most verbose output I can make it print can be found here: http://pastebin.com/iW4BqALf. I have set the debug level to DEBUG3 in the /etc/ssh/sshd_config line which now looks like: > > Subsystem sftp /usr/libexec/openssh/sftp-server -l DEBUG3 > > And that is what came out. SSH works as expected for the user and I cannot think of anything that has changed that would cause it to stop working. > > I do not get the same issue for other users on the same server. For example, the output of a working user connecting to the same server is: http://pastebin.com/6VtcCPhg (filezilla) and http://pastebin.com/9ETc8JSS (openssh). I'm at a complete loss as to what may be causing this and cannot find anyone on t'internet with the same issue. > > Thanks in advance, > Marcus > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2252 bytes Desc: S/MIME Cryptographic Signature URL: From marcus.hann at dexdyne.com Fri May 27 17:20:01 2016 From: marcus.hann at dexdyne.com (Marcus Hann) Date: Fri, 27 May 2016 07:20:01 +0000 (UTC) Subject: Directory listing fails for specific user In-Reply-To: <57449538.2000609@hlrs.de> References: <1161156140.187778.1463756857120.JavaMail.root@dexdyne.com> <57449538.2000609@hlrs.de> Message-ID: <96303285.225402.1464333601882.JavaMail.root@dexdyne.com> Hi Martin, Thanks for that, our problem was indeed that someone had edited .bashrc and had added echo lines to create a MOTD effect - having moved these to /etc/motd everything is working as expected now. Thanks, Marcus ----- Original Message ----- From: "Martin Hecht" To: "Marcus Hann" , openssh-unix-dev at mindrot.org Sent: Tuesday, 24 May, 2016 6:54:00 PM Subject: Re: Directory listing fails for specific user Hi, we had a similar issue when one of our users has modified his .bashrc such that it was supposed to execute commands upon login, but they were called without absolute path and stored in non-default locations (i.e. a prior modification of the $PATH by profile.d was required). In an interactive bash a full profile was loaded and therefore it worked, but transferring files did not work, because that was not a login shell and thus the commands were not found and caused the error. Putting the commands into .profile instead of .bashrc solved the problem. That was Scientific Linux 6 (a RHEL clone), and I think it was with scp and not with sftp, but it might be related). Martin On 20.05.2016 17:07, Marcus Hann wrote: > Hello, > > We have recently had a new problem with one of the users on one of our servers. > > Filezilla claims it connects and authenticates, but then fails to list the directory (although no error message is output, it just eventually times out. There is the full output of filezilla located here: http://pastebin.com/tAVcSP8Y. > > From the server side, the most verbose output I can make it print can be found here: http://pastebin.com/iW4BqALf. I have set the debug level to DEBUG3 in the /etc/ssh/sshd_config line which now looks like: > > Subsystem sftp /usr/libexec/openssh/sftp-server -l DEBUG3 > > And that is what came out. SSH works as expected for the user and I cannot think of anything that has changed that would cause it to stop working. > > I do not get the same issue for other users on the same server. For example, the output of a working user connecting to the same server is: http://pastebin.com/6VtcCPhg (filezilla) and http://pastebin.com/9ETc8JSS (openssh). I'm at a complete loss as to what may be causing this and cannot find anyone on t'internet with the same issue. > > Thanks in advance, > Marcus > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From vinschen at redhat.com Mon May 30 18:30:18 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 30 May 2016 10:30:18 +0200 Subject: Fix a missing option in Cygwin README Message-ID: <20160530083018.GA4636@calimero.vinschen.de> Hi guys, the Cygwin README file misses to explain an option to the ssh-host-config script. Patch attached. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- From a1cce42ae640bf7c0bff3c3ed082046f80321370 Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Mon, 30 May 2016 10:29:25 +0200 Subject: [PATCH] Add missing ssh-host-config --name option to Cygwin README Signed-off-by: Corinna Vinschen --- contrib/cygwin/README | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/cygwin/README b/contrib/cygwin/README index 1396d99..a73a0f6 100644 --- a/contrib/cygwin/README +++ b/contrib/cygwin/README @@ -25,6 +25,7 @@ Options: --yes -y Answer all questions with "yes" automatically. --no -n Answer all questions with "no" automatically. --cygwin -c Use "options" as value for CYGWIN environment var. + --name -N sshd windows service name. --port -p sshd listens on port n. --user -u privileged user for service, default 'cyg_server'. --pwd -w Use "pwd" as password for privileged user. -- 2.5.5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dtucker at zip.com.au Mon May 30 19:37:24 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 30 May 2016 19:37:24 +1000 Subject: Fix a missing option in Cygwin README In-Reply-To: <20160530083018.GA4636@calimero.vinschen.de> References: <20160530083018.GA4636@calimero.vinschen.de> Message-ID: On Mon, May 30, 2016 at 6:30 PM, Corinna Vinschen wrote: > Hi guys, > > the Cygwin README file misses to explain an option to the ssh-host-config > script. Patch attached. > 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.