From diochnos at gmail.com Wed Jun 1 00:59:51 2016 From: diochnos at gmail.com (Dimitris Diochnos) Date: Tue, 31 May 2016 10:59:51 -0400 Subject: On automatic MAC selection in OpenSSH_6.7p1 + OpenSSL 1.0.1k Message-ID: Dear All, I am writing this email because of some observed strange behavior of ssh. I think this is some sort of complement of the issue that was discussed in [1] ([2, 3, 4, 5, 6] were related to the issue). Long story short, I have a client and a server, both running the latest raspbian jessie with all the relevant updates in two different countries (i.e. both OpenSSH_6.7p1 Raspbian-5+deb8u2, OpenSSL 1.0.1k 8 Jan 2015). When I attempt to ssh from one to the other one (direction: country B --> country A) using the command $ ssh -p PPPP user at host then the connection times out after about 2 minutes and I get the error message `Connection closed by `. (So, it is not the message `connection reset by peer` that was present in [1].) Inspecting the configuration for the established link using `-v` I can see that the cipher selected is `aes128-ctr`, the message authentication code (mac) is `umac-64-etm at openssh.com` and the compression is `none`. If I now go ahead and use the command $ ssh -m umac-64-etm at openssh.com -p PPPP user at host quite surprisingly, the key exchange issue that I have above has disappeared and I can connect to the remote machine from country B to country A. Further, specifying only the cipher on command line does not resolve the issue; i.e. using $ ssh -c aes128-ctr -p PPPPP user at host the key exchange times out again. Finally, the combined $ ssh -c aes128-ctr -m umac-64-etm at openssh.com -p PPPPP user at host also works. To make things even weirder, when I attempt to ssh between the two machines in the opposite direction (country A --> country B), then the simple $ ssh -p PPPP user at host command works as expected using exactly the same configuration. That is, I do not have to specify the message authentication code (recall that both machines are raspberry pi's running the latest raspbian jessie, OpenSSH_6.7p1 and OpenSSL 1.0.1k). On another note, lowering the MTU size (which was another workaround for [1]) also allows me to pass successfully the key exchange phase in the direction where I normally have an issue (that is, country B --> country A). The maximum MTU size that would allow me to pass the key exchange negotiation was 1458 (that is, with a size of 1459 the key exchange got stuck). My first attempt to resolve the situation was in Raspberry Pi Stack Exchange in thread [7]. Since the issue was not resolved there, I posted the issue in Super User Stack Exchange in thread [8]. It was this thread that made me aware of the issue in [1] where by lowering the MTU size was a viable solution. However, this may not be the only issue here, because, as explained above, automatic configuration of MAC leads to failure (but then again, only in one direction of establishing the link). If you need more details on the output or the configurations that I am using I am happy to provide you with all the relevant information. Meanwhile, if you would like to read an extended version with debug information (`ssh -vv ...`), I would suggest [8] which was written more recently and I think has a better description of the problem. Best regards, Dimitris References [1] ssh 'connection reset by peer' problem since 5.8p1, url: http://lists.mindrot.org/pipermail/openssh-unix-dev/2011-March/029432.html [2] The mysterious case of broken SSH client (?connection reset by peer?), url: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/ [3] Can't login anymore: Read from socket failed: Connection reset by peer, url: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/708493 [4] Connecting to older ssh version has cipher negotiation problem, url: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612607 [5] FS#22897 - [openssh] SSH is falling to connect to some server Read from socket failed: Connection reset by peer, url: https://bugs.archlinux.org/task/22897 [6] ssh client problem: Connection reset by peer [closed], url: http://serverfault.com/questions/265244/ssh-client-problem-connection-reset-by-peer [7] Can not ssh on remote host, url: http://raspberrypi.stackexchange.com/questions/48089/can-not-ssh-on-remote-host [8] Strange ssh connection issue, url: http://superuser.com/questions/1082529/strange-ssh-connection-issue/ From dkg at fifthhorseman.net Wed Jun 1 02:20:43 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 31 May 2016 12:20:43 -0400 Subject: On automatic MAC selection in OpenSSH_6.7p1 + OpenSSL 1.0.1k In-Reply-To: References: Message-ID: <87y46qgpwk.fsf@alice.fifthhorseman.net> On Tue 2016-05-31 10:59:51 -0400, Dimitris Diochnos wrote: > On another note, lowering the MTU size (which was another workaround for > [1]) also allows me to pass successfully the key exchange phase in the > direction where I normally have an issue (that is, country B --> country > A). The maximum MTU size that would allow me to pass the key exchange > negotiation was 1458 (that is, with a size of 1459 the key exchange got > stuck). This is the relevant hint for your connection. It sounds like some element along the network path from B to A is silently dropping packets that are larger than 1458, and your network stack has not detected this situation. When you force the MAC algorithm to be the specific one, you are probably making the ssh handshake negotiation packets each be small enough to fit into the smaller MTU. As such, i think this is a networking configuration issue, and not something for ssh to try to fix. Maybe the fix belongs in your TCP stack, or in your network configuration? Sounds frustrating! --dkg From diochnos at gmail.com Wed Jun 1 03:22:06 2016 From: diochnos at gmail.com (Dimitris Diochnos) Date: Tue, 31 May 2016 13:22:06 -0400 Subject: On automatic MAC selection in OpenSSH_6.7p1 + OpenSSL 1.0.1k In-Reply-To: <87y46qgpwk.fsf@alice.fifthhorseman.net> References: <87y46qgpwk.fsf@alice.fifthhorseman.net> Message-ID: I can understand that some element along the path from B to A is silently dropping packets larger than 1458. However, the other point that I am making is that when MTU is set to the default 1500 (as reported by ifconfig) then, the command ssh -p PPPP user at host fails (selecting automatically for mac umac-64-etm at openssh.com), while the command ssh -m umac-64-etm at openssh.com -p PPPP user at host succeeds. In this sense, both commands are executed with MTU=1500 but ssh does behave differently in these two situations without me having to change anything in my network configuration. Thus a reasonable (?) guess is that perhaps ssh does not set all the necessary flags and options correctly when umac-64-etm at openssh.com is set automatically during the negotiation, but does set all the necessary flags and options correctly when the same mac is specified as a command line parameter. Perhaps my guess is incorrect (after all I have no real knowledge on this matter), but I thought it would be best if I report this. My apologies if this is spamming the mailing list. Best regards, Dimitris On Tue, May 31, 2016 at 12:20 PM, Daniel Kahn Gillmor wrote: > > On Tue 2016-05-31 10:59:51 -0400, Dimitris Diochnos wrote: > > On another note, lowering the MTU size (which was another workaround for > > [1]) also allows me to pass successfully the key exchange phase in the > > direction where I normally have an issue (that is, country B --> country > > A). The maximum MTU size that would allow me to pass the key exchange > > negotiation was 1458 (that is, with a size of 1459 the key exchange got > > stuck). > > This is the relevant hint for your connection. It sounds like some > element along the network path from B to A is silently dropping packets > that are larger than 1458, and your network stack has not detected this > situation. > > When you force the MAC algorithm to be the specific one, you are > probably making the ssh handshake negotiation packets each be small > enough to fit into the smaller MTU. > > As such, i think this is a networking configuration issue, and not > something for ssh to try to fix. Maybe the fix belongs in your TCP > stack, or in your network configuration? > > Sounds frustrating! > > --dkg From alex at alex.org.uk Wed Jun 1 03:29:00 2016 From: alex at alex.org.uk (Alex Bligh) Date: Tue, 31 May 2016 18:29:00 +0100 Subject: On automatic MAC selection in OpenSSH_6.7p1 + OpenSSL 1.0.1k In-Reply-To: References: <87y46qgpwk.fsf@alice.fifthhorseman.net> Message-ID: <07F5B38E-FAE7-4369-AFEF-62C61F8D83F7@alex.org.uk> On 31 May 2016, at 18:22, Dimitris Diochnos wrote: > I can understand that some element along the path from B to A is > silently dropping packets larger than 1458. However, the other point > that I am making is that when MTU is set to the default 1500 (as > reported by ifconfig) then, the command > > ssh -p PPPP user at host > > fails (selecting automatically for mac umac-64-etm at openssh.com), while > the command > > ssh -m umac-64-etm at openssh.com -p PPPP user at host > > succeeds. MTU / MSS problems are notorious for being tickled only by specific data sizes. Your first example happens to use different size packets from the second, causing the TCP window to be within the problematic range. A bit smaller or a bit larger packets will work. Debug the network problem and all will be fine. http://netalyzr.icsi.berkeley.edu/ specifically this test http://netalyzr.icsi.berkeley.edu/info_mtu.html is quite useful though only tests between the browser and the site it runs on. Other tools are also available. -- Alex Bligh From sanumesh at in.ibm.com Wed Jun 1 04:31:54 2016 From: sanumesh at in.ibm.com (Sandeep Umesh) Date: Wed, 1 Jun 2016 00:01:54 +0530 Subject: openssh dependency on openssl Message-ID: <201605311832.u4VINsFl006323@mx0a-001b2d01.pphosted.com> Hello I compiled openssh 7.1p1 with 1.0.2e openSSL header files. These ssh binaries work absolutely fine if 1.0.2 ssl libraries is installed. However, if 1.0.1e ssl libraries is installed, then it gives a error - OpenSSL version mismatch. Built against 1000205f, you have 1000105f I think the dependency of openSSL is more from crypto library and ssh is looking for libcrpyto.so.1.0.0 ssl version. This versioned crypto library is available when both 1.0.2 and 1.0.1 ssl library is installed. Can anyone please provide insights on why this error message is seen ? And how it can be resolved ? In general, is it possible to have the SSH binaries (which is generated by compiling with a higher version of openssl ) working when a lower version of openssl is installed on the machine ? Thanks Regards Sandeep From keisial at gmail.com Wed Jun 1 08:04:35 2016 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 01 Jun 2016 00:04:35 +0200 Subject: openssh dependency on openssl In-Reply-To: <201605311832.u4VINsFl006323@mx0a-001b2d01.pphosted.com> References: <201605311832.u4VINsFl006323@mx0a-001b2d01.pphosted.com> Message-ID: <574E0A73.4010403@gmail.com> On 31/05/16 20:31, Sandeep Umesh wrote: > In general, is it possible to have the SSH binaries (which is generated by > compiling with a higher version of openssl ) working when a lower version > of openssl is installed on the machine ? Thanks In general, you should do it the opposite way. Compile with the lowest supported library version, and it will work with an higher one. Going backwards is unlikely to be supported by the libraries internals. Note however, that ssh doesn't cry when "going backwards" within the patch series (just like going forward won't generate such notice). Regards From dtucker at zip.com.au Wed Jun 1 09:44:00 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 1 Jun 2016 09:44:00 +1000 Subject: On automatic MAC selection in OpenSSH_6.7p1 + OpenSSL 1.0.1k In-Reply-To: References: <87y46qgpwk.fsf@alice.fifthhorseman.net> Message-ID: On Wed, Jun 1, 2016 at 3:22 AM, Dimitris Diochnos wrote: > [...] > In this sense, both commands are executed with MTU=1500 but ssh does > behave differently in these two situations without me having to change > anything in my network configuration. The thing ssh does differently in these two instances is that when you don't specify -m, it uses the default MACs list which can be reasonably long. If you look at the output of ssh -vv you'll see something like this: debug2: kex_parse_kexinit: umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-sha1 which in my case is 214 bytes, compared to 24 bytes when you specify umac64. You'll likely see similar behaviour if you specify the Ciphers or KexAlgorithms. > Thus a reasonable (?) guess is > that perhaps ssh does not set all the necessary flags and options > correctly when umac-64-etm at openssh.com is set automatically during the > negotiation Nope, it doesn't do anything different with regard to network options and such. You did an good job figuring out that your network is broken, but that's what you need to fix to resolve your problem. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From rian at thelig.ht Thu Jun 2 12:17:55 2016 From: rian at thelig.ht (Rian Hunter) Date: Thu, 02 Jun 2016 02:17:55 +0000 Subject: [PATCH] Link count attribute extension Message-ID: Hello, This patch adds client and server support for transmitting the st_nlink field across SSH2_FXP_NAME and SSH2_FXP_ATTRS responses. Please let me know if there anything I can do to improve this patch. I am not subscribed to list so please CC me. Index: sftp-common.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp-common.c,v retrieving revision 1.28 diff -u -r1.28 sftp-common.c --- sftp-common.c 20 Jan 2015 23:14:00 -0000 1.28 +++ sftp-common.c 2 Jun 2016 01:32:02 -0000 @@ -56,6 +56,8 @@ a->perm = 0; a->atime = 0; a->mtime = 0; + a->has_nlink = 0; + a->nlink = 0; } /* Convert from struct stat to filexfer attribs */ @@ -74,6 +76,9 @@ a->flags |= SSH2_FILEXFER_ATTR_ACMODTIME; a->atime = st->st_atime; a->mtime = st->st_mtime; + a->flags |= SSH2_FILEXFER_ATTR_EXTENDED; + a->has_nlink = 1; + a->nlink = st->st_nlink; } /* Convert from filexfer attribs to struct stat */ @@ -94,6 +99,11 @@ st->st_atime = a->atime; st->st_mtime = a->mtime; } + if (a->flags & SSH2_FILEXFER_ATTR_EXTENDED) { + if (a->has_nlink) { + st->st_nlink = a->nlink; + } + } } /* Decode attributes in buffer */ @@ -138,6 +148,15 @@ return r; debug3("Got file attribute \"%.100s\" len %zu", type, dlen); + if (strcmp(type, SFTP_EXT_ATTR_LINK_COUNT) == 0) { + if (dlen < 8) { + return SSH_ERR_MESSAGE_INCOMPLETE; + free(type); + free(data); + } + a->has_nlink = 1; + a->nlink = PEEK_U64(data); + } free(type); free(data); } @@ -170,6 +189,24 @@ if ((r = sshbuf_put_u32(b, a->atime)) != 0 || (r = sshbuf_put_u32(b, a->mtime)) != 0) return r; + } + if (a->flags & SSH2_FILEXFER_ATTR_EXTENDED) { + u_int32_t count = 0; + if (a->has_nlink) { + count += 1; + } + + if (count) { + if ((r = sshbuf_put_u32(b, count)) != 0) + return r; + + if (a->has_nlink) { + if ((r = sshbuf_put_cstring(b, SFTP_EXT_ATTR_LINK_COUNT)) != 0 || + (r = sshbuf_put_u32(b, 8)) != 0 || + (r = sshbuf_put_u64(b, a->nlink))) + return r; + } + } } return 0; } Index: sftp-common.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp-common.h,v retrieving revision 1.12 diff -u -r1.12 sftp-common.h --- sftp-common.h 14 Jan 2015 13:54:13 -0000 1.12 +++ sftp-common.h 2 Jun 2016 01:32:02 -0000 @@ -40,6 +40,8 @@ u_int32_t perm; u_int32_t atime; u_int32_t mtime; + u_int32_t has_nlink; + u_int64_t nlink; }; void attrib_clear(Attrib *); @@ -50,3 +52,5 @@ char *ls_file(const char *, const struct stat *, int, int); const char *fx2txt(int); + +#define SFTP_EXT_ATTR_LINK_COUNT "attr-link-count at openssh.com" Index: sftp-server.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp-server.c,v retrieving revision 1.109 diff -u -r1.109 sftp-server.c --- sftp-server.c 15 Feb 2016 09:47:49 -0000 1.109 +++ sftp-server.c 2 Jun 2016 01:32:02 -0000 @@ -659,6 +659,9 @@ (r = sshbuf_put_cstring(msg, "1")) != 0 || /* version */ /* fsync extension */ (r = sshbuf_put_cstring(msg, "fsync at openssh.com")) != 0 || + (r = sshbuf_put_cstring(msg, "1")) != 0 || /* version */ + /* attr link count extension */ + (r = sshbuf_put_cstring(msg, SFTP_EXT_ATTR_LINK_COUNT)) != 0 || (r = sshbuf_put_cstring(msg, "1")) != 0) /* version */ fatal("%s: buffer error: %s", __func__, ssh_err(r)); send_msg(msg); From djm at mindrot.org Thu Jun 2 12:45:21 2016 From: djm at mindrot.org (Damien Miller) Date: Thu, 2 Jun 2016 12:45:21 +1000 (AEST) Subject: [PATCH] Link count attribute extension In-Reply-To: References: Message-ID: Hi, Thanks for the patch! Could I ask you to create a bug on https://bugzilla.mindrot.org/ and attach it so it doesn't get lost? Thanks, Damien Miller On Thu, 2 Jun 2016, Rian Hunter wrote: > Hello, > > This patch adds client and server support for transmitting the st_nlink field > across SSH2_FXP_NAME and SSH2_FXP_ATTRS responses. > > Please let me know if there anything I can do to improve this patch. I am > not subscribed to list so please CC me. > > Index: sftp-common.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/sftp-common.c,v > retrieving revision 1.28 > diff -u -r1.28 sftp-common.c > --- sftp-common.c 20 Jan 2015 23:14:00 -0000 1.28 > +++ sftp-common.c 2 Jun 2016 01:32:02 -0000 > @@ -56,6 +56,8 @@ > a->perm = 0; > a->atime = 0; > a->mtime = 0; > + a->has_nlink = 0; > + a->nlink = 0; > } > > /* Convert from struct stat to filexfer attribs */ > @@ -74,6 +76,9 @@ > a->flags |= SSH2_FILEXFER_ATTR_ACMODTIME; > a->atime = st->st_atime; > a->mtime = st->st_mtime; > + a->flags |= SSH2_FILEXFER_ATTR_EXTENDED; > + a->has_nlink = 1; > + a->nlink = st->st_nlink; > } > > /* Convert from filexfer attribs to struct stat */ > @@ -94,6 +99,11 @@ > st->st_atime = a->atime; > st->st_mtime = a->mtime; > } > + if (a->flags & SSH2_FILEXFER_ATTR_EXTENDED) { > + if (a->has_nlink) { > + st->st_nlink = a->nlink; > + } > + } > } > > /* Decode attributes in buffer */ > @@ -138,6 +148,15 @@ > return r; > debug3("Got file attribute \"%.100s\" len %zu", > type, dlen); > + if (strcmp(type, SFTP_EXT_ATTR_LINK_COUNT) == 0) { > + if (dlen < 8) { > + return SSH_ERR_MESSAGE_INCOMPLETE; > + free(type); > + free(data); > + } > + a->has_nlink = 1; > + a->nlink = PEEK_U64(data); > + } > free(type); > free(data); > } > @@ -170,6 +189,24 @@ > if ((r = sshbuf_put_u32(b, a->atime)) != 0 || > (r = sshbuf_put_u32(b, a->mtime)) != 0) > return r; > + } > + if (a->flags & SSH2_FILEXFER_ATTR_EXTENDED) { > + u_int32_t count = 0; > + if (a->has_nlink) { > + count += 1; > + } > + > + if (count) { > + if ((r = sshbuf_put_u32(b, count)) != 0) > + return r; > + > + if (a->has_nlink) { > + if ((r = sshbuf_put_cstring(b, SFTP_EXT_ATTR_LINK_COUNT)) != 0 || > + (r = sshbuf_put_u32(b, 8)) != 0 || > + (r = sshbuf_put_u64(b, a->nlink))) > + return r; > + } > + } > } > return 0; > } > Index: sftp-common.h > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/sftp-common.h,v > retrieving revision 1.12 > diff -u -r1.12 sftp-common.h > --- sftp-common.h 14 Jan 2015 13:54:13 -0000 1.12 > +++ sftp-common.h 2 Jun 2016 01:32:02 -0000 > @@ -40,6 +40,8 @@ > u_int32_t perm; > u_int32_t atime; > u_int32_t mtime; > + u_int32_t has_nlink; > + u_int64_t nlink; > }; > > void attrib_clear(Attrib *); > @@ -50,3 +52,5 @@ > char *ls_file(const char *, const struct stat *, int, int); > > const char *fx2txt(int); > + > +#define SFTP_EXT_ATTR_LINK_COUNT "attr-link-count at openssh.com" > Index: sftp-server.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/sftp-server.c,v > retrieving revision 1.109 > diff -u -r1.109 sftp-server.c > --- sftp-server.c 15 Feb 2016 09:47:49 -0000 1.109 > +++ sftp-server.c 2 Jun 2016 01:32:02 -0000 > @@ -659,6 +659,9 @@ > (r = sshbuf_put_cstring(msg, "1")) != 0 || /* version */ > /* fsync extension */ > (r = sshbuf_put_cstring(msg, "fsync at openssh.com")) != 0 || > + (r = sshbuf_put_cstring(msg, "1")) != 0 || /* version */ > + /* attr link count extension */ > + (r = sshbuf_put_cstring(msg, SFTP_EXT_ATTR_LINK_COUNT)) != 0 || > (r = sshbuf_put_cstring(msg, "1")) != 0) /* version */ > fatal("%s: buffer error: %s", __func__, ssh_err(r)); > send_msg(msg); > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From openssh at mzpqnxow.com Thu Jun 2 11:51:27 2016 From: openssh at mzpqnxow.com (AG) Date: Wed, 1 Jun 2016 21:51:27 -0400 Subject: MaxDisplays configuration option Message-ID: Hello, I manage OpenSSH on a dozen or so servers that act as gateways for a large amount of developers and system administrators. On these servers it is common for there to be more than 1000 active X11 forwards active at peak usage. Beyond ~1000 active X11 forwards, sshd will fail to bind additional ports due to a hard coded range check in channels.c that limits the port range that sshd will attempt to bind. Today this is set at 1000: channels.c:152:#define MAX_DISPLAYS 1000 I have made changes to OpenSSH portable that allow this setting to be configured via an option in sshd_config named MaxDisplays. If not explicitly set, it maintains the default value of 1000. It seems to me that this setting should be configurable by the user similar to how X11DisplayOffset is configurable. I've read the code carefully and am currently using this patch in my production environment without any issues. I don't see any reason this change would cause any issues for users that do not need to explicitly set it. I also don't envision this being a maintenance burden as it's a very simple feature. I'd appreciate this being considered for acceptance into OpenSSH. Also, I'm curious if this issue has ever come up before? Is it really that strange of a case? I understand that you don't utilize GitHub for development, but for convenience you can see the changes in a web browser: https://github.com/openssh/openssh-portable/pull/41 I've attached the patch to this message as well. Thanks, Adam -------------- next part -------------- diff -Naur openssh-portable/channels.c openssh-portable-maxdisplays/channels.c --- openssh-portable/channels.c 2016-06-01 21:14:01.772052924 -0400 +++ openssh-portable-maxdisplays/channels.c 2016-06-01 21:14:22.924053856 -0400 @@ -148,9 +148,6 @@ /* -- X11 forwarding */ -/* Maximum number of fake X11 displays to try. */ -#define MAX_DISPLAYS 1000 - /* Saved X11 local (client) display. */ static char *x11_saved_display = NULL; @@ -3890,7 +3887,8 @@ */ int x11_create_display_inet(int x11_display_offset, int x11_use_localhost, - int single_connection, u_int *display_numberp, int **chanids) + int max_displays, int single_connection, u_int *display_numberp, + int **chanids) { Channel *nc = NULL; int display_number, sock; @@ -3902,8 +3900,11 @@ if (chanids == NULL) return -1; + /* Try max_displays ports starting at the range 6000+X11DisplayOffset */ + max_displays = max_displays + x11_display_offset; + for (display_number = x11_display_offset; - display_number < MAX_DISPLAYS; + display_number < max_displays; display_number++) { port = 6000 + display_number; memset(&hints, 0, sizeof(hints)); @@ -3957,7 +3958,7 @@ if (num_socks > 0) break; } - if (display_number >= MAX_DISPLAYS) { + if (display_number >= max_displays) { error("Failed to allocate internet-domain X11 display socket."); return -1; } diff -Naur openssh-portable/channels.h openssh-portable-maxdisplays/channels.h --- openssh-portable/channels.h 2016-06-01 21:14:01.772052924 -0400 +++ openssh-portable-maxdisplays/channels.h 2016-06-01 21:14:22.924053856 -0400 @@ -286,7 +286,7 @@ void channel_set_x11_refuse_time(u_int); int x11_connect_display(void); -int x11_create_display_inet(int, int, int, u_int *, int **); +int x11_create_display_inet(int, int, int, int, u_int *, int **); int x11_input_open(int, u_int32_t, void *); void x11_request_forwarding_with_spoofing(int, const char *, const char *, const char *, int); diff -Naur openssh-portable/servconf.c openssh-portable-maxdisplays/servconf.c --- openssh-portable/servconf.c 2016-06-01 21:14:01.820052926 -0400 +++ openssh-portable-maxdisplays/servconf.c 2016-06-01 21:14:22.976053858 -0400 @@ -96,6 +96,7 @@ options->print_lastlog = -1; options->x11_forwarding = -1; options->x11_display_offset = -1; + options->max_displays = -1; options->x11_use_localhost = -1; options->permit_tty = -1; options->permit_user_rc = -1; @@ -327,6 +328,8 @@ options->max_authtries = DEFAULT_AUTH_FAIL_MAX; if (options->max_sessions == -1) options->max_sessions = DEFAULT_SESSIONS_MAX; + if (options->max_displays == -1) + options->max_displays = MAX_DISPLAYS; if (options->use_dns == -1) options->use_dns = 0; if (options->client_alive_interval == -1) @@ -429,7 +432,7 @@ sAuthorizedKeysCommand, sAuthorizedKeysCommandUser, sAuthenticationMethods, sHostKeyAgent, sPermitUserRC, sStreamLocalBindMask, sStreamLocalBindUnlink, - sAllowStreamLocalForwarding, sFingerprintHash, + sAllowStreamLocalForwarding, sFingerprintHash, sMaxDisplays, sDeprecated, sUnsupported } ServerOpCodes; @@ -572,6 +575,7 @@ { "streamlocalbindunlink", sStreamLocalBindUnlink, SSHCFG_ALL }, { "allowstreamlocalforwarding", sAllowStreamLocalForwarding, SSHCFG_ALL }, { "fingerprinthash", sFingerprintHash, SSHCFG_GLOBAL }, + { "maxdisplays", sMaxDisplays, SSHCFG_GLOBAL }, { NULL, sBadOption, 0 } }; @@ -1031,7 +1035,15 @@ fatal("%s line %d: Badly formatted port number.", filename, linenum); break; - + case sMaxDisplays: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%s line %d: missing value.",filename, linenum); + if ((options->max_displays = a2port(arg)) == -1) { + error("Invalid MaxDisplays '%s'", arg); + return -1; + } + break; case sServerKeyBits: intptr = &options->server_key_bits; parse_int: @@ -2001,6 +2013,7 @@ M_CP_INTOPT(permit_tty); M_CP_INTOPT(permit_user_rc); M_CP_INTOPT(max_sessions); + M_CP_INTOPT(max_displays); M_CP_INTOPT(max_authtries); M_CP_INTOPT(ip_qos_interactive); M_CP_INTOPT(ip_qos_bulk); @@ -2254,6 +2267,7 @@ dump_cfg_int(sX11DisplayOffset, o->x11_display_offset); dump_cfg_int(sMaxAuthTries, o->max_authtries); dump_cfg_int(sMaxSessions, o->max_sessions); + dump_cfg_int(sMaxDisplays, o->max_displays); dump_cfg_int(sClientAliveInterval, o->client_alive_interval); dump_cfg_int(sClientAliveCountMax, o->client_alive_count_max); dump_cfg_oct(sStreamLocalBindMask, o->fwd_opts.streamlocal_bind_mask); diff -Naur openssh-portable/servconf.h openssh-portable-maxdisplays/servconf.h --- openssh-portable/servconf.h 2016-06-01 21:14:01.820052926 -0400 +++ openssh-portable-maxdisplays/servconf.h 2016-06-01 21:14:22.976053858 -0400 @@ -29,6 +29,7 @@ #define MAX_MATCH_GROUPS 256 /* Max # of groups for Match. */ #define MAX_AUTHKEYS_FILES 256 /* Max # of authorized_keys files. */ #define MAX_AUTH_METHODS 256 /* Max # of AuthenticationMethods. */ +#define MAX_DISPLAYS 1000 /* Maximum number of fake X11 displays to try. */ /* permit_root_login */ #define PERMIT_NOT_SET -1 @@ -154,6 +155,7 @@ int max_startups; int max_authtries; int max_sessions; + int max_displays; char *banner; /* SSH-2 banner message */ int use_dns; int client_alive_interval; /* diff -Naur openssh-portable/session.c openssh-portable-maxdisplays/session.c --- openssh-portable/session.c 2016-06-01 21:14:01.820052926 -0400 +++ openssh-portable-maxdisplays/session.c 2016-06-01 21:14:22.980053858 -0400 @@ -2701,8 +2701,9 @@ return 0; } if (x11_create_display_inet(options.x11_display_offset, - options.x11_use_localhost, s->single_connection, - &s->display_number, &s->x11_chanids) == -1) { + options.x11_use_localhost, options.max_displays, + s->single_connection, &s->display_number, + &s->x11_chanids) == -1) { debug("x11_create_display_inet failed."); return 0; } From rian at thelig.ht Thu Jun 2 16:45:31 2016 From: rian at thelig.ht (rian at thelig.ht) Date: Wed, 01 Jun 2016 23:45:31 -0700 Subject: [PATCH] Link count attribute extension In-Reply-To: References: Message-ID: <090a8e07007247dd22d4575ac40e12f9@thelig.ht> Sure, now located at https://bugzilla.mindrot.org/show_bug.cgi?id=2579 On 2016-06-01 19:45, Damien Miller wrote: > Hi, > > Thanks for the patch! Could I ask you to create a bug on > https://bugzilla.mindrot.org/ and attach it so it doesn't get lost? > > Thanks, > Damien Miller > > On Thu, 2 Jun 2016, Rian Hunter wrote: > >> Hello, >> >> This patch adds client and server support for transmitting the >> st_nlink field >> across SSH2_FXP_NAME and SSH2_FXP_ATTRS responses. >> >> Please let me know if there anything I can do to improve this patch. I >> am >> not subscribed to list so please CC me. >> >> Index: sftp-common.c >> =================================================================== >> RCS file: /cvs/src/usr.bin/ssh/sftp-common.c,v >> retrieving revision 1.28 >> diff -u -r1.28 sftp-common.c >> --- sftp-common.c 20 Jan 2015 23:14:00 -0000 1.28 >> +++ sftp-common.c 2 Jun 2016 01:32:02 -0000 >> @@ -56,6 +56,8 @@ >> a->perm = 0; >> a->atime = 0; >> a->mtime = 0; >> + a->has_nlink = 0; >> + a->nlink = 0; >> } >> >> /* Convert from struct stat to filexfer attribs */ >> @@ -74,6 +76,9 @@ >> a->flags |= SSH2_FILEXFER_ATTR_ACMODTIME; >> a->atime = st->st_atime; >> a->mtime = st->st_mtime; >> + a->flags |= SSH2_FILEXFER_ATTR_EXTENDED; >> + a->has_nlink = 1; >> + a->nlink = st->st_nlink; >> } >> >> /* Convert from filexfer attribs to struct stat */ >> @@ -94,6 +99,11 @@ >> st->st_atime = a->atime; >> st->st_mtime = a->mtime; >> } >> + if (a->flags & SSH2_FILEXFER_ATTR_EXTENDED) { >> + if (a->has_nlink) { >> + st->st_nlink = a->nlink; >> + } >> + } >> } >> >> /* Decode attributes in buffer */ >> @@ -138,6 +148,15 @@ >> return r; >> debug3("Got file attribute \"%.100s\" len %zu", >> type, dlen); >> + if (strcmp(type, SFTP_EXT_ATTR_LINK_COUNT) == 0) { >> + if (dlen < 8) { >> + return SSH_ERR_MESSAGE_INCOMPLETE; >> + free(type); >> + free(data); >> + } >> + a->has_nlink = 1; >> + a->nlink = PEEK_U64(data); >> + } >> free(type); >> free(data); >> } >> @@ -170,6 +189,24 @@ >> if ((r = sshbuf_put_u32(b, a->atime)) != 0 || >> (r = sshbuf_put_u32(b, a->mtime)) != 0) >> return r; >> + } >> + if (a->flags & SSH2_FILEXFER_ATTR_EXTENDED) { >> + u_int32_t count = 0; >> + if (a->has_nlink) { >> + count += 1; >> + } >> + >> + if (count) { >> + if ((r = sshbuf_put_u32(b, count)) != 0) >> + return r; >> + >> + if (a->has_nlink) { >> + if ((r = sshbuf_put_cstring(b, SFTP_EXT_ATTR_LINK_COUNT)) != 0 || >> + (r = sshbuf_put_u32(b, 8)) != 0 || >> + (r = sshbuf_put_u64(b, a->nlink))) >> + return r; >> + } >> + } >> } >> return 0; >> } >> Index: sftp-common.h >> =================================================================== >> RCS file: /cvs/src/usr.bin/ssh/sftp-common.h,v >> retrieving revision 1.12 >> diff -u -r1.12 sftp-common.h >> --- sftp-common.h 14 Jan 2015 13:54:13 -0000 1.12 >> +++ sftp-common.h 2 Jun 2016 01:32:02 -0000 >> @@ -40,6 +40,8 @@ >> u_int32_t perm; >> u_int32_t atime; >> u_int32_t mtime; >> + u_int32_t has_nlink; >> + u_int64_t nlink; >> }; >> >> void attrib_clear(Attrib *); >> @@ -50,3 +52,5 @@ >> char *ls_file(const char *, const struct stat *, int, int); >> >> const char *fx2txt(int); >> + >> +#define SFTP_EXT_ATTR_LINK_COUNT "attr-link-count at openssh.com" >> Index: sftp-server.c >> =================================================================== >> RCS file: /cvs/src/usr.bin/ssh/sftp-server.c,v >> retrieving revision 1.109 >> diff -u -r1.109 sftp-server.c >> --- sftp-server.c 15 Feb 2016 09:47:49 -0000 1.109 >> +++ sftp-server.c 2 Jun 2016 01:32:02 -0000 >> @@ -659,6 +659,9 @@ >> (r = sshbuf_put_cstring(msg, "1")) != 0 || /* version */ >> /* fsync extension */ >> (r = sshbuf_put_cstring(msg, "fsync at openssh.com")) != 0 || >> + (r = sshbuf_put_cstring(msg, "1")) != 0 || /* version */ >> + /* attr link count extension */ >> + (r = sshbuf_put_cstring(msg, SFTP_EXT_ATTR_LINK_COUNT)) != 0 || >> (r = sshbuf_put_cstring(msg, "1")) != 0) /* version */ >> fatal("%s: buffer error: %s", __func__, ssh_err(r)); >> send_msg(msg); >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> From stu at spacehopper.org Thu Jun 2 19:04:08 2016 From: stu at spacehopper.org (Stuart Henderson) Date: Thu, 2 Jun 2016 09:04:08 +0000 (UTC) Subject: openssh dependency on openssl References: <201605311832.u4VINsFl006323@mx0a-001b2d01.pphosted.com> <574E0A73.4010403@gmail.com> Message-ID: On 2016-05-31, ?ngel Gonz?lez wrote: > On 31/05/16 20:31, Sandeep Umesh wrote: >> In general, is it possible to have the SSH binaries (which is generated by >> compiling with a higher version of openssl ) working when a lower version >> of openssl is installed on the machine ? Thanks > In general, you should do it the opposite way. Compile with the lowest > supported library version, and it will work with an higher one. That's not reliable - OpenSSL do sometimes break the ABI, even between different alphabetic versions with the same numeric branch. Moving between branches (1.0.1, 1.0.2, etc) you're highly likely to have incompatibilities. If you're not in control of the installed libraries on a system that you build binaries for, perhaps statically linking is a better option. It doesn't need to be openssl either, tried ssh -V on a Mac lately? From nkadel at gmail.com Fri Jun 3 15:29:20 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 3 Jun 2016 01:29:20 -0400 Subject: MaxDisplays configuration option In-Reply-To: References: Message-ID: On Wed, Jun 1, 2016 at 9:51 PM, AG wrote: > Hello, > > I manage OpenSSH on a dozen or so servers that act as gateways for a large > amount of developers and system administrators. On these servers it is > common for there to be more than 1000 active X11 forwards active at peak > usage. Beyond ~1000 active X11 forwards, sshd will fail to bind additional > ports due to a hard coded range check in channels.c that limits the port > range that sshd will attempt to bind. Today this is set at 1000: I think your development environment is insane, but that's your problem, not mine. > channels.c:152:#define MAX_DISPLAYS 1000 > > I have made changes to OpenSSH portable that allow this setting to be > configured via an option in sshd_config named MaxDisplays. If not > explicitly set, it maintains the default value of 1000. This would seem a sane approach. I do hope you'll also document the change in the man page for sshd_config? I never have noticed documentation for the "sshd -r" option, though it still seems to exist. Options that are not documented..... are a long source of cofusion for many projects. > It seems to me that this setting should be configurable by the user similar > to how X11DisplayOffset is configurable. I've read the code carefully and > am currently using this patch in my production environment without any > issues. I don't see any reason this change would cause any issues for users > that do not need to explicitly set it. I also don't envision this being a > maintenance burden as it's a very simple feature. > > I'd appreciate this being considered for acceptance into OpenSSH. > > Also, I'm curious if this issue has ever come up before? Is it really that > strange of a case? >From decades in the field, I'd say It's pretty weird. I've not personally seen anything approaching that number of clients on a single server in..... well, not since I worked with Multics back in the 1980's. Dozens on a robust system, yes. One thousand? > I understand that you don't utilize GitHub for development, but for > convenience you can see the changes in a web browser: > > https://github.com/openssh/openssh-portable/pull/41 > > I've attached the patch to this message as well. > > Thanks, > Adam > From arw at cs.fau.de Fri Jun 3 18:52:50 2016 From: arw at cs.fau.de (Alexander Wuerstlein) Date: Fri, 3 Jun 2016 10:52:50 +0200 Subject: MaxDisplays configuration option In-Reply-To: References: Message-ID: <20160603085250.GT7172@cip.informatik.uni-erlangen.de> On 2016-06-03T07:35, Nico Kadel-Garcia wrote: > On Wed, Jun 1, 2016 at 9:51 PM, AG wrote: > > Also, I'm curious if this issue has ever come up before? Is it really that > > strange of a case? > > From decades in the field, I'd say It's pretty weird. I've not > personally seen anything approaching that number of clients on a > single server in..... well, not since I worked with Multics back in > the 1980's. Dozens on a robust system, yes. One thousand? We do have some boxes with concurrent ssh-users in the lower 3-digit range. But in general this seems to be rare, especially since software is often unprepared for and untested in that amount of activity (see e.g. https://github.com/systemd/systemd/issues/1961). For the number of X displays, there was never any issue, usually since CPU and memory resources run out long before you run out of display numbers. Users just pick another box or their laptop, if applications are slow, so the number of X displays is self-limiting ;) Ciao, Alexander Wuerstlein. From openssh at mzpqnxow.com Sun Jun 5 06:00:46 2016 From: openssh at mzpqnxow.com (AG) Date: Sat, 4 Jun 2016 16:00:46 -0400 Subject: MaxDisplays configuration option Message-ID: > > From decades in the field, I'd say It's pretty weird. I've not > personally seen anything approaching that number of clients on a > single server in..... well, not since I worked with Multics back in > the 1980's. Dozens on a robust system, yes. One thousand? >> We do have some boxes with concurrent ssh-users in the lower 3-digit >> range. But in general this seems to be rare, especially since software >> is often unprepared for and untested in that amount of activity (see >> e.g. https://github.com/systemd/systemd/issues/1961). >> >> For the number of X displays, there was never any issue, usually since >> CPU and memory resources run out long before you run out of display >> numbers. Users just pick another box or their laptop, if applications >> are slow, so the number of X displays is self-limiting ;) >> >> >> >> Ciao, >> >> Alexander Wuerstlein. I should clarify, these aren't systems that have users shell access to. It's an X11 forward only, used as a chokepoint into a segregated network. Anyway, I will clean up the patch and add documentation and then report back. I've already created an entry on the bugtracker in case anyone wants to follow along. https://bugzilla.mindrot.org/show_bug.cgi?id=2580 Thx, A From openssh at mzpqnxow.com Sun Jun 5 09:25:58 2016 From: openssh at mzpqnxow.com (AG) Date: Sat, 4 Jun 2016 19:25:58 -0400 Subject: MaxDisplays configuration option In-Reply-To: <20160603085250.GT7172@cip.informatik.uni-erlangen.de> References: <20160603085250.GT7172@cip.informatik.uni-erlangen.de> Message-ID: FYI- I have attached a finalized version of the X11MaxDisplays patch to the mindrot bugzilla. https://bugzilla.mindrot.org/show_bug.cgi?id=2580 The issues with variable naming, whitespace and other style issues are addressed and I've added documentation to sshd_config I appreciate any feedback, but I think this is in pretty good shape to be considered. Thx. A On Fri, Jun 3, 2016 at 4:52 AM, Alexander Wuerstlein wrote: > On 2016-06-03T07:35, Nico Kadel-Garcia wrote: > > On Wed, Jun 1, 2016 at 9:51 PM, AG wrote: > > > Also, I'm curious if this issue has ever come up before? Is it really > that > > > strange of a case? > > > > From decades in the field, I'd say It's pretty weird. I've not > > personally seen anything approaching that number of clients on a > > single server in..... well, not since I worked with Multics back in > > the 1980's. Dozens on a robust system, yes. One thousand? > > We do have some boxes with concurrent ssh-users in the lower 3-digit > range. But in general this seems to be rare, especially since software > is often unprepared for and untested in that amount of activity (see > e.g. https://github.com/systemd/systemd/issues/1961). > > For the number of X displays, there was never any issue, usually since > CPU and memory resources run out long before you run out of display > numbers. Users just pick another box or their laptop, if applications > are slow, so the number of X displays is self-limiting ;) > > > > Ciao, > > Alexander Wuerstlein. > From nkadel at gmail.com Sun Jun 5 10:05:02 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 4 Jun 2016 20:05:02 -0400 Subject: MaxDisplays configuration option In-Reply-To: References: Message-ID: On Sat, Jun 4, 2016 at 4:00 PM, AG wrote: >> >> From decades in the field, I'd say It's pretty weird. I've not >> personally seen anything approaching that number of clients on a >> single server in..... well, not since I worked with Multics back in >> the 1980's. Dozens on a robust system, yes. One thousand? > >>> We do have some boxes with concurrent ssh-users in the lower 3-digit >>> range. But in general this seems to be rare, especially since software >>> is often unprepared for and untested in that amount of activity (see >>> e.g. https://github.com/systemd/systemd/issues/1961). >>> >>> For the number of X displays, there was never any issue, usually since >>> CPU and memory resources run out long before you run out of display >>> numbers. Users just pick another box or their laptop, if applications >>> are slow, so the number of X displays is self-limiting ;) >>> >>> >>> >>> Ciao, >>> >>> Alexander Wuerstlein. > > I should clarify, these aren't systems that have users shell access to. > It's an X11 forward only, used as a chokepoint into a segregated network. > > Anyway, I will clean up the patch and add documentation and then report > back. I've already created an entry on the bugtracker in case anyone wants > to follow along. > > https://bugzilla.mindrot.org/show_bug.cgi?id=2580 > > Thx, > A *Oh*. OK, that suddenly makes a great deal more sense. From openssh at mzpqnxow.com Mon Jun 6 07:30:05 2016 From: openssh at mzpqnxow.com (AG) Date: Sun, 5 Jun 2016 17:30:05 -0400 Subject: Patch for PermitOpen hostname wildcard with fixed port feature Message-ID: Hello, Attached is a patch for anongit OpenSSH: Added FWD_PERMIT_ANY_HOST to add the ability to use an asterisk to mean any hostname matches in a PermitOpen rule. This is simple and looks like this: PermitOpen *:443 One use case here is when OpenSSH is used to be a multi-factor authenticated broker to a specific TCP based service across many servers in a trusted network when the client is in an untrusted network. This patch allows a simple configuration that can allow all forwards to service X without the need to provide a large list of every server on the trusted network in the sshd_config file. Doing doing so is impractical when the trusted network is larger than a few hosts- a large list of hosts in sshd_config would be unwieldy and would need to be updated constantly if the trusted network changes often. This is a real use case for me- I need to provide this type of authenticated and limited access to several thousand systems. In any given week in my environment there might be 2-3 new servers and there might be 2-3 servers that have been decommissioned. This patch is a huge improvement over allowing all ports to all hosts, which is all that I can do at this point without having a huge management headache maintaining a gigantic list. I was very surprised this wasn't supported alongside FWD_PERMIT_ANY_PORT. It's a simple enough change. I wonder if there was any debate on this or if it just slipped through the cracks as an uncommon use case? Note that this doesn't go down the more complex road of allowing more finegrained cases. The '*' is NOT actually a pattern, it is a symbol that means any host. Using *.bah.org will not work and is not intended to work. I'd appreciate this feature being considered for inclusion into the next release of OpenSSH. I have also entered a bug for this: https://bugzilla.mindrot.org/show_bug.cgi?id=2582 Thx. Adam -------------- next part -------------- diff --git a/channels.c b/channels.c index 7ee1f98..ba0d728 100644 --- a/channels.c +++ b/channels.c @@ -138,6 +138,9 @@ static int num_adm_permitted_opens = 0; /* special-case port number meaning allow any port */ #define FWD_PERMIT_ANY_PORT 0 +/* special-case port number meaning allow any host */ +#define FWD_PERMIT_ANY_HOST "*" + /* * If this is true, all opens are permitted. This is the case on the server * on which we have to trust the client anyway, and the user could do @@ -3296,10 +3299,13 @@ open_match(ForwardPermission *allowed_open, const char *requestedhost, if (allowed_open->host_to_connect == NULL) return 0; if (allowed_open->port_to_connect != FWD_PERMIT_ANY_PORT && - allowed_open->port_to_connect != requestedport) - return 0; - if (strcmp(allowed_open->host_to_connect, requestedhost) != 0) - return 0; + allowed_open->port_to_connect != requestedport) + return 0; + + if (strcmp(allowed_open->host_to_connect, FWD_PERMIT_ANY_HOST) != 0 && + strcmp(allowed_open->host_to_connect, requestedhost) != 0) + return 0; + return 1; } From djm at mindrot.org Fri Jun 17 13:54:00 2016 From: djm at mindrot.org (Damien Miller) Date: Fri, 17 Jun 2016 13:54:00 +1000 (AEST) Subject: test, please ignore Message-ID: From nunojpg at gmail.com Sat Jun 18 03:58:40 2016 From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=) Date: Fri, 17 Jun 2016 18:58:40 +0100 Subject: ssh-pkcs11.c Message-ID: Hi, It seems there is a bug with the pkcs11 feature where a zero-length PIN is accepted. I believe this is a bug, since the user might want to press return when asked for the PIN to ignore that slot/key. This is caused at pkcs11_rsa_private_encrypt: snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ", si->token.label); pin = read_passphrase(prompt, RP_ALLOW_EOF); if (pin == NULL) return (-1); /* bail out */ Actually a zero-length PIN will not cause a NULL to be returned, so it will still try to authenticate and fail the PIN login! Also, I think it would be great to support the CKF_* flags to provide some feedback to the user regarding PIN tries left remaining, something like this: if (info.flags & CKF_USER_PIN_COUNT_LOW) printf("WARNING: User PIN count low\n"); else if (info.flags & CKF_USER_PIN_FINAL_TRY) printf("WARNING: User PIN final try\n"); else if (info.flags & CKF_USER_PIN_LOCKED) /* Maybe we should bail out here, or just try to continue? */ printf("WARNING: User PIN reported locked\n"); Thanks, Nuno From alon.barlev at gmail.com Sat Jun 18 04:57:59 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 17 Jun 2016 21:57:59 +0300 Subject: ssh-pkcs11.c In-Reply-To: References: Message-ID: On 17 June 2016 at 20:58, Nuno Gon?alves wrote: > Hi, > > It seems there is a bug with the pkcs11 feature where a zero-length > PIN is accepted. I believe this is a bug, since the user might want to > press return when asked for the PIN to ignore that slot/key. Hi, Empty PIN is valid case, not sure why you want to avoid supporting it. Alon From nunojpg at gmail.com Sat Jun 18 05:45:12 2016 From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=) Date: Fri, 17 Jun 2016 20:45:12 +0100 Subject: ssh-pkcs11.c In-Reply-To: References: Message-ID: On Fri, Jun 17, 2016 at 7:57 PM, Alon Bar-Lev wrote: > On 17 June 2016 at 20:58, Nuno Gon?alves wrote: >> Hi, >> >> It seems there is a bug with the pkcs11 feature where a zero-length >> PIN is accepted. I believe this is a bug, since the user might want to >> press return when asked for the PIN to ignore that slot/key. > > Hi, > > Empty PIN is valid case, not sure why you want to avoid supporting it. > > Alon I didn't know it was valid but the reasoning still applies. I don't really know the standard use cases, but I think it could eventually be useful for the user, when asked for the PIN, to decide not enter it. Currently it can only be done by killing ssh. If empty PIN is valid, but eventually not usual, maybe we should ask if the user really wants to try a empty pin or just continue to another authentication option? Regarding the CKF_USER_PIN flags, do you think it is a good idea to implement the warning messages? Thanks, Nuno From alon.barlev at gmail.com Sat Jun 18 06:04:21 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 17 Jun 2016 23:04:21 +0300 Subject: ssh-pkcs11.c In-Reply-To: References: Message-ID: On 17 June 2016 at 22:45, Nuno Gon?alves wrote: > On Fri, Jun 17, 2016 at 7:57 PM, Alon Bar-Lev wrote: >> On 17 June 2016 at 20:58, Nuno Gon?alves wrote: >>> Hi, >>> >>> It seems there is a bug with the pkcs11 feature where a zero-length >>> PIN is accepted. I believe this is a bug, since the user might want to >>> press return when asked for the PIN to ignore that slot/key. >> >> Hi, >> >> Empty PIN is valid case, not sure why you want to avoid supporting it. >> >> Alon > > I didn't know it was valid but the reasoning still applies. I don't > really know the standard use cases, but I think it could eventually be > useful for the user, when asked for the PIN, to decide not enter it. > Currently it can only be done by killing ssh. If empty PIN is valid, > but eventually not usual, maybe we should ask if the user really wants > to try a empty pin or just continue to another authentication option? Not sure what best solution, but ignoring empty PIN is the same as ignoring "cancel" or similar constants, which is more explicit. What's wrong with plain -C, as without PIN there is no use to continue session anyway. > Regarding the CKF_USER_PIN flags, do you think it is a good idea to > implement the warning messages? Most implementations do not support these. Regards, Alon From nunojpg at gmail.com Sat Jun 18 06:09:55 2016 From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=) Date: Fri, 17 Jun 2016 21:09:55 +0100 Subject: ssh-pkcs11.c In-Reply-To: References: Message-ID: On Fri, Jun 17, 2016 at 9:04 PM, Alon Bar-Lev wrote: > Not sure what best solution, but ignoring empty PIN is the same as > ignoring "cancel" or similar constants, which is more explicit. > What's wrong with plain -C, as without PIN there is no use to > continue session anyway. The session could continue with other publickey auth or even password, that could be asked after. Anyway I was confuses by the behaviour as a user, such that it eventually locked my card. I agree there is no clear cut solution, so I'll just live with it as it is. >> Regarding the CKF_USER_PIN flags, do you think it is a good idea to >> implement the warning messages? OpenSC does. I have no idea what is the OpenSC quota for ssh users. Anyway the libraries can be waiting for the clients to support it! I'll provide a patch and hope it is acceptable. Thanks for the replies! Nuno From odelreym at gmail.com Sun Jun 19 04:50:26 2016 From: odelreym at gmail.com (Nacho del Rey) Date: Sat, 18 Jun 2016 20:50:26 +0200 Subject: Strange behaviour with ptmx file descriptors In-Reply-To: References: Message-ID: Hi again Finally I recompiled the ssh to include several 'traps' within the code (channels.c mainly) channel_pre_open(Channel *c, fd_set *readset, fd_set *writeset) { u_int limit = compat20 ? c->remote_window : packet_get_maxsize(); int aux = buffer_len(&c->input); debugnacho("En pre_open c-istate: %d limit %d buffer_len %d c_ostate %d ctl_fd %d\n",c->istate,limit,aux,c->ostate,c->ctl_fd); /* the rest of the function code */ } In normal conditions the buffer_len(&c->input) is adjusting its window size En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 1048495 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 1048495 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 1048415 buffer_len 0 c_ostate 0 ctl_fd -1 ...... time later En pre_open c-istate: 0 limit 1002267 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 1002267 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 1002267 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 998560 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 998560 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 But, If I compare the same trace when the the hand-terminal connects to the application... En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 1048476 buffer_len 0 c_ostate 0 ctl_fd -1 ...... En pre_open c-istate: 0 limit 985 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 647 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 647 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 647 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 647 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 632 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 322 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 322 buffer_len 0 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 It seems the channel_input_window_adjust function is not adjusting rwindow size and it finally comes to zero and it is when the problem appears ( the file-descriptor fd#13 which connects to the application dissapear) So the question is.. who is the responsible in adjusting "channel_input_window_adjust" function? the binary application which runs in the server or on the contrary the ssh client? I ask this question because when I'm connected thru ssh (putty), although I am not sending a keystroke to the server if I'm changing the size of the putty window (using the mouse), I can see the buffer_len(c->input) changes , and I don't have clear in which side (client/server) the rwindow is adjusted Thanks in advance Nacho. 2016-04-20 16:52 GMT+02:00 Nacho del Rey : > Hi Peter > > Can you let me know how to proceed for forward this to the openssh source > code team? > > Regards > > > Nacho del Rey wrote: > >> 6647 1456244042.325310 select(14, [3 9], [], NULL, {900, 0}) = 1 (in > [3], > >> left {892, 12016}) <<-- where id fd#13 ? > > >Can you map this back to the OpenSSH source code? > > > >//Peter > From peter at int19h.net Mon Jun 20 07:14:58 2016 From: peter at int19h.net (Peter Bisroev) Date: Sun, 19 Jun 2016 17:14:58 -0400 Subject: UsePAM documentation clarification in sshd_config. Message-ID: Dear OpenSSH Portable developers, Firstly, thank you for the fantastic port and the effort you take to maintain it! I have a minor suggestion regarding the documentation of UsePAM in sshd_config. Currently it has a comment that states that 'Depending on your PAM configuration, PAM authentication via ChallengeResponseAuthentication may bypass the setting of "PermitRootLogin without-password".' Due to a recent project, I needed to take a look at this in a bit more depth, to see under what circumstances this bypass of "PermitRootLogin without-password" can happen. The first thing that jumps to mind is someone misconfiguring PAM and using pam_permit.so in the wrong place. Of course, there could be a lot more subtle configuration issues that can lead to the same situation. So while looking through the code in the master branch of portable OpenSSH, in auth-pam.c in function sshpam_query(), during the check for PAM_SUCCESS there is a check for 'options.permit_root_login != PERMIT_YES' and if that fails, a fatal error message is logged "Internal error: PAM auth succeeded when it should have failed", and the connection is closed. Please see the reference below: * https://anongit.mindrot.org/openssh.git/tree/auth-pam.c#n768 These lines were added during commit for bug fix #971 in January 2005, as can be seen in the commit <63e6b0f4>, referenced below: * https://anongit.mindrot.org/openssh.git/commit/?id=36a3d60347f23528695e550317d5ba6d63e6b0f4 The documentation comment in sshd_config for UsePAM was added in commit <90407053>, dated May 2004, referenced below: * https://anongit.mindrot.org/openssh.git/commit/sshd_config?id=701d0514ee3ffc5e8fde36bb0559709490407053 And is still present in the master branch of sshd_config: * https://anongit.mindrot.org/openssh.git/tree/sshd_config Unless I am missing something (and that could well be the case :)), that check in auth-pam.c, should only allow PAM auth to succeed if PasswordAuthentication for root is enabled, otherwise it should always fail. Just to be sure, I have verified this using the following *broken* lines in /etc/pam.d/sshd: auth [default=ignore success=1] pam_succeed_if.so uid != 0 auth sufficient pam_permit.so These configuration changes do result in the expected line from auth-pam.c in the logs. So if my understanding of this behavior is correct, would it be beneficial for other users to document that behavior in sshd_config and the associated man page for option UsePAM? Maybe remove the bypass of "PermitRootLogin without-password" statement in order to avoid confusion? It would also be helpful to mention the specific error line that can appear in the logs in order to explain to the user that the problem is not with OpenSSH itself but with the PAM configuration. Of course if I am missing something and my assumptions are incorrect, under what circumstances can the behavior describe in sshd_config manifest itself? Should a sample PAM configuration that can lead to such behavior be documented? What are your thoughts? Thank you! --peter From odelreym at gmail.com Wed Jun 22 20:18:56 2016 From: odelreym at gmail.com (Nacho del Rey) Date: Wed, 22 Jun 2016 12:18:56 +0200 Subject: Strange behaviour with ptmx file descriptors In-Reply-To: References: Message-ID: Hi again Finally I found out what it was going on The problem lays on the Honeywell ssh client (a fork of OpenSSH) The client doesn't negotiate SSH_MSG_CHANNEL_WINDOW_ADJUST/SSH2_MSG_CHANNEL_WINDOW_ADJUST parameters This issue it's not happening using putty ssh client (for instance) Hope this information helps anyone [SOLVED] Nacho. 2016-06-18 20:50 GMT+02:00 Nacho del Rey : > Hi again > > Finally I recompiled the ssh to include several 'traps' within the code > (channels.c mainly) > > channel_pre_open(Channel *c, fd_set *readset, fd_set *writeset) > { > u_int limit = compat20 ? c->remote_window : packet_get_maxsize(); > > int aux = buffer_len(&c->input); > debugnacho("En pre_open c-istate: %d limit %d buffer_len %d c_ostate %d > ctl_fd %d\n",c->istate,limit,aux,c->ostate,c->ctl_fd); > > /* the rest of the function code */ > } > > In normal conditions the buffer_len(&c->input) is adjusting its window > size > > En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 1048495 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 1048495 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 1048415 buffer_len 0 c_ostate 0 ctl_fd -1 > ...... time later > En pre_open c-istate: 0 limit 1002267 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 1002267 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 1002267 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 998560 buffer_len 0 c_ostate 0 ctl_fd > -1 > En pre_open c-istate: 0 limit 998560 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 > > But, If I compare the same trace when the the hand-terminal connects to > the application... > > En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 1048576 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 1048476 buffer_len 0 c_ostate 0 ctl_fd -1 > ...... > En pre_open c-istate: 0 limit 985 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 647 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 647 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 647 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 647 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 632 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 322 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 322 buffer_len 0 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 > En pre_open c-istate: 0 limit 0 buffer_len 16 c_ostate 0 ctl_fd -1 > > It seems the channel_input_window_adjust function is not adjusting rwindow > size and it finally comes to zero and it is when the problem appears ( the > file-descriptor fd#13 which connects to the application dissapear) > > So the question is.. who is the responsible in adjusting > "channel_input_window_adjust" function? the binary application which runs > in the server or on the contrary the ssh client? > > I ask this question because when I'm connected thru ssh (putty), although > I am not sending a keystroke to the server if I'm changing the size of the > putty window (using the mouse), I can see the buffer_len(c->input) changes > , and I don't have clear in which side (client/server) the rwindow is > adjusted > > Thanks in advance > > Nacho. > > > > > > > > > 2016-04-20 16:52 GMT+02:00 Nacho del Rey : > >> Hi Peter >> >> Can you let me know how to proceed for forward this to the openssh source >> code team? >> >> Regards >> >> >> Nacho del Rey wrote: >> >> 6647 1456244042.325310 select(14, [3 9], [], NULL, {900, 0}) = 1 (in >> [3], >> >> left {892, 12016}) <<-- where id fd#13 ? >> >> >Can you map this back to the OpenSSH source code? >> >> >> >//Peter >> > > From wallace.forman at gmail.com Thu Jun 30 02:24:55 2016 From: wallace.forman at gmail.com (Wallace Forman) Date: Wed, 29 Jun 2016 12:24:55 -0400 Subject: SSH Closes Immediately After Opening Message-ID: Hello there, I am having trouble connecting to a ssh server installed with openssh recently. I have posted about the problem on Superuser, and I will repost a description of the issue below. If anyone here is able to rescue me from my deep well of ignorance, I will be very grateful. http://superuser.com/questions/1094734/ssh-automatically-disconnects-after-login I'm trying to set up an ssh server using OpenSSH on Windows 10. On one of my computers, I've been able to set up the server and successfully login from the same machine. On the other computer, the SSH session seems to be terminating immediately, despite having the same default settings in a similar Windows 10 system. After logging in from the command prompt with ssh -vvv localhost, here is the information displayed after the password has been entered: debug3: send packet: type 50 debug2: we sent a password packet, wait for reply debug3: receive packet: type 52 debug1: Authentication succeeded (password). Authenticated to localhost ([::1]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Requesting no-more-sessions at openssh.com debug3: send packet: type 80 debug1: Entering interactive session. debug1: pledge: network debug3: receive packet: type 80 debug1: client_input_global_request: rtype hostkeys-00 at openssh.com want_reply 0 debug3: receive packet: type 91 debug2: callback start debug2: fd 3 setting TCP_NODELAY debug3: ssh_packet_set_tos: set IPV6_TCLASS 0x10 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug3: send packet: type 98 debug2: channel 0: request shell confirm 1 debug3: send packet: type 98 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 debug3: receive packet: type 98 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug3: receive packet: type 98 debug1: client_input_channel_req: channel 0 rtype eow at openssh.com reply 0 debug2: channel 0: rcvd eow debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: receive packet: type 96 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug3: receive packet: type 97 debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug3: send packet: type 97 debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1) debug3: send packet: type 1 Connection to localhost closed. Transferred: sent 2168, received 4052 bytes, in 0.9 seconds Bytes per second: sent 2501.0, received 4674.3 debug1: Exit status 255 Here are the sshd_config settings: # $OpenBSD: sshd_config,v 1.98 2016/02/17 05:29:04 djm Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/bin:/usr/sbin:/sbin:/usr/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: # The default requires explicit activation of protocol 1 # Protocol 2 # HostKey for protocol version 1 #HostKey /etc/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh_host_rsa_key #HostKey /etc/ssh_host_dsa_key #HostKey /etc/ssh_host_ecdsa_key #HostKey /etc/ssh_host_ed25519_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 1024 # Ciphers and keying #RekeyLimit default none # Logging #obsoletes QuietMode and FascistLogging #SyslogFacility AUTH LogLevel DEBUG3 # Authentication: #LoginGraceTime 2m PermitRootLogin yes StrictModes yes #MaxAuthTries 6 #MaxSessions 10 RSAAuthentication yes #PubkeyAuthentication yes # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys #AuthorizedKeysFile .ssh/authorized_keys #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication IgnoreUserKnownHosts yes # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCreds yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of 'PermitRootLogin without-password'. # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. #UsePAM no #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no UsePrivilegeSeparation no #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # default banner path Banner /etc/banner.txt # override default of no subsystems Subsystem sftp /usr/sbin/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server I've seen a few posts suggesting that I turn on logging to get more information. However, I can't figure out how to accomplish this. None of the log files that appear in C:\Program Files\OpenSSH\var\loghave any information, and I can't figure out where the logs might be, or how else to enable them. Let me know if you have any suggestions how to solve my problem or at least to enable logging. Thanks! From scott_n at xypro.com Thu Jun 30 02:48:06 2016 From: scott_n at xypro.com (Scott Neugroschl) Date: Wed, 29 Jun 2016 16:48:06 +0000 Subject: SSH Closes Immediately After Opening In-Reply-To: References: Message-ID: You can turn on server logging with the -ddd option. This will run the server in the foreground and send debug output to stderr -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On Behalf Of Wallace Forman Sent: Wednesday, June 29, 2016 9:25 AM To: openssh-unix-dev at mindrot.org Subject: SSH Closes Immediately After Opening Hello there, I am having trouble connecting to a ssh server installed with openssh recently. I have posted about the problem on Superuser, and I will repost a description of the issue below. If anyone here is able to rescue me from my deep well of ignorance, I will be very grateful. http://superuser.com/questions/1094734/ssh-automatically-disconnects-after-login I'm trying to set up an ssh server using OpenSSH on Windows 10. On one of my computers, I've been able to set up the server and successfully login from the same machine. On the other computer, the SSH session seems to be terminating immediately, despite having the same default settings in a similar Windows 10 system. After logging in from the command prompt with ssh -vvv localhost, here is the information displayed after the password has been entered: [redacted] I've seen a few posts suggesting that I turn on logging to get more information. However, I can't figure out how to accomplish this. None of the log files that appear in C:\Program Files\OpenSSH\var\loghave any information, and I can't figure out where the logs might be, or how else to enable them. Let me know if you have any suggestions how to solve my problem or at least to enable logging. Thanks! _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From keisial at gmail.com Thu Jun 30 04:48:46 2016 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 29 Jun 2016 20:48:46 +0200 Subject: SSH Closes Immediately After Opening In-Reply-To: References: Message-ID: <5774180E.5060504@gmail.com> On 29/06/16 18:24, Wallace Forman wrote: > Let me know if you have any suggestions how to solve my problem or at least > to enable logging. Thanks! Does the user that is trying to login have a shell that sshd will be able to run? From wallace.forman at gmail.com Thu Jun 30 05:36:08 2016 From: wallace.forman at gmail.com (Wallace Forman) Date: Wed, 29 Jun 2016 15:36:08 -0400 Subject: SSH Closes Immediately After Opening In-Reply-To: <5774180E.5060504@gmail.com> References: <5774180E.5060504@gmail.com> Message-ID: Hmm... Perhaps not. Is something like cygwin required for it to work? Wallace Forman 913-669-4453 On Wed, Jun 29, 2016 at 2:48 PM, ?ngel Gonz?lez wrote: > On 29/06/16 18:24, Wallace Forman wrote: > >> Let me know if you have any suggestions how to solve my problem or at >> least >> to enable logging. Thanks! >> > Does the user that is trying to login have a shell that sshd will be able > to run? > From keisial at gmail.com Thu Jun 30 06:37:24 2016 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Wed, 29 Jun 2016 22:37:24 +0200 Subject: SSH Closes Immediately After Opening In-Reply-To: References: <5774180E.5060504@gmail.com> Message-ID: <57743184.2010409@gmail.com> On 29/06/16 21:36, Wallace Forman wrote: > Hmm... Perhaps not. Is something like cygwin required for it to work? > Where did you install OpenSSH from? cygwin is an avenue for running openssh in Windows, but I don't think it supports native Windows out-of-the box (someone else on the list will surely correct me if I'm wrong). Regards From wallace.forman at gmail.com Thu Jun 30 06:57:14 2016 From: wallace.forman at gmail.com (Wallace Forman) Date: Wed, 29 Jun 2016 16:57:14 -0400 Subject: SSH Closes Immediately After Opening In-Reply-To: <57743184.2010409@gmail.com> References: <5774180E.5060504@gmail.com> <57743184.2010409@gmail.com> Message-ID: I used the latest version from here: http://www.mls-software.com/opensshd.html On my other (Windows 10) machine (on which openssh works), I have cygwin installed, but if ssh was using cygwin, I wasn't aware of it. I just ran ssh from the command prompt. Wallace Forman 913-669-4453 On Wed, Jun 29, 2016 at 4:37 PM, ?ngel Gonz?lez wrote: > On 29/06/16 21:36, Wallace Forman wrote: > > Hmm... Perhaps not. Is something like cygwin required for it to work? > > Where did you install OpenSSH from? > cygwin is an avenue for running openssh in Windows, but > I don't think it supports native Windows out-of-the box > (someone else on the list will surely correct me if I'm wrong). > > Regards > > From keisial at gmail.com Thu Jun 30 07:35:33 2016 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Wed, 29 Jun 2016 23:35:33 +0200 Subject: SSH Closes Immediately After Opening In-Reply-To: References: <5774180E.5060504@gmail.com> <57743184.2010409@gmail.com> Message-ID: <57743F25.9090704@gmail.com> On 29/06/16 22:57, Wallace Forman wrote: > I used the latest version from here: > > http://www.mls-software.com/opensshd.html > > On my other (Windows 10) machine (on which openssh works), I have > cygwin installed, but if ssh was using cygwin, I wasn't aware of it. I > just ran ssh from the command prompt. > > Wallace Forman Yes, that ssh server is cygwin-based. It is however including the basic cygwin files it needs, so the fact that it actually doesn't work without a normal cygwin install seems a bug in the package. Regards From htodd at twofifty.com Thu Jun 30 13:23:27 2016 From: htodd at twofifty.com (Hisashi T Fujinaka) Date: Wed, 29 Jun 2016 20:23:27 -0700 (PDT) Subject: SSH Closes Immediately After Opening In-Reply-To: <57743F25.9090704@gmail.com> References: <5774180E.5060504@gmail.com> <57743184.2010409@gmail.com> <57743F25.9090704@gmail.com> Message-ID: On Wed, 29 Jun 2016, ?ngel Gonz?lez wrote: > On 29/06/16 22:57, Wallace Forman wrote: >> I used the latest version from here: >> >> http://www.mls-software.com/opensshd.html >> >> On my other (Windows 10) machine (on which openssh works), I have cygwin >> installed, but if ssh was using cygwin, I wasn't aware of it. I just ran >> ssh from the command prompt. >> >> Wallace Forman > > Yes, that ssh server is cygwin-based. It is however including the basic > cygwin files it needs, so the fact that it actually doesn't work without a > normal cygwin install seems a bug in the package. I wasn't really paying attention but the first thing I thought of was this sounds like the problem I usually see when my shell is broken. Can you log into the account using the console? -- Hisashi T Fujinaka - htodd at twofifty.com BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee