From schwarze at usta.de Fri Apr 1 02:49:46 2016 From: schwarze at usta.de (Ingo Schwarze) Date: Thu, 31 Mar 2016 17:49:46 +0200 Subject: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 In-Reply-To: <20160329192107.Xw2uF-jht%steffen@sdaoden.eu> References: <20160329192107.Xw2uF-jht%steffen@sdaoden.eu> Message-ID: <20160331154946.GD22000@athene.usta.de> Hi Steffen, Steffen Nurpmeso wrote on Tue, Mar 29, 2016 at 09:21:07PM +0200: > the fix says it all. sftp.1 uses correct syntax already. This patch is bogus. Both versions are completely correct. The purpose of escaping in this context is to prevent mdoc(7) from treating the exclamation mark as a delimiter, which can influence spacing and end of sentence detection. The mdoc(7) language treats the argument of an mdoc macro as a delimiter if both of the following conditions hold: 1. The macro argument consists of exactly one input character. 2. That character is anyone from the following set: - opening delimiters: ([ - middle delimiters: | - closing delimiters: .,:;)]?! The usual way to escape an argument such that it isn't taken as a delimiter is to add a zero-width space "\&" such that condition 1 no longer holds. See the mdoc(7) manual, subsection "Delimiters", for a full discussion. I admit that i usually put the "\&" in front of the character rather than after it, and so do the examples in the mdoc(7) manual. But some people find it more intuitive to put the "\&" afterwards to express that the character is not ending a sentence (i.e. is not a delimiter). I don't see the point in enforcing either style, it seems like useless churn and wasted time. Yours, Ingo From steffen at sdaoden.eu Fri Apr 1 06:24:57 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 31 Mar 2016 21:24:57 +0200 Subject: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 In-Reply-To: <20160331173846.GH22000@athene.usta.de> References: <20160329192536.QChwcJaIo%steffen@sdaoden.eu> <20160331162003.GF22000@athene.usta.de> <20160331171114.eOBzGfOWc%steffen@sdaoden.eu> <20160331173846.GH22000@athene.usta.de> Message-ID: <20160331192457.grb_VWxTg%steffen@sdaoden.eu> Hallo Ingo, list, Ingo Schwarze wrote: |Steffen Nurpmeso wrote on Thu, Mar 31, 2016 at 07:11:14PM +0200: |> I still haven't checked the OpenBSD version of OpenSSH, but i have |> seen your message on their ML (via Gmane) and there you correctly |> state what \& is far, it is used to avoid (mis)interpretation of "!". |> So it should be before that, not thereafter. | |Non sequitur. So now i have, and the bug(s) is (are) still in there. It is a bug, if i type "man ssh_config" i see PermitLocalCommand Allow local command execution via the LocalCommand option or using the ! Ns command escape sequence in ssh(1). The argument must be ``yes'' or ``no''. The default is ``no''. In OpenBSD language that is total crap. If i type "zcat /usr/share/man/man5/ssh_config.5.gz|mandoc|v" i see ... the very same! |In many languages, you escape characters by placing something before |them. But that isn't true in roff. In some contexts of roff, you can |escape stuff by putting something *after* it. | |>>> and that mandoc falsely does the correct thing, if that is possible. |>> Mandoc correctly does the correct thing. |> The CVS version now does. | |Now you confuse me completely. During the last few years, i changed |nothing in the mandoc code we are talking about. So how can the |version of mandoc matter? The version from September 2015 acted as if "\&! Ns" had been used. I don't have it no more, and am toooo lazy to bite. In the meanwhile i seem to remember a message from A. J. Bentley who reported some bug a while back, did he? I'm drowning in work, i'd surely search otherwise. |>> some people find it more intuitive to put the "\&" afterwards to |>> express that the character is not ending a sentence (i.e. is not a |>> delimiter). | |> A bug. | |No, that practice is just fine. |I don't understand why you keep calling it a bug. Bugbugbugbugbugbugbugbugbugbugbug. (Manually typed.) |> The visible flyspeck in the manuals of the portable version |> springs into the eye and drives you up the wall. Bah. | |I have no idea what you are talking about. Which formatter are you |using? Which output does it generate for which input? Just feeding animals in the zoo. And then home. Tsch??. --steffen From steffen at sdaoden.eu Fri Apr 1 23:46:23 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 01 Apr 2016 14:46:23 +0200 Subject: Fwd: Small fixes for ssh.1 and ssh_config.5, OpenSSH_7.2p2 In-Reply-To: <20160331200404.GA79521@www.stare.cz> References: <20160329192536.QChwcJaIo%steffen@sdaoden.eu> <20160331162003.GF22000@athene.usta.de> <20160331171114.eOBzGfOWc%steffen@sdaoden.eu> <20160331173846.GH22000@athene.usta.de> <20160331192457.grb_VWxTg%steffen@sdaoden.eu> <20160331200404.GA79521@www.stare.cz> Message-ID: <20160401124623.M7XL_cRT9%steffen@sdaoden.eu> hans wrote: |On Mar 31 21:24:57, steffen at sdaoden.eu wrote: |> PermitLocalCommand |> Allow local command execution via the LocalComman\ |> d option or |> using the ! Ns command escape sequence in ssh(1). Th\ |> e argument |> must be ``yes'' or ``no''. The default is ``no''. | |This is what I see: If i could read "the ! King command" it would be fine by me. Ns is not acceptable. |What system are you on and which man(7) formatter does your man(1) use? It is groff. It is mandoc as of CVS. It is Linux and FreeBSD, up-to-date. What i wasn't sure about, is wether in "!\& Ns" the "\&" should really escape the following Ns macro or not. I.e., wether that was also a bug in mdoc(7) parsing or not. Ingo said it's not. (The mdoc(7) macro expand such things recursive.) |> If i type "zcat /usr/share/man/man5/ssh_config.5.gz|mandoc|v" |> i see ... the very same! | |What is 'v'? v='LESS= less --RAW-CONTROL-CHARS --ignore-case --no-init --quit-if-one-screen' |> Just feeding animals in the zoo. And then home. | |Ah. I should have known better. Yeah, but no meat a.k.a. cut corpses. Not imprisoned but free. Only vegetarian stuff. --steffen From tgc at jupiterrise.com Sun Apr 3 22:09:14 2016 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Sun, 3 Apr 2016 14:09:14 +0200 Subject: Broken cat style manpages in the distribution tarballs? Message-ID: <570107EA.3070901@jupiterrise.com> Hello, I just noticed that the cat style manpages distributed with openssh 7.2p2 contains what looks like some sort of unprocessed control/escape sequences. Looking at ssh.0 the NAME section contains M-bM-^@M-^S and similar can be found throughout the file and in the other .0 files. Starting with 6.8p1 every release has this issue. -tgc From odelreym at gmail.com Mon Apr 4 23:38:37 2016 From: odelreym at gmail.com (Nacho del Rey) Date: Mon, 4 Apr 2016 15:38:37 +0200 Subject: Strange behaviour with ptmx file descriptors Message-ID: Hi list At job we have an old C program which works with industrial hand terminals from Honeywell. That terminal has its own ssh/telnet client to connect to a linux redhat 6.6 server (openssh-server-5.3p1-104.el6_6.1.x86_64). Once it is connected to the linux box (using a certain user), a C program is launched by the bash shell with the following parameters export TERM=vt200 stty raw icrnl -echo $APLI_EXEC/program param1 param2 so the flow is like => ssh client --> ssh server-> bash --> c program (telnet client -> telnet server -> bash -> c program is working fine, no problem reported) The application (or it seems) is working fine but sometimes (1-3-5 times per week) a randomly terminal stops receiving data from the server but the application receives the inputs from it. It is like if you writes Ctrl+S in a shell. Debuging the application and the ssh process using strace I realized about something strange: Having the following file descriptors in the sshd process lr-x------ 1 root root 64 Feb 15 17:12 9 -> pipe:[383586491] lr-x------ 1 root root 64 Feb 15 17:12 8 -> /var/lib/sss/mc/group lrwx------ 1 root root 64 Feb 15 17:12 7 -> socket:[383586484] lrwx------ 1 root root 64 Feb 15 17:12 6 -> socket:[383586478] lrwx------ 1 root root 64 Feb 15 17:12 5 -> socket:[383586458] lrwx------ 1 root root 64 Feb 15 17:12 4 -> socket:[383586457] lrwx------ 1 root root 64 Feb 15 17:12 3 -> socket:[383585929] lrwx------ 1 root root 64 Feb 15 17:12 2 -> /dev/null lrwx------ 1 root root 64 Feb 15 17:12 14 -> /dev/ptmx lrwx------ 1 root root 64 Feb 15 17:12 13 -> /dev/ptmx lrwx------ 1 root root 64 Feb 15 17:12 11 -> /dev/ptmx l-wx------ 1 root root 64 Feb 15 17:12 10 -> pipe:[383586491] lrwx------ 1 root root 64 Feb 15 17:12 1 -> /dev/null lrwx------ 1 root root 64 Feb 15 17:12 0 -> /dev/null A strace over the sshd process: select(14, [3 9 13], [], NULL, {900, 0}) = 1 (in [13], left {899, 998835}) <<- sshd realizes about data in fd #13 from C application read(13, "\33[1;23H1\33[1;24H", 16384) = 15 <<- sshd check data from th fd#13 select(14, [3 9 13], [3], NULL, {900, 0}) = 1 (out [3], left {899, 999998}) <<- sshd sends data to fd#3 (socket) write(3, "\301\236W\250\333\260\r\204\316o]:*1K\203\242\204\257Vb,V\347l\242\352K\341,,\307d\273\277\202.l\32F\2471\257DJt3\36\303\5\256\21K6\27\212\253\326|l\33\270\262S", 64) = 64 (1) <<- sshd encrypts data to be sent select(14, [3 9 13], [3], NULL, {900, 0}) = 1 (out [3], left {899, 999998}) <<-- sshd sends data thru the socket select(14, [3 9 13], [], NULL, {900, 0}) = 1 (in [13], left {899, 998569}) <<- sshd realizes about data in fd #13 from C application read(13, "\7\33[1;16H \33[6;6H_______\33[7;1H -INFORME CANT. RECOGIDA-\33[7;26H", 16384) = 67 <<- sshd check data from th fd#13 select(14, [3 9], [], NULL, {900, 0}) = 1 (in [3], left {892, 12016}) <<- sshd sends data to fd#3 (socket) but... where is fd#13 where sshd has to read it from? read it from? the terminal receives "\7\33[1;16H " but the rest of the string " \33[6;6H_______\33[7;1H -INFORME CANT. RECOGIDA-\33[7;26H" is not received in the client side.............,and fd #13 is lost???????? I have tried to reproduce the behaviour with no success The following is what it happens Transmission ok read(13, "\7\33[1;16H \33[6;6H_______\33[7;1H -INFORME CANT. RECOGIDA-\33[7;26H", 16384) = 67 write(3, "\306n\273W\315\265\204\333\201\334\240\346(\354qtz\274L?V\214$\374m\345\321\206\242\235D\255uJ\357\315\313\230\20\375\262\241E\302\360\306\37g1Y\352\7\330h\257\250\276%\344\375o=\227\316\ 354@!\205\356\177\330\213\35\330&\251F\225\335\n\312)n08\246x\245\202K\2138C,\10zJ\303\2002\237\321)U\217h\1771\215\3z)", 112) = 112 Transmission KO read(13, "\7\33[1;16H \33[6;6H_______\33[7;1H -INFORME CANT. RECOGIDA-\33[7;26H", 16384) = 67 write(3, "P\247\244}\277\322\260\21\3314\7\227\223~\317\360\35\334\232\372\237\250\320\312\1;\25\37\23\363\363O&0\355i{zUbr\365,\362yyl\222", 48) = 48 It seems the file descriptor disappears while the system call (read) is reading from it? I ran out of ideas. Can anybody drive me to the right direction? Regards, Nacho. From rigoxls at gmail.com Thu Apr 7 01:16:27 2016 From: rigoxls at gmail.com (rigoberto giraldo) Date: Wed, 6 Apr 2016 10:16:27 -0500 Subject: Issue upgrading openssh from 6.6p1 to 7.2p2 Message-ID: Hi Guys I have a server running with Ubuntu 14.04, but i have an issue with PCI requeriments. I have installed in my server openSSH 6.6p1, then i upgraded it to openSSH 7.2p, compiling code with*make and make install directly from repositories from openSSH*, but it seems something is broken because i continue getting the old version after i check dpkg -l openssh* ii openssh-client 1:6.6p1-2ubunt amd64 secure shell (SSH) client, ii openssh-server 1:6.6p1-2ubunt amd64 secure shell (SSH) server, ii openssh-sftp-serve 1:6.6p1-2ubunt amd64 secure shell (SSH) sftp server And PCI scanner continues reporting same issue about that i have to install the latest version of openSSH. but i i try *ssh -V* i get the right version of openssh << 7.2p2 >> This is the CVI Id of the issue: CVE-2016-3115 thanks From cjwatson at debian.org Thu Apr 7 01:57:05 2016 From: cjwatson at debian.org (Colin Watson) Date: Wed, 6 Apr 2016 16:57:05 +0100 Subject: Issue upgrading openssh from 6.6p1 to 7.2p2 In-Reply-To: References: Message-ID: <20160406155704.GA3027@riva.ucam.org> On Wed, Apr 06, 2016 at 10:16:27AM -0500, rigoberto giraldo wrote: > I have a server running with Ubuntu 14.04, but i have an issue with PCI > requeriments. I have installed in my server openSSH 6.6p1, then i upgraded > it to openSSH 7.2p, compiling code with*make and make install directly from > repositories from openSSH*, but it seems something is broken because i > continue getting the old version after i check dpkg -l openssh* > > ii openssh-client 1:6.6p1-2ubunt amd64 secure shell (SSH) client, > ii openssh-server 1:6.6p1-2ubunt amd64 secure shell (SSH) server, > ii openssh-sftp-serve 1:6.6p1-2ubunt amd64 secure shell (SSH) sftp server dpkg tells you what's been installed from packages. If you're using "make" and "make install", then you've stepped outside the packaging system and will have to take responsibility for it yourself. You might be better off backporting the packages from Ubuntu 16.04 instead. > And PCI scanner continues reporting same issue about that i have to install > the latest version of openSSH. You probably didn't install it in such a way that the new sshd will in fact be running. -- Colin Watson [cjwatson at debian.org] From piotr.jerzy.jurkiewicz at gmail.com Thu Apr 7 11:45:48 2016 From: piotr.jerzy.jurkiewicz at gmail.com (Piotr Jurkiewicz) Date: Thu, 7 Apr 2016 03:45:48 +0200 Subject: [PATCH 1/2] Implement recursive upload resume support in sftp client Message-ID: <5705BBCC.3010801@gmail.com> This patch adds support for recursive upload resume (`reput -r`, `put -a -r` commands) in sftp client. Now this combination (-a -r), despite being valid and accepted by sftp client, does not do anything useful: it always results in errors. Apparently possibility of recursive upload was overlooked when upload resume support was being implemented in 2014. I tried to make its logic similar to the already existing recursive download resume behavior, that is: when target file doesn't exists on the remote end: upload the whole file when remote file is smaller than local one: upload the remaining part when remote file size is equal the local one: skip this file when remote file is larger than local one: skip this file with an error message Signed-off-by: Piotr Jurkiewicz --- sftp-client.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/sftp-client.c b/sftp-client.c index d49bfaa..ee4d131 100644 --- a/sftp-client.c +++ b/sftp-client.c @@ -1598,23 +1598,24 @@ do_upload(struct sftp_conn *conn, const char *local_path, if (!preserve_flag) a.flags &= ~SSH2_FILEXFER_ATTR_ACMODTIME; + offset = 0; if (resume) { /* Get remote file size if it exists */ - if ((c = do_stat(conn, remote_path, 0)) == NULL) { - close(local_fd); - return -1; - } + if ((c = do_stat(conn, remote_path, 1)) != NULL) { + if ((off_t)c->size > sb.st_size) { + error("Unable to resume upload of \"%s\": " + "remote file is larger than local", + remote_path); + close(local_fd); + return -1; + } - if ((off_t)c->size >= sb.st_size) { - error("destination file bigger or same size as " - "source file"); - close(local_fd); - return -1; - } + offset = c->size; - if (lseek(local_fd, (off_t)c->size, SEEK_SET) == -1) { - close(local_fd); - return -1; + if (lseek(local_fd, offset, SEEK_SET) == -1) { + close(local_fd); + return -1; + } } } @@ -1627,7 +1628,7 @@ do_upload(struct sftp_conn *conn, const char *local_path, (r = sshbuf_put_u32(msg, id)) != 0 || (r = sshbuf_put_cstring(msg, remote_path)) != 0 || (r = sshbuf_put_u32(msg, SSH2_FXF_WRITE|SSH2_FXF_CREAT| - (resume ? SSH2_FXF_APPEND : SSH2_FXF_TRUNC))) != 0 || + (offset > 0 ? SSH2_FXF_APPEND : SSH2_FXF_TRUNC))) != 0 || (r = encode_attrib(msg, &a)) != 0) fatal("%s: buffer error: %s", __func__, ssh_err(r)); send_msg(conn, msg); @@ -1647,7 +1648,7 @@ do_upload(struct sftp_conn *conn, const char *local_path, data = xmalloc(conn->transfer_buflen); /* Read from local and write to remote */ - offset = progress_counter = (resume ? c->size : 0); + progress_counter = offset; if (showprogress) start_progress_meter(local_path, sb.st_size, &progress_counter); -- 2.1.4 From piotr.jerzy.jurkiewicz at gmail.com Thu Apr 7 11:54:14 2016 From: piotr.jerzy.jurkiewicz at gmail.com (Piotr Jurkiewicz) Date: Thu, 7 Apr 2016 03:54:14 +0200 Subject: [PATCH 2/2] More consistent upload args and error messages in sftp client Message-ID: <5705BDC6.3020706@gmail.com> This patch changes the name of `resume` argument in upload related functions to `resume_flag`, to make it consistent with a similar argument in download related functions. It also changes recursive upload error message to be consistent with a similar error message during recursive download. Signed-off-by: Piotr Jurkiewicz --- sftp-client.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/sftp-client.c b/sftp-client.c index ee4d131..be69acb 100644 --- a/sftp-client.c +++ b/sftp-client.c @@ -1549,7 +1549,7 @@ download_dir(struct sftp_conn *conn, const char *src, const char *dst, int do_upload(struct sftp_conn *conn, const char *local_path, - const char *remote_path, int preserve_flag, int resume, int fsync_flag) + const char *remote_path, int preserve_flag, int resume_flag, int fsync_flag) { int r, local_fd; u_int status = SSH2_FX_OK; @@ -1599,7 +1599,7 @@ do_upload(struct sftp_conn *conn, const char *local_path, a.flags &= ~SSH2_FILEXFER_ATTR_ACMODTIME; offset = 0; - if (resume) { + if (resume_flag) { /* Get remote file size if it exists */ if ((c = do_stat(conn, remote_path, 1)) != NULL) { if ((off_t)c->size > sb.st_size) { @@ -1771,7 +1771,8 @@ do_upload(struct sftp_conn *conn, const char *local_path, static int upload_dir_internal(struct sftp_conn *conn, const char *src, const char *dst, - int depth, int preserve_flag, int print_flag, int resume, int fsync_flag) + int depth, int preserve_flag, int print_flag, int resume_flag, + int fsync_flag) { int ret = 0; DIR *dirp; @@ -1841,13 +1842,13 @@ upload_dir_internal(struct sftp_conn *conn, const char *src, const char *dst, continue; if (upload_dir_internal(conn, new_src, new_dst, - depth + 1, preserve_flag, print_flag, resume, + depth + 1, preserve_flag, print_flag, resume_flag, fsync_flag) == -1) ret = -1; } else if (S_ISREG(sb.st_mode)) { if (do_upload(conn, new_src, new_dst, - preserve_flag, resume, fsync_flag) == -1) { - error("Uploading of file %s to %s failed!", + preserve_flag, resume_flag, fsync_flag) == -1) { + error("Upload of file %s to %s failed", new_src, new_dst); ret = -1; } @@ -1865,7 +1866,7 @@ upload_dir_internal(struct sftp_conn *conn, const char *src, const char *dst, int upload_dir(struct sftp_conn *conn, const char *src, const char *dst, - int preserve_flag, int print_flag, int resume, int fsync_flag) + int preserve_flag, int print_flag, int resume_flag, int fsync_flag) { char *dst_canon; int ret; @@ -1876,7 +1877,7 @@ upload_dir(struct sftp_conn *conn, const char *src, const char *dst, } ret = upload_dir_internal(conn, src, dst_canon, 0, preserve_flag, - print_flag, resume, fsync_flag); + print_flag, resume_flag, fsync_flag); free(dst_canon); return ret; -- 2.1.4 From dtucker at zip.com.au Fri Apr 8 14:42:18 2016 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 8 Apr 2016 14:42:18 +1000 Subject: replace Cygwin NO_IPPORT_RESERVED_CONCEPT Message-ID: <20160408044218.GA25833@gate.dtucker.net> Hi. I while syncing an OpenBSD diff I got tripped up by NO_IPPORT_RESERVED_CONCEPT which is in Portable and not OpenBSD so the diff failed to apply. This diff replaces that #define by defining IPPORT_RESERVED=0, which should have the same effect (since it's always compared to unsigfned 16bit port numbers) but without a difference in the code. I vaguely recall suggesting this once before, although if I did I didn't follow through. Corinna: does this seem reasonable? Thanks. diff --git a/configure.ac b/configure.ac index f9fb48d..dde3c45 100644 --- a/configure.ac +++ b/configure.ac @@ -586,9 +586,8 @@ case "$host" in [Define if you want to disable shadow passwords]) AC_DEFINE([NO_X11_UNIX_SOCKETS], [1], [Define if X11 doesn't support AF_UNIX sockets on that system]) - AC_DEFINE([NO_IPPORT_RESERVED_CONCEPT], [1], - [Define if the concept of ports only accessible to - superusers isn't known]) + AC_DEFINE([IPPORT_RESERVED], [0], + [Cygwin has no notion of ports only accessible to superusers]) AC_DEFINE([DISABLE_FD_PASSING], [1], [Define if your platform needs to skip post auth file descriptor passing]) diff --git a/readconf.c b/readconf.c index c692f7d..d63e596 100644 --- a/readconf.c +++ b/readconf.c @@ -294,14 +294,12 @@ void add_local_forward(Options *options, const struct Forward *newfwd) { struct Forward *fwd; - int i; -#ifndef NO_IPPORT_RESERVED_CONCEPT extern uid_t original_real_uid; + int i; if (newfwd->listen_port < IPPORT_RESERVED && original_real_uid != 0 && newfwd->listen_path == NULL) fatal("Privileged ports can only be forwarded by root."); -#endif /* Don't add duplicates */ for (i = 0; i < options->num_local_forwards; i++) { if (forward_equals(newfwd, options->local_forwards + i)) diff --git a/serverloop.c b/serverloop.c index f9e3e5d..3563e5d 100644 --- a/serverloop.c +++ b/serverloop.c @@ -1243,12 +1243,9 @@ server_input_global_request(int type, u_int32_t seq, void *ctxt) /* check permissions */ if ((options.allow_tcp_forwarding & FORWARD_REMOTE) == 0 || no_port_forwarding_flag || - (!want_reply && fwd.listen_port == 0) -#ifndef NO_IPPORT_RESERVED_CONCEPT - || (fwd.listen_port != 0 && fwd.listen_port < IPPORT_RESERVED && - pw->pw_uid != 0) -#endif - ) { + (!want_reply && fwd.listen_port == 0) || + (fwd.listen_port != 0 && fwd.listen_port < IPPORT_RESERVED && + pw->pw_uid != 0)) { success = 0; packet_send_debug("Server has disabled port forwarding."); } else { -- 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 vinschen at redhat.com Fri Apr 8 20:03:20 2016 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 8 Apr 2016 12:03:20 +0200 Subject: replace Cygwin NO_IPPORT_RESERVED_CONCEPT In-Reply-To: <20160408044218.GA25833@gate.dtucker.net> References: <20160408044218.GA25833@gate.dtucker.net> Message-ID: <20160408100320.GD7505@calimero.vinschen.de> Hi Darren, On Apr 8 14:42, Darren Tucker wrote: > Hi. > > I while syncing an OpenBSD diff I got tripped up by > NO_IPPORT_RESERVED_CONCEPT which is in Portable and not OpenBSD so the > diff failed to apply. > > This diff replaces that #define by defining IPPORT_RESERVED=0, which > should have the same effect (since it's always compared to unsigfned 16bit > port numbers) but without a difference in the code. I vaguely recall > suggesting this once before, although if I did I didn't follow through. > > Corinna: does this seem reasonable? Instead of this awkward #ifndef, just set the lowest non-reserved port number to 0? That looks pretty good to me. Please note that we have IPPORT_RESERVED set to 1024 in our headers for historical porting reasons. However, it's an enum value so it can be easily overloaded with a macro. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From cristian.ionescu-idbohrn at axis.com Thu Apr 14 21:19:24 2016 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 14 Apr 2016 13:19:24 +0200 (CEST) Subject: (rfc) too many keys, usecase? Message-ID: There is no /root/.ssh/authorized_keys on remote host, so I have to authenticate with password. On the remote host: # /usr/sbin/sshd -T | egrep permitroot permitrootlogin yes Attempting: $ ssh root@ shows: Received disconnect from port 22:2: Too many authentication failures for root packet_write_wait: Connection to port 22: Broken pipe mux_client_request_session: read from master failed: Broken pipe Failed to connect to new control master Yes, I do have a few keys in ~/.ssh and use ControlMaster: debug1: Offering RSA public key: /.ssh/id_rsa debug1: Offering RSA public key: /.ssh/id_rsa debug1: Offering RSA public key: /.ssh/another_id_rsa debug1: Trying private key: /.ssh/id_dsa debug1: Offering ECDSA public key: /.ssh/id_ecdsa debug1: Offering ED25519 public key: /.ssh/id_ed25519 debug1: Next authentication method: keyboard-interactive Received disconnect from port 22:2: Too many authentication failures for root Yes, I know about MaxAuthTries and I used it as a workaround. Still, I would imagine the remote server knows there's no point refusing the slient offered keys one after the other, as none will work. Why then not telling the client there's no point trying, use password instead? Cheers, -- Cristian From jjelen at redhat.com Thu Apr 14 22:26:45 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Thu, 14 Apr 2016 14:26:45 +0200 Subject: (rfc) too many keys, usecase? In-Reply-To: References: Message-ID: <570F8C85.5090803@redhat.com> On 04/14/2016 01:19 PM, Cristian Ionescu-Idbohrn wrote: > There is no /root/.ssh/authorized_keys on remote host, so I have to > authenticate with password. > > On the remote host: > > # /usr/sbin/sshd -T | egrep permitroot > permitrootlogin yes > > Attempting: > > $ ssh root@ > > shows: > > Received disconnect from port 22:2: Too many authentication failures for root > packet_write_wait: Connection to port 22: Broken pipe > mux_client_request_session: read from master failed: Broken pipe > Failed to connect to new control master > > Yes, I do have a few keys in ~/.ssh and use ControlMaster: > > debug1: Offering RSA public key: /.ssh/id_rsa > debug1: Offering RSA public key: /.ssh/id_rsa > debug1: Offering RSA public key: /.ssh/another_id_rsa > debug1: Trying private key: /.ssh/id_dsa > debug1: Offering ECDSA public key: /.ssh/id_ecdsa > debug1: Offering ED25519 public key: /.ssh/id_ed25519 > debug1: Next authentication method: keyboard-interactive > Received disconnect from port 22:2: Too many authentication failures for root > > Yes, I know about MaxAuthTries and I used it as a workaround. Still, > I would imagine the remote server knows there's no point refusing the > slient offered keys one after the other, as none will work. Why then > not telling the client there's no point trying, use password instead? The server knows that there is no point in trying, but the (possibly malicious) client does not know that. And server is trying to tell the client the least possible amount of information (basic rule of security). If you know that you don't want to authenticate using PK, you can disable this method using -oPubkeyAuthentication=no option. Regards, -- Jakub Jelen Security Technologies Red Hat From cristian.ionescu-idbohrn at axis.com Thu Apr 14 23:28:20 2016 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 14 Apr 2016 15:28:20 +0200 (CEST) Subject: (rfc) too many keys, usecase? In-Reply-To: <570F8C85.5090803@redhat.com> References: <570F8C85.5090803@redhat.com> Message-ID: On Thu, 14 Apr 2016, Jakub Jelen wrote: > On 04/14/2016 01:19 PM, Cristian Ionescu-Idbohrn wrote: > > There is no /root/.ssh/authorized_keys on remote host, so I have to > > authenticate with password. > > > > On the remote host: > > > > # /usr/sbin/sshd -T | egrep permitroot > > permitrootlogin yes > > > > Attempting: > > > > $ ssh root@ > > > > shows: > > > > Received disconnect from port 22:2: Too many authentication failures for root > > packet_write_wait: Connection to port 22: Broken pipe > > mux_client_request_session: read from master failed: Broken pipe > > Failed to connect to new control master > > > > Yes, I do have a few keys in ~/.ssh and use ControlMaster: > > > > debug1: Offering RSA public key: /.ssh/id_rsa > > debug1: Offering RSA public key: /.ssh/id_rsa > > debug1: Offering RSA public key: /.ssh/another_id_rsa > > debug1: Trying private key: /.ssh/id_dsa > > debug1: Offering ECDSA public key: /.ssh/id_ecdsa > > debug1: Offering ED25519 public key: /.ssh/id_ed25519 > > debug1: Next authentication method: keyboard-interactive > > Received disconnect from port 22:2: Too many authentication failures for root > > > > Yes, I know about MaxAuthTries and I used it as a workaround. Still, > > I would imagine the remote server knows there's no point refusing the > > slient offered keys one after the other, as none will work. Why then > > not telling the client there's no point trying, use password instead? > > The server knows that there is no point in trying, but the (possibly > malicious) client does not know that. And server is trying to tell > the client the least possible amount of information (basic rule of > security). Right. Still, how much more damage could a malicious client do if it ware presented with a password prompt? Is it worth annoying the non-malicious clients or push the admin into ticking up MaxAuthTries? > If you know that you don't want to authenticate using PK, you can > disable this method using -oPubkeyAuthentication=no option. Yes, if I know. Cheers, -- Cristian From mouring at eviladmin.org Fri Apr 15 03:01:48 2016 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 14 Apr 2016 12:01:48 -0500 Subject: (rfc) too many keys, usecase? In-Reply-To: References: <570F8C85.5090803@redhat.com> Message-ID: <570FCCFC.8070007@eviladmin.org> Cristian Ionescu-Idbohrn wrote: > On Thu, 14 Apr 2016, Jakub Jelen wrote: >> On 04/14/2016 01:19 PM, Cristian Ionescu-Idbohrn wrote: [..] >>> Yes, I know about MaxAuthTries and I used it as a workaround. Still, >>> I would imagine the remote server knows there's no point refusing the >>> slient offered keys one after the other, as none will work. Why then >>> not telling the client there's no point trying, use password instead? >> The server knows that there is no point in trying, but the (possibly >> malicious) client does not know that. And server is trying to tell >> the client the least possible amount of information (basic rule of >> security). > > Right. Still, how much more damage could a malicious client do if it > ware presented with a password prompt? Is it worth annoying the > non-malicious clients or push the admin into ticking up MaxAuthTries? > Same argument could be applied to why I bother to present a password prompt if all the server accepts only public keys. By not doing it, I reduce the possible attack service a hacker has to break into my server. Knowing that keys aren't except for the server or for an individual user it leaks information that an attacker can use against me. This is the same reason why a few years ago we went through painful effort to stop ssh from short-cutting out of bad authentications attempts. Because it leaked a bit of information an attacker could detect to shift their attack method. *shrug* My solution to this "issue" was to stop generating keys with standard id_{rsa,dsa,etc} names. And use something more useful "id_rsa_work" "id_rsa_play" .. etc.. Then I specify via ~/.ssh/config which key is to be served to a server. As I honestly never liked the "throw ssh keys at the server and see which one sticks" feature of the SSH RFC. It feels like a lazy way of key administration. It was great when you are learning, but sucks when you start collecting dozens of ssh keys for different community, work, personal, and friend's servers. All of them being completely different so you can keep good isolation habits (e.g. If I leave a community I want to do rm -rf .ssh/id_rsa_communityname* and know for a fact that I no longer have the key and it improves my confidence that I'm not going to lose it, and thus causing a possible compromise if the community doesn't do their own due diligence on removing my account or key). The above also linked with ssh-agent and locking/unlocking ssh keys has how I've lived for 10+ years now, and have never ran into this problem. Honestly, it is better to learn to manage your SSH keys properly. - Ben From cristian.ionescu-idbohrn at axis.com Fri Apr 15 03:53:43 2016 From: cristian.ionescu-idbohrn at axis.com (Cristian Ionescu-Idbohrn) Date: Thu, 14 Apr 2016 19:53:43 +0200 (CEST) Subject: (rfc) too many keys, usecase? In-Reply-To: <570FCCFC.8070007@eviladmin.org> References: <570F8C85.5090803@redhat.com> <570FCCFC.8070007@eviladmin.org> Message-ID: On Thu, 14 Apr 2016, Ben Lindstrom wrote: > Cristian Ionescu-Idbohrn wrote: > > > > Right. Still, how much more damage could a malicious client do if > > it ware presented with a password prompt? Is it worth annoying > > the non-malicious clients or push the admin into ticking up > > MaxAuthTries? ... > This is the same reason why a few years ago we went > through painful effort to stop ssh from short-cutting out of bad > authentications attempts. Because it leaked a bit of information an > attacker could detect to shift their attack method. ... > Then I specify via ~/.ssh/config which key is to be served to a > server. As I honestly never liked the "throw ssh keys at the server > and see which one sticks" feature of the SSH RFC. > It feels like a lazy way of key administration. > > It was great when you are learning, but sucks when you start > collecting dozens of ssh keys for different community, work, > personal, and friend's servers. All of them being completely > different so you can keep good isolation habits (e.g. If I leave a > community I want to do rm -rf .ssh/id_rsa_communityname* and know > for a fact that I no longer have the key and it improves my > confidence that I'm not going to lose it, and thus causing a > possible compromise if the community doesn't do their own due > diligence on removing my account or key). Now, that sounds like a good idea. I'll do that, I think. Serve selected key(s) to selected servers, throuh ~/.ssh/config, using the IdentityFile option. A little more administration, but not heavy at all. Thanks. Cheers, -- Cristian From keisial at gmail.com Fri Apr 15 09:46:28 2016 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 15 Apr 2016 01:46:28 +0200 Subject: (rfc) too many keys, usecase? In-Reply-To: References: <570F8C85.5090803@redhat.com> <570FCCFC.8070007@eviladmin.org> Message-ID: <57102BD4.7080005@gmail.com> On 14/04/16 19:53, Cristian Ionescu-Idbohrn wrote: > Now, that sounds like a good idea. I'll do that, I think. Serve > selected key(s) to selected servers, throuh ~/.ssh/config, using the > IdentityFile option. A little more administration, but not heavy at > all. Thanks. > > Cheers, *and* IdentitiesOnly yes. Remember that otherwise you can still hit MaxAuthTries, even if the client was told the right key to use, it would try other agent keys first. From keisial at gmail.com Fri Apr 15 09:58:20 2016 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 15 Apr 2016 01:58:20 +0200 Subject: Does SCTP help against TCP reset attacks? In-Reply-To: <20160316105419.HmJwkG-XE%steffen@sdaoden.eu> References: <20160316105419.HmJwkG-XE%steffen@sdaoden.eu> Message-ID: <57102E9C.10701@gmail.com> Steffen Nurpmeso wrote: > I don't know how you do it, i never managed a(n exposed) server > until January and now [.] i think what i have to face are TCP > RST attacks on SSH connections, leading to "connection reset"s > ["connection closed" on client side in fact] (of course). Are you sure that's the case? For RST attack, it would need to guess the right TCP sequence numbers. It seems more likely that the connection is timing out (maybe there's some firewall enforcing it?) and thus the other side considers it to be closed. From keisial at gmail.com Fri Apr 15 10:06:53 2016 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Fri, 15 Apr 2016 02:06:53 +0200 Subject: Strange behaviour with ptmx file descriptors In-Reply-To: References: Message-ID: <5710309D.4060900@gmail.com> Hello Nacho El 04/04/16 15:38, Nacho del Rey escribi?: > Hi list (?) > Transmission KO > > read(13, "\7\33[1;16H \33[6;6H_______\33[7;1H -INFORME CANT. > RECOGIDA-\33[7;26H", 16384) = 67 > > write(3, > "P\247\244}\277\322\260\21\3314\7\227\223~\317\360\35\334\232\372\237\250\320\312\1;\25\37\23\363\363O&0\355i{zUbr\365,\362yyl\222", > 48) = 48 > > It seems the file descriptor disappears while the system call (read) is > reading from it? No, the file descriptor will still be there. sshd is taking the program output from the terminal (13) and sending out through the socket (3). What's the corresponding strace of the client ssh? > I ran out of ideas. Can anybody drive me to the right direction? > > Regards, Nacho. What's the terminal emulator used in the client side? Does resetting it (from a menu option) make it receive the server output again? Cheers From odelreym at gmail.com Fri Apr 15 19:28:16 2016 From: odelreym at gmail.com (Nacho del Rey) Date: Fri, 15 Apr 2016 11:28:16 +0200 Subject: Strange behaviour with ptmx file descriptors In-Reply-To: <5710309D.4060900@gmail.com> References: <5710309D.4060900@gmail.com> Message-ID: Hi Angel and many thanks for your answer The application still sending & receiving data .- strace over the application: write(1, "\33[1;1H\237#SF \234", 44) = 44 <--it was sent from the application to the terminal, but ssh didn't received this string read(0, "\10", 1024) = 1 <- the client remained sending data and it was received by the application read(0, "\n", 1024) = 1 write(1, "\33[6;6H", 6) = 6 <-- the answered '\n' but it wasn't received by the ssh finally, several minutes later, the operator realized the screen is frozen and he closed the ssh client The strange thing is all file descriptors of all processes are in place but it seems for any strange reason, something happen to fd#13 ( C Program fd #1 --> ssd read fd #13) because it disappears from the select call (it won't be available in the read fd set ever) ssh client is made by Honeywell company. This behaviour is similar as when you send a Ctrl+S from the ssh client but in this case, fd#13 is not lost. Kind regards Nacho. 2016-04-15 2:06 GMT+02:00 ?ngel Gonz?lez : > Hello Nacho > > El 04/04/16 15:38, Nacho del Rey escribi?: > >> Hi list >> > (?) > >> Transmission KO >> >> read(13, "\7\33[1;16H \33[6;6H_______\33[7;1H -INFORME CANT. >> RECOGIDA-\33[7;26H", 16384) = 67 >> >> write(3, >> >> "P\247\244}\277\322\260\21\3314\7\227\223~\317\360\35\334\232\372\237\250\320\312\1;\25\37\23\363\363O&0\355i{zUbr\365,\362yyl\222", >> 48) = 48 >> >> It seems the file descriptor disappears while the system call (read) is >> reading from it? >> > No, the file descriptor will still be there. > > sshd is taking the program output from the terminal (13) and sending out > through the socket > (3). What's the corresponding strace of the client ssh? > > > I ran out of ideas. Can anybody drive me to the right direction? >> >> Regards, Nacho. >> > What's the terminal emulator used in the client side? Does resetting it > (from a menu option) make it receive the server output again? > > > Cheers > > From steffen at sdaoden.eu Fri Apr 15 19:41:35 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 15 Apr 2016 11:41:35 +0200 Subject: Does SCTP help against TCP reset attacks? In-Reply-To: <57102E9C.10701@gmail.com> References: <20160316105419.HmJwkG-XE%steffen@sdaoden.eu> <57102E9C.10701@gmail.com> Message-ID: <20160415094135.vsyv6dv5N%steffen@sdaoden.eu> ?ngel Gonz?lez wrote: |Steffen Nurpmeso wrote: |> I don't know how you do it, i never managed a(n exposed) server |> until January and now [.] i think what i have to face are TCP |> RST attacks on SSH connections, leading to "connection reset"s |> ["connection closed" on client side in fact] (of course). |Are you sure that's the case? For RST attack, it would need to guess |the right TCP sequence numbers. |It seems more likely that the connection is timing out (maybe there's |some firewall enforcing it?) and thus the other side considers it to be |closed. Yes there are many experts on this list who have a penetrating knowledge of protocols and network behaviour, and i really would prefer not having to face that attacks restart just as promptly. Thank you! --steffen From griff.miller at oplink.net Sat Apr 16 07:21:06 2016 From: griff.miller at oplink.net (Griff Miller II) Date: Fri, 15 Apr 2016 16:21:06 -0500 Subject: ssh-keygen -R is case-sensitive, but should not be Message-ID: <0e17af1a288b276e9c45d96957ca89b6.squirrel@webmail.oplink.net> Hostnames and domains are case-insensitive, but ssh-keygen -R is not honoring this. With openssh-7.2p2 Cygwin/Windows 7 (I've also seen the same behavior on RHEL/CentOS with 5.3p1 and 6.6.1p1): % grep -i myhost ~/.ssh/known_hosts # to show myhost is not there yet % ssh gmiller at Myhost.domain.com date # this will put myhost there if I say "yes", which I will do. Note mixed case. The authenticity of host 'myhost.domain.com (1.2.3.4)' can't be established. RSA key fingerprint is SHA256:kr1BeHAQgtdws3gB1NPpKtVDm9OPJ8Gg1loyiDC1z8Y. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'myhost.domain.com,1.2.3.4' (RSA) to the list of known hosts. Fri Apr 15 15:19:54 EDT 2016 % grep -i myhost ~/.ssh/known_hosts # to show that myhost is now in known_hosts - note it has been smashed to lowercase, which is okay. myhost.domain.com,1.2.3.4 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAwBsMvQ0wMfDKDXJT092F3NWjv840AHpzP0MWR+vAK1t+Uu5fjh2Jh93GFtwUH6BHCKntA7ZRTryk8xFGxlXy1NEmBzMkzNEDzWtVKBSTwnyxUZHs81r6DWBmJbsqny+lxYcUIUWMvjHis8ms6fT9G5rfde0hoLQzUSCN+L3cE1k= % ssh-keygen -R Myhost.domain.com # now try to remove it. Case should not matter here. Host Myhost.domain.com not found in /home/millerig/.ssh/known_hosts % grep -i myhost ~/.ssh/known_hosts # ...but it does. Show that it is still there. myhost.domain.com,1.2.3.4 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAwBsMvQ0wMfDKDXJT092F3NWjv840AHpzP0MWR+vAK1t+Uu5fjh2Jh93GFtwUH6BHCKntA7ZRTryk8xFGxlXy1NEmBzMkzNEDzWtVKBSTwnyxUZHs81r6DWBmJbsqny+lxYcUIUWMvjHis8ms6fT9G5rfde0hoLQzUSCN+L3cE1k= % ssh-keygen -R myhost.domain.com # this time it will work because we made sure to use lower case. # Host myhost.domain.com found: line 14 /home/millerig/.ssh/known_hosts updated. Original contents retained as /home/millerig/.ssh/known_hosts.old % grep -i myhost ~/.ssh/known_hosts # show that it's gone % Seems like ssh-keygen -R is performing a case-sensitive string compare on the provided hostname and the hostnames in the known_hosts file. It should be a case-insensitive compare. I can fix my scripts so that I convert to lowercase before calling ssh-keygen -R, but it would be nice if this could be fixed so that others don't get caught by surprise. P.S. The same issue exists for the domain portion of the fully-qualified hostname. P.P.S Here is a patch I whipped up. I hope it might be useful. ------------------------------------------------------- % diff match.c ~/osrc/openssh-7.2p2/match.c 121a122 > char *low_string = 0; 124c125 < u_int i, subi, len = strlen(pattern); --- > u_int i, j, subi, len = strlen(pattern); 156,159c157,165 < if (match_pattern(string, sub)) { < if (negated) < return -1; /* Negative */ < else --- > if (low_string) free(low_string); > low_string = malloc(strlen(string) + 1); > for (j = 0; j < strlen(string); ++j) low_string[j] = tolower(string[j]); > low_string[j] = 0; > if (match_pattern((dolower ? low_string : string), sub)) { > if (negated) { > got_positive = -1; /* Negative */ > break; > } else 165,166c171,172 < * Return success if got a positive match. If there was a negative < * match, we have already returned -1 and never get here. --- > * Return success if there was a positive match; > * return -1 if there was a negative match. 167a174 > if (low_string) free(low_string); ------------------------------------------------------- Griff From griff.miller at oplink.net Sat Apr 16 05:16:54 2016 From: griff.miller at oplink.net (Griff Miller II) Date: Fri, 15 Apr 2016 14:16:54 -0500 Subject: Broken link on openssh.com Message-ID: <8b44c5a4f764689d0bb7fbed7503e4b8.squirrel@webmail.oplink.net> http://www.openssh.com/report.html points to http://www.openssh.com/faq.html, which doesn't exist. It's near the top of the page, with hypertext "Check the FAQ for problems frequently reported as bugs but which aren't. " . From keisial at gmail.com Sat Apr 16 07:53:53 2016 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Fri, 15 Apr 2016 23:53:53 +0200 Subject: Strange behaviour with ptmx file descriptors In-Reply-To: References: <5710309D.4060900@gmail.com> Message-ID: <571162F1.4050406@gmail.com> El 15/04/16 11:28, Nacho del Rey escribi?: > Hi Angel and many thanks for your answer > > The application still sending & receiving data > .- strace over the application: I asked for the corresponding strace of the client ssh, where the data should have been received and printed to the console. > The strange thing is all file descriptors of all processes are in > place but it seems for any strange reason, something happen to fd#13 ( > C Program fd #1 --> ssd read fd #13) because it disappears from the > select call (it won't be available in the read fd set ever) Interesting. I wonder if that's expected and sshd waits for acknowledgment from the remote ssh before reading again. Also, seems you missed this suggestion: > > What's the terminal emulator used in the client side? Does > resetting it (from a menu option) make it receive the server > output again? > > Cheers > Best regards From griff.miller at oplink.net Sat Apr 16 08:32:24 2016 From: griff.miller at oplink.net (Griff Miller II) Date: Fri, 15 Apr 2016 17:32:24 -0500 Subject: ssh-keygen -R is case-sensitive, but should not be Message-ID: Here is a better patch. Somehow I pasted an older version of my edits: ------------------------------------------------------- % diff ./match.c /home/millerig/osrc/openssh-7.2p2/match.c 121a122 > char *low_string = 0; 156,159c157,168 < if (match_pattern(string, sub)) { < if (negated) < return -1; /* Negative */ < else --- > if (dolower) { > u_int j; > if (low_string) free(low_string); > low_string = malloc(strlen(string) + 1); > for (j = 0; j < strlen(string); ++j) low_string[j] = tolower(string[j]); > low_string[j] = 0; > } > if (match_pattern((dolower ? low_string : string), sub)) { > if (negated) { > got_positive = -1; /* Negative */ > break; > } else 165,166c174,175 < * Return success if got a positive match. If there was a negative < * match, we have already returned -1 and never get here. --- > * Return success if there was a positive match; > * return -1 if there was a negative match. 167a177 > if (low_string) free(low_string); ------------------------------------------------------- From keisial at gmail.com Sat Apr 16 09:28:00 2016 From: keisial at gmail.com (=?windows-1252?Q?=C1ngel_Gonz=E1lez?=) Date: Sat, 16 Apr 2016 01:28:00 +0200 Subject: ssh-keygen -R is case-sensitive, but should not be In-Reply-To: References: Message-ID: <57117900.5060008@gmail.com> On 16/04/16 00:32, Griff Miller II wrote: > Here is a better patch. Somehow I pasted an older version of my edits: Hello Griff Thanks for your patch. That will surely help the maintainers. Here are a few comments from my part: > ------------------------------------------------------- > % diff ./match.c /home/millerig/osrc/openssh-7.2p2/match.c > 121a122 I'd have prefered an unified diff :) >> char *low_string = 0; I know that the C standard guarantees that it has the exact same semantic, but please, if you are initializing a pointer, use NULL. (PS: there's exactly an instance of that in openssh code at server_input_hostkeys_prove, that should be changed, too) There's a memory leak on line 147 when a subpattern is too long. > 156,159c157,168 > < if (match_pattern(string, sub)) { > < if (negated) > < return -1; /* Negative */ > < else > --- >> if (dolower) { By performing the lowercase here, you are doing a free() + malloc() + tolower() copying of the string per subpattern. Just move the lowercasing code before the for. >> u_int j; >> if (low_string) free(low_string); Which then makes this innecessary. >> low_string = malloc(strlen(string) + 1); Use xmalloc() here >> for (j = 0; j< strlen(string); ++j) low_string[j] = tolower(string[j]); I'd recommend breaking this in two lines. The compiler will probably figure out that strlen() can be called only once, instead of creating O(n?) code, but this is equivalent to ?for (j = 0; string[j]; ?? >> low_string[j] = 0; Similar to the above NULL issue: low_string is a char*, so -although equivalent- it's generally better to use '\0'. >> } >> if (match_pattern((dolower ? low_string : string), sub)) { >> if (negated) { >> got_positive = -1; /* Negative */ >> break; >> } else > 165,166c174,175 > < * Return success if got a positive match. If there was a negative > < * match, we have already returned -1 and never get here. > --- >> * Return success if there was a positive match; >> * return -1 if there was a negative match. > 167a177 >> if (low_string) free(low_string); Useless if Best regards From griff.miller at oplink.net Sat Apr 16 14:19:57 2016 From: griff.miller at oplink.net (Griff Miller II) Date: Fri, 15 Apr 2016 23:19:57 -0500 Subject: ssh-keygen -R is case-sensitive, but should not be In-Reply-To: <57117900.5060008@gmail.com> References: <57117900.5060008@gmail.com> Message-ID: <130fe2e6ca8bac2172b9331550573a45.squirrel@webmail.oplink.net> ?ngel, thanks for the comments. I'm really annoyed with myself about that memory leak. :) I guess that will teach me not to break one of my own rules, i.e. always set the code aside for a while and take a second look later. I like your technique for terminating the string copy loop, i.e. testing on string[i] instead of i < strlen(string). I got rid of the j declaration, BTW. Of course it makes more sense to move the string copy outside the loop. I'm annoyed with myself about that, too. I knew that free() is supposed to do nothing if you pass it a null pointer, but it's an old habit from the days of sketchy C compilers. :) New diff attached. On Fri, April 15, 2016 6:28 pm, ?ngel Gonz?lez wrote: > On 16/04/16 00:32, Griff Miller II wrote: > >> Here is a better patch. Somehow I pasted an older version of my edits: >> > > Hello Griff > > > Thanks for your patch. That will surely help the maintainers. > Here are a few comments from my part: > > >> ------------------------------------------------------- >> % diff ./match.c /home/millerig/osrc/openssh-7.2p2/match.c >> 121a122 >> > I'd have prefered an unified diff :) > > > >>> char *low_string = 0; > I know that the C standard guarantees that it has the exact > same semantic, but please, if you are initializing a pointer, use NULL. > > (PS: there's exactly an instance of that in openssh code at > server_input_hostkeys_prove, that should be changed, too) > > There's a memory leak on line 147 when a subpattern is too long. > > > >> 156,159c157,168 >> < if (match_pattern(string, sub)) { >> < if (negated) >> < return -1; /* Negative */ >> < else >> --- >> >>> if (dolower) { > By performing the lowercase here, you are doing a free() + malloc() + > tolower() copying of the string per subpattern. Just move the lowercasing > code before the for. > >>> u_int j; if (low_string) free(low_string); > Which then makes this innecessary. > > >>> low_string = malloc(strlen(string) + 1); > Use xmalloc() here > > >>> for (j = 0; j< strlen(string); ++j) low_string[j] = >>> tolower(string[j]); > I'd recommend breaking this in two lines. > > > The compiler will probably figure out that strlen() can be called only > once, instead of creating O(n?) code, but this is equivalent to ?for (j = > 0; string[j]; ? > > >>> low_string[j] = 0; > Similar to the above NULL issue: low_string is a char*, so -although > equivalent- it's generally better to use '\0'. > >>> } >>> if (match_pattern((dolower ? low_string : string), sub)) { if (negated) >>> { >>> got_positive = -1; /* Negative */ break; } else >>> >> 165,166c174,175 >> < * Return success if got a positive match. If there was a negative >> < * match, we have already returned -1 and never get here. >> --- >> >>> * Return success if there was a positive match; >>> * return -1 if there was a negative match. >>> >> 167a177 >> >>> if (low_string) free(low_string); > Useless if > > > Best regards > > > From griff.miller at oplink.net Sat Apr 16 14:33:07 2016 From: griff.miller at oplink.net (Griff Miller II) Date: Fri, 15 Apr 2016 23:33:07 -0500 Subject: ssh-keygen -R is case-sensitive, but should not be In-Reply-To: <130fe2e6ca8bac2172b9331550573a45.squirrel@webmail.oplink.net> References: <57117900.5060008@gmail.com> <130fe2e6ca8bac2172b9331550573a45.squirrel@webmail.oplink.net> Message-ID: <1ef0ce022329f05f2f5b5aa089291412.squirrel@webmail.oplink.net> I guess attachments get stripped out. I'll paste it: ---------------------------------------------------- --- match.c 2016-03-09 12:04:48.000000000 -0600 +++ /home/millerig/osrc/openssh-7.2p2/match.c 2016-04-15 22:50:08.917536100 -0500 @@ -119,10 +119,18 @@ match_pattern_list(const char *string, const char *pattern, int dolower) { char sub[1024]; + char *low_string = NULL; int negated; int got_positive; u_int i, subi, len = strlen(pattern); + if (dolower) { + low_string = xmalloc(strlen(string) + 1); + for (i = 0; string[i]; ++i) + low_string[i] = tolower(string[i]); + low_string[i] = '\0'; + } + got_positive = 0; for (i = 0; i < len;) { /* Check if the subpattern is negated. */ @@ -142,8 +150,10 @@ sub[subi] = dolower && isupper((u_char)pattern[i]) ? tolower((u_char)pattern[i]) : pattern[i]; /* If subpattern too long, return failure (no match). */ - if (subi >= sizeof(sub) - 1) + if (subi >= sizeof(sub) - 1) { + free(low_string); return 0; + } /* If the subpattern was terminated by a comma, skip the comma. */ if (i < len && pattern[i] == ',') @@ -153,18 +163,20 @@ sub[subi] = '\0'; /* Try to match the subpattern against the string. */ - if (match_pattern(string, sub)) { - if (negated) - return -1; /* Negative */ - else + if (match_pattern((dolower ? low_string : string), sub)) { + if (negated) { + got_positive = -1; /* Negative */ + break; + } else got_positive = 1; /* Positive */ } } /* - * Return success if got a positive match. If there was a negative - * match, we have already returned -1 and never get here. + * Return success if there was a positive match; + * return -1 if there was a negative match. */ + free(low_string); return got_positive; } ---------------------------------------------------- From odelreym at gmail.com Sat Apr 16 19:11:32 2016 From: odelreym at gmail.com (Nacho del Rey) Date: Sat, 16 Apr 2016 11:11:32 +0200 Subject: Strange behaviour with ptmx file descriptors In-Reply-To: <571162F1.4050406@gmail.com> References: <5710309D.4060900@gmail.com> <571162F1.4050406@gmail.com> Message-ID: Hi again I think I didn't explain the problem properly I'll try to explain it using an example of what it happened last time in Feb, the 23th This is the point of view of the C application, running in the linux box, when answering to the client: 4911 1456244042.324336 write(1, "\7", 1) = 1 4911 1456244042.324610 write(1, "\33[1;16H \33[6;6H_______\33[7;1H -INFORME CANT. RECOGIDA-\33[7;26H", 66) = 66 This is the point of view of the ssh process in the linux box: 6647 1456244042.323463 select(14, [3 9 13], [], NULL, {900, 0}) = 1 (in [13], left {899, 998569}) 6647 1456244042.324971 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 6647 1456244042.325010 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 6647 1456244042.325033 read(13, "\7\33[1;16H \33[6;6H_______\33[7;1H -INFORME CANT. RECOGIDA-\33[7;26H", 16384) = 67 6647 1456244042.325126 select(14, [3 9], [3], NULL, {900, 0}) = 1 (out [3], left {899, 999998}) 6647 1456244042.325203 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 6647 1456244042.325240 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 6647 1456244042.325264 write(3, "P\247\244}\277\322\260\21\3314\7\227\223~\317\360\35\334\232\372\237\250\320\312\1;\25\37\23\363\363O&0\355i{zUbr\365,\362yyl\222", 48) = 48 6647 1456244042.325310 select(14, [3 9], [], NULL, {900, 0}) = 1 (in [3], left {892, 12016}) <<-- where id fd#13 ? This is the point of view of the ssh client: 74539.285 0BE6003A I-ITE 38:VT220_IO: tohost:0x31='1' 74539.300 0BE6003A I-ITE 52:ANSITERM: charin: 74539.300 0BE6003A I-ITE 53:ANSITERM: charin:<[> 74539.300 0BE6003A I-ITE 54:ANSITERM: charin:<1> 74539.300 0BE6003A I-ITE 55:ANSITERM: charin:<;> 74539.300 0BE6003A I-ITE 56:ANSITERM: charin:<2> 74539.300 0BE6003A I-ITE 57:ANSITERM: charin:<3> 74539.300 0BE6003A I-ITE 58:ANSITERM: charin: 74539.301 0BE6003A I-ITE 59:ANSITERM: charin:<1> 74539.301 0BE6003A I-ITE 63:ANSITERM: charin: 74539.301 0BE6003A I-ITE 64:ANSITERM: charin:<[> 74539.301 0BE6003A I-ITE 65:ANSITERM: charin:<1> 74539.301 0BE6003A I-ITE 66:ANSITERM: charin:<;> 74539.302 0BE6003A I-ITE 67:ANSITERM: charin:<2> 74539.302 0BE6003A I-ITE 68:ANSITERM: charin:<4> 74539.302 0BE6003A I-ITE 69:ANSITERM: charin: 74539.302 0BE6003A I-ITE 70:ANSITERM: charin: 74539.346 0BE6003A I-ITE 71:ANSITERM: charin: 74539.347 0BE6003A I-ITE 72:ANSITERM: charin:<[> 74539.347 0BE6003A I-ITE 73:ANSITERM: charin:<1> 74539.347 0BE6003A I-ITE 74:ANSITERM: charin:<;> 74539.347 0BE6003A I-ITE 75:ANSITERM: charin:<1> 74539.347 0BE6003A I-ITE 76:ANSITERM: charin:<6> 74539.347 0BE6003A I-ITE 77:ANSITERM: charin: 74539.347 0BE6003A I-ITE 78:ANSITERM: charin:< > 74539.348 0BE6003A I-ITE 82:ANSITERM: charin:< > 74539.348 0BE6003A I-ITE 86:ANSITERM: charin:< > 74547.277 0BE6003A I-ITE 97:VT220_IO: tohost:0x08='.' <-- here the client stops receiving data 74547.779 0BE6003A I-ITE 08:VT220_IO: tohost:0x08='.' 74547.821 0BE6003A I-ITE 19:VT220_IO: tohost:0x08='.' 74547.864 0BE6003A I-ITE 30:VT220_IO: tohost:0x08='.' 74547.907 0BE6003A I-ITE 41:VT220_IO: tohost:0x08='.' 74547.950 0BE6003A I-ITE 52:VT220_IO: tohost:0x08='.' 74547.993 0BE6003A I-ITE 63:VT220_IO: tohost:0x08='.' 74548.036 0BE6003A I-ITE 74:VT220_IO: tohost:0x08='.' And when it happens, the ssh client still working properly, it continues sending keystrokes to the the application, the application receives these keystrokes, it answers to the client, but the answer is not yet received by the sshd process (so it seems the application is frozen... when it is not ?true?) One time, the operator tried to reset the connection from the ssh client, but no way The C program works properly thru telnet.. no incident has been reported ever I hope this information helps Many thanks Regards Nacho. 2016-04-15 23:53 GMT+02:00 ?ngel Gonz?lez : > El 15/04/16 11:28, Nacho del Rey escribi?: > > Hi Angel and many thanks for your answer > > The application still sending & receiving data > .- strace over the application: > > I asked for the corresponding strace of the client ssh, where the data > should have been received and printed to the console. > > The strange thing is all file descriptors of all processes are in place > but it seems for any strange reason, something happen to fd#13 ( C Program > fd #1 --> ssd read fd #13) because it disappears from the select call (it > won't be available in the read fd set ever) > > Interesting. I wonder if that's expected and sshd waits for acknowledgment > from the remote ssh before reading again. > > > Also, seems you missed this suggestion: > > What's the terminal emulator used in the client side? Does resetting it >> (from a menu option) make it receive the server output again? >> >> Cheers >> > > Best regards > > From peter at stuge.se Sat Apr 16 22:14:05 2016 From: peter at stuge.se (Peter Stuge) Date: Sat, 16 Apr 2016 12:14:05 +0000 Subject: Strange behaviour with ptmx file descriptors In-Reply-To: References: <5710309D.4060900@gmail.com> <571162F1.4050406@gmail.com> Message-ID: <20160416121405.GF26940@foo.stuge.se> 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 lists at y42.org Tue Apr 19 02:39:49 2016 From: lists at y42.org (IMAP List Administration) Date: Mon, 18 Apr 2016 18:39:49 +0200 Subject: request: add IP address to a log message to allow blocking In-Reply-To: References: <56FA65BA.6010704@y42.org> <877fgk2acd.fsf@alice.fifthhorseman.net> Message-ID: <57150DD5.5000701@y42.org> On 03/30/2016 12:37 AM, Martin Schr?der wrote: > 2016-03-30 0:22 GMT+02:00 Daniel Kahn Gillmor : >> Will it be configurable? There are situations where people actively >> don't want to have any IP addresses logged for legal reasons, and >> ideally it would be easy to get diagnostics without risks of IP >> addresses being written to log storage. > Aye. Or scramble the lower octet of IPv4 addresses (don't know what's > the equivalent for IPv6). oh good idea. For the < 1% of people that want to intentionally destroy their data let's impose mandatory data destruction on everyone. From brewbot at yahoo.com Tue Apr 19 17:09:14 2016 From: brewbot at yahoo.com (brewbot at yahoo.com) Date: Tue, 19 Apr 2016 07:09:14 +0000 Subject: openSSH w/out openSSL Message-ID: <20160419070914.GA25819@brew-bot.com> All, I looked into compiling openSSH w/out openSSL and discovered it would not save the ed25519 key if it contained a passphrase. Debugging revealed the code is using the DEFAULT_CIPHERNAME = aes256-cbc, but the availble ciphers w/out openSSL are of the aes*-ctr types. Changing DEFAULT_CIPHERNAME = aes256-ctr in sshkey.c fixed the problem. [1] has some discussion regarding aes256-cbc vs aes256-ctr but would like another opinion on whether those points are valid(or references to journal papers discussing the differences). Are there reasons the default is set to aes256-cbc from a security standpoint? If this is a valid fix, please push it upstream. -- rick [1] https://crypto.stackexchange.com/questions/18538/aes256-cbc-vs-aes256-ctr-in-ssh From elouan.keryell at gmail.com Tue Apr 19 22:04:33 2016 From: elouan.keryell at gmail.com (Elouan Keryell-Even) Date: Tue, 19 Apr 2016 14:04:33 +0200 Subject: Client-side public key causing mess Message-ID: Hello, I have a client machine and a server machine. I generated a pair of private-public rsa keys using ssh-keygen. On the client-machine, I uploaded my private key onto ~/.ssh/id_rsa On the server machine, I appended the content of the public key to .ssh/authorized_keys I can successfully connect from the client to the server with that config. However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key file that doesn?t match the private key file ~/.ssh/id_rsa, it will fail with ?Permission denied (publickey).? Error on the server-side (sshd logs): error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106) # openssl errstr 0407006A error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 It seems weird to me that a public key on the client side is taken into account, when it works well without. Linux distrib: CentOS 7 ssh version on the client side: OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013 ssh version on the server side: OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013 Full verbose output of ssh-client: # ssh -vvv OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 56: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to [] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug3: Incorrect RSA1 identifier debug3: Could not load "/root/.ssh/id_rsa" as a RSA1 public key debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-ed25519,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,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-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,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-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,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-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,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-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: setup hmac-md5-etm at openssh.com debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none debug2: mac_setup: setup hmac-md5-etm at openssh.com debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA debug3: load_hostkeys: loading entries for host "" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: Host '' is known and matches the ECDSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/id_rsa (0x7fb0334d5fd0), debug2: key: /root/.ssh/id_dsa ((nil)), debug2: key: /root/.ssh/id_ecdsa ((nil)), debug2: key: /root/.ssh/id_ed25519 ((nil)), debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /root/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey debug1: Trying private key: /root/.ssh/id_dsa debug3: no such identity: /root/.ssh/id_dsa: No such file or directory debug1: Trying private key: /root/.ssh/id_ecdsa debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /root/.ssh/id_ed25519 debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey). Elouan From jjelen at redhat.com Tue Apr 19 23:18:10 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 19 Apr 2016 15:18:10 +0200 Subject: Client-side public key causing mess In-Reply-To: References: Message-ID: <57163012.6080803@redhat.com> On 04/19/2016 02:04 PM, Elouan Keryell-Even wrote: > However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key file > that doesn?t match the private key file ~/.ssh/id_rsa, it will fail with > ?Permission denied (publickey).? Why would you do that? > It seems weird to me that a public key on the client side is taken into > account, when it works well without. The pubkey authentication works in two steps. * The first one is verification only with public key (cheap fast operation, which does not require to decode your private key and to enter pass-phrase). * If the first succeeds (or there is not corresponding public key) then the server verifies if you have corresponding private key. If you provide signature with different private key, server will fail to verify the signature and fails. > debug1: Next authentication method: publickey > > debug1: Offering RSA public key: /root/.ssh/id_rsa > > debug3: send_pubkey_test > > debug2: we sent a publickey packet, wait for reply > > debug1: Authentications that can continue: publickey It is certainly miss-configuration, but client should probably validate what data does it send. I played with similar issue few weeks ago. If I am right, it worked the same way in recent openssh versions. But I would not consider this as a high priority. -- Jakub Jelen Security Technologies Red Hat From elouan.keryell at gmail.com Wed Apr 20 17:33:26 2016 From: elouan.keryell at gmail.com (Elouan Keryell-Even) Date: Wed, 20 Apr 2016 09:33:26 +0200 Subject: Client-side public key causing mess In-Reply-To: <57163012.6080803@redhat.com> References: <57163012.6080803@redhat.com> Message-ID: 2016-04-19 15:18 GMT+02:00 Jakub Jelen : > On 04/19/2016 02:04 PM, Elouan Keryell-Even wrote: > >> However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key file >> that doesn?t match the private key file ~/.ssh/id_rsa, it will fail with >> ?Permission denied (publickey).? >> > Why would you do that? Well it just happened to me, though not in that order. I had old keys id_rsa & id_rsa.pub files in my .ssh directory. I uploaded a new id_rsa private key file (generated on another machine) to replace the old one. However, the id_rsa.pub stayed the same, and I spent a looot of time to figure out it was the cause of my problem. > > It seems weird to me that a public key on the client side is taken into >> account, when it works well without. >> > The pubkey authentication works in two steps. > * The first one is verification only with public key (cheap fast > operation, which does not require to decode your private key and to enter > pass-phrase). > * If the first succeeds (or there is not corresponding public key) then > the server verifies if you have corresponding private key. If you provide > signature with different private key, server will fail to verify the > signature and fails. Ok, I understand better know. I guess my mistake was to upload only the private key on the client side, while I should have uploaded both keys (wiping out the unnecessary old config which was causing trouble). > > debug1: Next authentication method: publickey >> >> debug1: Offering RSA public key: /root/.ssh/id_rsa >> >> debug3: send_pubkey_test >> >> debug2: we sent a publickey packet, wait for reply >> >> debug1: Authentications that can continue: publickey >> > It is certainly miss-configuration, but client should probably validate > what data does it send. I played with similar issue few weeks ago. If I am > right, it worked the same way in recent openssh versions. But I would not > consider this as a high priority. Thank you Jakub, Elouan > > > -- > Jakub Jelen > Security Technologies > Red Hat > > From odelreym at gmail.com Thu Apr 21 00:52:45 2016 From: odelreym at gmail.com (Nacho del Rey) Date: Wed, 20 Apr 2016 16:52:45 +0200 Subject: Strange behaviour with ptmx file descriptors Message-ID: 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 da_audiophile at yahoo.com Thu Apr 21 05:19:44 2016 From: da_audiophile at yahoo.com (John) Date: Wed, 20 Apr 2016 19:19:44 +0000 (UTC) Subject: Backspace key does not work in a ssh chroot jail References: <669094821.4373484.1461179984857.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <669094821.4373484.1461179984857.JavaMail.yahoo@mail.yahoo.com> I setup a ssh chroot jail following this[1] guide. It works for my user to login, use ls and use scp which is all I really want. I do have a problem I cannot solve: when connected and navigating the filesystem, the backspace key actually moves the cursor forward and does not delete what I type. I may have found a hint from some googling that readline will read in /etc/inputrc on login but if this is true, I am unsure what component of readline might I require to copy over from the live system into the chroot jail. For reference, I include the tree view of the chroot jail I created below. Thank you kindly for any suggestions. % tree -a /var/jail /var/jail ??? .bashrc ??? bin -> usr/bin ??? dev ? ??? null ? ??? random ? ??? tty ? ??? zero ??? etc ? ??? group ? ??? inputrc ? ??? passwd ? ??? profile ??? lib -> usr/lib ??? lib64 -> usr/lib64 ??? usr ??? bin ? ??? bash ? ??? ls ? ??? scp ??? lib ? ??? libcap.so.2 ? ??? libc.so.6 ? ??? libdl.so.2 ? ??? libncursesw.so.6 ? ??? libnss3.so ? ??? libnssckbi-p11-kit.so ? ??? libnssckbi.so ? ??? libnss_compat-2.23.so ? ??? libnss_compat.so ? ??? libnss_compat.so.2 ? ??? libnss_db-2.23.so ? ??? libnssdbm3.chk ? ??? libnssdbm3.so ? ??? libnss_db.so ? ??? libnss_db.so.2 ? ??? libnss_dns-2.23.so ? ??? libnss_dns.so ? ??? libnss_dns.so.2 ? ??? libnss_files-2.23.so ? ??? libnss_files.so ? ??? libnss_files.so.2 ? ??? libnss_hesiod-2.23.so ? ??? libnss_hesiod.so ? ??? libnss_hesiod.so.2 ? ??? libnss_myhostname.so.2 ? ??? libnss_mymachines.so.2 ? ??? libnss_nis-2.23.so ? ??? libnss_nisplus-2.23.so ? ??? libnss_nisplus.so ? ??? libnss_nisplus.so.2 ? ??? libnss_nis.so ? ??? libnss_nis.so.2 ? ??? libnss_resolve.so.2 ? ??? libnsssysinit.so ? ??? libnssutil3.so ? ??? libnss_winbind.so ? ??? libnss_winbind.so.2 ? ??? libnss_wins.so ? ??? libnss_wins.so.2 ? ??? libreadline.so.6 ??? lib64 ??? ld-linux-x86-64.so.2 9 directories, 53 files 1. http://www.cyberciti.biz/faq/debian-ubuntu-restricting-ssh-user-session-to-a-directory-chrooted-jail/ From ras at anzio.com Thu Apr 21 06:48:26 2016 From: ras at anzio.com (Bob Rasmussen) Date: Wed, 20 Apr 2016 13:48:26 -0700 (PDT) Subject: Backspace key does not work in a ssh chroot jail In-Reply-To: <669094821.4373484.1461179984857.JavaMail.yahoo@mail.yahoo.com> References: <669094821.4373484.1461179984857.JavaMail.yahoo.ref@mail.yahoo.com> <669094821.4373484.1461179984857.JavaMail.yahoo@mail.yahoo.com> Message-ID: Have you looked at your 'stty' settings? Do stty -a and see what the 'erase' variable equates to. What are you using for an SSH client? On what OS? Some clients can pass along settings during the login procedure. On Wed, 20 Apr 2016, John wrote: > I setup a ssh chroot jail following this[1] guide. It works for my user to login, use ls and use scp which is all I really want. I do have a problem I cannot solve: when connected and navigating the filesystem, the backspace key actually moves the cursor forward and does not delete what I type. > > I may have found a hint from some googling that readline will read in /etc/inputrc on login but if this is true, I am unsure what component of readline might I require to copy over from the live system into the chroot jail. > > For reference, I include the tree view of the chroot jail I created below. Thank you kindly for any suggestions. > > % tree -a /var/jail > > /var/jail > ??? .bashrc > ??? bin -> usr/bin > ??? dev > ? ??? null > ? ??? random > ? ??? tty > ? ??? zero > ??? etc > ? ??? group > ? ??? inputrc > ? ??? passwd > ? ??? profile > ??? lib -> usr/lib > ??? lib64 -> usr/lib64 > ??? usr > ??? bin > ? ??? bash > ? ??? ls > ? ??? scp > ??? lib > ? ??? libcap.so.2 > ? ??? libc.so.6 > ? ??? libdl.so.2 > ? ??? libncursesw.so.6 > ? ??? libnss3.so > ? ??? libnssckbi-p11-kit.so > ? ??? libnssckbi.so > ? ??? libnss_compat-2.23.so > ? ??? libnss_compat.so > ? ??? libnss_compat.so.2 > ? ??? libnss_db-2.23.so > ? ??? libnssdbm3.chk > ? ??? libnssdbm3.so > ? ??? libnss_db.so > ? ??? libnss_db.so.2 > ? ??? libnss_dns-2.23.so > ? ??? libnss_dns.so > ? ??? libnss_dns.so.2 > ? ??? libnss_files-2.23.so > ? ??? libnss_files.so > ? ??? libnss_files.so.2 > ? ??? libnss_hesiod-2.23.so > ? ??? libnss_hesiod.so > ? ??? libnss_hesiod.so.2 > ? ??? libnss_myhostname.so.2 > ? ??? libnss_mymachines.so.2 > ? ??? libnss_nis-2.23.so > ? ??? libnss_nisplus-2.23.so > ? ??? libnss_nisplus.so > ? ??? libnss_nisplus.so.2 > ? ??? libnss_nis.so > ? ??? libnss_nis.so.2 > ? ??? libnss_resolve.so.2 > ? ??? libnsssysinit.so > ? ??? libnssutil3.so > ? ??? libnss_winbind.so > ? ??? libnss_winbind.so.2 > ? ??? libnss_wins.so > ? ??? libnss_wins.so.2 > ? ??? libreadline.so.6 > ??? lib64 > ??? ld-linux-x86-64.so.2 > > 9 directories, 53 files > > 1. http://www.cyberciti.biz/faq/debian-ubuntu-restricting-ssh-user-session-to-a-directory-chrooted-jail/ > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From da_audiophile at yahoo.com Thu Apr 21 06:53:21 2016 From: da_audiophile at yahoo.com (John) Date: Wed, 20 Apr 2016 20:53:21 +0000 (UTC) Subject: Backspace key does not work in a ssh chroot jail In-Reply-To: References: Message-ID: <1023428681.4425237.1461185601816.JavaMail.yahoo@mail.yahoo.com> ----- Original Message ----- > From: Bob Rasmussen > To: John > Cc: "openssh-unix-dev at mindrot.org" > Sent: Wednesday, April 20, 2016 4:48 PM > Subject: Re: Backspace key does not work in a ssh chroot jail > > Have you looked at your 'stty' settings? Do > stty -a > and see what the 'erase' variable equates to. > > What are you using for an SSH client? On what OS? Some clients can pass > along settings during the login procedure. Initially, I did not copy /usr/bin/stty from the root filesystem to the jail. I just did now and I have attached the output of the command you asked about below. To answer your other question: the ssh client is the linux native /usr/bin/ssh (provided by openssh 7.2p2). >From within the chroot jail: $ stty -a speed 38400 baud; rows 36; columns 128; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc >From the native linux environment: % stty -a speed 38400 baud; rows 36; columns 128; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc From peter at stuge.se Thu Apr 21 07:08:31 2016 From: peter at stuge.se (Peter Stuge) Date: Wed, 20 Apr 2016 21:08:31 +0000 Subject: Strange behaviour with ptmx file descriptors In-Reply-To: References: Message-ID: <20160420210831.GH26940@foo.stuge.se> Nacho del Rey wrote: > Can you let me know how to proceed for forward this to the openssh > source code team? Map your strace syscalls to the source code and point out where the problem is. Do debugging on your own. Send a patch. //Peter From djm at mindrot.org Fri Apr 22 17:41:10 2016 From: djm at mindrot.org (Damien Miller) Date: Fri, 22 Apr 2016 17:41:10 +1000 (AEST) Subject: Client-side public key causing mess In-Reply-To: References: Message-ID: On Tue, 19 Apr 2016, Elouan Keryell-Even wrote: > Hello, > > I have a client machine and a server machine. I generated a pair of > private-public rsa keys using ssh-keygen. > > On the client-machine, I uploaded my private key onto ~/.ssh/id_rsa > > On the server machine, I appended the content of the public key to > .ssh/authorized_keys > > I can successfully connect from the client to the server with that config. > > However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key file > that doesn?t match the private key file ~/.ssh/id_rsa, it will fail with > ?Permission denied (publickey).? > > Error on the server-side (sshd logs): > > error: RSA_public_decrypt failed: > error:0407006A:lib(4):func(112):reason(106) ssh uses the public key to avoid loading or decrypting the private key for cases were it isn't necessary. We should improve the handling of cases where they don't match. diff --git a/sshconnect2.c b/sshconnect2.c index 1cf48a2..5a27392 100644 --- a/sshconnect2.c +++ b/sshconnect2.c @@ -1243,6 +1243,14 @@ load_identity_file(Identity *id) quit = 1; break; } + if (private != NULL && id->key != NULL && + !sshkey_equal(id->key, private)) { + error("Load key \"%s\": private key does not match " + "public key", id->filename); + sshkey_free(private); + private = NULL; + quit = 1; + } if (!quit && private != NULL && id->agent_fd == -1 && !(id->key && id->isprivate)) maybe_add_key_to_agent(id->filename, private, comment, From raubvogel at gmail.com Fri Apr 22 23:06:14 2016 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 22 Apr 2016 09:06:14 -0400 Subject: Client-side public key causing mess In-Reply-To: References: Message-ID: On Apr 19, 2016 8:11 AM, "Elouan Keryell-Even" wrote: > > Hello, > > > > I have a client machine and a server machine. I generated a pair of > private-public rsa keys using ssh-keygen. > > > > On the client-machine, I uploaded my private key onto ~/.ssh/id_rsa > > On the server machine, I appended the content of the public key to > .ssh/authorized_keys > > > > I can successfully connect from the client to the server with that config. > > > > However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key file > that doesn?t match the private key file ~/.ssh/id_rsa, it will fail with > ?Permission denied (publickey).? > > > > Error on the server-side (sshd logs): > > error: RSA_public_decrypt failed: > error:0407006A:lib(4):func(112):reason(106) > > > > > > # openssl errstr 0407006A > > error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is > not 01 > > > > It seems weird to me that a public key on the client side is taken into > account, when it works well without. > > > > Linux distrib: CentOS 7 > > ssh version on the client side: OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb > 2013 > > ssh version on the server side: OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb > 2013 > > > > Full verbose output of ssh-client: > > # ssh -vvv > What happens if you specify the private key (as in -i /root/.ssh/id_rsa)? > OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug1: /etc/ssh/ssh_config line 56: Applying options for * > > debug2: ssh_connect: needpriv 0 > > debug1: Connecting to [] port 22. > > debug1: Connection established. > > debug1: permanently_set_uid: 0/0 > > debug3: Incorrect RSA1 identifier > > debug3: Could not load "/root/.ssh/id_rsa" as a RSA1 public key > > debug1: identity file /root/.ssh/id_rsa type 1 > > debug1: identity file /root/.ssh/id_rsa-cert type -1 > > debug1: identity file /root/.ssh/id_dsa type -1 > > debug1: identity file /root/.ssh/id_dsa-cert type -1 > > debug1: identity file /root/.ssh/id_ecdsa type -1 > > debug1: identity file /root/.ssh/id_ecdsa-cert type -1 > > debug1: identity file /root/.ssh/id_ed25519 type -1 > > debug1: identity file /root/.ssh/id_ed25519-cert type -1 > > debug1: Enabling compatibility mode for protocol 2.0 > > debug1: Local version string SSH-2.0-OpenSSH_6.6.1 > > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 > > debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000 > > debug2: fd 3 setting O_NONBLOCK > > debug3: load_hostkeys: loading entries for host "" from file > "/root/.ssh/known_hosts" > > debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1 > > debug3: load_hostkeys: loaded 1 keys > > debug3: order_hostkeyalgs: prefer hostkeyalgs: > ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 > > debug1: SSH2_MSG_KEXINIT sent > > debug1: SSH2_MSG_KEXINIT received > > debug2: kex_parse_kexinit: > curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > > debug2: kex_parse_kexinit: > ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, ssh-ed25519-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com, ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com, ssh-dss-cert-v00 at openssh.com,ssh-ed25519,ssh-rsa,ssh-dss > > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, > aes128-gcm at openssh.com,aes256-gcm at openssh.com, chacha20-poly1305 at openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, > aes128-gcm at openssh.com,aes256-gcm at openssh.com, chacha20-poly1305 at openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > > debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,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-ripemd160-etm at openssh.com, hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1, umac-64 at openssh.com,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 > > debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,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-ripemd160-etm at openssh.com, hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1, umac-64 at openssh.com,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 > > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > > debug2: kex_parse_kexinit: > > debug2: kex_parse_kexinit: > > debug2: kex_parse_kexinit: first_kex_follows 0 > > debug2: kex_parse_kexinit: reserved 0 > > debug2: kex_parse_kexinit: > curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > > debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256 > > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, > aes128-gcm at openssh.com,aes256-gcm at openssh.com, chacha20-poly1305 at openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, > aes128-gcm at openssh.com,aes256-gcm at openssh.com, chacha20-poly1305 at openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, > rijndael-cbc at lysator.liu.se > > debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,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-ripemd160-etm at openssh.com, hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1, umac-64 at openssh.com,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 > > debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,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-ripemd160-etm at openssh.com, hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1, umac-64 at openssh.com,umac-128 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 > > debug2: kex_parse_kexinit: none,zlib at openssh.com > > debug2: kex_parse_kexinit: none,zlib at openssh.com > > debug2: kex_parse_kexinit: > > debug2: kex_parse_kexinit: > > debug2: kex_parse_kexinit: first_kex_follows 0 > > debug2: kex_parse_kexinit: reserved 0 > > debug2: mac_setup: setup hmac-md5-etm at openssh.com > > debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none > > debug2: mac_setup: setup hmac-md5-etm at openssh.com > > debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none > > debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 > > debug1: kex: curve25519-sha256 at libssh.org need=16 dh_need=16 > > debug1: sending SSH2_MSG_KEX_ECDH_INIT > > debug1: expecting SSH2_MSG_KEX_ECDH_REPLY > > debug1: Server host key: ECDSA > > debug3: load_hostkeys: loading entries for host "" from file > "/root/.ssh/known_hosts" > > debug3: load_hostkeys: found key type ECDSA in file /root/.ssh/known_hosts:1 > > debug3: load_hostkeys: loaded 1 keys > > debug1: Host '' is known and matches the ECDSA host key. > > debug1: Found key in /root/.ssh/known_hosts:1 > > debug1: ssh_ecdsa_verify: signature correct > > debug2: kex_derive_keys > > debug2: set_newkeys: mode 1 > > debug1: SSH2_MSG_NEWKEYS sent > > debug1: expecting SSH2_MSG_NEWKEYS > > debug2: set_newkeys: mode 0 > > debug1: SSH2_MSG_NEWKEYS received > > debug1: SSH2_MSG_SERVICE_REQUEST sent > > debug2: service_accept: ssh-userauth > > debug1: SSH2_MSG_SERVICE_ACCEPT received > > debug2: key: /root/.ssh/id_rsa (0x7fb0334d5fd0), > > debug2: key: /root/.ssh/id_dsa ((nil)), > > debug2: key: /root/.ssh/id_ecdsa ((nil)), > > debug2: key: /root/.ssh/id_ed25519 ((nil)), > > debug1: Authentications that can continue: publickey > > debug3: start over, passed a different list publickey > > debug3: preferred > gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password > > debug3: authmethod_lookup publickey > > debug3: remaining preferred: keyboard-interactive,password > > debug3: authmethod_is_enabled publickey > > debug1: Next authentication method: publickey > > debug1: Offering RSA public key: /root/.ssh/id_rsa > > debug3: send_pubkey_test > > debug2: we sent a publickey packet, wait for reply > > debug1: Authentications that can continue: publickey > > debug1: Trying private key: /root/.ssh/id_dsa > > debug3: no such identity: /root/.ssh/id_dsa: No such file or directory > > debug1: Trying private key: /root/.ssh/id_ecdsa > > debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory > > debug1: Trying private key: /root/.ssh/id_ed25519 > > debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory > > debug2: we did not send a packet, disable method > > debug1: No more authentication methods to try. > > Permission denied (publickey). > > > > Elouan > _______________________________________________ > 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 Sat Apr 23 03:31:09 2016 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 22 Apr 2016 13:31:09 -0400 Subject: Client-side public key causing mess In-Reply-To: References: Message-ID: On Fri, Apr 22, 2016 at 3:41 AM, Damien Miller wrote: > On Tue, 19 Apr 2016, Elouan Keryell-Even wrote: > >> Hello, >> >> I have a client machine and a server machine. I generated a pair of >> private-public rsa keys using ssh-keygen. >> >> On the client-machine, I uploaded my private key onto ~/.ssh/id_rsa >> >> On the server machine, I appended the content of the public key to >> .ssh/authorized_keys >> >> I can successfully connect from the client to the server with that config. >> >> However, on the client-side, if I add a ~/.ssh/id_rsa.pub public key file >> that doesn?t match the private key file ~/.ssh/id_rsa, it will fail with >> ?Permission denied (publickey).? >> >> Error on the server-side (sshd logs): >> >> error: RSA_public_decrypt failed: >> error:0407006A:lib(4):func(112):reason(106) > > ssh uses the public key to avoid loading or decrypting the private > key for cases were it isn't necessary. We should improve the handling > of cases where they don't match. > But if it does not have the public key whose name matches the private key being used, it will still work, right? If that is the case I too think it should handle non-matching key pairs better. i.e. ignore behave as if there was just a private key there (which is how I use it). Or let user decide if it should warn, ignore completely, or quit. > diff --git a/sshconnect2.c b/sshconnect2.c > index 1cf48a2..5a27392 100644 > --- a/sshconnect2.c > +++ b/sshconnect2.c > @@ -1243,6 +1243,14 @@ load_identity_file(Identity *id) > quit = 1; > break; > } > + if (private != NULL && id->key != NULL && > + !sshkey_equal(id->key, private)) { > + error("Load key \"%s\": private key does not match " > + "public key", id->filename); > + sshkey_free(private); > + private = NULL; > + quit = 1; > + } > if (!quit && private != NULL && id->agent_fd == -1 && > !(id->key && id->isprivate)) > maybe_add_key_to_agent(id->filename, private, comment, > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From leres at ee.lbl.gov Sat Apr 23 04:16:02 2016 From: leres at ee.lbl.gov (Craig Leres) Date: Fri, 22 Apr 2016 11:16:02 -0700 Subject: openssh 7.2p2: tty sometimes left in raw mode after a connection timeout Message-ID: <5b122c85-2852-f5ce-0a50-5046c1b96aef@ee.lbl.gov> I'm running FreeBSD 9 and openssh 7.2p2: ice 1040 % uname -a FreeBSD ice.ee.lbl.gov 9.3-RELEASE FreeBSD 9.3-RELEASE #1 r21: Fri Mar 4 10:42:36 PST 2016 leres at fun.ee.lbl.gov:/sys/amd64/compile/LBL amd64 ice 1041 % ssh -V OpenSSH_7.2p2, OpenSSL 1.0.2g 1 Mar 2016 Occasionally when a connection times out, ssh leaves my shell in raw mode: packet_write_wait: Connection to UNKNOWN port 0: Broken pipe tcsetattr: Interrupted system call I think the problem is that a signal can interrupt tcsetattr() in leave_raw_mode() causing it to fail with EINTR. When this happens, the terminal is left in raw mode. The attached (untested) patch retries the tcsetattr() if it fails with EINTR. Craig -------------- next part -------------- --- sshtty.c.orig 2016-04-22 11:02:05.000000000 -0700 +++ sshtty.c 2016-04-22 11:12:58.000000000 -0700 @@ -41,6 +41,7 @@ #include #include #include +#include #include "sshpty.h" @@ -58,11 +59,14 @@ { if (!_in_raw_mode) return; - if (tcsetattr(fileno(stdin), TCSADRAIN, &_saved_tio) == -1) { + while (tcsetattr(fileno(stdin), TCSADRAIN, &_saved_tio) == -1) { if (!quiet) perror("tcsetattr"); - } else - _in_raw_mode = 0; + if (errno == EINTR) + continue; + return; + } + _in_raw_mode = 0; } void From djm at mindrot.org Sat Apr 23 10:39:50 2016 From: djm at mindrot.org (Damien Miller) Date: Sat, 23 Apr 2016 10:39:50 +1000 (AEST) Subject: Client-side public key causing mess In-Reply-To: References: Message-ID: On Fri, 22 Apr 2016, Mauricio Tavares wrote: > > ssh uses the public key to avoid loading or decrypting the private > > key for cases were it isn't necessary. We should improve the handling > > of cases where they don't match. > > > But if it does not have the public key whose name matches the > private key being used, it will still work, right? If that is the case > I too think it should handle non-matching key pairs better. i.e. > ignore behave as if there was just a private key there (which is how I > use it). Or let user decide if it should warn, ignore completely, or > quit. Having a mismatched private and public key is an invalid configuration. We don't need to implement complicated recovery logic for it, we can just tell the user and they can fix it themself (or not). -d From nkadel at gmail.com Sun Apr 24 02:18:50 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 23 Apr 2016 12:18:50 -0400 Subject: Client-side public key causing mess In-Reply-To: References: Message-ID: On Fri, Apr 22, 2016 at 8:39 PM, Damien Miller wrote: > On Fri, 22 Apr 2016, Mauricio Tavares wrote: > >> > ssh uses the public key to avoid loading or decrypting the private >> > key for cases were it isn't necessary. We should improve the handling >> > of cases where they don't match. >> > >> But if it does not have the public key whose name matches the >> private key being used, it will still work, right? If that is the case >> I too think it should handle non-matching key pairs better. i.e. >> ignore behave as if there was just a private key there (which is how I >> use it). Or let user decide if it should warn, ignore completely, or >> quit. > > Having a mismatched private and public key is an invalid configuration. > We don't need to implement complicated recovery logic for it, we can > just tell the user and they can fix it themself (or not). > > -d Is a published requirement that a local copy of a key, such as $HOME/.ssh/id_rsa, match a copy of the local public key, such as $HOME/.ssh/id_rsa.pub, and vice versa? While it seems very sensible, I've certainly seen people replicate one to a new working environment without the other, and later accidentally copy the other file from a new working environment. I've not really seen anyone get bitten hard by this discrepancy since they'mostly using ssh-agent or the Windows "Pageant" tool, but if it's a requirement I've seen nothing stating it explicitly. Is this a good reason to discard keeping public keys around? From rogan at dawes.za.net Sun Apr 24 05:07:28 2016 From: rogan at dawes.za.net (Rogan Dawes) Date: Sat, 23 Apr 2016 21:07:28 +0200 Subject: StreamLocal forwarding Message-ID: 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 RMATTSON at harris.com Tue Apr 26 13:52:37 2016 From: RMATTSON at harris.com (Mattson, Robert) Date: Tue, 26 Apr 2016 03:52:37 +0000 Subject: ControlMaster failure of RH/CentOS 6.6.1p1-25 Message-ID: <1461642757421.60203@harris.com> Dear OpenSSH Team, We use OpenSSH ControlPath/multiplexed sessions heavily to avoid session handshake overheads in a system of CentOS machines performing remote shell commands. The commands are run at different times and take different amounts of time to complete. We're currently experiencing a failure of sshd which relies on timing to trigger a fault and elicit a failure. The failure is typically a process termination. Depending on the loop used to reproduce a crash, the time required can be between five minutes and one hour (approx). On CentOS, failure messages look like [3], on RHEL, reproduced failure messages look like [4]. Previously RedHat supported and fixed a ~very~ similar issue (see ChangeLog entry[1]), however it appears we still see sshd crashes in our system on both CentOS and RHEL (which we know are compiled from the same source code) when using this feature. We are running the latest RPMS for OpenSSH - 6.6.1p1-25.el7_2.x86_64.rpm on both the client and server hosts. When investigating the issue previously, RedHat documented the method we used to reproduce the failure in some detail[2]. I do swap the while loop described on that page for a different loop which is can elicit a failure sooner. The loop used to produce the error in [4] was [5], while I have also written/used [6],[7],[8]. There is probably an infinite number of possible loops. I tried to reproduce this in OpenBSD last May/June and did not see this failure, however, because of the issues around timing, not seeing a failure does not give me confidence there is no fault present. Is there any guidance available on how this can be resolved? ControlMaster is an important and very good feature of OpenSSH without which our remote execution system would not be nearly as efficient or scalable. It is my intention to open a case with RH but sometimes it is difficult to progress such support cases, I'm hoping I can get some assistance to help get this stabilised from wherever I can find it. Sincerely, Rob Mattson Dr Robert Mattson Product Development 380 St Kilda Road, Melbourne, Victoria, 3004 Australia +61 3 9926 0000 phone robert.mattson at harris.com www.c4i.com [1] rpm -q --changelog openssh * Wed Jul 15 2015 Jakub Jelen > 6.6.1p1-15 + 0.9.3-9 ... - Fix race condition with auditing messages answers (#1240613) [2] - https://access.redhat.com/solutions/1521923 [3] from /var/log/secure Apr 26 10:42:58 host01 sshd[15138]: error: buffer_get_ret: trying to get more bytes 68 than in buffer 2 Apr 26 10:42:58 host01 sshd[15138]: error: buffer_get_string_ret: buffer_get failed Apr 26 10:42:58 host01 sshd[15138]: fatal: buffer_get_string: buffer error Apr 26 10:56:58 host01 sshd[15293]: fatal: mm_request_receive: read: bad msg_len 4096768 Apr 26 10:56:58 host01 sshd[15293]: pam_unix(sshd:session): session closed for user targetuser Apr 26 10:56:58 host01 sshd[15296]: fatal: mm_request_receive: read: Connection reset by peer Apr 26 10:56:58 host01 sshd[15296]: fatal: mm_request_send: write: Broken pipe Apr 26 10:58:58 host01 sshd[16028]: error: buffer_get_ret: trying to get more bytes 68 than in buffer 53 Apr 26 10:58:58 host01 sshd[16028]: error: buffer_get_string_ret: buffer_get failed Apr 26 10:58:58 host01 sshd[16028]: fatal: buffer_get_string: buffer error Apr 26 10:58:58 host01 sshd[16028]: pam_unix(sshd:session): session closed for user targetuser Apr 26 10:58:58 host01 sshd[16032]: fatal: mm_request_receive: read: Connection reset by peer Apr 26 10:58:58 host01 sshd[16032]: fatal: mm_request_send: write: Broken pipe Apr 26 11:07:58 host01 sshd[16149]: error: buffer_get_ret: trying to get more bytes 68 than in buffer 50 Apr 26 11:07:58 host01 sshd[16149]: error: buffer_get_string_ret: buffer_get failed Apr 26 11:07:58 host01 sshd[16149]: fatal: buffer_get_string: buffer error Apr 26 11:07:58 host01 sshd[16149]: pam_unix(sshd:session): session closed for user targetuser Apr 26 11:07:58 host01 sshd[16152]: fatal: mm_request_receive: read: Connection reset by peer Apr 26 11:07:58 host01 sshd[16152]: fatal: mm_request_send: write: Broken pipe Apr 26 11:12:58 host01 sshd[17475]: fatal: mm_request_receive: read: bad msg_len 4529920 Apr 26 11:12:58 host01 sshd[17475]: pam_unix(sshd:session): session closed for user targetuser Apr 26 11:12:58 host01 sshd[17501]: fatal: mm_request_receive: read: Connection reset by peer Apr 26 11:12:58 host01 sshd[17501]: fatal: mm_request_send: write: Broken pipe [4] time /usr/sbin/sshd -p 1026 -ddd debug2: fd 19 setting O_NONBLOCK debug2: fd 11 setting O_NONBLOCK debug2: fd 22 setting O_NONBLOCK debug2: channel 4: rcvd eof debug2: channel 4: output open -> drain debug2: channel 4: obuf empty debug2: channel 4: close_write debug2: channel 4: output drain -> closed debug2: channel 3: read 664 from efd 20 debug2: channel 4: read 664 from efd 22 debug2: channel 3: rwin 2097152 elen 664 euse 1 debug2: channel 3: sent ext data 664 debug2: channel 4: rwin 2097152 elen 664 euse 1 debug2: channel 4: sent ext data 664 debug3: mm_request_receive entering debug3: monitor_read: checking request 124 buffer_get_ret: trying to get more bytes 68 than in buffer 63 <----******* buffer_get_string_ret: buffer_get failed <----******* buffer_get_string: buffer error <----******* debug1: do_cleanup debug1: PAM: cleanup debug1: PAM: closing session debug1: PAM: deleting credentials debug3: PAM: sshpam_thread_cleanup entering real 8m4.228s user 0m0.506s sys 0m1.884s [root at rhel ~]# debug1: server_input_channel_open: ctype session rchan 12 win 2097152 max 32768 debug1: input_session_request debug1: channel 5: new [server-session] debug1: session_new: session 7 debug1: session_open: channel 5 debug1: session_open: session 7: link with channel 5 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 5 request env reply 0 debug1: session_by_channel: session 7 channel 5 debug1: session_input_channel_req: session 7 req env debug2: Setting env 0: LANG=en_AU.UTF-8 debug1: server_input_channel_req: channel 5 request exec reply 1 debug1: session_by_channel: session 7 channel 5 debug1: session_input_channel_req: session 7 req exec Starting session: command for joe from ::1 port 41194 debug3: mm_audit_run_command entering command sleep .2 debug3: mm_request_send entering: type 114 mm_request_send: write: Broken pipe debug1: do_cleanup debug3: PAM: sshpam_thread_cleanup entering debug3: mm_request_send entering: type 124 mm_request_send: write: Broken pipe [root at rhel ~]# [5] while true; do runCommand .22 runCommand .2 runCommand .2 runCommand .2 runCommand .2 runCommand .2 sleep .333 done [6] while true; do runCommand 3 sleep .6 runCommand 3 sleep .6 runCommand 3 sleep .6 runCommand 3 sleep .6 runCommand 3 sleep .7 done [7] while true; do runCommand 3 runCommand 1 runCommand 1 runCommand 1 runCommand 1 runCommand 2 runCommand 2 runCommand 2 sleep 1 runCommand 1 sleep 1 done [8] while true; do runCommand 1 runCommand 1 runCommand 1 runCommand 1 sleep 1 runCommand 1 sleep 1 done From jjelen at redhat.com Tue Apr 26 19:16:11 2016 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 26 Apr 2016 11:16:11 +0200 Subject: ControlMaster failure of RH/CentOS 6.6.1p1-25 In-Reply-To: <1461642757421.60203@harris.com> References: <1461642757421.60203@harris.com> Message-ID: <571F31DB.5030600@redhat.com> Hello Rob, I am sorry for the caused problems. The previous attempt to resolve this issue, mentioned in the linked changelog didn't solve the issue completely. This is also not caused by anything in openssh upstrem, but by our downstream audit patch and it is already addressed for RHEL7.3. Red Hat Support will be able to provide you testing package to address this issue. Kind regards, Jakub On 04/26/2016 05:52 AM, Mattson, Robert wrote: > Dear OpenSSH Team, > > > > We use OpenSSH ControlPath/multiplexed sessions heavily to avoid session handshake overheads in a system of CentOS machines performing remote shell commands. The commands are run at different times and take different amounts of time to complete. We're currently experiencing a failure of sshd which relies on timing to trigger a fault and elicit a failure. The failure is typically a process termination. Depending on the loop used to reproduce a crash, the time required can be between five minutes and one hour (approx). > > > > On CentOS, failure messages look like [3], on RHEL, reproduced failure messages look like [4]. > > > > Previously RedHat supported and fixed a ~very~ similar issue (see ChangeLog entry[1]), however it appears we still see sshd crashes in our system on both CentOS and RHEL (which we know are compiled from the same source code) when using this feature. We are running the latest RPMS for OpenSSH - 6.6.1p1-25.el7_2.x86_64.rpm on both the client and server hosts. > > When investigating the issue previously, RedHat documented the method we used to reproduce the failure in some detail[2]. > I do swap the while loop described on that page for a different loop which is can elicit a failure sooner. > > The loop used to produce the error in [4] was [5], while I have also written/used [6],[7],[8]. There is probably an infinite number of possible loops. > > > > I tried to reproduce this in OpenBSD last May/June and did not see this failure, however, because of the issues around timing, not seeing a failure does not give me confidence there is no fault present. > > > > Is there any guidance available on how this can be resolved? > ControlMaster is an important and very good feature of OpenSSH without which our remote execution system would not be nearly as efficient or scalable. > > > > It is my intention to open a case with RH but sometimes it is difficult to progress such support cases, I'm hoping I can get some assistance to help get this stabilised from wherever I can find it. > > Sincerely, > > Rob Mattson > > > > > Dr Robert Mattson > Product Development > 380 St Kilda Road, > Melbourne, Victoria, 3004 > Australia > > +61 3 9926 0000 phone > robert.mattson at harris.com > www.c4i.com > > [1] rpm -q --changelog openssh > * Wed Jul 15 2015 Jakub Jelen > 6.6.1p1-15 + 0.9.3-9 > ... > - Fix race condition with auditing messages answers (#1240613) > > [2] - https://access.redhat.com/solutions/1521923 > > [3] from /var/log/secure > Apr 26 10:42:58 host01 sshd[15138]: error: buffer_get_ret: trying to get more bytes 68 than in buffer 2 > Apr 26 10:42:58 host01 sshd[15138]: error: buffer_get_string_ret: buffer_get failed > Apr 26 10:42:58 host01 sshd[15138]: fatal: buffer_get_string: buffer error > > Apr 26 10:56:58 host01 sshd[15293]: fatal: mm_request_receive: read: bad msg_len 4096768 > Apr 26 10:56:58 host01 sshd[15293]: pam_unix(sshd:session): session closed for user targetuser > Apr 26 10:56:58 host01 sshd[15296]: fatal: mm_request_receive: read: Connection reset by peer > Apr 26 10:56:58 host01 sshd[15296]: fatal: mm_request_send: write: Broken pipe > > Apr 26 10:58:58 host01 sshd[16028]: error: buffer_get_ret: trying to get more bytes 68 than in buffer 53 > Apr 26 10:58:58 host01 sshd[16028]: error: buffer_get_string_ret: buffer_get failed > Apr 26 10:58:58 host01 sshd[16028]: fatal: buffer_get_string: buffer error > Apr 26 10:58:58 host01 sshd[16028]: pam_unix(sshd:session): session closed for user targetuser > Apr 26 10:58:58 host01 sshd[16032]: fatal: mm_request_receive: read: Connection reset by peer > Apr 26 10:58:58 host01 sshd[16032]: fatal: mm_request_send: write: Broken pipe > > Apr 26 11:07:58 host01 sshd[16149]: error: buffer_get_ret: trying to get more bytes 68 than in buffer 50 > Apr 26 11:07:58 host01 sshd[16149]: error: buffer_get_string_ret: buffer_get failed > Apr 26 11:07:58 host01 sshd[16149]: fatal: buffer_get_string: buffer error > Apr 26 11:07:58 host01 sshd[16149]: pam_unix(sshd:session): session closed for user targetuser > Apr 26 11:07:58 host01 sshd[16152]: fatal: mm_request_receive: read: Connection reset by peer > Apr 26 11:07:58 host01 sshd[16152]: fatal: mm_request_send: write: Broken pipe > > Apr 26 11:12:58 host01 sshd[17475]: fatal: mm_request_receive: read: bad msg_len 4529920 > Apr 26 11:12:58 host01 sshd[17475]: pam_unix(sshd:session): session closed for user targetuser > Apr 26 11:12:58 host01 sshd[17501]: fatal: mm_request_receive: read: Connection reset by peer > Apr 26 11:12:58 host01 sshd[17501]: fatal: mm_request_send: write: Broken pipe > > > > [4] > time /usr/sbin/sshd -p 1026 -ddd > > > debug2: fd 19 setting O_NONBLOCK > debug2: fd 11 setting O_NONBLOCK > debug2: fd 22 setting O_NONBLOCK > debug2: channel 4: rcvd eof > debug2: channel 4: output open -> drain > debug2: channel 4: obuf empty > debug2: channel 4: close_write > debug2: channel 4: output drain -> closed > debug2: channel 3: read 664 from efd 20 > debug2: channel 4: read 664 from efd 22 > debug2: channel 3: rwin 2097152 elen 664 euse 1 > debug2: channel 3: sent ext data 664 > debug2: channel 4: rwin 2097152 elen 664 euse 1 > debug2: channel 4: sent ext data 664 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 124 > buffer_get_ret: trying to get more bytes 68 than in buffer 63 <----******* > buffer_get_string_ret: buffer_get failed <----******* > buffer_get_string: buffer error <----******* > debug1: do_cleanup > debug1: PAM: cleanup > debug1: PAM: closing session > debug1: PAM: deleting credentials > debug3: PAM: sshpam_thread_cleanup entering > > real 8m4.228s > user 0m0.506s > sys 0m1.884s > [root at rhel ~]# debug1: server_input_channel_open: ctype session rchan 12 win 2097152 max 32768 > debug1: input_session_request > debug1: channel 5: new [server-session] > debug1: session_new: session 7 > debug1: session_open: channel 5 > debug1: session_open: session 7: link with channel 5 > debug1: server_input_channel_open: confirm session > debug1: server_input_channel_req: channel 5 request env reply 0 > debug1: session_by_channel: session 7 channel 5 > debug1: session_input_channel_req: session 7 req env > debug2: Setting env 0: LANG=en_AU.UTF-8 > debug1: server_input_channel_req: channel 5 request exec reply 1 > debug1: session_by_channel: session 7 channel 5 > debug1: session_input_channel_req: session 7 req exec > Starting session: command for joe from ::1 port 41194 > debug3: mm_audit_run_command entering command sleep .2 > debug3: mm_request_send entering: type 114 > mm_request_send: write: Broken pipe > debug1: do_cleanup > debug3: PAM: sshpam_thread_cleanup entering > debug3: mm_request_send entering: type 124 > mm_request_send: write: Broken pipe > [root at rhel ~]# > > > > [5] > while true; do > runCommand .22 > runCommand .2 > runCommand .2 > runCommand .2 > runCommand .2 > runCommand .2 > sleep .333 > done > > [6] > while true; do > runCommand 3 > sleep .6 > runCommand 3 > sleep .6 > runCommand 3 > sleep .6 > runCommand 3 > sleep .6 > runCommand 3 > sleep .7 > done > > > > [7] > while true; do > runCommand 3 > runCommand 1 > runCommand 1 > runCommand 1 > runCommand 1 > runCommand 2 > runCommand 2 > runCommand 2 > sleep 1 > runCommand 1 > sleep 1 > done > > > > [8] > while true; do > runCommand 1 > runCommand 1 > runCommand 1 > runCommand 1 > sleep 1 > runCommand 1 > sleep 1 > done > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat From nkadel at gmail.com Tue Apr 26 21:51:52 2016 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 26 Apr 2016 07:51:52 -0400 Subject: ControlMaster failure of RH/CentOS 6.6.1p1-25 In-Reply-To: <1461642757421.60203@harris.com> References: <1461642757421.60203@harris.com> Message-ID: On Mon, Apr 25, 2016 at 11:52 PM, Mattson, Robert wrote: > Dear OpenSSH Team, > > > > We use OpenSSH ControlPath/multiplexed sessions heavily to avoid session handshake overheads in a system of CentOS machines performing remote shell commands. The commands are run at different times and take different amounts of time to complete. We're currently experiencing a failure of sshd which relies on timing to trigger a fault and elicit a failure. The failure is typically a process termination. Depending on the loop used to reproduce a crash, the time required can be between five minutes and one hour (approx). Not sure of why the issue occurs, but for *anything* that connects OpenSSH to a lot of distinct targets, make sure you turn off the the reverse DNS looks on every server you connect to, This means changing the init script options to use "sshd -u0" in the SSH init scripts on every remote server. For RHEL 6, it means putting "OPTIONS=-u0" in /etc/sysconfig/sshd. Might not solve your issues, but it's really helpful to reduce connection delays and improve performance. The other weaselish way to achieve what you're doing is to run an "ssh bash" command, connected to a pipe on the local side, and send your commands through a pipe to the remote bash. It's been.... 15 years since I last pulled that one, but you may find it helpful. Protecting and terminating the pipe well is an adventure in local security, but it could help eliminate the reliance on a feature that is probably not well tested for RHEL. Another option, for testing, is to compile OpenSSH locally, say in /opt/openssh/7.1, and run a much more recent client to see if you can reproduce the error. You caould also test and run a separate OpenSSH daemon on a different port on a few target servers, ideally with locked down privileges, segregated this way to prevent interference with the default OpenSSH. It can even be built as an RPM, though I'd be cautious about replacing the system standard version of OpenSSH. > On CentOS, failure messages look like [3], on RHEL, reproduced failure messages look like [4]. > > > > Previously RedHat supported and fixed a ~very~ similar issue (see ChangeLog entry[1]), however it appears we still see sshd crashes in our system on both CentOS and RHEL (which we know are compiled from the same source code) when using this feature. We are running the latest RPMS for OpenSSH - 6.6.1p1-25.el7_2.x86_64.rpm on both the client and server hosts. > > When investigating the issue previously, RedHat documented the method we used to reproduce the failure in some detail[2]. > I do swap the while loop described on that page for a different loop which is can elicit a failure sooner. > > The loop used to produce the error in [4] was [5], while I have also written/used [6],[7],[8]. There is probably an infinite number of possible loops. > > > > I tried to reproduce this in OpenBSD last May/June and did not see this failure, however, because of the issues around timing, not seeing a failure does not give me confidence there is no fault present. > > > > Is there any guidance available on how this can be resolved? > ControlMaster is an important and very good feature of OpenSSH without which our remote execution system would not be nearly as efficient or scalable. > > > > It is my intention to open a case with RH but sometimes it is difficult to progress such support cases, I'm hoping I can get some assistance to help get this stabilised from wherever I can find it. > > Sincerely, > > Rob Mattson > > > > > Dr Robert Mattson > Product Development > 380 St Kilda Road, > Melbourne, Victoria, 3004 > Australia > > +61 3 9926 0000 phone > robert.mattson at harris.com > www.c4i.com > > [1] rpm -q --changelog openssh > * Wed Jul 15 2015 Jakub Jelen > 6.6.1p1-15 + 0.9.3-9 > ... > - Fix race condition with auditing messages answers (#1240613) > > [2] - https://access.redhat.com/solutions/1521923 > > [3] from /var/log/secure > Apr 26 10:42:58 host01 sshd[15138]: error: buffer_get_ret: trying to get more bytes 68 than in buffer 2 > Apr 26 10:42:58 host01 sshd[15138]: error: buffer_get_string_ret: buffer_get failed > Apr 26 10:42:58 host01 sshd[15138]: fatal: buffer_get_string: buffer error > > Apr 26 10:56:58 host01 sshd[15293]: fatal: mm_request_receive: read: bad msg_len 4096768 > Apr 26 10:56:58 host01 sshd[15293]: pam_unix(sshd:session): session closed for user targetuser > Apr 26 10:56:58 host01 sshd[15296]: fatal: mm_request_receive: read: Connection reset by peer > Apr 26 10:56:58 host01 sshd[15296]: fatal: mm_request_send: write: Broken pipe > > Apr 26 10:58:58 host01 sshd[16028]: error: buffer_get_ret: trying to get more bytes 68 than in buffer 53 > Apr 26 10:58:58 host01 sshd[16028]: error: buffer_get_string_ret: buffer_get failed > Apr 26 10:58:58 host01 sshd[16028]: fatal: buffer_get_string: buffer error > Apr 26 10:58:58 host01 sshd[16028]: pam_unix(sshd:session): session closed for user targetuser > Apr 26 10:58:58 host01 sshd[16032]: fatal: mm_request_receive: read: Connection reset by peer > Apr 26 10:58:58 host01 sshd[16032]: fatal: mm_request_send: write: Broken pipe > > Apr 26 11:07:58 host01 sshd[16149]: error: buffer_get_ret: trying to get more bytes 68 than in buffer 50 > Apr 26 11:07:58 host01 sshd[16149]: error: buffer_get_string_ret: buffer_get failed > Apr 26 11:07:58 host01 sshd[16149]: fatal: buffer_get_string: buffer error > Apr 26 11:07:58 host01 sshd[16149]: pam_unix(sshd:session): session closed for user targetuser > Apr 26 11:07:58 host01 sshd[16152]: fatal: mm_request_receive: read: Connection reset by peer > Apr 26 11:07:58 host01 sshd[16152]: fatal: mm_request_send: write: Broken pipe > > Apr 26 11:12:58 host01 sshd[17475]: fatal: mm_request_receive: read: bad msg_len 4529920 > Apr 26 11:12:58 host01 sshd[17475]: pam_unix(sshd:session): session closed for user targetuser > Apr 26 11:12:58 host01 sshd[17501]: fatal: mm_request_receive: read: Connection reset by peer > Apr 26 11:12:58 host01 sshd[17501]: fatal: mm_request_send: write: Broken pipe > > > > [4] > time /usr/sbin/sshd -p 1026 -ddd > > > debug2: fd 19 setting O_NONBLOCK > debug2: fd 11 setting O_NONBLOCK > debug2: fd 22 setting O_NONBLOCK > debug2: channel 4: rcvd eof > debug2: channel 4: output open -> drain > debug2: channel 4: obuf empty > debug2: channel 4: close_write > debug2: channel 4: output drain -> closed > debug2: channel 3: read 664 from efd 20 > debug2: channel 4: read 664 from efd 22 > debug2: channel 3: rwin 2097152 elen 664 euse 1 > debug2: channel 3: sent ext data 664 > debug2: channel 4: rwin 2097152 elen 664 euse 1 > debug2: channel 4: sent ext data 664 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 124 > buffer_get_ret: trying to get more bytes 68 than in buffer 63 <----******* > buffer_get_string_ret: buffer_get failed <----******* > buffer_get_string: buffer error <----******* > debug1: do_cleanup > debug1: PAM: cleanup > debug1: PAM: closing session > debug1: PAM: deleting credentials > debug3: PAM: sshpam_thread_cleanup entering > > real 8m4.228s > user 0m0.506s > sys 0m1.884s > [root at rhel ~]# debug1: server_input_channel_open: ctype session rchan 12 win 2097152 max 32768 > debug1: input_session_request > debug1: channel 5: new [server-session] > debug1: session_new: session 7 > debug1: session_open: channel 5 > debug1: session_open: session 7: link with channel 5 > debug1: server_input_channel_open: confirm session > debug1: server_input_channel_req: channel 5 request env reply 0 > debug1: session_by_channel: session 7 channel 5 > debug1: session_input_channel_req: session 7 req env > debug2: Setting env 0: LANG=en_AU.UTF-8 > debug1: server_input_channel_req: channel 5 request exec reply 1 > debug1: session_by_channel: session 7 channel 5 > debug1: session_input_channel_req: session 7 req exec > Starting session: command for joe from ::1 port 41194 > debug3: mm_audit_run_command entering command sleep .2 > debug3: mm_request_send entering: type 114 > mm_request_send: write: Broken pipe > debug1: do_cleanup > debug3: PAM: sshpam_thread_cleanup entering > debug3: mm_request_send entering: type 124 > mm_request_send: write: Broken pipe > [root at rhel ~]# > > > > [5] > while true; do > runCommand .22 > runCommand .2 > runCommand .2 > runCommand .2 > runCommand .2 > runCommand .2 > sleep .333 > done > > [6] > while true; do > runCommand 3 > sleep .6 > runCommand 3 > sleep .6 > runCommand 3 > sleep .6 > runCommand 3 > sleep .6 > runCommand 3 > sleep .7 > done > > > > [7] > while true; do > runCommand 3 > runCommand 1 > runCommand 1 > runCommand 1 > runCommand 1 > runCommand 2 > runCommand 2 > runCommand 2 > sleep 1 > runCommand 1 > sleep 1 > done > > > > [8] > while true; do > runCommand 1 > runCommand 1 > runCommand 1 > runCommand 1 > sleep 1 > runCommand 1 > sleep 1 > done > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From paul.moore at centrify.com Wed Apr 27 06:25:48 2016 From: paul.moore at centrify.com (Paul Moore) Date: Tue, 26 Apr 2016 20:25:48 +0000 Subject: cert authentication and 'aliasing' nss providers Message-ID: This is a feature request. I can code it up but I am curious to know if it would be accepted, if its been discussed before etc. Many NSS providers (ldap, AD, ...) do what I call 'aliasing'. The directory behind the NSS providers knows the user by an enterprisey name and knows how to map that name to a logical passwd entry. For example $ getent passwd joe.doe at pmdev.test joe.doe:x:1182794839:1182794839:joe doe:/home/joe.doe:/bin/bash that's because the NSS provider knows that on this system joe.doe at pmdev.test is joe.doe. On another system he might be joed, on others he might not exist at all. In many SSO scenarios the client doesn't know the unix name of the user and so sends the enterprisey name (it knows that one) during user auth. For example GSSAPI enabled putty running on Windows knows who the logged in AD user is and connects using that name, on the server side the NSS lookup resolves the user to the correct local name. All good Regarding openssh certificate support - this doesnt work. The principal list in the cert is checked against the pw->name NSS field, i.e. the unix name of the user. But the enterprisey software that issued the cert doesn't know what name that will be so it doesn't know what to put in the principal list in the cert. My current solution is to put the full name in the principal list and use AuthorizedPrincipalsCommand in sshd_config Like this: AuthorizedPrincipalsCommand /usr/bin/adquery user -P %u That tool returns the full name when given the unix name of a user. However this solution works but doesn't scale well for a general purpose solution - That tool may not exist for some NSS providers - The mods to the sshd_config are different depending on what NSS provider is in use The simple solution is to change the sshd code to check the principal list against the username sent in the auth request (this is the full user name) instead of checking the pw->name field.