From vinschen at redhat.com Mon Feb 3 21:44:37 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 3 Feb 2014 11:44:37 +0100 Subject: Announce: OpenSSH 6.5 released In-Reply-To: <201401300634.s0U6YI9i011801@cvs.openbsd.org> References: <201401300634.s0U6YI9i011801@cvs.openbsd.org> Message-ID: <20140203104437.GA21400@calimero.vinschen.de> Hi guys, On Jan 29 23:34, Damien Miller wrote: > Changes since OpenSSH 6.4 > ========================= > [...] > Bugfixes: > > * ssh(1), sshd(8): Fix potential stack exhaustion caused by nested > certificates. > > * ssh(1): bz#1211: make BindAddress work with UsePrivilegedPort. there's a bug in this change. Try this as user root: $ ssh -V OpenSSH_6.5p1, [...] $ ssh -oUsePrivilegedPort=yes remote-machine getaddrinfo: (null): Name or service not known getaddrinfo: (null): Name or service not known ssh: connect to host remote-machine port 22: No such file or directory The bug is in sshconnect.c, function ssh_create_socket(). The only way to avoid a call to to getaddrinfo is if *either* options.bind_address is non-NULL, *or* UsePrivilegedPort is set to no: /* Bind the socket to an alternative local IP address */ if (options.bind_address == NULL && !privileged) return sock; However, if UsePrivilegedPort is set to yes, options.bind_address will be checked in the subsequent getaddrinfo call, even if it's NULL, because the -b option hasn't been used. The result is, both input parameters to getaddrinfo() are NULL, so getaddrinfo() returns with EAI_NONAME, thus breaking the UsePrivilegedPort functionality, unless -b is given as well. Here's a patch: Index: sshconnect.c =================================================================== RCS file: /cvs/openssh/sshconnect.c,v retrieving revision 1.217 diff -u -p -r1.217 sshconnect.c --- sshconnect.c 9 Jan 2014 23:59:24 -0000 1.217 +++ sshconnect.c 3 Feb 2014 10:44:20 -0000 @@ -269,7 +269,7 @@ static int ssh_create_socket(int privileged, struct addrinfo *ai) { int sock, r, gaierr; - struct addrinfo hints, *res; + struct addrinfo hints, *res = NULL; sock = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); if (sock < 0) { @@ -282,17 +282,19 @@ ssh_create_socket(int privileged, struct if (options.bind_address == NULL && !privileged) return sock; - memset(&hints, 0, sizeof(hints)); - hints.ai_family = ai->ai_family; - hints.ai_socktype = ai->ai_socktype; - hints.ai_protocol = ai->ai_protocol; - hints.ai_flags = AI_PASSIVE; - gaierr = getaddrinfo(options.bind_address, NULL, &hints, &res); - if (gaierr) { - error("getaddrinfo: %s: %s", options.bind_address, - ssh_gai_strerror(gaierr)); - close(sock); - return -1; + if (options.bind_address) { + memset(&hints, 0, sizeof(hints)); + hints.ai_family = ai->ai_family; + hints.ai_socktype = ai->ai_socktype; + hints.ai_protocol = ai->ai_protocol; + hints.ai_flags = AI_PASSIVE; + gaierr = getaddrinfo(options.bind_address, NULL, &hints, &res); + if (gaierr) { + error("getaddrinfo: %s: %s", options.bind_address, + ssh_gai_strerror(gaierr)); + close(sock); + return -1; + } } /* * If we are running as root and want to connect to a privileged @@ -300,7 +302,7 @@ ssh_create_socket(int privileged, struct */ if (privileged) { PRIV_START; - r = bindresvport_sa(sock, res->ai_addr); + r = bindresvport_sa(sock, res ? res->ai_addr : NULL); PRIV_END; if (r < 0) { error("bindresvport_sa: af=%d %s", ai->ai_family, -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From ike.devolder at gmail.com Mon Feb 3 23:45:22 2014 From: ike.devolder at gmail.com (Ike Devolder) Date: Mon, 3 Feb 2014 13:45:22 +0100 Subject: ssh config Host case insensitive Message-ID: <20140203124522.GA4732@BlackRaptor.nuclear.id> Hi, There seems to be an issue where a case sensitive Host entry is no longer working after update to openssh 6.5 example entry: (was working before update) Host MyHost Hostname 192.168.0.1 Port 1234 User root IdentityFile ~/.ssh/id_rsa When issuing "ssh MyHost" the outcome is now: ssh: Could not resolve hostname myhost: Name or service not known When the above entry is changed to: Host myhost, the connection works fine again. $ ssh -V OpenSSH_6.5p1, OpenSSL 1.0.1f 6 Jan 2014 OS: Archlinux fully up to date when sending this mail thx -- Ike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From methier at CGR.Harvard.edu Tue Feb 4 01:46:20 2014 From: methier at CGR.Harvard.edu (Ethier, Michael) Date: Mon, 3 Feb 2014 14:46:20 +0000 Subject: Compiling openssh v6.5 with --with-ssl-dir not working Message-ID: <0B117990D8364D45A6371D22353FD9CC0AE4AF@HARVANDMBX01.fasmail.priv> Hello, I am trying to compile openssh v6.5p1 with openssl-1.0.1f and it doesn't seem to find my custom openssl libraries and defaults to the system version. This has been working on all previous openssh version until v6.5. Is this a bug ? More details below: [root at test openssh-6.5p1]# ./configure --prefix=/usr/local/openssh-6.5p1 --with-tcp-wrappers --with-selinux --with-kerberos5 --with-ssl-engine --with-pam --with-md5-passwords --with-ssl-dir=/usr/local/openssl-1.0.1f ... ... checking whether getpgrp requires zero arguments... yes checking openssl/opensslv.h usability... yes checking openssl/opensslv.h presence... yes checking for openssl/opensslv.h... yes checking OpenSSL header version... 90802f (OpenSSL 0.9.8e-rhel5 01 Jul 2008) checking OpenSSL library version... 90802f (OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008) checking whether OpenSSL's headers match the library... yes checking if programs using OpenSSL functions will link... yes So the version of SSL is not the proper one. I have installed openssl-1.0.1f in /usr/local: [root at iliadaccess04 src]# ls -l /usr/local/openssl-1.0.1f total 16 drwxr-xr-x 2 root root 4096 Jan 15 08:35 bin drwxr-xr-x 3 root root 4096 Jan 15 08:35 include drwxr-xr-x 4 root root 4096 Jan 15 08:35 lib drwxr-xr-x 6 root root 4096 Jan 15 08:35 openssl Any ideas ? Thanks, Mike From imorgan at nas.nasa.gov Tue Feb 4 05:47:48 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 3 Feb 2014 10:47:48 -0800 Subject: Compiling openssh v6.5 with --with-ssl-dir not working In-Reply-To: <0B117990D8364D45A6371D22353FD9CC0AE4AF@HARVANDMBX01.fasmail.priv> References: <0B117990D8364D45A6371D22353FD9CC0AE4AF@HARVANDMBX01.fasmail.priv> Message-ID: <20140203184748.GB11408@linux124.nas.nasa.gov> On Mon, Feb 03, 2014 at 14:46:20 +0000, Ethier, Michael wrote: > Hello, > > I am trying to compile openssh v6.5p1 with openssl-1.0.1f and it doesn't seem to find > my custom openssl libraries and defaults to the system version. This has been working on all > previous openssh version until v6.5. Is this a bug ? More details below: > > [root at test openssh-6.5p1]# ./configure --prefix=/usr/local/openssh-6.5p1 --with-tcp-wrappers --with-selinux --with-kerberos5 --with-ssl-engine --with-pam --with-md5-passwords --with-ssl-dir=/usr/local/openssl-1.0.1f > ... > ... > checking whether getpgrp requires zero arguments... yes > checking openssl/opensslv.h usability... yes > checking openssl/opensslv.h presence... yes > checking for openssl/opensslv.h... yes > checking OpenSSL header version... 90802f (OpenSSL 0.9.8e-rhel5 01 Jul 2008) > checking OpenSSL library version... 90802f (OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008) > checking whether OpenSSL's headers match the library... yes > checking if programs using OpenSSL functions will link... yes > > > So the version of SSL is not the proper one. I have installed openssl-1.0.1f in /usr/local: > [root at iliadaccess04 src]# ls -l /usr/local/openssl-1.0.1f > total 16 > drwxr-xr-x 2 root root 4096 Jan 15 08:35 bin > drwxr-xr-x 3 root root 4096 Jan 15 08:35 include > drwxr-xr-x 4 root root 4096 Jan 15 08:35 lib > drwxr-xr-x 6 root root 4096 Jan 15 08:35 openssl > > Any ideas ? > > Thanks, > Mike > I suspect that you are running into a similar issue to what I encountered during the early testing of the additional build-hardening options. If you check config.log, you will most likely find that linking against your copy of libcrypto failed and that the build system fell back to the system-provided library. Try rebuilding OpenSSL, but add -fPIC when you run ./config. At least, that worked for me. -- Iain Morgan From methier at CGR.Harvard.edu Tue Feb 4 06:18:58 2014 From: methier at CGR.Harvard.edu (Ethier, Michael) Date: Mon, 3 Feb 2014 19:18:58 +0000 Subject: Compiling openssh v6.5 with --with-ssl-dir not working In-Reply-To: <20140203184748.GB11408@linux124.nas.nasa.gov> References: <0B117990D8364D45A6371D22353FD9CC0AE4AF@HARVANDMBX01.fasmail.priv> <20140203184748.GB11408@linux124.nas.nasa.gov> Message-ID: <0B117990D8364D45A6371D22353FD9CC0AE9F6@HARVANDMBX01.fasmail.priv> Hi Iain, Yup that did it. I recompiled OpenSSL with: ./config -fPIC --prefix=..... And the OpenSSH 6.5 worked. This was not required in previous versions of OpenSSH. Thanks for your reply. Mike -----Original Message----- From: Iain Morgan [mailto:imorgan at nas.nasa.gov] Sent: Monday, February 03, 2014 1:48 PM To: Ethier, Michael Cc: openssh-unix-dev at mindrot.org Subject: Re: Compiling openssh v6.5 with --with-ssl-dir not working On Mon, Feb 03, 2014 at 14:46:20 +0000, Ethier, Michael wrote: > Hello, > > I am trying to compile openssh v6.5p1 with openssl-1.0.1f and it > doesn't seem to find my custom openssl libraries and defaults to the > system version. This has been working on all previous openssh version until v6.5. Is this a bug ? More details below: > > [root at test openssh-6.5p1]# ./configure > --prefix=/usr/local/openssh-6.5p1 --with-tcp-wrappers --with-selinux > --with-kerberos5 --with-ssl-engine --with-pam --with-md5-passwords > --with-ssl-dir=/usr/local/openssl-1.0.1f > ... > ... > checking whether getpgrp requires zero arguments... yes checking > openssl/opensslv.h usability... yes checking openssl/opensslv.h > presence... yes checking for openssl/opensslv.h... yes checking > OpenSSL header version... 90802f (OpenSSL 0.9.8e-rhel5 01 Jul 2008) > checking OpenSSL library version... 90802f (OpenSSL 0.9.8e-fips-rhel5 > 01 Jul 2008) checking whether OpenSSL's headers match the library... > yes checking if programs using OpenSSL functions will link... yes > > > So the version of SSL is not the proper one. I have installed openssl-1.0.1f in /usr/local: > [root at iliadaccess04 src]# ls -l /usr/local/openssl-1.0.1f total 16 > drwxr-xr-x 2 root root 4096 Jan 15 08:35 bin drwxr-xr-x 3 root root > 4096 Jan 15 08:35 include drwxr-xr-x 4 root root 4096 Jan 15 08:35 lib > drwxr-xr-x 6 root root 4096 Jan 15 08:35 openssl > > Any ideas ? > > Thanks, > Mike > I suspect that you are running into a similar issue to what I encountered during the early testing of the additional build-hardening options. If you check config.log, you will most likely find that linking against your copy of libcrypto failed and that the build system fell back to the system-provided library. Try rebuilding OpenSSL, but add -fPIC when you run ./config. At least, that worked for me. -- Iain Morgan From dennis.grevenstein at gmail.com Tue Feb 4 06:26:39 2014 From: dennis.grevenstein at gmail.com (Dennis Grevenstein) Date: Mon, 3 Feb 2014 20:26:39 +0100 Subject: OpenSSH 6.5 on HP-UX 10.20 Message-ID: <0105B42D-21E4-4BB5-A952-7D00B772DB6E@gmail.com> Hi, just a minor bugreport. OpenSSH 6.5 needs a fix to compile on HP-UX 10.20. On HP-UX 10.20, ntohs is not defined in "netinet/in.h" but in "arpa/inet.h". readconf.c misses the required additional #include : $ diff -c readconf.c readconf.c_new *** readconf.c Fri Jan 17 14:03:57 2014 --- readconf.c_new Mon Feb 3 01:18:29 2014 *************** *** 22,27 **** --- 22,28 ---- #include #include #include + #include #include #include if you want to reply, please CC: me, because I am not on the list. regards, Dennis -- Don't suffer from insanity... Enjoy every minute of it. From djm at mindrot.org Tue Feb 4 08:07:20 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 4 Feb 2014 08:07:20 +1100 (EST) Subject: ssh config Host case insensitive In-Reply-To: <20140203124522.GA4732@BlackRaptor.nuclear.id> References: <20140203124522.GA4732@BlackRaptor.nuclear.id> Message-ID: On Mon, 3 Feb 2014, Ike Devolder wrote: > Hi, > > There seems to be an issue where a case sensitive Host entry is no > longer working after update to openssh 6.5 > > example entry: (was working before update) > Host MyHost > Hostname 192.168.0.1 > Port 1234 > User root > IdentityFile ~/.ssh/id_rsa > > When issuing "ssh MyHost" the outcome is now: > ssh: Could not resolve hostname myhost: Name or service not known > > When the above entry is changed to: > Host myhost, the connection works fine again. This should fix it: Index: ssh.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.c,v retrieving revision 1.398 diff -u -p -r1.398 ssh.c --- ssh.c 31 Jan 2014 16:39:19 -0000 1.398 +++ ssh.c 3 Feb 2014 21:05:40 -0000 @@ -752,7 +752,6 @@ main(int ac, char **av) if (!host) usage(); - lowercase(host); host_arg = xstrdup(host); OpenSSL_add_all_algorithms(); @@ -882,6 +881,7 @@ main(int ac, char **av) } /* If canonicalization requested then try to apply it */ + lowercase(host); if (options.canonicalize_hostname != SSH_CANONICALISE_NO) addrs = resolve_canonicalize(&host, options.port); /* From djm at mindrot.org Tue Feb 4 08:09:13 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 4 Feb 2014 08:09:13 +1100 (EST) Subject: Compiling openssh v6.5 with --with-ssl-dir not working In-Reply-To: <0B117990D8364D45A6371D22353FD9CC0AE9F6@HARVANDMBX01.fasmail.priv> References: <0B117990D8364D45A6371D22353FD9CC0AE4AF@HARVANDMBX01.fasmail.priv> <20140203184748.GB11408@linux124.nas.nasa.gov> <0B117990D8364D45A6371D22353FD9CC0AE9F6@HARVANDMBX01.fasmail.priv> Message-ID: On Mon, 3 Feb 2014, Ethier, Michael wrote: > Hi Iain, > > Yup that did it. I recompiled OpenSSL with: > > ./config -fPIC --prefix=..... > > And the OpenSSH 6.5 worked. This was not required in previous versions > of OpenSSH. Yes, OpenSSH now attempts to build a Position Independent Executable (PIE) by default on Linux, OpenBSD and OS X. This requires that the libraries that it links against are build -fPIC. Another way to work around that would be to build OpenSSH --without-pie, but then you lose the security benefits of PIE. -d From dtucker at zip.com.au Tue Feb 4 13:58:11 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 4 Feb 2014 13:58:11 +1100 Subject: OpenSSH 6.5 on HP-UX 10.20 In-Reply-To: <0105B42D-21E4-4BB5-A952-7D00B772DB6E@gmail.com> References: <0105B42D-21E4-4BB5-A952-7D00B772DB6E@gmail.com> Message-ID: On Tue, Feb 4, 2014 at 6:26 AM, Dennis Grevenstein wrote: [...] > OpenSSH 6.5 needs a fix to compile on HP-UX 10.20. > On HP-UX 10.20, ntohs is not defined in "netinet/in.h" but in "arpa/inet.h". Thanks for the report. Unfortunately we didn't find out about it until after the release, but it's already been fixed and will be in the next release. https://anongit.mindrot.org/openssh.git/commit/?id=0eeafcd76b972a3d159f3118227c149a4d7817fe Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From ike.devolder at gmail.com Tue Feb 4 19:17:47 2014 From: ike.devolder at gmail.com (Ike Devolder) Date: Tue, 4 Feb 2014 09:17:47 +0100 Subject: ssh config Host case insensitive In-Reply-To: References: <20140203124522.GA4732@BlackRaptor.nuclear.id> Message-ID: <20140204081747.GC4732@BlackRaptor.nuclear.id> On Tue, Feb 04, 2014 at 08:07:20AM +1100, Damien Miller wrote: > On Mon, 3 Feb 2014, Ike Devolder wrote: > > > Hi, > > > > There seems to be an issue where a case sensitive Host entry is no > > longer working after update to openssh 6.5 > > > > example entry: (was working before update) > > Host MyHost > > Hostname 192.168.0.1 > > Port 1234 > > User root > > IdentityFile ~/.ssh/id_rsa > > > > When issuing "ssh MyHost" the outcome is now: > > ssh: Could not resolve hostname myhost: Name or service not known > > > > When the above entry is changed to: > > Host myhost, the connection works fine again. > > This should fix it: > > Index: ssh.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/ssh.c,v > retrieving revision 1.398 > diff -u -p -r1.398 ssh.c > --- ssh.c 31 Jan 2014 16:39:19 -0000 1.398 > +++ ssh.c 3 Feb 2014 21:05:40 -0000 > @@ -752,7 +752,6 @@ main(int ac, char **av) > if (!host) > usage(); > > - lowercase(host); > host_arg = xstrdup(host); > > OpenSSL_add_all_algorithms(); > @@ -882,6 +881,7 @@ main(int ac, char **av) > } > > /* If canonicalization requested then try to apply it */ > + lowercase(host); > if (options.canonicalize_hostname != SSH_CANONICALISE_NO) > addrs = resolve_canonicalize(&host, options.port); > /* So it was kinda intentional ? on my 6.5p1 the patch fails patch -Np0 -i ../../fix-mixed-upper-lower-case-host.patch patching file ssh.c Hunk #1 FAILED at 752. Hunk #2 FAILED at 882. 2 out of 2 hunks FAILED -- saving rejects to file ssh.c.rej probably due to the 'older' version of ssh.c following applies on 6.5p1 --- ssh.c.orig 2014-02-04 08:40:18.866715480 +0100 +++ ssh.c 2014-02-04 08:43:22.931826364 +0100 @@ -780,7 +780,6 @@ if (!host) usage(); - lowercase(host); host_arg = xstrdup(host); OpenSSL_add_all_algorithms(); @@ -914,6 +913,7 @@ } /* If canonicalization requested then try to apply it */ + lowercase(host); if (options.canonicalize_hostname != SSH_CANONICALISE_NO) addrs = resolve_canonicalize(&host, options.port); /* I have checked and the configuration as given in my example works again. Thank you very much for such quick answer :) -- Ike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From hkario at redhat.com Wed Feb 5 02:58:24 2014 From: hkario at redhat.com (Hubert Kario) Date: Tue, 4 Feb 2014 10:58:24 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: <1958226279.13081142.1391526655324.JavaMail.root@redhat.com> Message-ID: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> Hi all! Continuing the discussion from https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032037.html I have looked at the changes made to implement automatic selection of DH groups and there are few changes confusing to me, to say the least. Especially 1.97~1.96 rev diff of kex.c: > + dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher)); Why "MAX("? Why security of chosen dh moduli should match the _most_ secure primitive? Since DH KEX is computationally expensive (think smartphones), shouldn't we try to use as small DH parameters as possible? > + dh_need = MAX(dh_need, newkeys->enc.block_size); This is plain confusing. Which cipher's security level is influenced by its block size? + dh_need = MAX(dh_need, newkeys->enc.iv_len); I'd also say that the relationship between IV size and and security estimate is a bit more complex. I.e. IV of size 96 bits won't lower the security level of whole system to 96 bits. + dh_need = MAX(dh_need, newkeys->mac.key_len); Shouldn't this use mac.mac_len? I mean MACs like hmac-md5-96 provide 96 bits of security, not the 128 bits from key size. -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From djm at mindrot.org Wed Feb 5 09:42:31 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 5 Feb 2014 09:42:31 +1100 (EST) Subject: 3des cipher and DH group size In-Reply-To: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> Message-ID: On Tue, 4 Feb 2014, Hubert Kario wrote: > Hi all! > > Continuing the discussion from https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032037.html > > I have looked at the changes made to implement automatic selection of DH > groups and there are few changes confusing to me, to say the least. > > Especially 1.97~1.96 rev diff of kex.c: > > > + dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher)); > > Why "MAX("? Why security of chosen dh moduli should match the _most_ > secure primitive? Since DH KEX is computationally expensive (think smartphones), > shouldn't we try to use as small DH parameters as possible? I think that it's reasonable for users, when they select a cipher of a given strength, to expect that ssh actually provides enough key material to properly use it. > > + dh_need = MAX(dh_need, newkeys->enc.block_size); > > This is plain confusing. Which cipher's security level is influenced by its > block size? All of them because of the the birthday bound. In OpenSSH's case, this is a noop since all our ciphers have key_len >= block_size. > + dh_need = MAX(dh_need, newkeys->enc.iv_len); > > I'd also say that the relationship between IV size and and security estimate > is a bit more complex. I.e. IV of size 96 bits won't lower the security level > of whole system to 96 bits. Really? If a cipher requires a random IV of a certain size then I think we should be ensuring that the key exchange output can actually provide it. But again, this is a nop; we don't currently have any ciphers where iv_len > key_len; > + dh_need = MAX(dh_need, newkeys->mac.key_len); > > Shouldn't this use mac.mac_len? I mean MACs like hmac-md5-96 provide > 96 bits of security, not the 128 bits from key size. While truncated MACs are common, I've never heard of anyone recommend truncating the key along with it. -d [1] https://anongit.mindrot.org/openssh.git/commit/dh.c?id=df62d71e64d29d1054e7a53d1a801075ef70335f From sdb at stuartdb.com Wed Feb 5 13:56:01 2014 From: sdb at stuartdb.com (Stuart Baker) Date: Wed, 05 Feb 2014 15:56:01 +1300 Subject: SFTP: Unable to input unicode characters Message-ID: <52F1A841.90203@stuartdb.com> Hi openssh mailing list, I'm currently running Arch x86_64 with openssh 6.5p1, but the following is also reproduceable on Debian stable (openssh 6.0p1 I believe). Entering unicode characters directly into sftp results in no input. Not a placeholder character or a space, just no input. Here are some relevant details: The machines in my test both have locale correctly set (in this specific example it's en_NZ.UTF-8). Entering in the same character into the shell, ssh and scp all work as expected without issue. sftp will autocomplete a filename with a unicode character in it correctly. The transfer works as expected. The issue becomes apparent when you are not in a situation to autocomplete the filename and you need to manually enter the unicode character. Example (auto complete after "t" works fine): sftp> ls t?st-file sftp> get t?st-file Example (unable to find a way to complete command): sftp> ls test-file t?st-file sftp> get t test-file t?st-file sftp> get t Trying to enter '?' results in no visible input. Pasting in 't?st-file' results in 'tst-file'. As mentioned, this seems to only be an issue with sftp and is not an issue in ssh or scp. Is this a known issue? I did my best to search for other mentions of this but was unable to find anything. Kind Regards, Stuart From fleurent at ivsweb.com Wed Feb 5 21:44:28 2014 From: fleurent at ivsweb.com (Francois Leurent) Date: Wed, 5 Feb 2014 11:44:28 +0100 Subject: Make SSH_ORIGINAL_COMMAND available in AuthorizedKeysCommand context Message-ID: Hi Using SSH_ORIGINAL_COMMAND in AuthorizedKeys is so helpful, I'd like to know if it might be possible to access it in the AuthorizedKeysCommand context (via env ?). Is this possible ? can anybody give me advice on going into this ? If possible, I'll use this SSH_ORIGINAL_COMMAND to send client specifics information to the AuthorizedKeysCommand script. Currently, the only alternative to this is to use the login itself (we have around 30k+ different 'hosts' that might want to connect to our servers) to identify the client, but that come with the need of a custom nss endpoint configuration (we use libnss-pgsql2 ) to support dynamic user lookup, and more work (to manage uid & co) Using 'one' standard user file was enough (and a lot simplier), as those hosts don't need to do anything but to setup a revert port forwarding rule, and are bound to a very limited shell. My (now useless) /home/host_controler/.ssh/authorized_keys file (build on a cron run) was like : command="limited_shell.sh --host_id=XXX1 $SSH_ORIGINAL_COMMAND" ssh-rsa pubkey of host 1" command="limited_shell.sh --host_id=XXX2 $SSH_ORIGINAL_COMMAND" ssh-rsa pubkey of host 2" command="limited_shell.sh --host_id=XXX3 $SSH_ORIGINAL_COMMAND" ssh-rsa pubkey of host 3" ... Thank you very much for your help Francois Leurent From djm at mindrot.org Wed Feb 5 23:25:54 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 5 Feb 2014 23:25:54 +1100 (EST) Subject: Make SSH_ORIGINAL_COMMAND available in AuthorizedKeysCommand context In-Reply-To: References: Message-ID: On Wed, 5 Feb 2014, Francois Leurent wrote: > Hi > > Using SSH_ORIGINAL_COMMAND in AuthorizedKeys is so helpful, > I'd like to know if it might be possible to access it in the > AuthorizedKeysCommand context (via env ?). Is this possible ? can > anybody give me advice on going into this ? Can't be done sorry - authentication happens well before the command is sent. When command="..." is specified in authorized_keys and the output of AuthorizedKeysCommand, it's just saving the restriction for later once authentication has completed and the protocol has progressed far enough for the client to request a shell or command execution. -d From hkario at redhat.com Thu Feb 6 03:19:14 2014 From: hkario at redhat.com (Hubert Kario) Date: Wed, 5 Feb 2014 11:19:14 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> Message-ID: <1713717810.13639007.1391617154422.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Damien Miller" > To: "Hubert Kario" > Cc: openssh-unix-dev at mindrot.org > Sent: Tuesday, 4 February, 2014 11:42:31 PM > Subject: Re: 3des cipher and DH group size > > On Tue, 4 Feb 2014, Hubert Kario wrote: > > > Hi all! > > > > Continuing the discussion from > > https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032037.html > > > > I have looked at the changes made to implement automatic selection of DH > > groups and there are few changes confusing to me, to say the least. > > > > Especially 1.97~1.96 rev diff of kex.c: > > > > > + dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher)); > > > > Why "MAX("? Why security of chosen dh moduli should match the _most_ > > secure primitive? Since DH KEX is computationally expensive (think > > smartphones), > > shouldn't we try to use as small DH parameters as possible? > > I think that it's reasonable for users, when they select a cipher of a > given strength, to expect that ssh actually provides enough key material > to properly use it. I agree with that. Thing is I don't see a reason to use key exchange that provides much more keying material that the cipher can use. If I'm trying to connect to old, embedded, SSH server that implements crypto in hardware the difference between 2048 bit and 3076 bit DH may be the difference between working and not working. As the patches stand now, I'm unable to force SSH to suggest 2048bit DH, no matter which combination of key exchanges, MACs, host keys or ciphers I use. If the cipher provides 112 bits of security, hash provides 96 bits of security and host key provides 80 bits of security there is no reason to select key exchange that provides 128 bits of security, is there? > > > + dh_need = MAX(dh_need, newkeys->enc.block_size); > > > > This is plain confusing. Which cipher's security level is influenced by its > > block size? > > All of them because of the the birthday bound. How does birthday bound on block size affect block ciphers? Can you point me to some literature on this? From what I know, a cipher with block_size > key_size would produce biased output. > > + dh_need = MAX(dh_need, newkeys->enc.iv_len); > > > > I'd also say that the relationship between IV size and and security > > estimate > > is a bit more complex. I.e. IV of size 96 bits won't lower the security > > level > > of whole system to 96 bits. > > Really? Well, IV is used to provide randomness in case of key-plaintext pair reuse/collision. So it mostly influences how much plaintext you can encrypt with the same key. I mean, how else would AES-GCM ciphers (which use 96bit IVs) be considered secure (let alone state of the art) if that wasn't the case? > If a cipher requires a random IV of a certain size then I think > we should be ensuring that the key exchange output can actually provide > it. But again, this is a nop; we don't currently have any ciphers where > iv_len > key_len; > > > + dh_need = MAX(dh_need, newkeys->mac.key_len); > > > > Shouldn't this use mac.mac_len? I mean MACs like hmac-md5-96 provide > > 96 bits of security, not the 128 bits from key size. > > While truncated MACs are common, I've never heard of anyone recommend > truncating the key along with it. I meant that truncated mac doesn't provide the same security as non-truncated version. So making sure that there are at least 128 bits of entropy in key of a MAC with 96 bit output is not necessary. There's a KDF between DH output and MAC input. As far as I read the code, dh_need is used to calculate the needed amount of entropy/security margin, not the actual amount of bits needed to feed to different primitives, the "need" variable is used for that, isn't it? > -d > > [1] > https://anongit.mindrot.org/openssh.git/commit/dh.c?id=df62d71e64d29d1054e7a53d1a801075ef70335f -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From sunil.kini at hp.com Thu Feb 6 17:15:38 2014 From: sunil.kini at hp.com (K, Sunil Kini (MCOU)) Date: Thu, 6 Feb 2014 06:15:38 +0000 Subject: Call for testing: OpenSSH-6.5 Message-ID: <6057E48969C51C44B34F71B60C2A1D83807115C1@G4W3304.americas.hpqcorp.net> Hi, Please find the snapshot test results on HP-UX platform. Used http://www.mindrot.org/openssh_snap/openssh-SNAP-20140120.tar.gz Results : OS Build_Target CC OpenSSL BUILD TEST ============== ===================== ================================================ ======= ===== ================ HP-UX 11.31 ia64-hp-hpux11.31 HP C (bundled) for Integrity Servers B3910B A.06.12 0.9.8t OK all tests passed HP-UX 11.31 PA-RISC-hp-hpux11.31 HP92453-01 B.11.11.24 HP C Compiler 0.9.8y OK all tests passed HP-UX 11.23 ia64-hp-hpux11.23 HP C/aC++ for Integrity Servers B3910B A.06.25 0.9.8y OK all tests passed HP-UX 11.23 PA-RISC -hp-hpux11.23 HP92453-01 B.11.11.22 HP C Compiler 0.9.8y OK all tests passed HP-UX 11.11 PA-RISC -hp-hpux11.11 HP92453-01 B.11.11.16 HP C Compiler 0.9.7i OK all tests passed The following changes were made for successful completion of build: On HP-UX 11.23 ia64 and PA-RISC platforms, In readconf.c added the following for ntohs unsatisfied symbol error, #if defined(__hpux) #include #endif On HP-UX 11.11 PA-RISC platform, In readconf.c added the following for ntohs unsatisfied symbol error, #if defined(__hpux) #include #endif We see that this issue has already been reported and patched. Thanks & Regards, Sunil From vinschen at redhat.com Thu Feb 6 20:41:17 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 6 Feb 2014 10:41:17 +0100 Subject: Announce: OpenSSH 6.5 released In-Reply-To: <20140203104437.GA21400@calimero.vinschen.de> References: <201401300634.s0U6YI9i011801@cvs.openbsd.org> <20140203104437.GA21400@calimero.vinschen.de> Message-ID: <20140206094117.GF2821@calimero.vinschen.de> Ping? Is there anything wrong with my analysis or the patch? Thanks, Corinna On Feb 3 11:44, Corinna Vinschen wrote: > Hi guys, > > On Jan 29 23:34, Damien Miller wrote: > > Changes since OpenSSH 6.4 > > ========================= > > [...] > > Bugfixes: > > > > * ssh(1), sshd(8): Fix potential stack exhaustion caused by nested > > certificates. > > > > * ssh(1): bz#1211: make BindAddress work with UsePrivilegedPort. > > there's a bug in this change. > > Try this as user root: > > $ ssh -V > OpenSSH_6.5p1, [...] > $ ssh -oUsePrivilegedPort=yes remote-machine > getaddrinfo: (null): Name or service not known > getaddrinfo: (null): Name or service not known > ssh: connect to host remote-machine port 22: No such file or directory > > The bug is in sshconnect.c, function ssh_create_socket(). The only > way to avoid a call to to getaddrinfo is if *either* options.bind_address > is non-NULL, *or* UsePrivilegedPort is set to no: > > /* Bind the socket to an alternative local IP address */ > if (options.bind_address == NULL && !privileged) > return sock; > > However, if UsePrivilegedPort is set to yes, options.bind_address will be > checked in the subsequent getaddrinfo call, even if it's NULL, because the > -b option hasn't been used. > > The result is, both input parameters to getaddrinfo() are NULL, so > getaddrinfo() returns with EAI_NONAME, thus breaking the UsePrivilegedPort > functionality, unless -b is given as well. > > Here's a patch: > > Index: sshconnect.c > =================================================================== > RCS file: /cvs/openssh/sshconnect.c,v > retrieving revision 1.217 > diff -u -p -r1.217 sshconnect.c > --- sshconnect.c 9 Jan 2014 23:59:24 -0000 1.217 > +++ sshconnect.c 3 Feb 2014 10:44:20 -0000 > @@ -269,7 +269,7 @@ static int > ssh_create_socket(int privileged, struct addrinfo *ai) > { > int sock, r, gaierr; > - struct addrinfo hints, *res; > + struct addrinfo hints, *res = NULL; > > sock = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > if (sock < 0) { > @@ -282,17 +282,19 @@ ssh_create_socket(int privileged, struct > if (options.bind_address == NULL && !privileged) > return sock; > > - memset(&hints, 0, sizeof(hints)); > - hints.ai_family = ai->ai_family; > - hints.ai_socktype = ai->ai_socktype; > - hints.ai_protocol = ai->ai_protocol; > - hints.ai_flags = AI_PASSIVE; > - gaierr = getaddrinfo(options.bind_address, NULL, &hints, &res); > - if (gaierr) { > - error("getaddrinfo: %s: %s", options.bind_address, > - ssh_gai_strerror(gaierr)); > - close(sock); > - return -1; > + if (options.bind_address) { > + memset(&hints, 0, sizeof(hints)); > + hints.ai_family = ai->ai_family; > + hints.ai_socktype = ai->ai_socktype; > + hints.ai_protocol = ai->ai_protocol; > + hints.ai_flags = AI_PASSIVE; > + gaierr = getaddrinfo(options.bind_address, NULL, &hints, &res); > + if (gaierr) { > + error("getaddrinfo: %s: %s", options.bind_address, > + ssh_gai_strerror(gaierr)); > + close(sock); > + return -1; > + } > } > /* > * If we are running as root and want to connect to a privileged > @@ -300,7 +302,7 @@ ssh_create_socket(int privileged, struct > */ > if (privileged) { > PRIV_START; > - r = bindresvport_sa(sock, res->ai_addr); > + r = bindresvport_sa(sock, res ? res->ai_addr : NULL); > PRIV_END; > if (r < 0) { > error("bindresvport_sa: af=%d %s", ai->ai_family, > > > > > -- > Corinna Vinschen > Cygwin Maintainer > Red Hat > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From Tim.Broberg at servicenow.com Fri Feb 7 08:47:49 2014 From: Tim.Broberg at servicenow.com (Tim Broberg) Date: Thu, 6 Feb 2014 21:47:49 +0000 Subject: Timing out a channel exec request Message-ID: Is anyone aware of a method to force termination of a single channel without waiting for the associated process to complete? I have a use case where my client submits several commands to be executed over the same session at the same time on separate channels. In some cases (cough df), one or more those commands may hang indefinitely. I detect that the command is not finishing in a reasonable amount of time, and now I want to tear down that process. What do I do? - SSH2_MSG_CHANNEL_CLOSE results in a long polling loop where sshd keeps trying to garbage collect the channel, but can't because the process is still alive. Furthermore, this appears to be stalling the other commands as well. (More experimentation is needed on this point.) - SSH_MSG_DISCONNECT tears down the whole session, killing *all* the commands. I could do this, but now I have to restart all the other commands that get trashed. - I could try a SSH_MSG_CHANNEL_REQUEST "signal" and send SIGINT, SIGTERM, SIGABRT, etc, but I don't see a handler for "signal" in the server loop. I've crawled the source for a few hours, but haven't come up with any ideas more productive than the non-options above. I could use a clue or two as to other options / how others deal with channel timeouts. Thanks! - Tim. From djm at mindrot.org Fri Feb 7 09:12:23 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 7 Feb 2014 09:12:23 +1100 (EST) Subject: Timing out a channel exec request In-Reply-To: References: Message-ID: On Thu, 6 Feb 2014, Tim Broberg wrote: > Is anyone aware of a method to force termination of a single channel > without waiting for the associated process to complete? I think SSH2_MSG_CHANNEL_EOF then SSH2_MSG_CHANNEL_CLOSE might do what you want. > - SSH2_MSG_CHANNEL_CLOSE results in a long polling loop where sshd keeps > trying to garbage collect the channel, but can't because the process is > still alive. Furthermore, this appears to be stalling the other commands > as well. (More experimentation is needed on this point.) The server shouldn't hang while processing a close. > - I could try a SSH_MSG_CHANNEL_REQUEST "signal" and send SIGINT, > SIGTERM, SIGABRT, etc, but I don't see a handler for "signal" in the > server loop. No we don't support sending signals. There are patches on https://bugzilla.mindrot.org/show_bug.cgi?id=1424 but we're worried about possible problems of sshd signalling processes it shouldn't. -d From peter at stuge.se Fri Feb 7 09:15:07 2014 From: peter at stuge.se (Peter Stuge) Date: Thu, 6 Feb 2014 23:15:07 +0100 Subject: Timing out a channel exec request In-Reply-To: References: Message-ID: <20140206221507.28389.qmail@stuge.se> Tim Broberg wrote: > I could use a clue or two as to other options Write and deploy a process manager onto the server. Doesn't scale. //Peter From djm at mindrot.org Fri Feb 7 09:21:36 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 7 Feb 2014 09:21:36 +1100 (EST) Subject: Announce: OpenSSH 6.5 released In-Reply-To: <20140206094117.GF2821@calimero.vinschen.de> References: <201401300634.s0U6YI9i011801@cvs.openbsd.org> <20140203104437.GA21400@calimero.vinschen.de> <20140206094117.GF2821@calimero.vinschen.de> Message-ID: On Thu, 6 Feb 2014, Corinna Vinschen wrote: > Ping? > > Is there anything wrong with my analysis or the patch? Committed, with this extra bit: diff --git sshconnect.c sshconnect.c index e3af605..8556662 100644 --- sshconnect.c +++ sshconnect.c @@ -307,7 +309,8 @@ ssh_create_socket(int privileged, struct addrinfo *ai) return -1; } } - freeaddrinfo(res); + if (res != NULL) + freeaddrinfo(res); return sock; } From Tim.Broberg at servicenow.com Fri Feb 7 09:22:19 2014 From: Tim.Broberg at servicenow.com (Tim Broberg) Date: Thu, 6 Feb 2014 22:22:19 +0000 Subject: Timing out a channel exec request In-Reply-To: Message-ID: Right now, the machine I'm experimenting against is running OpenSSH 5.5. I'm sending SSH2_MSG_CHANNEL_EOF right after I send the exec request, because I have nothing further to say. SSH2_MSG_CHANNEL_CLOSE gets sent at the time that the timeout condition is detected. I would expect the server to clean up and reply with SSH2_MSG_CHANNEL_CLOSE, but the process remains open and I never do get a SSH2_MSG_CHANNEL_CLOSE reply. When I eventually tear the whole session down, the process gets wiped out then. - Tim. On 2/6/14 2:12 PM, "Damien Miller" wrote: >On Thu, 6 Feb 2014, Tim Broberg wrote: > >> Is anyone aware of a method to force termination of a single channel >> without waiting for the associated process to complete? > >I think SSH2_MSG_CHANNEL_EOF then SSH2_MSG_CHANNEL_CLOSE might do what >you want. > >> - SSH2_MSG_CHANNEL_CLOSE results in a long polling loop where sshd keeps >> trying to garbage collect the channel, but can't because the process is >> still alive. Furthermore, this appears to be stalling the other commands >> as well. (More experimentation is needed on this point.) > >The server shouldn't hang while processing a close. > >> - I could try a SSH_MSG_CHANNEL_REQUEST "signal" and send SIGINT, >> SIGTERM, SIGABRT, etc, but I don't see a handler for "signal" in the >> server loop. > >No we don't support sending signals. There are patches on >https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.mindrot.org/sh >ow_bug.cgi?id%3D1424&k=vE6vJ%2F6us6MO2E%2BCdRJaLw%3D%3D%0A&r=CFOVYS%2Bpq34 >MoQdIh9mGy2v3juvm16uSvL2B2p9WKsQ%3D%0A&m=lwQZAeTp8nvxoDCauob1wrKWF%2FBMGa8 >GWy6P15rmk04%3D%0A&s=0cac9f89eacfc4ea8547a46a88fe6027f645bbf485232537dc7a3 >7ec3e36d760 but we're worried >about possible problems of sshd signalling processes it shouldn't. > >-d > From Tim.Broberg at servicenow.com Fri Feb 7 09:25:10 2014 From: Tim.Broberg at servicenow.com (Tim Broberg) Date: Thu, 6 Feb 2014 22:25:10 +0000 Subject: Timing out a channel exec request In-Reply-To: <20140206221507.28389.qmail@stuge.se> Message-ID: Yes, the best fallbacks I have are to kill the process with a separate command or go ahead and trash the whole session and resubmit any outstanding commands one by one. ?or none of the above: blame the user for the original hang and wait for him to solve the problem. x^D I'm hoping it won't come to that... Thanks for your thoughts, - Tim. On 2/6/14 2:15 PM, "Peter Stuge" wrote: >Tim Broberg wrote: >> I could use a clue or two as to other options > >Write and deploy a process manager onto the server. Doesn't scale. > > >//Peter >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://urldefense.proofpoint.com/v1/url?u=https://lists.mindrot.org/mailm >an/listinfo/openssh-unix-dev&k=vE6vJ%2F6us6MO2E%2BCdRJaLw%3D%3D%0A&r=CFOVY >S%2Bpq34MoQdIh9mGy2v3juvm16uSvL2B2p9WKsQ%3D%0A&m=RYLYjBEDRT%2BYHI7L7Ip9aR6 >QuJIPssTwo8thMa157yk%3D%0A&s=af88515e6534e04daa2f21b796c10785df7e9e95071a2 >f4b458a9d45729ca099 From Tim.Broberg at servicenow.com Fri Feb 7 09:42:35 2014 From: Tim.Broberg at servicenow.com (Tim Broberg) Date: Thu, 6 Feb 2014 22:42:35 +0000 Subject: Timing out a channel exec request In-Reply-To: Message-ID: The other commands hanging were because I had set the MaxSessions parameter artificially low for a previous test case. Those channels got failed at SSH2_MSG_CHANNEL_OPEN. That's one more mystery gone from the world. - Tim. On 2/6/14 2:22 PM, "Tim Broberg" wrote: >Right now, the machine I'm experimenting against is running OpenSSH 5.5. > >I'm sending SSH2_MSG_CHANNEL_EOF right after I send the exec request, >because I have nothing further to say. > >SSH2_MSG_CHANNEL_CLOSE gets sent at the time that the timeout condition is >detected. > >I would expect the server to clean up and reply with >SSH2_MSG_CHANNEL_CLOSE, but the process remains open and I never do get a >SSH2_MSG_CHANNEL_CLOSE reply. > >When I eventually tear the whole session down, the process gets wiped out >then. > > - Tim. > >On 2/6/14 2:12 PM, "Damien Miller" wrote: > >>On Thu, 6 Feb 2014, Tim Broberg wrote: >> >>> Is anyone aware of a method to force termination of a single channel >>> without waiting for the associated process to complete? >> >>I think SSH2_MSG_CHANNEL_EOF then SSH2_MSG_CHANNEL_CLOSE might do what >>you want. >> >>> - SSH2_MSG_CHANNEL_CLOSE results in a long polling loop where sshd >>>keeps >>> trying to garbage collect the channel, but can't because the process is >>> still alive. Furthermore, this appears to be stalling the other >>>commands >>> as well. (More experimentation is needed on this point.) >> >>The server shouldn't hang while processing a close. >> >>> - I could try a SSH_MSG_CHANNEL_REQUEST "signal" and send SIGINT, >>> SIGTERM, SIGABRT, etc, but I don't see a handler for "signal" in the >>> server loop. >> >>No we don't support sending signals. There are patches on >>https://urldefense.proofpoint.com/v1/url?u=https://bugzilla.mindrot.org/s >>h >>ow_bug.cgi?id%3D1424&k=vE6vJ%2F6us6MO2E%2BCdRJaLw%3D%3D%0A&r=CFOVYS%2Bpq3 >>4 >>MoQdIh9mGy2v3juvm16uSvL2B2p9WKsQ%3D%0A&m=lwQZAeTp8nvxoDCauob1wrKWF%2FBMGa >>8 >>GWy6P15rmk04%3D%0A&s=0cac9f89eacfc4ea8547a46a88fe6027f645bbf485232537dc7a >>3 >>7ec3e36d760 but we're worried >>about possible problems of sshd signalling processes it shouldn't. >> >>-d >> > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://urldefense.proofpoint.com/v1/url?u=https://lists.mindrot.org/mailm >an/listinfo/openssh-unix-dev&k=vE6vJ%2F6us6MO2E%2BCdRJaLw%3D%3D%0A&r=CFOVY >S%2Bpq34MoQdIh9mGy2v3juvm16uSvL2B2p9WKsQ%3D%0A&m=HPhc5wDb28b5AiNdkNUHuRfZh >PFNMfVHrU7%2F%2FNrrbKY%3D%0A&s=8c78e166eae651ee088748ceb7104a258610d8cb8eb >0dfc9550d707b641e0a87 From vinschen at redhat.com Fri Feb 7 20:50:44 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 7 Feb 2014 10:50:44 +0100 Subject: Announce: OpenSSH 6.5 released In-Reply-To: References: <201401300634.s0U6YI9i011801@cvs.openbsd.org> <20140203104437.GA21400@calimero.vinschen.de> <20140206094117.GF2821@calimero.vinschen.de> Message-ID: <20140207095044.GO2821@calimero.vinschen.de> On Feb 7 09:21, Damien Miller wrote: > On Thu, 6 Feb 2014, Corinna Vinschen wrote: > > > Ping? > > > > Is there anything wrong with my analysis or the patch? > > Committed, with this extra bit: > > diff --git sshconnect.c sshconnect.c > index e3af605..8556662 100644 > --- sshconnect.c > +++ sshconnect.c > @@ -307,7 +309,8 @@ ssh_create_socket(int privileged, struct addrinfo *ai) > return -1; > } > } > - freeaddrinfo(res); > + if (res != NULL) > + freeaddrinfo(res); > return sock; > } Thanks! Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From karl at freefriends.org Mon Feb 10 09:12:28 2014 From: karl at freefriends.org (Karl Berry) Date: Sun, 9 Feb 2014 22:12:28 GMT Subject: openssh 6.5p1 configure and ssl location/shared Message-ID: <201402092212.s19MCSrC031154@freefriends.org> Greetings, In openssh 6.5p1, configure --with-ssl-dir=/usr/local/openssl failed for me because it could not find opensslv.h. This is because that section of the configure hardwires the /usr/local/ssl directory instead of using the --with-ssl-dir value. From configure.ac: .. LDFLAGS="-L/usr/local/ssl/lib -R/usr/local/ssl/lib ${sa\ ved_LDFLAGS}" else LDFLAGS="-L/usr/local/ssl/lib ${saved_LDFLAGS}" fi CPPFLAGS="-I/usr/local/ssl/include ${saved_CPPFLAGS}" .. I made a symlink /usr/local/ssl to work around that. Then it failed again, this time because the link with libcrypto failed. This is because I only install a static openssl, where configure was assuming a shared library. The error looked like this, from config.log: /usr/bin/ld: /usr/local/ssl/lib/libcrypto.a(eng_init.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/local/ssl/lib/libcrypto.a: could not read symbols: Bad value This happened because the -Wl,-z,relro option is now being included by default. This is on CentOS 6.5, x86_64, though I suppose any GNU ld that supports the option would induce the same error given the lack of shared libraries. I ran configure --without-hardening to work around that problem. Then it all went through. Thanks for the amazing software, Karl From djm at mindrot.org Mon Feb 10 11:22:19 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Feb 2014 11:22:19 +1100 (EST) Subject: openssh 6.5p1 configure and ssl location/shared In-Reply-To: <201402092212.s19MCSrC031154@freefriends.org> References: <201402092212.s19MCSrC031154@freefriends.org> Message-ID: On Sun, 9 Feb 2014, Karl Berry wrote: > This happened because the -Wl,-z,relro option is now being included by > default. This is on CentOS 6.5, x86_64, though I suppose any > GNU ld that supports the option would induce the same error given the > lack of shared libraries. I think it's probably more likely to do with the -fPIE option - this requires that the libraries linked be position independent too. > I ran configure --without-hardening to work around that problem. Then > it all went through. I'd recommend rebuilding OpenSSL with -fPIC instead, there are many security benefits to the hardening options we enable. -d From karl at freefriends.org Mon Feb 10 11:36:20 2014 From: karl at freefriends.org (Karl Berry) Date: Sun, 09 Feb 2014 17:36:20 -0700 Subject: openssh 6.5p1 configure and ssl location/shared In-Reply-To: (message from Damien Miller on Mon, 10 Feb 2014 11:22:19 +1100 (EST)) Message-ID: <861tzbst16.fsf@frenzy.freefriends.org> I think it's probably more likely to do with the -fPIE option - this requires that the libraries linked be position independent too. The fact is that when I used --without-hardening, the link succeeded without any other changes. I don't believe any -fPIC option is being used anywhere in my scenario. I'd recommend rebuilding OpenSSL with -fPIC instead, There are various reasons why I don't want to do that, but that's irrelevant. The point is that linking with a static libssl always worked before; hence I thought it worth mentioning. If it's not going to be supported (I hope you won't go that route, of course), then it should bomb out intentionally, not just because some random test happened to fail. Another possibility would be to avoid the relro option unless the library is dynamic, or make it a separate configure option, or whatever. I believe that is the one that's the issue, and the others are fine. there are many security benefits to the hardening options we enable. I know. Best, Karl From djm at mindrot.org Mon Feb 10 11:43:38 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Feb 2014 11:43:38 +1100 (EST) Subject: openssh 6.5p1 configure and ssl location/shared In-Reply-To: <861tzbst16.fsf@frenzy.freefriends.org> References: <861tzbst16.fsf@frenzy.freefriends.org> Message-ID: On Sun, 9 Feb 2014, Karl Berry wrote: > I think it's probably more likely to do with the -fPIE option - this > requires that the libraries linked be position independent too. > > The fact is that when I used --without-hardening, the link succeeded > without any other changes. I don't believe any -fPIC option is being > used anywhere in my scenario. --without-hardening turns off PIE too > I'd recommend rebuilding OpenSSL with -fPIC instead, > > There are various reasons why I don't want to do that, but that's > irrelevant. The point is that linking with a static libssl always > worked before; hence I thought it worth mentioning. If it's not going > to be supported (I hope you won't go that route, of course), then it > should bomb out intentionally, not just because some random test > happened to fail. --without-hardening will continue to be supported, but toolchain hardening will continue to be the default. It's hard and fairly platform-dependent to provide better diagnostics for why linking against OpenSSL fails and IMO not worth it given config.log gives a pretty clear reason. > Another possibility would be to avoid the relro option unless the > library is dynamic, or make it a separate configure option, or > whatever. I believe that is the one that's the issue, and the others > are fine. pretty sure it isn't relro, you can verify by editing it from Makefile afrer configure has run. You could also try --without-pie to turn PIE off and leave relro intact. -d From the.warl0ck.1989 at gmail.com Mon Feb 10 19:39:51 2014 From: the.warl0ck.1989 at gmail.com (Aaron Lewis) Date: Mon, 10 Feb 2014 16:39:51 +0800 Subject: What magic did openssh do to handle programs like VIM? Message-ID: Hi, I'm trying to write my own remote shell program, It simply connects to a remote server then copy the sock fd to stdin, stdout and stderr. And it works. But I found several problems: 1. It doesn't handle characters like ^A ^E or tab (any bash/readline stuff) -> openssh itself doesn't seem to incorporate readline, so the magic is not on readline 2. If I run command like VIM, it doesn't run. And buttons like ":q" won't work Can someone enlighten me about what SSH did, so it all works perfectly? Attached the prototype: int sockfd = socket(PF_INET, SOCK_STREAM, 0); struct sockaddr_in remaddr = { 0 }; remaddr.sin_family = AF_INET; remaddr.sin_port = htons(9999); remaddr.sin_addr.s_addr = inet_addr("192.168.56.1"); if (connect(sockfd, (struct sockaddr *)&remaddr, sizeof(struct sockaddr))) ERR_QUIT("connect"); for (int i = 0; i < 2; ++i ) dup2 (sockfd, i); execl("/bin/bash", "/bin/bash", "-i", NULL); -- Best Regards, Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/ Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33 From ziirish at ziirish.info Mon Feb 10 20:01:56 2014 From: ziirish at ziirish.info (Ziirish) Date: Mon, 10 Feb 2014 10:01:56 +0100 Subject: What magic did openssh do to handle programs like VIM? In-Reply-To: References: Message-ID: <20140210090156.GH28113@shell.ziirish.info> Hi, I'm not familiar with openssh internals, but in order to "catch" the specials characters, you may want to use ioctl(2) with the requests TCGETS and TCSETS. * On Monday, 10 February 2014 09:45, Aaron Lewis wrote: > Hi, > > I'm trying to write my own remote shell program, > > It simply connects to a remote server then copy the sock fd to stdin, > stdout and stderr. And it works. > > But I found several problems: > 1. It doesn't handle characters like ^A ^E or tab (any bash/readline stuff) > -> openssh itself doesn't seem to incorporate readline, so the > magic is not on readline > 2. If I run command like VIM, it doesn't run. > And buttons like ":q" won't work > > Can someone enlighten me about what SSH did, so it all works perfectly? > > Attached the prototype: > > int sockfd = socket(PF_INET, SOCK_STREAM, 0); > struct sockaddr_in remaddr = { 0 }; > > remaddr.sin_family = AF_INET; > remaddr.sin_port = htons(9999); > remaddr.sin_addr.s_addr = inet_addr("192.168.56.1"); > > if (connect(sockfd, (struct sockaddr *)&remaddr, sizeof(struct sockaddr))) > ERR_QUIT("connect"); > > for (int i = 0; i < 2; ++i ) > dup2 (sockfd, i); > execl("/bin/bash", "/bin/bash", "-i", NULL); > > > > -- > Best Regards, > Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/ > Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Mon Feb 10 19:59:41 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 10 Feb 2014 19:59:41 +1100 Subject: What magic did openssh do to handle programs like VIM? In-Reply-To: References: Message-ID: On Mon, Feb 10, 2014 at 7:39 PM, Aaron Lewis wrote: > I'm trying to write my own remote shell program, [...] > 2. If I run command like VIM, it doesn't run. > And buttons like ":q" won't work > > Can someone enlighten me about what SSH did, so it all works perfectly? Pseudo terminals: http://en.wikipedia.org/wiki/Pseudo_terminal. ssh asks sshd for one when you run an interactive shell (eg "ssh yourserver") or you use the -t flag. You can run vim via ssh without a pty and it'll behave like your application: "ssh server vim somefile". If you can find a copy of Stevens' Advanced Programming in the Unix Environment it's got a chapter on PTYs that's pretty good. Failing that, take a look at the openpty man page and the code in openssh's sshpty.c. if you don't have openpty then your task just got harder because it's quite platform-specific; take a look in openbsd-compat/bsd-openpty.c. -- 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 nkadel at gmail.com Mon Feb 10 20:10:03 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 10 Feb 2014 04:10:03 -0500 Subject: What magic did openssh do to handle programs like VIM? In-Reply-To: References: Message-ID: On Mon, Feb 10, 2014 at 3:39 AM, Aaron Lewis wrote: > Hi, > > I'm trying to write my own remote shell program, *Why*? Seriously, why re-invent the wheel? If you need an insecure version of such a toolkit, look back into the old telnet source code. For secure versions, use OpenSSH. From hlandau at devever.net Mon Feb 10 22:34:03 2014 From: hlandau at devever.net (Hugo Landau) Date: Mon, 10 Feb 2014 11:34:03 +0000 Subject: [PATCH] Basic SCTP support for OpenSSH client and server Message-ID: <1392032043-3950-1-git-send-email-hlandau@devever.net> This patch allows the OpenSSH client to make connections over SCTP, and allows the OpenSSH server to listen for connections over SCTP. SCTP is a robust transport-layer protocol which supports, amongst other things, the changing of endpoint IPs without breaking the connection. To connect via SCTP, pass -H or set "ConnectViaSCTP yes". To listen via SCTP as well as TCP, set "ListenViaSCTP yes". You will need to run autoreconf after applying this patch since there are changes to configure.ac. SCTP will be automatically enabled if detected by configure. If you pass --with-sctp, configure will fail if SCTP is not detected. The include file is required. Linux users may need to install lksctp before this file is present. You may need to adjust system settings to enable some features of SCTP. For Linux, see the sysctls under /proc/sys/net/sctp such as addip_enable and default_auto_asconf, both of which should be enabled; see . For BSD, see the net.inet.sctp.* sysctls. Signed-off-by: Hugo Landau --- configure.ac | 28 ++++++++++++++++++++++++++++ misc.c | 40 ++++++++++++++++++++++++++++++---------- readconf.c | 14 +++++++++++++- readconf.h | 1 + servconf.c | 34 +++++++++++++++++++++++++++++++++- servconf.h | 2 ++ ssh.c | 20 +++++++++++++++++--- ssh_config | 1 + ssh_config.5 | 8 ++++++++ sshd_config | 3 +++ sshd_config.5 | 8 ++++++++ 11 files changed, 144 insertions(+), 15 deletions(-) diff --git a/configure.ac b/configure.ac index a350a2a..42438b2 100644 --- a/configure.ac +++ b/configure.ac @@ -2867,6 +2867,33 @@ if test "x$PAM_MSG" = "xyes" ; then ]) fi +# Check for SCTP support +AC_CHECK_DECL([IPPROTO_SCTP], [have_sctp=yes], , [ + #include + #include +]) + +SCTP_MSG="$have_sctp" +AC_ARG_WITH([sctp], + [ --with-sctp Enable SCTP support ], + [ + if test "x$withval" != "xno" ; then + SCTP_MSG="yes" + else + SCTP_MSG="no" + fi + ] +) + +if test "x$SCTP_MSG" = "xyes"; then + if test "x$have_sctp" != "xyes" ; then + AC_MSG_ERROR([SCTP support not found]) + fi + + AC_DEFINE([USE_SCTP], [1], + [Define if you want to enable SCTP support]) +fi + SSH_PRIVSEP_USER=sshd AC_ARG_WITH([privsep-user], [ --with-privsep-user=user Specify non-privileged user for privilege separation], @@ -4838,6 +4865,7 @@ echo " sshd superuser user PATH: $J" fi echo " Manpage format: $MANTYPE" echo " PAM support: $PAM_MSG" +echo " SCTP support: $SCTP_MSG" echo " OSF SIA support: $SIA_MSG" echo " KerberosV support: $KRB5_MSG" echo " SELinux support: $SELINUX_MSG" diff --git a/misc.c b/misc.c index e4c8c32..843ccd4 100644 --- a/misc.c +++ b/misc.c @@ -42,6 +42,9 @@ #include #include #include +#ifdef USE_SCTP +# include +#endif #include #include @@ -134,25 +137,42 @@ ssh_gai_strerror(int gaierr) } /* disable nagle on socket */ -void -set_nodelay(int fd) +static int +set_nodelay_proto(int fd, int proto, int optno, const char *pname) { int opt; socklen_t optlen; optlen = sizeof opt; - if (getsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &opt, &optlen) == -1) { - debug("getsockopt TCP_NODELAY: %.100s", strerror(errno)); - return; + if (getsockopt(fd, proto, optno, &opt, &optlen) == -1) { + debug("getsockopt %s_NODELAY: %.100s", pname, strerror(errno)); + return -1; } if (opt == 1) { - debug2("fd %d is TCP_NODELAY", fd); - return; + debug2("fd %d is %s_NODELAY", fd, pname); + return 0; } opt = 1; - debug2("fd %d setting TCP_NODELAY", fd); - if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &opt, sizeof opt) == -1) - error("setsockopt TCP_NODELAY: %.100s", strerror(errno)); + debug2("fd %d setting %s_NODELAY", fd, pname); + if (setsockopt(fd, proto, optno, &opt, sizeof opt) == -1) { + error("setsockopt %s_NODELAY: %.100s", pname, strerror(errno)); + return -1; + } + return 0; +} + +void +set_nodelay(int fd) +{ + /* We could use SO_PROTOCOL here to try and determine whether to set + * TCP_NODELAY or SCTP_NODELAY. But SO_PROTOCOL is supported only in Linux + * 2.6.32+ and is not portable. Let's just try both. + */ + if (set_nodelay_proto(fd, IPPROTO_TCP, TCP_NODELAY, "TCP") < 0) { +#ifdef USE_SCTP + set_nodelay_proto(fd, IPPROTO_SCTP, SCTP_NODELAY, "SCTP"); +#endif + } } /* Characters considered whitespace in strsep calls. */ diff --git a/readconf.c b/readconf.c index f80d1cc..1dc33fd 100644 --- a/readconf.c +++ b/readconf.c @@ -148,7 +148,7 @@ typedef enum { oVisualHostKey, oUseRoaming, oKexAlgorithms, oIPQoS, oRequestTTY, oIgnoreUnknown, oProxyUseFdpass, oCanonicalDomains, oCanonicalizeHostname, oCanonicalizeMaxDots, - oCanonicalizeFallbackLocal, oCanonicalizePermittedCNAMEs, + oCanonicalizeFallbackLocal, oCanonicalizePermittedCNAMEs, oConnectViaSCTP, oIgnoredUnknownOption, oDeprecated, oUnsupported } OpCodes; @@ -261,6 +261,11 @@ static struct { { "canonicalizehostname", oCanonicalizeHostname }, { "canonicalizemaxdots", oCanonicalizeMaxDots }, { "canonicalizepermittedcnames", oCanonicalizePermittedCNAMEs }, +#ifdef USE_SCTP + { "connectviasctp", oConnectViaSCTP }, +#else + { "connectviasctp", oUnsupported }, +#endif { "ignoreunknown", oIgnoreUnknown }, { NULL, oBadOption } @@ -1370,6 +1375,10 @@ parse_int: } break; + case oConnectViaSCTP: + intptr = &options->connect_via_sctp; + goto parse_flag; + case oCanonicalizeHostname: intptr = &options->canonicalize_hostname; multistate_ptr = multistate_canonicalizehostname; @@ -1550,6 +1559,7 @@ initialize_options(Options * options) options->canonicalize_max_dots = -1; options->canonicalize_fallback_local = -1; options->canonicalize_hostname = -1; + options->connect_via_sctp = -1; } /* @@ -1709,6 +1719,8 @@ fill_default_options(Options * options) options->canonicalize_fallback_local = 1; if (options->canonicalize_hostname == -1) options->canonicalize_hostname = SSH_CANONICALISE_NO; + if (options->connect_via_sctp == -1) + options->connect_via_sctp = 0; #define CLEAR_ON_NONE(v) \ do { \ if (v != NULL && strcasecmp(v, "none") == 0) { \ diff --git a/readconf.h b/readconf.h index 9723da0..0ed4838 100644 --- a/readconf.h +++ b/readconf.h @@ -152,6 +152,7 @@ typedef struct { int canonicalize_fallback_local; int num_permitted_cnames; struct allowed_cname permitted_cnames[MAX_CANON_DOMAINS]; + int connect_via_sctp; char *ignored_unknown; /* Pattern list of unknown tokens to ignore */ } Options; diff --git a/servconf.c b/servconf.c index 7ba65d5..b106458 100644 --- a/servconf.c +++ b/servconf.c @@ -57,6 +57,8 @@ static void add_listen_addr(ServerOptions *, char *, int); static void add_one_listen_addr(ServerOptions *, char *, int); +static void add_one_listen_addr_proto(ServerOptions *, char *, + int, int); /* Use of privilege separation or not */ extern int use_privsep; @@ -153,6 +155,7 @@ initialize_server_options(ServerOptions *options) options->ip_qos_interactive = -1; options->ip_qos_bulk = -1; options->version_addendum = NULL; + options->listen_via_sctp = -1; } void @@ -300,6 +303,9 @@ fill_default_server_options(ServerOptions *options) options->ip_qos_bulk = IPTOS_THROUGHPUT; if (options->version_addendum == NULL) options->version_addendum = xstrdup(""); + if (options->listen_via_sctp == -1) + options->listen_via_sctp = 0; + /* Turn privilege separation on by default */ if (use_privsep == -1) use_privsep = PRIVSEP_NOSANDBOX; @@ -347,7 +353,7 @@ typedef enum { sRevokedKeys, sTrustedUserCAKeys, sAuthorizedPrincipalsFile, sKexAlgorithms, sIPQoS, sVersionAddendum, sAuthorizedKeysCommand, sAuthorizedKeysCommandUser, - sAuthenticationMethods, sHostKeyAgent, + sAuthenticationMethods, sHostKeyAgent, sListenViaSCTP, sDeprecated, sUnsupported } ServerOpCodes; @@ -474,6 +480,11 @@ static struct { { "authorizedkeyscommanduser", sAuthorizedKeysCommandUser, SSHCFG_ALL }, { "versionaddendum", sVersionAddendum, SSHCFG_GLOBAL }, { "authenticationmethods", sAuthenticationMethods, SSHCFG_ALL }, +#ifdef USE_SCTP + { "listenviasctp", sListenViaSCTP, SSHCFG_GLOBAL }, +#else + { "listenviasctp", sUnsupported, SSHCFG_GLOBAL }, +#endif { NULL, sBadOption, 0 } }; @@ -543,6 +554,17 @@ add_listen_addr(ServerOptions *options, char *addr, int port) static void add_one_listen_addr(ServerOptions *options, char *addr, int port) { + add_one_listen_addr_proto(options, addr, port, 0); + +#ifdef USE_SCTP + if (options->listen_via_sctp) + add_one_listen_addr_proto(options, addr, port, IPPROTO_SCTP); +#endif +} + +static void +add_one_listen_addr_proto(ServerOptions *options, char *addr, int port, int proto) +{ struct addrinfo hints, *ai, *aitop; char strport[NI_MAXSERV]; int gaierr; @@ -551,6 +573,7 @@ add_one_listen_addr(ServerOptions *options, char *addr, int port) hints.ai_family = options->address_family; hints.ai_socktype = SOCK_STREAM; hints.ai_flags = (addr == NULL) ? AI_PASSIVE : 0; + hints.ai_protocol = proto; snprintf(strport, sizeof strport, "%d", port); if ((gaierr = getaddrinfo(addr, strport, &hints, &aitop)) != 0) fatal("bad addr or host: %s (%s)", @@ -949,6 +972,12 @@ process_server_config_line(ServerOptions *options, char *line, break; +#ifdef USE_SCTP + case sListenViaSCTP: + intptr = &options->listen_via_sctp; + goto parse_flag; +#endif + case sAddressFamily: intptr = &options->address_family; multistate_ptr = multistate_addressfamily; @@ -1974,6 +2003,9 @@ dump_config(ServerOptions *o) dump_cfg_int(sMaxSessions, o->max_sessions); dump_cfg_int(sClientAliveInterval, o->client_alive_interval); dump_cfg_int(sClientAliveCountMax, o->client_alive_count_max); +#ifdef USE_SCTP + dump_cfg_int(sListenViaSCTP, o->listen_via_sctp); +#endif /* formatted integer arguments */ dump_cfg_fmtint(sPermitRootLogin, o->permit_root_login); diff --git a/servconf.h b/servconf.h index 752d1c5..77bb49e 100644 --- a/servconf.h +++ b/servconf.h @@ -183,6 +183,8 @@ typedef struct { u_int num_auth_methods; char *auth_methods[MAX_AUTH_METHODS]; + + int listen_via_sctp; } ServerOptions; /* Information about the incoming connection as used by Match */ diff --git a/ssh.c b/ssh.c index add760c..c2f663c 100644 --- a/ssh.c +++ b/ssh.c @@ -196,7 +196,7 @@ static void usage(void) { fprintf(stderr, -"usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]\n" +"usage: ssh [-1246AaCfgHhKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]\n" " [-D [bind_address:]port] [-E log_file] [-e escape_char]\n" " [-F configfile] [-I pkcs11] [-i identity_file]\n" " [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]\n" @@ -242,6 +242,10 @@ resolve_host(const char *name, u_int port, int logerr, char *cname, size_t clen) memset(&hints, 0, sizeof(hints)); hints.ai_family = options.address_family; hints.ai_socktype = SOCK_STREAM; +#ifdef USE_SCTP + if (options.connect_via_sctp) + hints.ai_protocol = IPPROTO_SCTP; +#endif if (cname != NULL) hints.ai_flags = AI_CANONNAME; if ((gaierr = getaddrinfo(name, strport, &hints, &res)) != 0) { @@ -454,8 +458,8 @@ main(int ac, char **av) argv0 = av[0]; again: - while ((opt = getopt(ac, av, "1246ab:c:e:fgi:kl:m:no:p:qstvx" - "ACD:E:F:I:KL:MNO:PQ:R:S:TVw:W:XYy")) != -1) { + while ((opt = getopt(ac, av, "1246ab:c:e:fghi:kl:m:no:p:qstvx" + "ACD:E:F:HI:KL:MNO:PQ:R:S:TVw:W:XYy")) != -1) { switch (opt) { case '1': options.protocol = SSH_PROTO_1; @@ -488,6 +492,16 @@ main(int ac, char **av) case 'E': logfile = xstrdup(optarg); break; + case 'h': + options.connect_via_sctp = 0; + break; + case 'H': +#ifdef USE_SCTP + options.connect_via_sctp = 1; +#else + fprintf(stderr, "no support for SCTP.\n"); +#endif + break; case 'Y': options.forward_x11 = 1; options.forward_x11_trusted = 1; diff --git a/ssh_config b/ssh_config index 03a228f..2e8b9de 100644 --- a/ssh_config +++ b/ssh_config @@ -46,3 +46,4 @@ # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com # RekeyLimit 1G 1h +# ConnectViaSCTP no diff --git a/ssh_config.5 b/ssh_config.5 index 3cadcd7..cab0cde 100644 --- a/ssh_config.5 +++ b/ssh_config.5 @@ -1372,6 +1372,14 @@ Note that this option must be set to for .Cm RhostsRSAAuthentication with older servers. +.It Cm ConnectViaSCTP +Specifies whether to make SSH connections using SCTP instead of TCP. +The argument must be +.Dq yes +or +.Dq no . +The default is +.Dq no . .It Cm User Specifies the user to log in as. This can be useful when a different user name is used on different machines. diff --git a/sshd_config b/sshd_config index e9045bc..a1a8f03 100644 --- a/sshd_config +++ b/sshd_config @@ -96,6 +96,9 @@ AuthorizedKeysFile .ssh/authorized_keys # and ChallengeResponseAuthentication to 'no'. #UsePAM no +# Set to yes to enable connections via SCTP as well as TCP. +#ListenViaSCTP no + #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no diff --git a/sshd_config.5 b/sshd_config.5 index de330a0..4ef068b 100644 --- a/sshd_config.5 +++ b/sshd_config.5 @@ -728,6 +728,14 @@ options are permitted. Additionally, any .Cm Port options must precede this option for non-port qualified addresses. +.It Cm ListenViaSCTP +Specifies whether the daemon should listen via SCTP as well as TCP. +The argument must be +.Dq yes +or +.Dq no . +The default is +.Dq no . .It Cm LoginGraceTime The server disconnects after this time if the user has not successfully logged in. -- 1.8.5.4 From mstone at mathom.us Mon Feb 10 23:14:20 2014 From: mstone at mathom.us (Michael Stone) Date: Mon, 10 Feb 2014 07:14:20 -0500 Subject: What magic did openssh do to handle programs like VIM? In-Reply-To: References: Message-ID: On Mon, Feb 10, 2014 at 04:10:03AM -0500, you wrote: >On Mon, Feb 10, 2014 at 3:39 AM, Aaron Lewis wrote: >> Hi, >> >> I'm trying to write my own remote shell program, > >*Why*? Sometimes, people like to learn things. From djm at mindrot.org Tue Feb 11 09:20:47 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 11 Feb 2014 09:20:47 +1100 (EST) Subject: What magic did openssh do to handle programs like VIM? In-Reply-To: References: Message-ID: On Mon, 10 Feb 2014, Michael Stone wrote: > On Mon, Feb 10, 2014 at 04:10:03AM -0500, you wrote: > > On Mon, Feb 10, 2014 at 3:39 AM, Aaron Lewis > > wrote: > > > Hi, > > > > > > I'm trying to write my own remote shell program, > > > > *Why*? > > Sometimes, people like to learn things. Right. Before I started porting OpenSSH all those years ago I wrote a rsh-over-TLS remote shell program that is thankfully lost to history. There is no way I would have been able to meaningfully work on sshd without that experience. -d From nkadel at gmail.com Tue Feb 11 10:06:27 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 10 Feb 2014 18:06:27 -0500 Subject: What magic did openssh do to handle programs like VIM? In-Reply-To: References: Message-ID: On Mon, Feb 10, 2014 at 5:20 PM, Damien Miller wrote: > On Mon, 10 Feb 2014, Michael Stone wrote: > >> On Mon, Feb 10, 2014 at 04:10:03AM -0500, you wrote: >> > On Mon, Feb 10, 2014 at 3:39 AM, Aaron Lewis >> > wrote: >> > > Hi, >> > > >> > > I'm trying to write my own remote shell program, >> > >> > *Why*? >> >> Sometimes, people like to learn things. > > Right. Before I started porting OpenSSH all those years ago I wrote a > rsh-over-TLS remote shell program that is thankfully lost to history. > There is no way I would have been able to meaningfully work on sshd > without that experience. And sometimes people don't know what's already available, such as the old telnetd and rshd code, or why it's such a horribly bad idea to use in modern "people's laptops are often rootkitted" packet sniffing environments. So an actual answer "why" would actually be useful. From opensshdev at r.paypc.com Tue Feb 11 17:03:44 2014 From: opensshdev at r.paypc.com (Morham) Date: Mon, 10 Feb 2014 22:03:44 -0800 Subject: What magic did openssh do to handle programs like VIM? In-Reply-To: References: Message-ID: <52F9BD40.1030205@r.paypc.com> On 2/10/2014 3:06 PM, Nico Kadel-Garcia wrote: > And sometimes people don't know what's already available, such as the > old telnetd and rshd code, or why it's such a horribly bad idea to use > in modern "people's laptops are often rootkitted" packet sniffing > environments. So an actual answer "why" would actually be useful. I'd say it's safe to assume that the original poster is well aware of the existence of OpenSSH for what I hope are obvious reasons. It is not useless to undertake "ground-up" investigation into how to do things "properly" by referencing "reference" documentation, if there is even such a thing in today's chaotic open source development environment. I actually "cringe" when I see young engineers just surrendering intellectual capital to "copy-and-paste" methodologies. It's always useless to KNOW WHY & HOW, rather than just "from where to copy" something. There is little doubt that your first efforts will be buggy and insecure. But you'll learn many things, and their value may not be immediately apparent to you for some time. =R= From the.warl0ck.1989 at gmail.com Tue Feb 11 22:13:32 2014 From: the.warl0ck.1989 at gmail.com (Aaron Lewis) Date: Tue, 11 Feb 2014 19:13:32 +0800 Subject: [SOLVED] Re: What magic did openssh do to handle programs like VIM? Message-ID: Hi Darren, As you suggested, I've incorporated pty and enabled raw mode in my client program. VIM runs fine ;-P Now I only need to pass in the terminal window size and handle several signals Thanks for the heads up! On Mon, Feb 10, 2014 at 4:59 PM, Darren Tucker wrote: > On Mon, Feb 10, 2014 at 7:39 PM, Aaron Lewis wrote: >> I'm trying to write my own remote shell program, > [...] >> 2. If I run command like VIM, it doesn't run. >> And buttons like ":q" won't work >> >> Can someone enlighten me about what SSH did, so it all works perfectly? > > Pseudo terminals: http://en.wikipedia.org/wiki/Pseudo_terminal. ssh > asks sshd for one when you run an interactive shell (eg "ssh > yourserver") or you use the -t flag. You can run vim via ssh without > a pty and it'll behave like your application: "ssh server vim > somefile". > > If you can find a copy of Stevens' Advanced Programming in the Unix > Environment it's got a chapter on PTYs that's pretty good. Failing > that, take a look at the openpty man page and the code in openssh's > sshpty.c. > > if you don't have openpty then your task just got harder because it's > quite platform-specific; take a look in openbsd-compat/bsd-openpty.c. > > -- > 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. -- Best Regards, Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/ Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33 From peter at stuge.se Wed Feb 12 05:37:11 2014 From: peter at stuge.se (Peter Stuge) Date: Tue, 11 Feb 2014 19:37:11 +0100 Subject: [SOLVED] Re: What magic did openssh do to handle programs like VIM? In-Reply-To: References: Message-ID: <20140211183711.22434.qmail@stuge.se> Aaron Lewis wrote: > As you suggested, I've incorporated pty and enabled raw mode in my > client program. > VIM runs fine ;-P What happens when you use a different terminal emulator? //Peter From hkario at redhat.com Thu Feb 13 05:37:41 2014 From: hkario at redhat.com (Hubert Kario) Date: Wed, 12 Feb 2014 13:37:41 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> Message-ID: <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Damien Miller" > To: "Hubert Kario" > Cc: openssh-unix-dev at mindrot.org > Sent: Tuesday, 4 February, 2014 11:42:31 PM > Subject: Re: 3des cipher and DH group size > > On Tue, 4 Feb 2014, Hubert Kario wrote: > > > Hi all! > > > > Continuing the discussion from > > https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032037.html > > > > I have looked at the changes made to implement automatic selection of DH > > groups and there are few changes confusing to me, to say the least. > > > > Especially 1.97~1.96 rev diff of kex.c: > > > > > + dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher)); > > > > Why "MAX("? Why security of chosen dh moduli should match the _most_ > > secure primitive? Since DH KEX is computationally expensive (think > > smartphones), > > shouldn't we try to use as small DH parameters as possible? > > I think that it's reasonable for users, when they select a cipher of a > given strength, to expect that ssh actually provides enough key material > to properly use it. The previous version did bind cipher to DH sizes so this expectation was met. Problem is, that now when you're running in FIPS mode the chosen HMAC in worst case is sha1-based so the DH moduli end up being 7680 bits in size even when the selected cipher is 3DES: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent as a result, connection to cryptlib server in FIPS mode doesn't work. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team http://wiki.brq.redhat.com/hkario Email: hkario at redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From djm at mindrot.org Thu Feb 13 15:08:15 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 13 Feb 2014 15:08:15 +1100 (EST) Subject: 3des cipher and DH group size In-Reply-To: <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> Message-ID: On Wed, 12 Feb 2014, Hubert Kario wrote: > The previous version did bind cipher to DH sizes so this expectation was > met. Yes, but using obsolete symmetric/DH group size equivalences. > Problem is, that now when you're running in FIPS mode the chosen HMAC > in worst case is sha1-based so the DH moduli end up being 7680 bits in > size even when the selected cipher is 3DES: Which is the correct recommended length for a 160-bit key according to NIST. (It's ironic that you're effectively arguing to ignore NIST advice to make FIPS mode work) > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent > > as a result, connection to cryptlib server in FIPS mode doesn't work. We can't help other broken implementations. Easy workarounds include using ECDH and specifying explicit KexAlgorithms. -d From hkario at redhat.com Thu Feb 13 22:38:06 2014 From: hkario at redhat.com (Hubert Kario) Date: Thu, 13 Feb 2014 06:38:06 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> Message-ID: <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Damien Miller" > To: "Hubert Kario" > Cc: openssh-unix-dev at mindrot.org, dtucker at zip.com.au, "Petr Lautrbach" > Sent: Thursday, 13 February, 2014 5:08:15 AM > Subject: Re: 3des cipher and DH group size > > On Wed, 12 Feb 2014, Hubert Kario wrote: > > > The previous version did bind cipher to DH sizes so this expectation was > > met. > > Yes, but using obsolete symmetric/DH group size equivalences. By "previous" I mean the version of the patch that didn't effectively use HMAC key size as the requested DH param size. I do not mean the previous version of OpenSSH. Let me be clear: what I want to see is 2048 bit DH when 3des is selected, 3072 bit DH when AES-128 is selected and 7680 bit DH when AES-192 is selected. I also very much like that the new OpenSSH uses better algorithms for selecting the DH key size. But we also have to remember that openssh is not used in a vacuum, so interoperability is just as important as security. If I'm forced to use old version of OpenSSH (possibly with known bugs) to connect to a server that implements only a small subset of crypto OpenSSH is able to use, all this work is for nought. > > Problem is, that now when you're running in FIPS mode the chosen HMAC > > in worst case is sha1-based so the DH moduli end up being 7680 bits in > > size even when the selected cipher is 3DES: > > Which is the correct recommended length for a 160-bit key according to > NIST. It would be recommended if we were talking about symmetric encryption. But we're talking about MAC. See NIST SP 800-57, rev 3, pages 63-65. Table 2: Appropriate D-H parameter size for 3DES (112 bits) is 2048, for AES-128 is 3072. Now, if you take a look at Table 3, you can see that if you want to use appropriate HMAC with those symmetric algorithms you can use *any* SHA-family hash, from SHA-1 up to SHA512. Reading further, section 5.6.3, if I use SHA-512 HMAC with 2048 bit RSA keys and AES-128 cipher I don't magically get a system with 512 bits of security. I get a system that has only 112 bits of security (see point 1 and 2 therein) because 2048 bit RSA is the weakest link. So like I already said, there is no point in choosing DH parameters based on security of the most secure primitive used, because it does not increase the security of the system as whole. What we *need* to do is make sure that the chosen DH parameters don't *lower* the security of the system. > > (It's ironic that you're effectively arguing to ignore NIST advice to > make FIPS mode work) SP 800-57 rev 3, section 5.6.1 Comparable Algorithm Strengths, point 3: > Column 3 indicates the minimum size of the parameters associated > with the standards that use finite-field cryptography (FFC). Examples > of such algorithms include DSA as defined in [FIPS186] for digital > signatures, and Diffie-Hellman (DH) and MQV key agreement as defined > in [SP800-56A], where L is the size of the public key, and N is the > size of the private key. The largest key size *approved* in [FIPS186] > is (L = 3072, N = 256), and the largest key size *approved* in > [SP800-56A] is (L = 2048, N = 256). As you can see, any DH over 3072 bit in size is *not* FIPS compliant. So while I think that introducing a top bound (especially such low) for a crypto system is excessive, cryptlib refusing 7680 bit DH is in the clear as far as FIPS is concerned. > > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent > > > > as a result, connection to cryptlib server in FIPS mode doesn't work. > > We can't help other broken implementations. > > Easy workarounds include using ECDH and specifying explicit KexAlgorithms. Problem is, it doesn't support ECC. And while it can be argued that it is broken (protocol-wise), it still can be used securely according to the newest standards. As for security estimation of truncated HMAC and using key vs using the hmac output size I recommend reading SP 800-107, section 5.1 in particular: > Truncating the message digest can impact the security of an application. By > truncating a message digest, the expected collision resistance strength is > reduced from L/2 to ?/2 (in bits). For the example in item 2 above, even > though SHA-256 provides 128 bits of collision resistance, the collision > resistance provided by the 96-bit truncated message digest is half the > length of the truncated message digest, which is 48 bits, in this case. > The truncated message digest of ? bits provides an expected preimage > resistance of ? bits, not L bits, regardless of the hash function used. So using only the key size as the security estimate of HMACs is completely wrong! -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From saku at ytti.fi Fri Feb 14 01:22:22 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 13 Feb 2014 16:22:22 +0200 Subject: IPQoS Message-ID: <20140213142222.GA20018@pob.ytti.fi> Real networks use either PREC (as it maps 1:1 to 802.1p and MPLS TC) or DSCP. Interactive SSH uses PREC 0x0, which is just best-effort and DSCP 0x4 which has no standard meaning (found network where DSCP 0x4 was dropped, completely, as it didn't hit any defined/allowed QoS class, obviously misconfig, BE class should eat anything not already defined) Should interactive use TOS value which has highest chance for priority behaviour? If so, then PREC 5 == DSCP CS5 is best bet. -- ++ytti From chris at qwirx.com Fri Feb 14 01:42:43 2014 From: chris at qwirx.com (Chris Wilson) Date: Thu, 13 Feb 2014 14:42:43 +0000 (GMT) Subject: IPQoS In-Reply-To: <20140213142222.GA20018@pob.ytti.fi> References: <20140213142222.GA20018@pob.ytti.fi> Message-ID: Hi Saku, On Thu, 13 Feb 2014, Saku Ytti wrote: > Real networks use either PREC (as it maps 1:1 to 802.1p and MPLS TC) or > DSCP. Interactive SSH uses PREC 0x0, which is just best-effort and DSCP > 0x4 which has no standard meaning (found network where DSCP 0x4 was > dropped, completely, as it didn't hit any defined/allowed QoS class, > obviously misconfig, BE class should eat anything not already defined) > > Should interactive use TOS value which has highest chance for priority > behaviour? If so, then PREC 5 == DSCP CS5 is best bet. To my knowledge, DSCP code points have no predefined global interpretation. Their actual interpretation depends on network policy of the network where they are found. The only way to set a sensible DSCP on SSH packets is to make the actual code point configurable, so that admins can configure it according to their site policy. Because of that, there is no universal agreement (and can never be) on the meanings of TOS flags or DSCP code points when packets move between networks. One must understand the DSCP/TOS assignment of each network that one connects to, and remap inbound packets to conform to one's own policy. Since this is a complete and utter nightmare of impossibility, virtually nobody has actually done it. I've never seen a packet tagged with a DSCP code point inbound to my networks. Admittedly I haven't been looking very hard, but I do use TOS bits extensively. Because, since DSCP is useless between networks, an informal ad-hoc "standard" based on the old TOS values has evolved and is in widespread use (but certainly not universal), despite the IETF's best (not very good) effort to "kill it off" by redefining the bits with incompatible meanings in DSCP and ECN. OpenSSH is conforming to this "informal standard", and with its huge installed user base, helping to define it as well. It already does set a high-priority TOS flag on interactive sessions, and low-priority on non-interactive ones: * https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1067522 * http://www.gossamer-threads.com/lists/openssh/dev/48410 Until the ability to set a user-defined DSCP is implemented, you would need to remap outgoing packets on your SSH clients and servers to change the TOS flags into DSCP code points according to your site policies. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \__/_/_/_//_/___/ | We are GNU : free your mind & your software | From saku at ytti.fi Fri Feb 14 02:32:48 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 13 Feb 2014 17:32:48 +0200 Subject: IPQoS In-Reply-To: References: <20140213142222.GA20018@pob.ytti.fi> Message-ID: <20140213153248.GA30542@pob.ytti.fi> On (2014-02-13 14:42 +0000), Chris Wilson wrote: Hi Chris, > To my knowledge, DSCP code points have no predefined global > interpretation. Their actual interpretation depends on network There are well agreed, commonly used BE, AF, EF, NC. But in Internet between sensible AS numbers all packets are handled as BE regardless of markings (You don't want Internet DoS to kill your Voice) > OpenSSH is conforming to this "informal standard", and with its huge > installed user base, helping to define it as well. It already does > set a high-priority TOS flag on interactive sessions, and > low-priority on non-interactive ones: I've never ever seen DSCP 0x4 used for anything. And PREC 0 is BE. I also can't right now remember buying QoS from company which didn't by default map PREC 5/CS5 to high-priorioty/low-delay (it's used often by default in phones and conferencing systems). So if you're not going for DSCP 0x0, you should go with 0x28, i.e. CS5, and it would work in vast majority of networks which implement QoS, out of the box. -- ++ytti From chris at qwirx.com Fri Feb 14 02:51:39 2014 From: chris at qwirx.com (Chris Wilson) Date: Thu, 13 Feb 2014 15:51:39 +0000 (GMT) Subject: IPQoS In-Reply-To: <20140213153248.GA30542@pob.ytti.fi> References: <20140213142222.GA20018@pob.ytti.fi> <20140213153248.GA30542@pob.ytti.fi> Message-ID: Hi Saku, On Thu, 13 Feb 2014, Saku Ytti wrote: >> OpenSSH is conforming to this "informal standard", and with its huge >> installed user base, helping to define it as well. It already does set >> a high-priority TOS flag on interactive sessions, and low-priority on >> non-interactive ones: > > I've never ever seen DSCP 0x4 used for anything. That's because it's not a DSCP at all. It would be 000001 in the "Experimental or Local Use" block, and it has no standardised meaning in DSCP at the moment. What it is, is TOS 0x4 or "High Reliability" (which I take to mean as "we want this packet delivered, no matter how late). But OpenSSH apparently doesn't use it. According to djm, it uses IPTOS_THROUGHPUT which is 0x8 not 0x4. . (It would be 0x4 if you disregard the "must be 0" field and shift the TOS value one bit to the right). And according to the Linux manual page: "IP_TOS (since Linux 1.0) Set or receive the Type-Of-Service (TOS) field that is sent with every IP packet originating from this socket. It is used to prioritize packets on the network. TOS is a byte. There are some standard TOS flags defined: IPTOS_LOWDELAY to minimize delays for interactive traffic, IPTOS_THROUGHPUT to optimize throughput..." Nothing about DSCP there. IETF's attempt to kill it notwithstanding, this is what people actually use on the Internet. > And PREC 0 is BE. If you pay attention to PREC, which I don't think anyone does. I've never seen a packet with PREC bits set either. But I get plenty of packets with TOS bits set. > I also can't right now remember buying QoS from company which didn't by > default map PREC 5/CS5 to high-priorioty/low-delay (it's used often by > default in phones and conferencing systems). So if you're not going for > DSCP 0x0, you should go with 0x28, i.e. CS5, and it would work in vast > majority of networks which implement QoS, out of the box. And what networks are those? I don't think you can buy a connection that actually uses QoS in the UK unless you buy both ends and install your own routers on them. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \__/_/_/_//_/___/ | We are GNU : free your mind & your software | From saku at ytti.fi Fri Feb 14 03:15:11 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 13 Feb 2014 18:15:11 +0200 Subject: IPQoS In-Reply-To: References: <20140213142222.GA20018@pob.ytti.fi> <20140213153248.GA30542@pob.ytti.fi> Message-ID: <20140213161511.GA3511@pob.ytti.fi> On (2014-02-13 15:51 +0000), Chris Wilson wrote: Hi Chris, > That's because it's not a DSCP at all. It would be 000001 in the > "Experimental or Local Use" block, and it has no standardised > meaning in DSCP at the moment. In real networks TOS is either read as PREC or DSCP. So in real networks it's either PREC 0 or DSCP 0x4. Neither seem desirable. > What it is, is TOS 0x4 or "High Reliability" (which I take to mean > as "we want this packet delivered, no matter how late). > > But OpenSSH apparently doesn't use it. According to djm, it uses > IPTOS_THROUGHPUT which is 0x8 not 0x4. SCP/SFTP should be different than interactive, according to docs. So Interactive definitely is /DSCP/ 0x4 or PREC 0. You can easily check this in tshar: [ytti at ytti.fi ~]% sudo tshark -Vc 3 port 22|grep DSCP Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) > Nothing about DSCP there. IETF's attempt to kill it notwithstanding, > this is what people actually use on the Internet. No. This type of marking is not used. > If you pay attention to PREC, which I don't think anyone does. I've > never seen a packet with PREC bits set either. But I get plenty of > packets with TOS bits set. As PREC is 3 bits, which is only thing you have in 802.1p and MPLS TC, it's very commonly used. Both PREC and DSCP are common, nothing else is in practical terms ever used. And PREC+DSCP have same meaning for the left most 5 bits. > And what networks are those? I don't think you can buy a connection > that actually uses QoS in the UK unless you buy both ends and > install your own routers on them. In UK you can talk to BT. If you'll setup NNI there and ask in RFQ for their QoS, I'm sure you'll find what I said applies. -- ++ytti From saku at ytti.fi Fri Feb 14 03:17:00 2014 From: saku at ytti.fi (Saku Ytti) Date: Thu, 13 Feb 2014 18:17:00 +0200 Subject: IPQoS In-Reply-To: <20140213161511.GA3511@pob.ytti.fi> References: <20140213142222.GA20018@pob.ytti.fi> <20140213153248.GA30542@pob.ytti.fi> <20140213161511.GA3511@pob.ytti.fi> Message-ID: <20140213161700.GB3511@pob.ytti.fi> On (2014-02-13 18:15 +0200), Saku Ytti wrote: > As PREC is 3 bits, which is only thing you have in 802.1p and MPLS TC, it's > very commonly used. > Both PREC and DSCP are common, nothing else is in practical terms ever used. > And PREC+DSCP have same meaning for the left most 5 bits. excuse the typo, I hope it was obvious s/left most 5 bits/left most 3 bits/ -- ++ytti From mikep at noc.utoronto.ca Fri Feb 14 04:40:04 2014 From: mikep at noc.utoronto.ca (mikep at noc.utoronto.ca) Date: Thu, 13 Feb 2014 12:40:04 -0500 (EST) Subject: openssh-6.5p1 on Solaris 10 - segmentation fault Message-ID: I just installed 'openssh-6.5p1' on a Solaris 10 system, and when attempting to 'ssh' anywhere as anybody from the 'root' account, I get a segmentation fault. Debug output as 'root': kraken:/opt/local/src/security/openssh-6.5p1# ./ssh -vvv mimir OpenSSH_6.5, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc] debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc] debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc] debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc] debug3: ciphers ok: [aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc] debug3: kex names ok: [diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1] debug1: /etc/ssh/ssh_config line 57: Applying options for * debug3: RNG is ready, skipping seeding debug2: ssh_connect: needpriv 1 debug1: Connecting to mimir [XXX.XXX.XXX.XXX] port 22. Segmentation fault Debug as regular user: kraken:~> /opt/local/src/security/openssh-6.5p1/ssh -vvv mimir OpenSSH_6.5, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc] debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc] debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc] debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc] debug3: ciphers ok: [aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc] debug3: kex names ok: [diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1] debug1: /etc/ssh/ssh_config line 57: Applying options for * debug3: RNG is ready, skipping seeding debug2: ssh_connect: needpriv 0 debug1: Connecting to nemo [XXX.XXX.XXX.XXX] port 22. debug1: Connection established. debug1: could not open key file '/etc/ssh/ssh_host_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_dsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ed25519_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_dsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ed25519_key': Permission denied debug1: identity file /home/mikep/.ssh/id_rsa type -1 debug1: identity file /home/mikep/.ssh/id_rsa-cert type -1 debug1: identity file /home/mikep/.ssh/id_dsa type -1 debug1: identity file /home/mikep/.ssh/id_dsa-cert type -1 debug1: identity file /home/mikep/.ssh/id_ecdsa type -1 debug1: identity file /home/mikep/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/mikep/.ssh/id_ed25519 type -1 debug1: identity file /home/mikep/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.5 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.4 debug1: match: OpenSSH_6.4 pat OpenSSH* compat 0x04000000 'ssh' does appear to work as a regular user, but all the Cisco SSH connections hang again; haven't had time to investigate what combinations of ciphers and key exchange methods work with the latest version, if any. With the new version it hangs at: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP Version 6.4 shows: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY Any ideas? Thanks, Mike -- Mike Peterson Information Security Analyst - Audit E-mail: mikep at noc.utoronto.ca WWW: http://www.noc.utoronto.ca/ Tel: 416-978-5230 Fax: 416-978-6620 From mancha1 at hush.com Fri Feb 14 07:16:30 2014 From: mancha1 at hush.com (mancha) Date: Thu, 13 Feb 2014 20:16:30 +0000 (UTC) Subject: 3des cipher and DH group size References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> Message-ID: Hubert Kario redhat.com> writes: > [SNIP] Hi. I've identified three distinct points you've made so far; here are my brief reactions: 1. IV length and block size should not be taken into account for DH GEX group size computation. I'll leave the particulars of birthday collisions and how they link IV length and block size to security level as an exercise to the reader. 2. DH GEX group size requests should be as minimal as possible to accommodate the limited computing power of embedded devices (e.g. smartphones) I would be extremely uncomfortable if security infrastructure I relied on constrained its cryptographic primitives - potentially to the detriment of overall security - in order to facilitate use with phones, consumer-grade routers, or other devices characterized by limited processing power. 3. OpenSSH primitives should be confined to ensure interoperability with implementations that are RFC non-compliant (e.g. cryptlib & DH GEX & RFC 4419). What's the point of standards then? --- I personally would like larger increases in DH GEX requests. NIST SP 800-57, the basis for the OpenSSH change, recommends a value well above 8192 bits (which OpenSSH sets as a hard max following RFC 4419) when supporting 256 bits of security. Not to mention that other research initiatives (e.g. ECRYPT II) recommend even larger DH group sizes than NIST at every security level. Finally, if HW/SW limitations of embedded devices or non-compliant servers is of major concern and you want to force a 2048-bit DH modulus, why not use Oakley group 14? That's an RFC 4253 REQUIRED. --mancha From scott_n at xypro.com Fri Feb 14 10:02:44 2014 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 13 Feb 2014 23:02:44 +0000 Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> Message-ID: >Hubert Kario redhat.com> writes: > >> [SNIP] > >3. OpenSSH primitives should be confined to ensure interoperability with implementations that are RFC non-compliant (e.g. cryptlib & DH GEX & RFC 4419). > >What's the point of standards then? Maybe a ssh_config option for DH GEX group size, so that people like Hubert can configure SSH such implementations? From djm at mindrot.org Fri Feb 14 11:10:17 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 14 Feb 2014 11:10:17 +1100 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> Message-ID: On Thu, 13 Feb 2014, Scott Neugroschl wrote: > >Hubert Kario redhat.com> writes: > > > >> [SNIP] > > > >3. OpenSSH primitives should be confined to ensure interoperability > > with implementations that are RFC non-compliant (e.g. cryptlib & > > DH GEX & RFC 4419). > > > >What's the point of standards then? > > Maybe a ssh_config option for DH GEX group size, so that people like > Hubert can configure SSH such implementations? You can do this now by editing /etc/ssh/moduli Also KexAlgorithms=diffie-hellman-group14-sha1 -d From dtucker at zip.com.au Fri Feb 14 13:03:04 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 14 Feb 2014 13:03:04 +1100 Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> Message-ID: On Fri, Feb 14, 2014 at 11:10 AM, Damien Miller wrote: > On Thu, 13 Feb 2014, Scott Neugroschl wrote: [...] >> Maybe a ssh_config option for DH GEX group size, so that people like >> Hubert can configure SSH such implementations? > > You can do this now by editing /etc/ssh/moduli That'll only work on the server side. > Also KexAlgorithms=diffie-hellman-group14-sha1 That'll work. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From hkario at redhat.com Sat Feb 15 02:31:21 2014 From: hkario at redhat.com (Hubert Kario) Date: Fri, 14 Feb 2014 10:31:21 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> Message-ID: <1802254039.3475993.1392391881578.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "mancha" > To: openssh-unix-dev at mindrot.org > Sent: Thursday, 13 February, 2014 9:16:30 PM > Subject: Re: 3des cipher and DH group size > > Hubert Kario redhat.com> writes: > > > [SNIP] > > Hi. > > I've identified three distinct points you've made so far; > here are my brief reactions: > > 1. IV length and block size should not be taken into > account for DH GEX group size computation. > > I'll leave the particulars of birthday collisions and how > they link IV length and block size to security level as an > exercise to the reader. "Proving that P is equal NP is trivial and left as an exercise to the reader" I already asked for literature on the subject. No book or standard I read stated anything to the effect of "IV size" == "security estimate". Suite B for secret (effectively 128 bit security) communication allows use of AES only in GCM or CTR mode. RFC 6239 specifies that SSH in Suite B must use AES in GCM mode. IV of AES 128 in GCM mode as used in SSH is 12 octets (96bit). How do you explain this disparity? > 2. DH GEX group size requests should be as minimal as > possible to accommodate the limited computing power of > embedded devices (e.g. smartphones) > > I would be extremely uncomfortable if security > infrastructure I relied on constrained its cryptographic > primitives - potentially to the detriment of overall > security - in order to facilitate use with phones, > consumer-grade routers, or other devices characterized > by limited processing power. People have been doing that for the past 60 years in cryptography. 95% of Internet still uses SHA-1 certificates! Including online banking. All my suggestions are already way past the levels any normal person or business needs. Those people that actually require higher security won't be using defaults if they have any clue what so ever. I want the defaults to be relatively secure and provide maximum interoperability. > 3. OpenSSH primitives should be confined to ensure > interoperability with implementations that are RFC > non-compliant (e.g. cryptlib & DH GEX & RFC 4419). > > What's the point of standards then? The FIPS limits the size of parameters exactly for interoperability reasons. If there was no need for key size agreement, we would all be using hardcoded 8k or 16k DH. And I'm not saying they should be confined. I'm saying that the proposed values shouldn't effectively depend on the MAC key size. > > --- > > I personally would like larger increases in DH GEX > requests. NIST SP 800-57, the basis for the OpenSSH > change, recommends a value well above 8192 bits (which > OpenSSH sets as a hard max following RFC 4419) when > supporting 256 bits of security. Not to mention that > other research initiatives (e.g. ECRYPT II) recommend > even larger DH group sizes than NIST at every security > level. Security levels above 128 bit realistically have any meaning only if algorithms are broken or quantum computers come into play. In both cases all bets are off. At 128 bit ECRYPT II recommends 3248 bit DH, not 7168. ENISA also recommends 3072 bit DH at 128 bit security level[1]. > Finally, if HW/SW limitations of embedded devices or > non-compliant servers is of major concern and you want to > force a 2048-bit DH modulus, why not use Oakley group 14? > That's an RFC 4253 REQUIRED. That was the first thing I tried, unfortunately, not supported by the cryptlib server in question. 1 - https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From hkario at redhat.com Sat Feb 15 02:37:36 2014 From: hkario at redhat.com (Hubert Kario) Date: Fri, 14 Feb 2014 10:37:36 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> Message-ID: <1596206452.3480877.1392392256921.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Damien Miller" > To: "Scott Neugroschl" > Cc: "mancha" , openssh-unix-dev at mindrot.org > Sent: Friday, 14 February, 2014 1:10:17 AM > Subject: RE: 3des cipher and DH group size > > On Thu, 13 Feb 2014, Scott Neugroschl wrote: > > > >Hubert Kario redhat.com> writes: > > > > > >> [SNIP] > > > > > >3. OpenSSH primitives should be confined to ensure interoperability > > > with implementations that are RFC non-compliant (e.g. cryptlib & > > > DH GEX & RFC 4419). > > > > > >What's the point of standards then? > > > > Maybe a ssh_config option for DH GEX group size, so that people like > > Hubert can configure SSH such implementations? While not ideal, it would provide at least some workaround not requiring recompilation of ssh. > > You can do this now by editing /etc/ssh/moduli Why should I edit system wide config file when I want to connect to one specific server?! > > Also KexAlgorithms=diffie-hellman-group14-sha1 not supported by the server -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From mancha1 at hush.com Sat Feb 15 03:32:16 2014 From: mancha1 at hush.com (mancha) Date: Fri, 14 Feb 2014 16:32:16 +0000 (UTC) Subject: 3des cipher and DH group size References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> <1802254039.3475993.1392391881578.JavaMail.zimbra@redhat.com> Message-ID: Hubert Kario redhat.com> writes: > > I'll leave the particulars of birthday collisions and how > > they link IV length and block size to security level as an > > exercise to the reader. > > "Proving that P is equal NP is trivial and left as an exercise > to the reader" > > I already asked for literature on the subject. No book or standard > I read stated anything to the effect of "IV size" == "security estimate". P=NP is still unsolved. Having more pigeons than holes is not. > > I would be extremely uncomfortable if security > > infrastructure I relied on constrained its cryptographic > > primitives - potentially to the detriment of overall > > security - in order to facilitate use with phones, > > consumer-grade routers, or other devices characterized > > by limited processing power. > > People have been doing that for the past 60 years in cryptography. > > 95% of Internet still uses SHA-1 certificates! Including > online banking. Poor cryptographic decisions should be corrected not emulated and perpetuated. > All my suggestions are already way past the levels any normal person or > business needs. Those people that actually require higher > security won't be using defaults if they have any clue > what so ever. > > I want the defaults to be relatively secure and provide maximum > interoperability. Who knows what "normal person" or "relatively secure" mean. That's why we develop standards and objective guidelines instead. > Security levels above 128 bit realistically have any meaning > only if algorithms are broken or quantum computers > come into play. > > In both cases all bets are off. That's a longer debate. My point is OpenSSH already deviates its equivalences downwards from NIST recommendations at the high end of the spectrum. > At 128 bit ECRYPT II recommends 3248 bit DH, not 7168. > ENISA also recommends 3072 bit DH at 128 bit security level[1]. At 128 bits of security, NIST recommends 3072 bit DH and ECRYPT II recommends 3248 bit DH. if(3248>3072) printf("math is nice\n"); > > Finally, if HW/SW limitations of embedded devices or > > non-compliant servers is of major concern and you want to > > force a 2048-bit DH modulus, why not use Oakley group 14? > > That's an RFC 4253 REQUIRED. > > That was the first thing I tried, unfortunately, not supported by > the cryptlib server in question. Sorry to hear cryptlib breaks yet another RFC. RFC 4253 requires Oakley group 14 support. --mancha From hkario at redhat.com Sat Feb 15 05:19:04 2014 From: hkario at redhat.com (Hubert Kario) Date: Fri, 14 Feb 2014 13:19:04 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> <1802254039.3475993.1392391881578.JavaMail.zimbra@redhat.com> Message-ID: <1677660397.3569979.1392401944399.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "mancha" > To: openssh-unix-dev at mindrot.org > Sent: Friday, 14 February, 2014 5:32:16 PM > Subject: Re: 3des cipher and DH group size > > Hubert Kario redhat.com> writes: > > > I'll leave the particulars of birthday collisions and how > > > they link IV length and block size to security level as an > > > exercise to the reader. > > > > "Proving that P is equal NP is trivial and left as an exercise > > to the reader" > > > > I already asked for literature on the subject. No book or standard > > I read stated anything to the effect of "IV size" == "security estimate". > > P=NP is still unsolved. Having more pigeons than holes is not. You're telling one thing, multiple established standards tell another. If this was as easy as pigeonhole principle, someone would have called it by now. So unless you have at least one paper with hard math that says the same thing, I'm saying "not true". > > > I would be extremely uncomfortable if security > > > infrastructure I relied on constrained its cryptographic > > > primitives - potentially to the detriment of overall > > > security - in order to facilitate use with phones, > > > consumer-grade routers, or other devices characterized > > > by limited processing power. > > > > People have been doing that for the past 60 years in cryptography. > > > > 95% of Internet still uses SHA-1 certificates! Including > > online banking. > > Poor cryptographic decisions should be corrected not emulated and > perpetuated. People's lives depend on security of systems that at best provide 80 bit of security. I'm saying that there is no point of using anything past 128 bit with default settings if this hampers interoperability. That's a 281474976710656 times difference! You really don't see that? > > All my suggestions are already way past the levels any normal person or > > business needs. Those people that actually require higher > > security won't be using defaults if they have any clue > > what so ever. > > > > I want the defaults to be relatively secure and provide maximum > > interoperability. > > Who knows what "normal person" or "relatively secure" mean. That's > why we develop standards and objective guidelines instead. "normal person" - people that don't know about existence or purpose of /etc/ssh/moduli "relatively secure" - 128bit, a.k.a. SECRET as used by NATO. Using 7k DH with 3DES and AES-128 is not the effect of those guidelines. > > Security levels above 128 bit realistically have any meaning > > only if algorithms are broken or quantum computers > > come into play. > > > > In both cases all bets are off. > > That's a longer debate. My point is OpenSSH already deviates > its equivalences downwards from NIST recommendations at the high > end of the spectrum. thing is, that the high end of the spectrum is not important to normal people. And if you need 256 bit security you'll have to use ECC anyway. As such, SSH's DH KEX inability to work with anything that provides more than 128bit or 192bit of security is moot anyway. > > At 128 bit ECRYPT II recommends 3248 bit DH, not 7168. > > ENISA also recommends 3072 bit DH at 128 bit security level[1]. > > At 128 bits of security, NIST recommends 3072 bit DH and ECRYPT > II recommends 3248 bit DH. > > if(3248>3072) printf("math is nice\n"); that's less than 4 bit difference in security level, you really want to argue about "times 16" difference? OK, then let's round ECRYPT II recommendations up and use them like this: 3des - 3072 bit DH aes-128 - 4096 bit DH aes-192 - 8192 bit DH aes-256 - 8192 bit DH (because of protocol limitations) That will be compatible with such broken implementations when using 2 popular block ciphers and still provide more security than old versions of OpenSSH and meet NIST recommendations in all cases but aes-256. > > > Finally, if HW/SW limitations of embedded devices or > > > non-compliant servers is of major concern and you want to > > > force a 2048-bit DH modulus, why not use Oakley group 14? > > > That's an RFC 4253 REQUIRED. > > > > That was the first thing I tried, unfortunately, not supported by > > the cryptlib server in question. > > Sorry to hear cryptlib breaks yet another RFC. RFC 4253 requires > Oakley group 14 support. I'm not saying that it is RFC compliant. I'm saying that openssh can interoperate with it without compromising security. -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From mancha1 at hush.com Sat Feb 15 05:49:21 2014 From: mancha1 at hush.com (mancha) Date: Fri, 14 Feb 2014 18:49:21 +0000 (UTC) Subject: 3des cipher and DH group size References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> <1802254039.3475993.1392391881578.JavaMail.zimbra@redhat.com> <1677660397.3569979.1392401944399.JavaMail.zimbra@redhat.com> Message-ID: Hubert Kario redhat.com> writes: > > P=NP is still unsolved. Having more pigeons than holes is not. > > You're telling one thing, multiple established standards tell another. > > If this was as easy as pigeonhole principle, someone would have called it > by now. So unless you have at least one paper with hard math that says > the same thing, I'm saying "not true". http://lmgtfy.com/?q=initialization+vector+birthday+paradox > > Poor cryptographic decisions should be corrected not emulated and > > perpetuated. > > People's lives depend on security of systems that at best provide 80 bit > of security. > > I'm saying that there is no point of using anything past 128 bit > with default settings if this hampers interoperability. > > That's a 281474976710656 times difference! > > You really don't see that? You might be one of the few people left who are advocating for weak cryptographic primitives. Were you also upset when OpenSSL deprecated MD2? > > Who knows what "normal person" or "relatively secure" mean. That's > > why we develop standards and objective guidelines instead. > > "normal person" - people that don't know about existence or purpose > of /etc/ssh/moduli > > "relatively secure" - 128bit, a.k.a. SECRET as used by NATO. > > Using 7k DH with 3DES and AES-128 is not the effect of those guidelines. > I choose standards and objective guidelines over your personal definitions of "relatively secure" and "normal person". > > > At 128 bit ECRYPT II recommends 3248 bit DH, not 7168. > > > ENISA also recommends 3072 bit DH at 128 bit security level[1]. > > > > At 128 bits of security, NIST recommends 3072 bit DH and ECRYPT > > II recommends 3248 bit DH. > > > > if(3248>3072) printf("math is nice\n"); > > that's less than 4 bit difference in security level, you really want > to argue about "times 16" difference? > Huh? My initial statement was that ECRYPT II recommends higher DH bit sizes than NIST at every security level. Why exactly do you keep debating this provable fact? FYI: facts are stubborn things. > > > > > > That was the first thing I tried, unfortunately, not supported by > > > the cryptlib server in question. > > > > Sorry to hear cryptlib breaks yet another RFC. RFC 4253 requires > > Oakley group 14 support. > > I'm not saying that it is RFC compliant. I'm saying that openssh > can interoperate with it without compromising security. Fix what's broken so it works with what's not broken. Don't break things that aren't broken so they work with what's broken. --mancha From djm at mindrot.org Sat Feb 15 10:33:44 2014 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Feb 2014 10:33:44 +1100 (EST) Subject: 3des cipher and DH group size In-Reply-To: <1596206452.3480877.1392392256921.JavaMail.zimbra@redhat.com> References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> <1596206452.3480877.1392392256921.JavaMail.zimbra@redhat.com> Message-ID: On Fri, 14 Feb 2014, Hubert Kario wrote: > > Also KexAlgorithms=diffie-hellman-group14-sha1 > > not supported by the server you tried diffie-hellman-group1-sha1 too? It's mandated by the spec From djm at mindrot.org Sat Feb 15 10:39:39 2014 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Feb 2014 10:39:39 +1100 (EST) Subject: 3des cipher and DH group size In-Reply-To: <1802254039.3475993.1392391881578.JavaMail.zimbra@redhat.com> References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> <1802254039.3475993.1392391881578.JavaMail.zimbra@redhat.com> Message-ID: On Fri, 14 Feb 2014, Hubert Kario wrote: > Suite B for secret (effectively 128 bit security) communication > allows use of AES only in GCM or CTR mode. RFC 6239 > specifies that SSH in Suite B must use AES in GCM mode. > IV of AES 128 in GCM mode as used in SSH is 12 octets (96bit). > > How do you explain this disparity? Since you seem disinclined to go and read about AES-GCM for yourself, I'll point out that the remaining 32 bits are an implicit block counter. See https://tools.ietf.org/html/rfc5647 section 7.1 From openssh-dev at kutek.info Sun Feb 16 15:58:32 2014 From: openssh-dev at kutek.info (openssh-dev at kutek.info) Date: Sat, 15 Feb 2014 23:58:32 -0500 Subject: SSH forwarded NFS has 4GB file size limit...why? Message-ID: <20140216045832.GF5195@verizon.net> standard SSH port forwarding used, but this file size limit appears. NFS mounts not using SSH have no such limits on my machines. any ideas? fractoid From dtucker at zip.com.au Sun Feb 16 21:41:45 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 16 Feb 2014 21:41:45 +1100 Subject: SSH forwarded NFS has 4GB file size limit...why? In-Reply-To: <20140216045832.GF5195@verizon.net> References: <20140216045832.GF5195@verizon.net> Message-ID: On Sun, Feb 16, 2014 at 3:58 PM, wrote: > standard SSH port forwarding used, but this file size limit appears. > > NFS mounts not using SSH have no such limits on my machines. > any ideas? More information is required before anyone could even guess. What versions of are the ssh client and server? Which direction is the forward (ie -L or -R). What platforms are the NFS client and server? A simple port forward test here with the current versions of the client and server and -L with chargen did not show a 4G limit so whatever it is is probably not something obvious. -- 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 manish.jagtap at airtightnetworks.com Mon Feb 17 17:09:20 2014 From: manish.jagtap at airtightnetworks.com (Manish Jagtap) Date: Mon, 17 Feb 2014 11:39:20 +0530 Subject: [ DRAFT PATCH ] - FIPS 140-2 patch for OpenSSH 6.5p1 Message-ID: <2977089f92c3694b8d6c506fef3e3639@mail.gmail.com> Hi, Here is FIPS 140-2 patch for OpenSSH 6.5p1. Since our expertise in OpenSSH code is limited, request moderators to validate this patch and update as required. Regards, Manish Jagtap From marquess at opensslfoundation.com Mon Feb 17 23:05:07 2014 From: marquess at opensslfoundation.com (Steve Marquess) Date: Mon, 17 Feb 2014 07:05:07 -0500 Subject: [ DRAFT PATCH ] - FIPS 140-2 patch for OpenSSH 6.5p1 In-Reply-To: <2977089f92c3694b8d6c506fef3e3639@mail.gmail.com> References: <2977089f92c3694b8d6c506fef3e3639@mail.gmail.com> Message-ID: <5301FAF3.8020802@opensslfoundation.com> On 02/17/2014 01:09 AM, Manish Jagtap wrote: > Hi, > > > > Here is FIPS 140-2 patch for OpenSSH 6.5p1. Since our expertise in OpenSSH > code is limited, request moderators to validate this patch and update as > required. I didn't see any patch but the following comments apply regardless. For a long time I hoped to see native OpenSSL FIPS module support in OpenSSH. Over the years OSF has prepared a number of patches such as: http://opensslfoundation.com/export/openssh/openssh-6.0p1.fips-revised.patch for interested clients. However, with continuing evolution of OpenSSH and changing FIPS 140-2 requirements such support is becoming increasingly difficult. In order to make any reasonable claim that an application like OpenSSH is "FIPS 140-2 compliant" *all* cryptography used by that application must be implemented in the validated module(s). OpenSSH has always had some inlined cryptography, but the recent introduction of "non-NIST" cryptography exacerbates that issue. Then there is the additional consideration that FIPS 140-2 is only desirable in a context (USG and DoD) where x.509 support is also mandatory. OpenSSH has adopted a different (and more robust) certificate scheme. FIPS 140-2 has always been focused on compliance to a specific ritualized policy and process, and thus is necessarily less secure in an absolute sense, while OpenSSH is focused on real-world security. IMHO that discrepancy will probably continue to grow. So while it remains technically possible to jam the round OpenSSH peg into the square FIPS 140-2 hole, I'm no longer sure it makes sense to attempt it in the baseline OpenSSH. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc From manish.jagtap at airtightnetworks.com Tue Feb 18 00:01:16 2014 From: manish.jagtap at airtightnetworks.com (Manish Jagtap) Date: Mon, 17 Feb 2014 18:31:16 +0530 Subject: [ DRAFT PATCH ] - FIPS 140-2 patch for OpenSSH 6.5p1 In-Reply-To: <5301FAF3.8020802@opensslfoundation.com> References: <2977089f92c3694b8d6c506fef3e3639@mail.gmail.com> <5301FAF3.8020802@opensslfoundation.com> Message-ID: <3512b1340f51a70ee5f1f2bded2715bf@mail.gmail.com> Hi, I am facing some difficulties to attach the patch as a file. Trying now to attach with plain-text email. In addition, here is inline patch draft which is actually based on openssh-6.0p1.fips-revised.patch. I have also submitted via https://bugzilla.mindrot.org/show_bug.cgi?id=2202 Request moderators to validate this patch and update as required. Thanks, Manish --- PATCH START diff -ruN openssh-6.5p1_orig/auth2-hostbased.c openssh-6.5p1_patched/auth2-hostbased.c --- openssh-6.5p1_orig/auth2-hostbased.c 2013-12-31 06:55:41.000000000 +0530 +++ openssh-6.5p1_patched/auth2-hostbased.c 2014-02-06 20:18:02.000000000 +0530 @@ -207,15 +207,15 @@ if (host_status == HOST_OK) { if (key_is_cert(key)) { fp = key_fingerprint(key->cert->signature_key, - SSH_FP_MD5, SSH_FP_HEX); + key_fp_type_select(), SSH_FP_HEX); verbose("Accepted certificate ID \"%s\" signed by " "%s CA %s from %s@%s", key->cert->key_id, - key_type(key->cert->signature_key), fp, + key_fp_type_select(), fp, cuser, lookup); } else { - fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + fp = key_fingerprint(key, key_fp_type_select(), SSH_FP_HEX); verbose("Accepted %s public key %s from %s@%s", - key_type(key), fp, cuser, lookup); + key_fp_type_select(), fp, cuser, lookup); } free(fp); } diff -ruN openssh-6.5p1_orig/auth2-pubkey.c openssh-6.5p1_patched/auth2-pubkey.c --- openssh-6.5p1_orig/auth2-pubkey.c 2013-12-31 06:55:41.000000000 +0530 +++ openssh-6.5p1_patched/auth2-pubkey.c 2014-02-06 20:18:32.000000000 +0530 @@ -213,7 +213,7 @@ if (key_is_cert(key)) { fp = key_fingerprint(key->cert->signature_key, - SSH_FP_MD5, SSH_FP_HEX); + key_fp_type_select(), SSH_FP_HEX); auth_info(authctxt, "%s ID %s (serial %llu) CA %s %s%s%s", key_type(key), key->cert->key_id, (unsigned long long)key->cert->serial, @@ -221,7 +221,7 @@ extra == NULL ? "" : ", ", extra == NULL ? "" : extra); free(fp); } else { - fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + fp = key_fingerprint(key, key_fp_type_select(), SSH_FP_HEX); auth_info(authctxt, "%s %s%s%s", key_type(key), fp, extra == NULL ? "" : ", ", extra == NULL ? "" : extra); free(fp); @@ -365,7 +365,7 @@ continue; if (!key_is_cert_authority) continue; - fp = key_fingerprint(found, SSH_FP_MD5, + fp = key_fingerprint(found, key_fp_type_select(), SSH_FP_HEX); debug("matching CA found: file %s, line %lu, %s %s", file, linenum, key_type(found), fp); @@ -406,7 +406,7 @@ if (key_is_cert_authority) continue; found_key = 1; - fp = key_fingerprint(found, SSH_FP_MD5, SSH_FP_HEX); + fp = key_fingerprint(found, key_fp_type_select(), SSH_FP_HEX); debug("matching key found: file %s, line %lu %s %s", file, linenum, key_type(found), fp); free(fp); @@ -432,7 +432,7 @@ return 0; ca_fp = key_fingerprint(key->cert->signature_key, - SSH_FP_MD5, SSH_FP_HEX); + key_fp_type_select(), SSH_FP_HEX); if (key_in_file(key->cert->signature_key, options.trusted_user_ca_keys, 1) != 1) { diff -ruN openssh-6.5p1_orig/auth.c openssh-6.5p1_patched/auth.c --- openssh-6.5p1_orig/auth.c 2013-06-02 03:11:51.000000000 +0530 +++ openssh-6.5p1_patched/auth.c 2014-02-06 20:19:07.000000000 +0530 @@ -685,7 +685,7 @@ case 1: revoked: /* Key revoked */ - key_fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + key_fp = key_fingerprint(key, key_fp_type_select(), SSH_FP_HEX); error("WARNING: authentication attempt with a revoked " "%s key %s ", key_type(key), key_fp); free(key_fp); diff -ruN openssh-6.5p1_orig/auth-rsa.c openssh-6.5p1_patched/auth-rsa.c --- openssh-6.5p1_orig/auth-rsa.c 2013-07-18 11:42:44.000000000 +0530 +++ openssh-6.5p1_patched/auth-rsa.c 2014-02-06 20:27:36.000000000 +0530 @@ -2,7 +2,7 @@ /* * Author: Tatu Ylonen * Copyright (c) 1995 Tatu Ylonen , Espoo, Finland - * All rights reserved + * All rights reserved * RSA-based authentication. This code determines whether to admit a login * based on RSA authentication. This file also contains functions to check * validity of the host key. @@ -20,7 +20,7 @@ #include #include -#include +#include #include #include @@ -47,6 +47,7 @@ #include "monitor_wrap.h" #include "ssh.h" #include "misc.h" +#include "fips.h" /* import */ extern ServerOptions options; @@ -88,11 +89,14 @@ } int -auth_rsa_verify_response(Key *key, BIGNUM *challenge, u_char response[16]) +auth_rsa_verify_response(Key *key, BIGNUM *challenge, u_char response[MAX_HASH_LEN]) { - u_char buf[32], mdbuf[16]; - MD5_CTX md; + u_char buf[2 * MAX_HASH_LEN], mdbuf[MAX_HASH_LEN]; + const EVP_MD *evp_md; + EVP_MD_CTX md; + int len; + int hash_len; /* don't allow short keys */ if (BN_num_bits(key->rsa->n) < SSH_RSA_MINIMUM_MODULUS_SIZE) { @@ -101,19 +105,29 @@ return (0); } - /* The response is MD5 of decrypted challenge plus session id. */ + hash_len = fips_hash_len(fips_hash_min()); + + /* The response is a hash of decrypted challenge plus session id. + * Normally this is MD5, in FIPS mode a stronger function is used.*/ + + len = BN_num_bytes(challenge); - if (len <= 0 || len > 32) + if (len <= 0 || len > (2 * hash_len)) fatal("auth_rsa_verify_response: bad challenge length %d", len); - memset(buf, 0, 32); - BN_bn2bin(challenge, buf + 32 - len); - MD5_Init(&md); - MD5_Update(&md, buf, 32); - MD5_Update(&md, session_id, 16); - MD5_Final(mdbuf, &md); + + memset(buf, 0, sizeof(buf)); + BN_bn2bin(challenge, buf + 2 * hash_len - len); + + if ((evp_md = fips_EVP_get_digest_min()) == NULL) { + fatal("auth_rsa_verify_response: fips_EVP_get_digest_min failed"); + } + EVP_DigestInit(&md, evp_md); + EVP_DigestUpdate(&md, buf, 2 * hash_len); + EVP_DigestUpdate(&md, session_id, hash_len); + EVP_DigestFinal(&md, mdbuf, NULL); /* Verify that the response is the original challenge. */ - if (timingsafe_bcmp(response, mdbuf, 16) != 0) { + if (timingsafe_bcmp(response, mdbuf, hash_len) != 0) { /* Wrong answer. */ return (0); } @@ -131,7 +145,7 @@ auth_rsa_challenge_dialog(Key *key) { BIGNUM *challenge, *encrypted_challenge; - u_char response[16]; + u_char response[MAX_HASH_LEN]; int i, success; if ((encrypted_challenge = BN_new()) == NULL) @@ -151,7 +165,7 @@ /* Wait for a response. */ packet_read_expect(SSH_CMSG_AUTH_RSA_RESPONSE); - for (i = 0; i < 16; i++) + for (i = 0; i < fips_hash_len(fips_hash_min()); i++) response[i] = (u_char)packet_get_char(); packet_check_eom(); @@ -231,7 +245,7 @@ "actual %d vs. announced %d.", file, linenum, BN_num_bits(key->rsa->n), bits); - fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + fp = key_fingerprint(key, key_fp_type_select(), SSH_FP_HEX); debug("matching key found: file %s, line %lu %s %s", file, linenum, key_type(key), fp); free(fp); diff -ruN openssh-6.5p1_orig/cipher.c openssh-6.5p1_patched/cipher.c --- openssh-6.5p1_orig/cipher.c 2014-01-26 04:07:26.000000000 +0530 +++ openssh-6.5p1_patched/cipher.c 2014-02-07 00:52:15.000000000 +0530 @@ -2,7 +2,7 @@ /* * Author: Tatu Ylonen * Copyright (c) 1995 Tatu Ylonen , Espoo, Finland - * All rights reserved + * All rights reserved * * As far as I am concerned, the code I have written for this software * can be used freely for any purpose. Any derived versions of this @@ -49,6 +49,7 @@ #include "log.h" #include "misc.h" #include "cipher.h" +#include "fips.h" /* compatibility with old or broken OpenSSL versions */ #include "openbsd-compat/openssl-compat.h" @@ -104,8 +105,50 @@ { NULL, SSH_CIPHER_INVALID, 0, 0, 0, 0, 0, 0, NULL } }; +struct Cipher ciphers_fips140_2[] = { + { "none", SSH_CIPHER_NONE, 8, 0, 0, 0, 0, 0, EVP_enc_null }, + { "3des", SSH_CIPHER_3DES, 8, 16, 0, 0, 0, 1, evp_ssh1_3des }, + + { "3des-cbc", SSH_CIPHER_SSH2, 8, 24, 0, 0, 0, 1, EVP_des_ede3_cbc }, + { "aes128-cbc", SSH_CIPHER_SSH2, 16, 16, 0, 0, 0, 1, EVP_aes_128_cbc }, + { "aes192-cbc", SSH_CIPHER_SSH2, 16, 24, 0, 0, 0, 1, EVP_aes_192_cbc }, + { "aes256-cbc", SSH_CIPHER_SSH2, 16, 32, 0, 0, 0, 1, EVP_aes_256_cbc }, + { "rijndael-cbc at lysator.liu.se", + SSH_CIPHER_SSH2, 16, 32, 0, 0, 0, 1, EVP_aes_256_cbc }, + { "aes128-ctr", SSH_CIPHER_SSH2, 16, 16, 0, 0, 0, 0, EVP_aes_128_ctr }, + { "aes192-ctr", SSH_CIPHER_SSH2, 16, 24, 0, 0, 0, 0, EVP_aes_192_ctr }, + { "aes256-ctr", SSH_CIPHER_SSH2, 16, 32, 0, 0, 0, 0, EVP_aes_256_ctr }, +#ifdef OPENSSL_HAVE_EVPGCM + { "aes128-gcm at openssh.com", + SSH_CIPHER_SSH2, 16, 16, 12, 16, 0, 0, EVP_aes_128_gcm }, + { "aes256-gcm at openssh.com", + SSH_CIPHER_SSH2, 16, 32, 12, 16, 0, 0, EVP_aes_256_gcm }, +#endif + { "chacha20-poly1305 at openssh.com", + SSH_CIPHER_SSH2, 8, 64, 0, 16, 0, CFLAG_CHACHAPOLY, NULL }, + { NULL, SSH_CIPHER_INVALID, 0, 0, 0, 0, 0, 0, NULL } +}; + /*--*/ +static struct Cipher * +fips_select_ciphers(void) +{ + int fips = fips_mode(); + switch (fips) { + case 0: + return ciphers; + case 1: + return ciphers_fips140_2; + default: + /* should not be reached */ + fatal("Fatal error: incorrect FIPS mode '%i' at %s:%u", + fips, __FILE__, __LINE__); +// return NULL; + } +} + + /* Returns a list of supported ciphers separated by the specified char. */ char * cipher_alg_list(char sep, int auth_only) @@ -194,7 +237,7 @@ cipher_by_name(const char *name) { const Cipher *c; - for (c = ciphers; c->name != NULL; c++) + for (c = fips_select_ciphers(); c->name != NULL; c++) if (strcmp(c->name, name) == 0) return c; return NULL; @@ -204,7 +247,7 @@ cipher_by_number(int id) { const Cipher *c; - for (c = ciphers; c->name != NULL; c++) + for (c = fips_select_ciphers(); c->name != NULL; c++) if (c->number == id) return c; return NULL; @@ -248,7 +291,7 @@ const Cipher *c; if (name == NULL) return -1; - for (c = ciphers; c->name != NULL; c++) + for (c = fips_select_ciphers(); c->name != NULL; c++) if (strcasecmp(c->name, name) == 0) return c->number; return -1; @@ -436,14 +479,19 @@ cipher_set_key_string(CipherContext *cc, const Cipher *cipher, const char *passphrase, int do_encrypt) { - MD5_CTX md; - u_char digest[16]; + const EVP_MD *evp_md; + EVP_MD_CTX md; + u_char digest[MAX_HASH_LEN]; + int dlen; + if ((evp_md = fips_EVP_get_digest_min()) == NULL) { + fatal("auth_rsa_verify_response: fips_EVP_get_digest_min failed"); + } - MD5_Init(&md); - MD5_Update(&md, (const u_char *)passphrase, strlen(passphrase)); - MD5_Final(digest, &md); + EVP_DigestInit(&md, evp_md); + EVP_DigestUpdate(&md, (const u_char *)passphrase, strlen(passphrase)); + EVP_DigestFinal(&md, digest, &dlen); - cipher_init(cc, cipher, digest, 16, NULL, 0, do_encrypt); + cipher_init(cc, cipher, digest, dlen, NULL, 0, do_encrypt); memset(digest, 0, sizeof(digest)); memset(&md, 0, sizeof(md)); diff -ruN openssh-6.5p1_orig/cipher-ctr.c openssh-6.5p1_patched/cipher-ctr.c --- openssh-6.5p1_orig/cipher-ctr.c 2013-06-02 03:37:32.000000000 +0530 +++ openssh-6.5p1_patched/cipher-ctr.c 2014-02-07 00:54:23.000000000 +0530 @@ -26,6 +26,7 @@ #include "xmalloc.h" #include "log.h" +#include "fips.h" /* compatibility with old or broken OpenSSL versions */ #include "openbsd-compat/openssl-compat.h" @@ -139,6 +140,9 @@ #ifndef SSH_OLD_EVP aes_ctr.flags = EVP_CIPH_CBC_MODE | EVP_CIPH_VARIABLE_LENGTH | EVP_CIPH_ALWAYS_CALL_INIT | EVP_CIPH_CUSTOM_IV; + if (fips_mode()) + aes_ctr.flags |= EVP_CIPH_FLAG_FIPS; + #endif return (&aes_ctr); } diff -ruN openssh-6.5p1_orig/fips.c openssh-6.5p1_patched/fips.c --- openssh-6.5p1_orig/fips.c 1970-01-01 05:30:00.000000000 +0530 +++ openssh-6.5p1_patched/fips.c 2014-02-07 00:56:54.000000000 +0530 @@ -0,0 +1,176 @@ +/* + * Copyright (c) 2012 Petr Cerny. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "fips.h" + +#include "log.h" + +enum hgp { + HGP_LEN, + HGP_NID +}; + +static int fips_state = -1; + +static const struct Hashes { + enum hash_type ht; + int byte_length; + int nid; +} hashes[] = { + { HASH_MD5, HASH_LEN_MD5, NID_md5 }, + { HASH_SHA1, HASH_LEN_SHA1, NID_sha1 }, + { HASH_SHA256, HASH_LEN_SHA256, NID_sha256 }, + { HASH_err, -1, -1 } +}; + +int +fips_mode() +{ + if (-1 == fips_state) { + fips_state = FIPS_mode(); + if (fips_state) + debug("FIPS mode initialized"); + } + return fips_state; +} + +static int +fips_hash_get_param(enum hash_type ht, int param) +{ + int i; + for (i = 0; i < HASH_err; i++) { + if (hashes[i].ht == ht) { + switch (param) { + case HGP_LEN: + return hashes[i].byte_length; + case HGP_NID: + return hashes[i].nid; + default: + fatal("Fatal error: internal error at %s:%u", + __FILE__, __LINE__); + } + } + } + /* should not be reached */ + fatal("Fatal error: incorrect hash type '%i' at %s:%u", + ht, __FILE__, __LINE__); +// return -1; +} + +int +fips_hash2nid(enum hash_type ht) +{ + return fips_hash_get_param(ht, HGP_NID); +} + +int +fips_hash_len(enum hash_type ht) +{ + return fips_hash_get_param(ht, HGP_LEN); +} + +void +fips_correct_fp_type(enum fp_type *fp) +{ + int fips; + + fips = fips_mode(); + switch (fips) { + case 0: + break; + case 1: + if (SSH_FP_MD5 == *fp) { + *fp = SSH_FP_SHA1; + logit("MD5 not allowed in FIPS 140-2 mode, " + "using SHA-1 for key fingerprints instead."); + } + break; + default: + /* should not be reached */ + fatal("Fatal error: incorrect FIPS mode '%i' at %s:%u", + fips, __FILE__, __LINE__); + } + + return; +} + +void +fips_correct_nid(int *nid) +{ + int fips; + + fips = fips_mode(); + switch (fips) { + case 0: + break; + case 1: + if (NID_md5 == *nid) { + *nid = NID_sha1; + logit("MD5 not allowed in FIPS 140-2 mode, " + "using SHA-1 for hashing instead."); + } + break; + default: + /* should not be reached */ + fatal("Fatal error: incorrect FIPS mode '%i' at %s:%u", + fips, __FILE__, __LINE__); + } + + return; +} + +enum hash_type +fips_hash_min(void) +{ + int fips; + enum hash_type ht; + + fips = fips_mode(); + switch (fips) { + case 0: + ht = HASH_MD5; + break; + case 1: + ht = HASH_SHA1; + break; + default: + /* should not be reached */ + fatal("Fatal error: incorrect FIPS mode '%i' at %s:%u", + fips, __FILE__, __LINE__); + } + return ht; +} + +enum hash_type +fips_hash_nid_min() +{ + return fips_hash2nid(fips_hash_min()); +} + +const EVP_MD * +fips_EVP_get_digest_min(void) +{ + return EVP_get_digestbynid(fips_hash_nid_min()); +} + diff -ruN openssh-6.5p1_orig/fips.h openssh-6.5p1_patched/fips.h --- openssh-6.5p1_orig/fips.h 1970-01-01 05:30:00.000000000 +0530 +++ openssh-6.5p1_patched/fips.h 2014-02-07 00:58:38.000000000 +0530 @@ -0,0 +1,52 @@ +/* + * Copyright (c) 2012 Petr Cerny. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ +#ifndef FIPS_H +#define FIPS_H + +#include + +#include "key.h" + +#define HASH_LEN_MD5 16 +#define HASH_LEN_SHA1 20 +#define HASH_LEN_SHA256 32 +#define MAX_HASH_LEN HASH_LEN_SHA256 + +enum hash_type { + HASH_MD5 = 1, + HASH_SHA1, + HASH_SHA256, + HASH_err +}; + +int fips_mode(void); +void fips_correct_fp_type(enum fp_type *); +void fips_correct_nid(int *); + +enum hash_type fips_hash_min(void); +const EVP_MD *fips_EVP_get_digest_min(void); +int fips_hash2nid(enum hash_type); +int fips_hash_len(enum hash_type); + +#endif diff -ruN openssh-6.5p1_orig/key.c openssh-6.5p1_patched/key.c --- openssh-6.5p1_orig/key.c 2014-01-10 05:28:53.000000000 +0530 +++ openssh-6.5p1_patched/key.c 2014-02-11 00:57:29.000000000 +0530 @@ -57,6 +57,7 @@ #include "misc.h" #include "ssh2.h" #include "digest.h" +#include "fips.h" static int to_blob(const Key *, u_char **, u_int *, int); static Key *key_from_blob2(const u_char *, u_int, int); @@ -425,12 +426,12 @@ } static char * -key_fingerprint_hex(u_char *dgst_raw, u_int dgst_raw_len) +key_fingerprint_hex(u_char *dgst_raw, u_int dgst_raw_len, enum fp_type dgst_type) { char *retval; u_int i; - retval = xcalloc(1, dgst_raw_len * 3 + 1); + retval = xcalloc(1, dgst_raw_len * 3 + 1 + SSH_FP_TYPE_STRLEN + 2); for (i = 0; i < dgst_raw_len; i++) { char hex[4]; snprintf(hex, sizeof(hex), "%02x:", dgst_raw[i]); @@ -438,7 +439,14 @@ } /* Remove the trailing ':' character */ - retval[(dgst_raw_len * 3) - 1] = '\0'; + retval[(dgst_raw_len * 3) - 1] = ' '; + /* Append hash type */ + { + char hash[SSH_FP_TYPE_STRLEN + 2 + 1]; + snprintf(hash, sizeof(hash), "[%s]", key_fp_type_str(dgst_type)); + strlcat(retval, hash, dgst_raw_len * 3 + 1 + SSH_FP_TYPE_STRLEN + 2); + } + return retval; } @@ -523,7 +531,7 @@ #define FLDSIZE_Y (FLDBASE + 1) #define FLDSIZE_X (FLDBASE * 2 + 1) static char * -key_fingerprint_randomart(u_char *dgst_raw, u_int dgst_raw_len, const Key *k) +key_fingerprint_randomart(u_char *dgst_raw, u_int dgst_raw_len, const Key *k, enum fp_type dgst_type) { /* * Chars to be used after each other every time the worm @@ -590,8 +598,9 @@ } /* output lower border */ - *p++ = '+'; - for (i = 0; i < FLDSIZE_X; i++) + i = snprintf(p, FLDSIZE_X, "+--[%s]", key_fp_type_str(dgst_type)); + p += i; + for (i--; i < FLDSIZE_X; i++) *p++ = '-'; *p++ = '+'; @@ -610,13 +619,13 @@ fatal("key_fingerprint: null from key_fingerprint_raw()"); switch (dgst_rep) { case SSH_FP_HEX: - retval = key_fingerprint_hex(dgst_raw, dgst_raw_len); + retval = key_fingerprint_hex(dgst_raw, dgst_raw_len, dgst_type); break; case SSH_FP_BUBBLEBABBLE: retval = key_fingerprint_bubblebabble(dgst_raw, dgst_raw_len); break; case SSH_FP_RANDOMART: - retval = key_fingerprint_randomart(dgst_raw, dgst_raw_len, k); + retval = key_fingerprint_randomart(dgst_raw, dgst_raw_len, k, dgst_type); break; default: fatal("key_fingerprint: bad digest representation %d", @@ -628,6 +637,65 @@ return retval; } +enum fp_type +key_fp_type_select(void) +{ + static enum fp_type fp; + static char fp_defined = 0; + char *env; + + if (!fp_defined) { + env = getenv(SSH_FP_TYPE_ENVVAR); + if (env) { + if (!strcasecmp(env, "md5") || + !strcasecmp(env, "md-5")) + fp = SSH_FP_MD5; + else if (!strcasecmp(env, "sha1") || + !strcasecmp(env, "sha-1")) + fp = SSH_FP_SHA1; +#ifdef HAVE_EVP_SHA256 + else if (!strcasecmp(env, "sha256") || + !strcasecmp(env, "sha-256")) + fp = SSH_FP_SHA256; +#endif + else { + error("invalid key type in environment variable " + SSH_FP_TYPE_ENVVAR ": '%s' - falling back to MD5.", + env); + fp = SSH_FP_MD5; + } + } else + fp = SSH_FP_MD5; + + if (fips_mode()) + fips_correct_fp_type(&fp); + + fp_defined = 1; + } + return fp; +} + +/* + * string lengths must be less or equal to SSH_FP_TYPE_STRLEN (defined in + * key.h) as to fit into the fingerprint string buffer + */ +char * +key_fp_type_str(enum fp_type dgst_type) +{ + switch (dgst_type) { + case SSH_FP_MD5: + return "MD5"; + case SSH_FP_SHA1: + return "SHA-1"; +#ifdef HAVE_EVP_SHA256 + case SSH_FP_SHA256: + return "SHA-256"; +#endif + default: + fatal("%s: unknown key fingerprint hash algorithm requested", __func__); + } +} + /* * Reads a multiple-precision integer in decimal from the buffer, and advances * the pointer. The integer must already be initialized. This function is diff -ruN openssh-6.5p1_orig/key.h openssh-6.5p1_patched/key.h --- openssh-6.5p1_orig/key.h 2014-01-10 05:28:53.000000000 +0530 +++ openssh-6.5p1_patched/key.h 2014-02-07 01:09:41.000000000 +0530 @@ -58,6 +58,8 @@ SSH_FP_BUBBLEBABBLE, SSH_FP_RANDOMART }; +#define SSH_FP_TYPE_ENVVAR "SSH_FINGERPRINT_TYPE" +#define SSH_FP_TYPE_STRLEN 8 /* key is stored in external hardware */ #define KEY_FLAG_EXT 0x0001 @@ -109,6 +111,9 @@ int key_write(const Key *, FILE *); int key_read(Key *, char **); u_int key_size(const Key *); +enum fp_type key_fp_type_select(void); +char *key_fp_type_str(enum fp_type); + Key *key_generate(int, u_int); Key *key_from_private(const Key *); diff -ruN openssh-6.5p1_orig/mac.c openssh-6.5p1_patched/mac.c --- openssh-6.5p1_orig/mac.c 2014-01-10 05:07:05.000000000 +0530 +++ openssh-6.5p1_patched/mac.c 2014-02-07 01:14:38.000000000 +0530 @@ -41,6 +41,7 @@ #include "kex.h" #include "mac.h" #include "misc.h" +#include "fips.h" #include "umac.h" @@ -60,7 +61,7 @@ int etm; /* Encrypt-then-MAC */ }; -static const struct macalg macs[] = { +static const struct macalg all_macs[] = { /* Encrypt-and-MAC (encrypt-and-authenticate) variants */ { "hmac-sha1", SSH_EVP, EVP_sha1, 0, 0, 0, 0 }, { "hmac-sha1-96", SSH_EVP, EVP_sha1, 96, 0, 0, 0 }, @@ -90,6 +91,30 @@ { NULL, 0, NULL, 0, 0, 0, 0 } }; +struct macalg macs_fips140_2[] = { + { "hmac-sha1", SSH_EVP, EVP_sha1, 0, 0, 0, 0 }, +#ifdef HAVE_EVP_SHA256 + { "hmac-sha2-256", SSH_EVP, EVP_sha256, 0, 0, 0, 0 }, + { "hmac-sha2-512", SSH_EVP, EVP_sha512, 0, 0, 0, 0 }, +#endif + { NULL, 0, NULL, 0, 0, 0, 0 } +}; + +static struct macalg * +fips_select_macs(void) +{ + int fips = fips_mode(); + switch (fips) { + case 0: + return all_macs; + case 1: + return macs_fips140_2; + default: + /* should not be reached */ + fatal("Fatal error: incorrect FIPS mode '%i' at %s:%u", fips, __FILE__, __LINE__); +// return NULL; + } +} /* Returns a list of supported MACs separated by the specified char. */ char * @@ -97,9 +122,9 @@ { char *ret = NULL; size_t nlen, rlen = 0; - const struct macalg *m; + const struct macalg *m = fips_select_macs(); - for (m = macs; m->name != NULL; m++) { + for (; m->name != NULL; m++) { if (ret != NULL) ret[rlen++] = sep; nlen = strlen(m->name); @@ -134,9 +159,9 @@ int mac_setup(Mac *mac, char *name) { - const struct macalg *m; + const struct macalg *m = fips_select_macs(); - for (m = macs; m->name != NULL; m++) { + for (; m->name != NULL; m++) { if (strcmp(name, m->name) != 0) continue; if (mac != NULL) diff -ruN openssh-6.5p1_orig/Makefile.in openssh-6.5p1_patched/Makefile.in --- openssh-6.5p1_orig/Makefile.in 2014-01-27 12:05:04.000000000 +0530 +++ openssh-6.5p1_patched/Makefile.in 2014-02-07 01:58:20.000000000 +0530 @@ -76,7 +76,7 @@ jpake.o schnorr.o ssh-pkcs11.o krl.o smult_curve25519_ref.o \ kexc25519.o kexc25519c.o poly1305.o chacha.o cipher-chachapoly.o \ ssh-ed25519.o digest.o \ - sc25519.o ge25519.o fe25519.o ed25519.o verify.o hash.o blocks.o + sc25519.o ge25519.o fe25519.o ed25519.o verify.o hash.o blocks.o fips.o SSHOBJS= ssh.o readconf.o clientloop.o sshtty.o \ sshconnect.o sshconnect1.o sshconnect2.o mux.o \ diff -ruN openssh-6.5p1_orig/myproposal.h openssh-6.5p1_patched/myproposal.h --- openssh-6.5p1_orig/myproposal.h 2013-12-07 05:54:02.000000000 +0530 +++ openssh-6.5p1_patched/myproposal.h 2014-02-07 02:00:09.000000000 +0530 @@ -109,6 +109,10 @@ "chacha20-poly1305 at openssh.com," \ "aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc," \ "aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se" +#define KEX_FIPS_140_2_ENCRYPT \ + "aes128-ctr,aes192-ctr,aes256-ctr," \ + "aes128-cbc,3des-cbc," \ + "aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se" #define KEX_DEFAULT_MAC \ "hmac-md5-etm at openssh.com," \ @@ -129,6 +133,10 @@ "hmac-ripemd160 at openssh.com," \ "hmac-sha1-96," \ "hmac-md5-96" +#define KEX_FIPS_140_2_MAC \ + "hmac-sha1," \ + SHA2_HMAC_MODES + #define KEX_DEFAULT_COMP "none,zlib at openssh.com,zlib" #define KEX_DEFAULT_LANG "" diff -ruN openssh-6.5p1_orig/openbsd-compat/arc4random.c openssh-6.5p1_patched/openbsd-compat/arc4random.c --- openssh-6.5p1_orig/openbsd-compat/arc4random.c 2013-10-09 05:14:49.000000000 +0530 +++ openssh-6.5p1_patched/openbsd-compat/arc4random.c 2014-02-07 02:02:32.000000000 +0530 @@ -37,6 +37,7 @@ #include #include "log.h" +#include "fips.h" #define KEYSTREAM_ONLY #include "chacha_private.h" diff -ruN openssh-6.5p1_orig/ssh-add.c openssh-6.5p1_patched/ssh-add.c --- openssh-6.5p1_orig/ssh-add.c 2013-12-29 12:14:07.000000000 +0530 +++ openssh-6.5p1_patched/ssh-add.c 2014-02-07 02:08:54.000000000 +0530 @@ -330,7 +330,7 @@ key = ssh_get_next_identity(ac, &comment, version)) { had_identities = 1; if (do_fp) { - fp = key_fingerprint(key, SSH_FP_MD5, + fp = key_fingerprint(key, key_fp_type_select(), SSH_FP_HEX); printf("%d %s %s (%s)\n", key_size(key), fp, comment, key_type(key)); diff -ruN openssh-6.5p1_orig/ssh-agent.c openssh-6.5p1_patched/ssh-agent.c --- openssh-6.5p1_orig/ssh-agent.c 2013-12-29 12:15:52.000000000 +0530 +++ openssh-6.5p1_patched/ssh-agent.c 2014-02-07 02:09:21.000000000 +0530 @@ -198,7 +198,7 @@ char *p; int ret = -1; - p = key_fingerprint(id->key, SSH_FP_MD5, SSH_FP_HEX); + p = key_fingerprint(id->key, key_fp_type_select(), SSH_FP_HEX); if (ask_permission("Allow use of key %s?\nKey fingerprint %s.", id->comment, p)) ret = 0; diff -ruN openssh-6.5p1_orig/ssh.c openssh-6.5p1_patched/ssh.c --- openssh-6.5p1_orig/ssh.c 2013-12-29 12:23:40.000000000 +0530 +++ openssh-6.5p1_patched/ssh.c 2014-02-07 02:11:49.000000000 +0530 @@ -104,6 +104,7 @@ #include "uidswap.h" #include "roaming.h" #include "version.h" +#include "fips.h" #ifdef ENABLE_PKCS11 #include "ssh-pkcs11.h" @@ -458,6 +459,8 @@ "ACD:E:F:I:KL:MNO:PQ:R:S:TVw:W:XYy")) != -1) { switch (opt) { case '1': + if (fips_mode()) + fatal("Protocol 1 not allowed in the FIPS mode."); options.protocol = SSH_PROTO_1; break; case '2': @@ -964,6 +967,12 @@ timeout_ms = options.connection_timeout * 1000; + if (FIPS_mode()) { + options.protocol &= SSH_PROTO_2; + if (options.protocol == 0) + fatal("Protocol 2 disabled by configuration but required in the FIPS mode"); + } + /* Open a connection to the remote host. */ if (ssh_connect(host, addrs, &hostaddr, options.port, options.address_family, options.connection_attempts, diff -ruN openssh-6.5p1_orig/sshconnect2.c openssh-6.5p1_patched/sshconnect2.c --- openssh-6.5p1_orig/sshconnect2.c 2014-01-10 05:28:53.000000000 +0530 +++ openssh-6.5p1_patched/sshconnect2.c 2014-02-07 02:16:14.000000000 +0530 @@ -72,6 +72,7 @@ #include "hostfile.h" #include "schnorr.h" #include "jpake.h" +#include "fips.h" #ifdef GSSAPI #include "ssh-gss.h" @@ -170,6 +171,9 @@ if (options.ciphers != NULL) { myproposal[PROPOSAL_ENC_ALGS_CTOS] = myproposal[PROPOSAL_ENC_ALGS_STOC] = options.ciphers; + } else if (fips_mode()) { + myproposal[PROPOSAL_ENC_ALGS_CTOS] = + myproposal[PROPOSAL_ENC_ALGS_STOC] = KEX_FIPS_140_2_ENCRYPT; } myproposal[PROPOSAL_ENC_ALGS_CTOS] = compat_cipher_proposal(myproposal[PROPOSAL_ENC_ALGS_CTOS]); @@ -185,6 +189,9 @@ if (options.macs != NULL) { myproposal[PROPOSAL_MAC_ALGS_CTOS] = myproposal[PROPOSAL_MAC_ALGS_STOC] = options.macs; + } else if (fips_mode()) { + myproposal[PROPOSAL_MAC_ALGS_CTOS] = + myproposal[PROPOSAL_MAC_ALGS_STOC] = KEX_FIPS_140_2_MAC; } if (options.hostkeyalgorithms != NULL) myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = @@ -592,7 +599,7 @@ key->type, pktype); goto done; } - fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + fp = key_fingerprint(key, key_fp_type_select(), SSH_FP_HEX); debug2("input_userauth_pk_ok: fp %s", fp); free(fp); @@ -1204,7 +1211,7 @@ int have_sig = 1; char *fp; - fp = key_fingerprint(id->key, SSH_FP_MD5, SSH_FP_HEX); + fp = key_fingerprint(id->key, key_fp_type_select(), SSH_FP_HEX); debug3("sign_and_send_pubkey: %s %s", key_type(id->key), fp); free(fp); diff -ruN openssh-6.5p1_orig/sshconnect.c openssh-6.5p1_patched/sshconnect.c --- openssh-6.5p1_orig/sshconnect.c 2014-01-10 05:29:24.000000000 +0530 +++ openssh-6.5p1_patched/sshconnect.c 2014-02-07 02:17:50.000000000 +0530 @@ -911,8 +911,8 @@ "key for IP address '%.128s' to the list " "of known hosts.", type, ip); } else if (options.visual_host_key) { - fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX); - ra = key_fingerprint(host_key, SSH_FP_MD5, + fp = key_fingerprint(host_key, key_fp_type_select(), SSH_FP_HEX); + ra = key_fingerprint(host_key, key_fp_type_select(), SSH_FP_RANDOMART); logit("Host key fingerprint is %s\n%s\n", fp, ra); free(ra); @@ -952,8 +952,8 @@ else snprintf(msg1, sizeof(msg1), "."); /* The default */ - fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX); - ra = key_fingerprint(host_key, SSH_FP_MD5, + fp = key_fingerprint(host_key, key_fp_type_select(), SSH_FP_HEX); + ra = key_fingerprint(host_key, key_fp_type_select(), SSH_FP_RANDOMART); msg2[0] = '\0'; if (options.verify_host_key_dns) { @@ -1217,7 +1217,7 @@ int flags = 0; char *fp; - fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX); + fp = key_fingerprint(host_key, key_fp_type_select(), SSH_FP_HEX); debug("Server host key: %s %s", key_type(host_key), fp); free(fp); @@ -1324,8 +1324,8 @@ continue; if (!lookup_key_in_hostkeys_by_type(hostkeys, type[i], &found)) continue; - fp = key_fingerprint(found->key, SSH_FP_MD5, SSH_FP_HEX); - ra = key_fingerprint(found->key, SSH_FP_MD5, SSH_FP_RANDOMART); + fp = key_fingerprint(found->key, key_fp_type_select(), SSH_FP_HEX); + ra = key_fingerprint(found->key, key_fp_type_select(), SSH_FP_RANDOMART); logit("WARNING: %s key found for host %s\n" "in %s:%lu\n" "%s key fingerprint %s.", @@ -1346,7 +1346,7 @@ { char *fp; - fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX); + fp = key_fingerprint(host_key, key_fp_type_select(), SSH_FP_HEX); error("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"); error("@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @"); diff -ruN openssh-6.5p1_orig/sshd.c openssh-6.5p1_patched/sshd.c --- openssh-6.5p1_orig/sshd.c 2014-01-28 09:38:13.000000000 +0530 +++ openssh-6.5p1_patched/sshd.c 2014-02-07 02:22:10.000000000 +0530 @@ -121,6 +121,7 @@ #include "roaming.h" #include "ssh-sandbox.h" #include "version.h" +#include "fips.h" #ifdef LIBWRAP #include @@ -1717,6 +1718,10 @@ debug("private host key: #%d type %d %s", i, keytype, key_type(key ? key : pubkey)); } + if ((options.protocol & SSH_PROTO_1) && fips_mode()) { + logit("Disabling protocol version 1. Not allowed in the FIPS mode."); + options.protocol &= ~SSH_PROTO_1; + } if ((options.protocol & SSH_PROTO_1) && !sensitive_data.have_ssh1_key) { logit("Disabling protocol version 1. Could not load host key"); options.protocol &= ~SSH_PROTO_1; @@ -2429,6 +2434,9 @@ if (options.ciphers != NULL) { myproposal[PROPOSAL_ENC_ALGS_CTOS] = myproposal[PROPOSAL_ENC_ALGS_STOC] = options.ciphers; + } else if (fips_mode()) { + myproposal[PROPOSAL_ENC_ALGS_CTOS] = + myproposal[PROPOSAL_ENC_ALGS_STOC] = KEX_FIPS_140_2_ENCRYPT; } myproposal[PROPOSAL_ENC_ALGS_CTOS] = compat_cipher_proposal(myproposal[PROPOSAL_ENC_ALGS_CTOS]); @@ -2438,6 +2446,9 @@ if (options.macs != NULL) { myproposal[PROPOSAL_MAC_ALGS_CTOS] = myproposal[PROPOSAL_MAC_ALGS_STOC] = options.macs; + } else if (fips_mode()) { + myproposal[PROPOSAL_MAC_ALGS_CTOS] = + myproposal[PROPOSAL_MAC_ALGS_STOC] = KEX_FIPS_140_2_MAC; } if (options.compression == COMP_NONE) { myproposal[PROPOSAL_COMP_ALGS_CTOS] = diff -ruN openssh-6.5p1_orig/ssh-keygen.c openssh-6.5p1_patched/ssh-keygen.c --- openssh-6.5p1_orig/ssh-keygen.c 2013-12-07 05:54:02.000000000 +0530 +++ openssh-6.5p1_patched/ssh-keygen.c 2014-02-07 02:27:57.000000000 +0530 @@ -746,7 +746,7 @@ enum fp_type fptype; char *fp, *ra; - fptype = print_bubblebabble ? SSH_FP_SHA1 : SSH_FP_MD5; + fptype = print_bubblebabble ? SSH_FP_SHA1 : key_fp_type_select(); rep = print_bubblebabble ? SSH_FP_BUBBLEBABBLE : SSH_FP_HEX; pkcs11_init(0); @@ -801,7 +801,7 @@ public = key_load_public(identity_file, &comment); if (public != NULL) { fp = key_fingerprint(public, fptype, rep); - ra = key_fingerprint(public, SSH_FP_MD5, SSH_FP_RANDOMART); + ra = key_fingerprint(public, key_fp_type_select(), SSH_FP_RANDOMART); printf("%u %s %s (%s)\n", key_size(public), fp, comment, key_type(public)); if (log_level >= SYSLOG_LEVEL_VERBOSE) @@ -867,7 +867,7 @@ } comment = *cp ? cp : comment; fp = key_fingerprint(public, fptype, rep); - ra = key_fingerprint(public, SSH_FP_MD5, SSH_FP_RANDOMART); + ra = key_fingerprint(public, key_fp_type_select(), SSH_FP_RANDOMART); printf("%u %s %s (%s)\n", key_size(public), fp, comment ? comment : "no comment", key_type(public)); if (log_level >= SYSLOG_LEVEL_VERBOSE) @@ -988,10 +988,10 @@ enum fp_type fptype; char *fp, *ra; - fptype = print_bubblebabble ? SSH_FP_SHA1 : SSH_FP_MD5; + fptype = print_bubblebabble ? SSH_FP_SHA1 : key_fp_type_select(); rep = print_bubblebabble ? SSH_FP_BUBBLEBABBLE : SSH_FP_HEX; fp = key_fingerprint(public, fptype, rep); - ra = key_fingerprint(public, SSH_FP_MD5, SSH_FP_RANDOMART); + ra = key_fingerprint(public, key_fp_type_select(), SSH_FP_RANDOMART); printf("%u %s %s (%s)\n", key_size(public), fp, name, key_type(public)); if (log_level >= SYSLOG_LEVEL_VERBOSE) @@ -1878,9 +1878,9 @@ fatal("%s is not a certificate", identity_file); v00 = key->type == KEY_RSA_CERT_V00 || key->type == KEY_DSA_CERT_V00; - key_fp = key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX); + key_fp = key_fingerprint(key, key_fp_type_select(), SSH_FP_HEX); ca_fp = key_fingerprint(key->cert->signature_key, - SSH_FP_MD5, SSH_FP_HEX); + key_fp_type_select(), SSH_FP_HEX); printf("%s:\n", identity_file); printf(" Type: %s %s certificate\n", key_ssh_name(key), @@ -2686,8 +2686,8 @@ fclose(f); if (!quiet) { - char *fp = key_fingerprint(public, SSH_FP_MD5, SSH_FP_HEX); - char *ra = key_fingerprint(public, SSH_FP_MD5, + char *fp = key_fingerprint(public, key_fp_type_select(), SSH_FP_HEX); + char *ra = key_fingerprint(public, key_fp_type_select(), SSH_FP_RANDOMART); printf("Your public key has been saved in %s.\n", identity_file); diff -ruN openssh-6.5p1_orig/ssh-rsa.c openssh-6.5p1_patched/ssh-rsa.c --- openssh-6.5p1_orig/ssh-rsa.c 2014-01-10 05:28:53.000000000 +0530 +++ openssh-6.5p1_patched/ssh-rsa.c 2014-02-07 02:36:26.000000000 +0530 @@ -33,6 +33,7 @@ #include "misc.h" #include "ssh.h" #include "digest.h" +#include "fips.h" static int openssh_RSA_verify(int, u_char *, u_int, u_char *, u_int, RSA *); @@ -56,6 +57,7 @@ /* hash the data */ hash_alg = SSH_DIGEST_SHA1; nid = NID_sha1; + fips_correct_nid(&nid); if ((dlen = ssh_digest_bytes(hash_alg)) == 0) { error("%s: bad hash algorithm %d", __func__, hash_alg); return -1; --- PATCH END -----Original Message----- From: Steve Marquess [mailto:marquess at opensslfoundation.com] Sent: Monday, February 17, 2014 5:35 PM To: openssh-unix-dev at mindrot.org Cc: manish.jagtap at airtightnetworks.com Subject: Re: [ DRAFT PATCH ] - FIPS 140-2 patch for OpenSSH 6.5p1 On 02/17/2014 01:09 AM, Manish Jagtap wrote: > Hi, > > > > Here is FIPS 140-2 patch for OpenSSH 6.5p1. Since our expertise in > OpenSSH code is limited, request moderators to validate this patch and > update as required. I didn't see any patch but the following comments apply regardless. For a long time I hoped to see native OpenSSL FIPS module support in OpenSSH. Over the years OSF has prepared a number of patches such as: http://opensslfoundation.com/export/openssh/openssh-6.0p1.fips-revised.pat ch for interested clients. However, with continuing evolution of OpenSSH and changing FIPS 140-2 requirements such support is becoming increasingly difficult. In order to make any reasonable claim that an application like OpenSSH is "FIPS 140-2 compliant" *all* cryptography used by that application must be implemented in the validated module(s). OpenSSH has always had some inlined cryptography, but the recent introduction of "non-NIST" cryptography exacerbates that issue. Then there is the additional consideration that FIPS 140-2 is only desirable in a context (USG and DoD) where x.509 support is also mandatory. OpenSSH has adopted a different (and more robust) certificate scheme. FIPS 140-2 has always been focused on compliance to a specific ritualized policy and process, and thus is necessarily less secure in an absolute sense, while OpenSSH is focused on real-world security. IMHO that discrepancy will probably continue to grow. So while it remains technically possible to jam the round OpenSSH peg into the square FIPS 140-2 hole, I'm no longer sure it makes sense to attempt it in the baseline OpenSSH. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc From hkario at redhat.com Tue Feb 18 00:30:16 2014 From: hkario at redhat.com (Hubert Kario) Date: Mon, 17 Feb 2014 08:30:16 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> <1596206452.3480877.1392392256921.JavaMail.zimbra@redhat.com> Message-ID: <1285804307.4210570.1392643816234.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Damien Miller" > To: "Hubert Kario" > Cc: "Scott Neugroschl" , "mancha" , openssh-unix-dev at mindrot.org > Sent: Saturday, 15 February, 2014 12:33:44 AM > Subject: Re: 3des cipher and DH group size > > On Fri, 14 Feb 2014, Hubert Kario wrote: > > > > Also KexAlgorithms=diffie-hellman-group14-sha1 > > > > not supported by the server > > you tried diffie-hellman-group1-sha1 too? It's mandated by the spec It supported, but it is not secure. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team http://wiki.brq.redhat.com/hkario Email: hkario at redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From hkario at redhat.com Tue Feb 18 04:06:49 2014 From: hkario at redhat.com (Hubert Kario) Date: Mon, 17 Feb 2014 12:06:49 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1680779447.2191197.1392230261440.JavaMail.zimbra@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> <1802254039.3475993.1392391881578.JavaMail.zimbra@redhat.com> Message-ID: <1906455813.4410652.1392656809363.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Damien Miller" > To: "Hubert Kario" > Cc: "mancha" , openssh-unix-dev at mindrot.org > Sent: Saturday, 15 February, 2014 12:39:39 AM > Subject: Re: 3des cipher and DH group size > > On Fri, 14 Feb 2014, Hubert Kario wrote: > > > Suite B for secret (effectively 128 bit security) communication > > allows use of AES only in GCM or CTR mode. RFC 6239 > > specifies that SSH in Suite B must use AES in GCM mode. > > IV of AES 128 in GCM mode as used in SSH is 12 octets (96bit). > > > > How do you explain this disparity? > > Since you seem disinclined to go and read about AES-GCM for yourself, > I'll point out that the remaining 32 bits are an implicit block counter. > > See https://tools.ietf.org/html/rfc5647 section 7.1 Yes, I know that. The point I was arguing is that exact size of IV is not the exact upper limit for security estimate of the cipher. I've read both the SSH and IPsec RFCs related to AES GCM. They both refer to the truncated value as IV. Quite rightfully so, as those remaining bits are completely predictable to the attacker. The other thing is that for 256 bit or 196 bit keys, they still use "only" 128 bit as the combined "IV". This is also how iv_len field for aes-gcm ciphers is defined and used in openssh. Its value for aes-gcm is 12 octets: cipher.c:97: { "aes128-gcm at openssh.com", SSH_CIPHER_SSH2, 16, 16, 12, 16, 0, 0, EVP_aes_128_gcm }, { "aes256-gcm at openssh.com", SSH_CIPHER_SSH2, 16, 32, 12, 16, 0, 0, EVP_aes_256_gcm }, The same value of 12 octets is used to calculate the proposed dh size: kex.c:518: dh_need = MAX(dh_need, newkeys->enc.iv_len); Similar situation is with regards of block_size. As it was already stated, both are a noop. What's worse, they are confusing since the relation between IV, block size and cipher security level is not this simple and certainly those sizes are not the upper or lower bound. That's why I think the code as proposed by Darren Tucker is closest to being the best. In depth rationale and proposed code follow. Since breaking MAC requires most resources (requires real-time attack on the hash), it is therefore the least likely to be successfully performed. Breaking DH or cipher on the other hand can be done offline and provide useful information even decades after the connection took place. Breaking the host keys doesn't give such information and is useful only for online attacks, so attacks on RSA, ECDSA are second most likely. As such, binding the size of DH parameters to specific block ciphers makes the most sense. This can be done in two ways. Either by adding new column to ciphers[], which I don't think is particularly clean. Or by reusing key_len value as the security estimate and providing an exception mechanism, noting in the ciphers[] definition that such exception mechanism (cipher_seclen()) exists is important! Since there are no differences between ENISA and NIST recommendations and the differences between ECRYPTII and NIST are insignificant for the values we can use (because of protocol limitations), I think we should use NIST recommendations for DH - block cipher equivalence. I also think that we should not propose DH sizes below 2048 bit in any case, as recommended in SP 800-131A. So, I think that the code in kex.c in kex_choose_conf() should look like this: dh_need = 14; dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher)); } kex->we_need = need; kex->dh_need = dh_need; And code in cipher.c should look like this: u_int cipher_seclen(const Cipher *c) { if (strcmp("3des-cbc", c->name) == 0) return 14; if (strcmp("chacha20-poly1305 at openssh.com", c->name) == 0) return 32; return cipher_keylen(c); } -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From hkario at redhat.com Tue Feb 18 04:20:47 2014 From: hkario at redhat.com (Hubert Kario) Date: Mon, 17 Feb 2014 12:20:47 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> <1802254039.3475993.1392391881578.JavaMail.zimbra@redhat.com> <1677660397.3569979.1392401944399.JavaMail.zimbra@redhat.com> Message-ID: <1404053680.4431123.1392657647128.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "mancha" > To: openssh-unix-dev at mindrot.org > Sent: Friday, 14 February, 2014 7:49:21 PM > Subject: Re: 3des cipher and DH group size Why you're completely ignoring any of my suggestions for a compromise? I already stated few times that I consider the changes that better align openssh to NIST SP 800-57 to be a good thing. My main point is that the changes don't follow this recommendation to the letter and because of that interoperability suffers. > Hubert Kario redhat.com> writes: > > > P=NP is still unsolved. Having more pigeons than holes is not. > > > > You're telling one thing, multiple established standards tell another. > > > > If this was as easy as pigeonhole principle, someone would have called it > > by now. So unless you have at least one paper with hard math that says > > the same thing, I'm saying "not true". > > http://lmgtfy.com/?q=initialization+vector+birthday+paradox Let's see, the second top result (Computer and Information Security Handbook by John R. Vacca) has this text in it: > Using electronic code book mode on a message longer than a single > block leaks a bit per block. So even when I use no IV what so ever, encrypting few blocks is secure. Another first page result, the "Stream Cipher" by Andreas Klain says: > As a practical consequence we must require that an initialization vector > is never used twice. If we want to use 2^k sessions the birthday paradox > forces us to work with an initialization vector of length 2^2k. I already said "it mostly influences how much plaintext you can encrypt with the same key": http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-February/032182.html So I still consider "IV size == cipher security" as not true. Both IV size and block size have impact on security of the cipher, but they are not as simple as security_estimate=min(IV_size, block_size, key_size) or security_estimate=max(IV_size, block_size, key_size)! > > > Poor cryptographic decisions should be corrected not emulated and > > > perpetuated. > > > > People's lives depend on security of systems that at best provide 80 bit > > of security. > > > > I'm saying that there is no point of using anything past 128 bit > > with default settings if this hampers interoperability. > > > > That's a 281474976710656 times difference! > > > > You really don't see that? > > You might be one of the few people left who are advocating for weak > cryptographic primitives. Were you also upset when OpenSSL deprecated > MD2? I'm advocating for using sensible *sets* of cryptographic primitives. using 3DES, 2k RSA, 2k DH together with SHA-1 makes sense (mostly because MD5 is deprecated) using 3DES, 2k RSA, 7k DH together with SHA-1 does not make sense using AES-128, 3k RSA, 2k DH together with SHA-1 does not make sense > > > Who knows what "normal person" or "relatively secure" mean. That's > > > why we develop standards and objective guidelines instead. > > > > "normal person" - people that don't know about existence or purpose > > of /etc/ssh/moduli > > > > "relatively secure" - 128bit, a.k.a. SECRET as used by NATO. > > > > Using 7k DH with 3DES and AES-128 is not the effect of those guidelines. > > > > I choose standards and objective guidelines over your personal > definitions of "relatively secure" and "normal person". The standards say quite explicitly: iff 3DES => 2k DH. iff AES-128 => 3k DH. They don't say if SHA-1 MAC => 7k DH. But that's what current code is doing. FIPS (it even has "Standard" in the name) says that we shouldn't use DH with keys over 3072 bits, ever. Why you're not following it? > > > > At 128 bit ECRYPT II recommends 3248 bit DH, not 7168. > > > > ENISA also recommends 3072 bit DH at 128 bit security level[1]. > > > > > > At 128 bits of security, NIST recommends 3072 bit DH and ECRYPT > > > II recommends 3248 bit DH. > > > > > > if(3248>3072) printf("math is nice\n"); > > > > that's less than 4 bit difference in security level, you really want > > to argue about "times 16" difference? > > > > Huh? My initial statement was that ECRYPT II recommends higher DH > bit sizes than NIST at every security level. Why exactly do you > keep debating this provable fact? FYI: facts are stubborn things. The other fact is that the "112 bits" security of 3DES is not entirely equal the security of "112 bits" of ~2k RSA or DH (be it the NIST or ECRYPT II value). They require different hardware and different breakthroughs in mathematics for cracking. The values are just estimates, and you're insisting on using the exact values of those estimates. I also said that if you consider the higher values from ECRYPT II to be more trustworthy estimates I don't have a problem with using even much higher values. You're nitpicking and completely ignoring my main point. > > > > > > > > That was the first thing I tried, unfortunately, not supported by > > > > the cryptlib server in question. > > > > > > Sorry to hear cryptlib breaks yet another RFC. RFC 4253 requires > > > Oakley group 14 support. > > > > I'm not saying that it is RFC compliant. I'm saying that openssh > > can interoperate with it without compromising security. > > Fix what's broken so it works with what's not broken. Don't break > things that aren't broken so they work with what's broken. I don't see how insisting on usage of DH <= 4k if and *only* if the ciphers are 3DES or AES-128 is "breaking things". Why you're ignoring the fact that it's the original change to dh param size calculation that did break things? We are discussing a fix for this new breakage introduced in openssh 6.5. -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From djm at mindrot.org Tue Feb 18 14:53:42 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 18 Feb 2014 14:53:42 +1100 (EST) Subject: 3des cipher and DH group size In-Reply-To: <1404053680.4431123.1392657647128.JavaMail.zimbra@redhat.com> References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <905077333.2559483.1392291486114.JavaMail.zimbra@redhat.com> <1802254039.3475993.1392391881578.JavaMail.zimbra@redhat.com> <1677660397.3569979.1392401944399.JavaMail.zimbra@redhat.com> <1404053680.4431123.1392657647128.JavaMail.zimbra@redhat.com> Message-ID: On Mon, 17 Feb 2014, Hubert Kario wrote: > > I choose standards and objective guidelines over your personal > > definitions of "relatively secure" and "normal person". > > The standards say quite explicitly: iff 3DES => 2k DH. iff AES-128 => 3k DH. > They don't say if SHA-1 MAC => 7k DH. > > But that's what current code is doing. > > FIPS (it even has "Standard" in the name) says that we shouldn't use > DH with keys over 3072 bits, ever. Why you're not following it? FIPS always lags good practice. E.g. permitting single DES until 2007. -d From phil.pennock at globnix.org Tue Feb 18 19:33:59 2014 From: phil.pennock at globnix.org (Phil Pennock) Date: Tue, 18 Feb 2014 00:33:59 -0800 Subject: [PATCH] verify against known fingerprints Message-ID: <20140218083359.GA49803@redoubt.spodhuis.org> I've just written this patch, it's undergone minimal testing and "works for me" and I'm after feedback as to acceptability of approach, anything I should be doing differently for the feature to be acceptable upstream and what I should be doing about automated testing. Use-case: you have the host's SSH fingerprints via an out-of-band mechanism which you trust and want to be able to connect and have verification use those known-good fingerprints and, if they match, update known_hosts. In our case, we use Amazon EC2, and I scripted up something which can use the AWS APIs to grab the serial console from a recently installed machine and grab the SSH host key fingerprints out of that. This provides an authenticated and tamper-proof path (provided that you trust the EC2 infrastructure APIs and, if you don't trust them as much as you do trust the SSH running in the VM, then I'd argue that you have a broken trust/threat model). In addition, we have a bastion host between the internal machines and the Internet, so ssh-keyscan is not, AFAIK, applicable. ----------------------------8< cut here >8------------------------------ % ./ssh -v -H fplist aws-cluster-foo-host-bar [...] debug1: Server host key: ECDSA 12:34:......................................:ef debug1: Have a new ECDSA host key for aws-cluster-foo-host-bar and checking fingerprint against fplist. debug1: fingerprint matches line 3. Warning: Permanently added 'aws-cluster-foo-host-bar' (ECDSA) to the list of known hosts. debug1: ssh_ecdsa_verify: signature correct ----------------------------8< cut here >8------------------------------ The file contained lines looking like: ----------------------------8< cut here >8------------------------------ rsa 11:22:33:...................................:00 root at ip-10-0-0-1 dsa ba:98:......................................:21 root at ip-10-0-0-1 ecdsa 12:34:......................................:ef root at ip-10-0-0-1 ----------------------------8< cut here >8------------------------------ (albeit with full fingerprints, obviously). Constructive feedback appreciated, and any pointers to any contributor docs that need legal signoff, or whatever. Thanks, -Phil From 5a0925ff19f6a80ec6cbf6cd5473de1d9ebf241d Mon Sep 17 00:00:00 2001 From: Phil Pennock Date: Tue, 18 Feb 2014 03:19:26 -0500 Subject: [PATCH] Support -H/-o HashFile Use-case: have the expected host fingerprints via a trusted out-of-band mechanism (eg, console logs) and want to be able to connect and verify the fingerprints automatically. --- hostfile.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ hostfile.h | 2 ++ readconf.c | 8 +++++++- readconf.h | 1 + ssh.1 | 6 ++++++ ssh.c | 7 +++++-- ssh_config.5 | 7 +++++++ sshconnect.c | 21 +++++++++++++++++++-- 8 files changed, 99 insertions(+), 5 deletions(-) diff --git a/hostfile.c b/hostfile.c index 8bc9540..e5b834b 100644 --- a/hostfile.c +++ b/hostfile.c @@ -487,3 +487,55 @@ add_host_to_hostfile(const char *filename, const char *host, const Key *key, fclose(f); return success; } + +/* + * Checks if a fingerprint presented from a remote host can be found in the + * file. If found, returns line-number, starting with 1. If not found, + * returns -1. 0 should not be returned. + * This might be a pipe or other non-regular file, but we should only have + * one fingerprint to verify per process, so re-opening should not occur. + */ + +int +check_host_fingerprint(const char *type, const char *fp, const char *filename) +{ + char line[8192]; + FILE *f; + int match_line = -1; + u_long linenum = 0; + char *cp, *cp2; + + f = fopen(filename, "r"); + if (!f) + return -1; + + while (read_keyfile_line(f, filename, line, sizeof(line), &linenum) == 0) { + cp = line; + + /* Skip any leading whitespace, comments and empty lines. */ + for (; *cp == ' ' || *cp == '\t'; cp++) + ; + if (!*cp || *cp == '#' || *cp == '\n') + continue; + + /* expect: type fingerprint */ + for (cp2 = cp; *cp2 && *cp2 != ' ' && *cp2 != '\t'; cp2++) + ; + if (!*cp) + continue; + *cp2 = '\0'; + if (strcasecmp(type, cp) != 0) + continue; + cp = cp2 + 1; + for (cp2 = cp; *cp2 && *cp2 != ' ' && *cp2 != '\t' && *cp2 != '\n'; cp2++) + ; + *cp2 = '\0'; + if (strcasecmp(fp, cp) != 0) + continue; + match_line = (int)linenum; + break; + } + + fclose(f); + return match_line; +} diff --git a/hostfile.h b/hostfile.h index 679c034..489a82d 100644 --- a/hostfile.h +++ b/hostfile.h @@ -51,4 +51,6 @@ int add_host_to_hostfile(const char *, const char *, const Key *, int); char *host_hash(const char *, const char *, u_int); +int check_host_fingerprint(const char *, const char *, const char *); + #endif diff --git a/readconf.c b/readconf.c index f80d1cc..af170e6 100644 --- a/readconf.c +++ b/readconf.c @@ -143,7 +143,7 @@ typedef enum { oAddressFamily, oGssAuthentication, oGssDelegateCreds, oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly, oSendEnv, oControlPath, oControlMaster, oControlPersist, - oHashKnownHosts, + oHashKnownHosts, oHashFile, oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand, oVisualHostKey, oUseRoaming, oKexAlgorithms, oIPQoS, oRequestTTY, oIgnoreUnknown, oProxyUseFdpass, @@ -246,6 +246,7 @@ static struct { { "controlmaster", oControlMaster }, { "controlpersist", oControlPersist }, { "hashknownhosts", oHashKnownHosts }, + { "hashfile", oHashFile }, { "tunnel", oTunnel }, { "tunneldevice", oTunnelDevice }, { "localcommand", oLocalCommand }, @@ -953,6 +954,10 @@ parse_char_array: max_entries = SSH_MAX_HOSTS_FILES; goto parse_char_array; + case oHashFile: + charptr = &options->hash_file; + goto parse_string; + case oHostName: charptr = &options->hostname; goto parse_string; @@ -1533,6 +1538,7 @@ initialize_options(Options * options) options->control_persist = -1; options->control_persist_timeout = 0; options->hash_known_hosts = -1; + options->hash_file = NULL; options->tun_open = -1; options->tun_local = -1; options->tun_remote = -1; diff --git a/readconf.h b/readconf.h index 9723da0..5b7d796 100644 --- a/readconf.h +++ b/readconf.h @@ -94,6 +94,7 @@ typedef struct { char *system_hostfiles[SSH_MAX_HOSTS_FILES]; u_int num_user_hostfiles; /* Path for $HOME/.ssh/known_hosts */ char *user_hostfiles[SSH_MAX_HOSTS_FILES]; + char *hash_file; /* when user has fingerprints for remote host */ char *preferred_authentications; char *bind_address; /* local socket address for connection to sshd */ char *pkcs11_provider; /* PKCS#11 provider */ diff --git a/ssh.1 b/ssh.1 index 27794e2..50e32e8 100644 --- a/ssh.1 +++ b/ssh.1 @@ -50,6 +50,7 @@ .Op Fl E Ar log_file .Op Fl e Ar escape_char .Op Fl F Ar configfile +.Op Fl H Ar hashfile .Op Fl I Ar pkcs11 .Op Fl i Ar identity_file .Op Fl L Oo Ar bind_address : Oc Ns Ar port : Ns Ar host : Ns Ar hostport @@ -267,6 +268,11 @@ will wait for all remote port forwards to be successfully established before placing itself in the background. .It Fl g Allows remote hosts to connect to local forwarded ports. +.It Fl H Ar hash_file +Provides a filename which contains expected fingerprints if the remote +host presents an unknown public key. If provided, the remote key must +match one of these, and if it does match, then it will be added to the +known hosts file. .It Fl I Ar pkcs11 Specify the PKCS#11 shared library .Nm diff --git a/ssh.c b/ssh.c index add760c..affd92f 100644 --- a/ssh.c +++ b/ssh.c @@ -198,7 +198,7 @@ usage(void) fprintf(stderr, "usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]\n" " [-D [bind_address:]port] [-E log_file] [-e escape_char]\n" -" [-F configfile] [-I pkcs11] [-i identity_file]\n" +" [-F configfile] [-H hash_file] [-I pkcs11] [-i identity_file]\n" " [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]\n" " [-O ctl_cmd] [-o option] [-p port]\n" " [-Q cipher | cipher-auth | mac | kex | key]\n" @@ -455,7 +455,7 @@ main(int ac, char **av) again: while ((opt = getopt(ac, av, "1246ab:c:e:fgi:kl:m:no:p:qstvx" - "ACD:E:F:I:KL:MNO:PQ:R:S:TVw:W:XYy")) != -1) { + "ACD:E:F:H:I:KL:MNO:PQ:R:S:TVw:W:XYy")) != -1) { switch (opt) { case '1': options.protocol = SSH_PROTO_1; @@ -568,6 +568,9 @@ main(int ac, char **av) fprintf(stderr, "no support for PKCS#11.\n"); #endif break; + case 'H': + options.hash_file = xstrdup(optarg); + break; case 't': if (options.request_tty == REQUEST_TTY_YES) options.request_tty = REQUEST_TTY_FORCE; diff --git a/ssh_config.5 b/ssh_config.5 index 3cadcd7..1b6861d 100644 --- a/ssh_config.5 +++ b/ssh_config.5 @@ -681,6 +681,13 @@ Forward (delegate) credentials to the server. The default is .Dq no . Note that this option applies to protocol version 2 only. +.It Cm HashFile +Provides a file which should contain host fingerprint lines, in the same +format as reported by +.Xr ssh-keygen . +If the remote host's key is not known, but matches a fingerprint in this +file, then it will be automatically accepted. If it does not match, then +it will be automatically rejected. .It Cm HashKnownHosts Indicates that .Xr ssh 1 diff --git a/sshconnect.c b/sshconnect.c index 573d7a8..0ce3e52 100644 --- a/sshconnect.c +++ b/sshconnect.c @@ -811,7 +811,7 @@ check_host_key(char *hostname, struct sockaddr *hostaddr, u_short port, char msg[1024]; const char *type; const struct hostkey_entry *host_found, *ip_found; - int len, cancelled_forwarding = 0; + int len, line, cancelled_forwarding = 0; int local = sockaddr_is_local(hostaddr); int r, want_cert = key_is_cert(host_key), host_ip_differ = 0; struct hostkeys *host_hostkeys, *ip_hostkeys; @@ -936,7 +936,24 @@ check_host_key(char *hostname, struct sockaddr *hostaddr, u_short port, if (readonly || want_cert) goto fail; /* The host is new. */ - if (options.strict_host_key_checking == 1) { + if (options.hash_file) { + debug("Have a new %s host key for %.200s and checking " + "fingerprint against %s.", + type, host, options.hash_file); + fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX); + line = check_host_fingerprint(type, fp, options.hash_file); + if (line >= 1) { + free(fp); + debug("fingerprint matches line %d.", line); + } else { + error("Explicit hash file given and host key " + "does not match.\n" + "Presented with: %s %s\n", + type, fp); + free(fp); + goto fail; + } + } else if (options.strict_host_key_checking == 1) { /* * User has requested strict host key checking. We * will not add the host key automatically. The only -- 1.8.5.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From mfriedl at gmail.com Tue Feb 18 20:26:58 2014 From: mfriedl at gmail.com (Markus Friedl) Date: Tue, 18 Feb 2014 10:26:58 +0100 Subject: 3des cipher and DH group size In-Reply-To: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> Message-ID: <8459C525-16D6-484B-8346-7899BA4A3062@gmail.com> Am 04.02.2014 um 16:58 schrieb Hubert Kario : > Continuing the discussion from https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032037.html > > I have looked at the changes made to implement automatic selection of DH > groups and there are few changes confusing to me, to say the least. > > Especially 1.97~1.96 rev diff of kex.c: > >> + dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher)); > > Why "MAX("? Why security of chosen dh moduli should match the _most_ > secure primitive? Since DH KEX is computationally expensive (think smartphones), > shouldn't we try to use as small DH parameters as possible? I don?t understand your excitement. I chose MAX() here, because the old release did the same. The old release basically did need = MAX(enckeylen, block size, ivlen, mackeylen) and all I did was to replace enckeylen (192 bits for 3DES) with cipher_seclen (112 bits). You might argue that the old code was wrong, but I chose a minimal change to fall back to a conservative choice. -m From hkario at redhat.com Tue Feb 18 22:54:21 2014 From: hkario at redhat.com (Hubert Kario) Date: Tue, 18 Feb 2014 06:54:21 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <1802254039.3475993.1392391881578.JavaMail.zimbra@redhat.com> <1677660397.3569979.1392401944399.JavaMail.zimbra@redhat.com> <1404053680.4431123.1392657647128.JavaMail.zimbra@redhat.com> Message-ID: <125638473.4855593.1392724461093.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Damien Miller" > To: "Hubert Kario" > Cc: "mancha" , openssh-unix-dev at mindrot.org > Sent: Tuesday, 18 February, 2014 4:53:42 AM > Subject: Re: 3des cipher and DH group size > > On Mon, 17 Feb 2014, Hubert Kario wrote: > > > > I choose standards and objective guidelines over your personal > > > definitions of "relatively secure" and "normal person". > > > > The standards say quite explicitly: iff 3DES => 2k DH. iff AES-128 => 3k > > DH. > > They don't say if SHA-1 MAC => 7k DH. > > > > But that's what current code is doing. > > > > FIPS (it even has "Standard" in the name) says that we shouldn't use > > DH with keys over 3072 bits, ever. Why you're not following it? > > FIPS always lags good practice. E.g. permitting single DES until 2007. I was trying to show that even when you "choose standards" you still have a lot of space for interpretation, not to mention you have to choose which standards you want to follow, as more often that not, they are incompatible between each other. -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From hkario at redhat.com Wed Feb 19 00:10:17 2014 From: hkario at redhat.com (Hubert Kario) Date: Tue, 18 Feb 2014 08:10:17 -0500 (EST) Subject: 3des cipher and DH group size In-Reply-To: <8459C525-16D6-484B-8346-7899BA4A3062@gmail.com> References: <977519298.13108849.1391529504617.JavaMail.root@redhat.com> <8459C525-16D6-484B-8346-7899BA4A3062@gmail.com> Message-ID: <807711002.4883258.1392729017949.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Markus Friedl" > To: "Hubert Kario" > Cc: openssh-unix-dev at mindrot.org > Sent: Tuesday, 18 February, 2014 10:26:58 AM > Subject: Re: 3des cipher and DH group size > > > Am 04.02.2014 um 16:58 schrieb Hubert Kario : > > > Continuing the discussion from > > https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032037.html > > > > I have looked at the changes made to implement automatic selection of DH > > groups and there are few changes confusing to me, to say the least. > > > > Especially 1.97~1.96 rev diff of kex.c: > > > >> + dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher)); > > > > Why "MAX("? Why security of chosen dh moduli should match the _most_ > > secure primitive? Since DH KEX is computationally expensive (think > > smartphones), > > shouldn't we try to use as small DH parameters as possible? > > I don?t understand your excitement. That wasn't excitement, that was surprise. Also, that were (are) genuine questions. > I chose MAX() here, because the old release did the same. > > The old release basically did > need = MAX(enckeylen, block size, ivlen, mackeylen) > and all I did was to replace enckeylen (192 bits for 3DES) with cipher_seclen > (112 bits). > > You might argue that the old code was wrong, but I chose a minimal change > to fall back to a conservative choice. OK. So, since now the DH group sizes themselves are conservative, perhaps we should revise it? I mean that even when we're using just the cipher key size as the selection criteria for DH key sizes, we still end up with much bigger DH sizes than old openssh proposed. Old openssh: 3des with sha1: 2048 bit DH aes128 with sha1: 2048 bit DH aes192 with sha1: 2048 bit DH aes256 with sha1: 4096 bit DH default (aes128 with md5): 1024 bit DH what I'm saying the code should do: 3des with sha1: 2048 bit DH aes128 with sha1: 3072 bit DH aes192 with sha1: 7680 bit DH aes192 with sha256: 7680 bit DH aes256 with sha1: 8192 bit DH default (aes-128 with md5): 3072 bit DH What the code actually does: 3des with sha1: 7680 bit DH aes128 with sha1: 7680 bit DH aes192 with sha1: 7680 bit DH aes192 with sha256: 8192 bit DH aes256 with sha1: 8192 bit DH default (aes-128 with md5): 3072 bit DH (I'm completely ignoring the fact that if you're connecting to any relatively new openssh you'll get ECDH, not DH by default) -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From hkario at redhat.com Wed Feb 19 00:19:51 2014 From: hkario at redhat.com (Hubert Kario) Date: Tue, 18 Feb 2014 08:19:51 -0500 (EST) Subject: [PATCH] verify against known fingerprints In-Reply-To: <20140218083359.GA49803@redoubt.spodhuis.org> References: <20140218083359.GA49803@redoubt.spodhuis.org> Message-ID: <1326570691.4886491.1392729591292.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Phil Pennock" > To: openssh-unix-dev at mindrot.org > Sent: Tuesday, 18 February, 2014 9:33:59 AM > Subject: [PATCH] verify against known fingerprints > > I've just written this patch, it's undergone minimal testing and "works > for me" and I'm after feedback as to acceptability of approach, anything > I should be doing differently for the feature to be acceptable upstream > and what I should be doing about automated testing. > > Use-case: you have the host's SSH fingerprints via an out-of-band > mechanism which you trust and want to be able to connect and have > verification use those known-good fingerprints and, if they match, > update known_hosts. Since you already have an out-of-band communication, why not provide a pre-populated ~/.ssh/known_hosts file though it? -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From phil.pennock at globnix.org Wed Feb 19 05:29:44 2014 From: phil.pennock at globnix.org (Phil Pennock) Date: Tue, 18 Feb 2014 10:29:44 -0800 Subject: [PATCH] verify against known fingerprints In-Reply-To: <1326570691.4886491.1392729591292.JavaMail.zimbra@redhat.com> References: <20140218083359.GA49803@redoubt.spodhuis.org> <1326570691.4886491.1392729591292.JavaMail.zimbra@redhat.com> Message-ID: <20140218182943.GA57593@redoubt.spodhuis.org> On 2014-02-18 at 08:19 -0500, Hubert Kario wrote: > > I've just written this patch, it's undergone minimal testing and "works > > for me" and I'm after feedback as to acceptability of approach, anything > > I should be doing differently for the feature to be acceptable upstream > > and what I should be doing about automated testing. > > > > Use-case: you have the host's SSH fingerprints via an out-of-band > > mechanism which you trust and want to be able to connect and have > > verification use those known-good fingerprints and, if they match, > > update known_hosts. > > Since you already have an out-of-band communication, why not provide > a pre-populated ~/.ssh/known_hosts file though it? That is what this tool is being used to provide; I have out-of-band trustworthy access to the hostkey fingerprints, nothing else. I am _providing_, to my colleagues, out-of-band SSH configuration and known_hosts. The intent is not that everyone always use this option, but that it be used by the person updating known_hosts. Everyone else just does a `git pull` and a `merge_ssh` from that repo, reviewing output as they see fit. It won't scale to continuously changing sets of hosts, but it will scale well enough for now, and I suspect that any improvement will still leverage this patch because, fundamentally, the only trust anchor information we have access to is the host key fingerprints. The OOB links now are "us to Amazon", which gets me fingerprints, and "between us, using trusted git (with audit history)", which currently risks being a leap of faith. This patch lets me link those two OOB paths, with no leap of faith connecting to machines out in the cloud across networks which we don't control. Without this patch, I can connect, accept, copy out the entry from known_hosts to a file on its own, massage, use ssh-keygen to get a fingerprint and compare to the trusted form; when done, commit to the git repo. It's hassle, I've done it, I want to not make this our procedure which others, less paranoid than I, follow when others are depending on the result. With this change, we're providing the same sort of trust anchoring as VerifyHostKeyDNS, but from a file, so that any kind of user tooling can be used to provide the anchors, instead of DNS+DNSSEC. Work-flow: bring up cluster, use tool to grab hostkey fingerprints for every machine. Add IPs to configuration template, invoke tool to generate/merge SSH configuration. Use new wrapper tool to repeatedly invoke ssh using the new option, grabbing the actual public keys in a verified manner, and prepping an updated configuration for commit. Review, commit, push. Apologies for the verbosity of this email, I'm trying to make it very clear what trust paths do and don't exist and why this patch is Rather Quite Helpful. Think of this patch as "scriptable VerifyHostKeyDNS". -Phil From vinschen at redhat.com Thu Feb 20 19:47:31 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 20 Feb 2014 09:47:31 +0100 Subject: Regression in 6.5p1 when using -W option Message-ID: <20140220084731.GA6385@calimero.vinschen.de> Hi, we got a report on the Cygwin mailing list showing that there's a spurious error message when using the -W option. This didn't occur with OpenSSH 6.4p1. Here's an example: $ ssh machine1 -W machine2:22 getsockname failed: Bad file descriptor SSH-2.0-OpenSSH_6.1 The error message is a result of getsockname being called with a file descriptor -1. The call stack at the time looks like this: Breakpoint 2, get_socket_address (sock=-1, remote=remote at entry=0, flags=flags at entry=2) at /usr/src/debug/openssh-6.5p1-1/canohost.c:256 256 if (getsockname(sock, (struct sockaddr *)&addr, &addrlen) (gdb) bt #0 get_socket_address (sock=-1, remote=remote at entry=0, flags=flags at entry=2) at /usr/src/debug/openssh-6.5p1-1/canohost.c:256 #1 0x0000000100432213 in get_local_ipaddr (sock=) at /usr/src/debug/openssh-6.5p1-1/canohost.c:292 #2 0x0000000100418db5 in port_open_helper (c=c at entry=0x600074700, rtype=rtype at entry=0x10045fe0d "direct-tcpip") at /usr/src/debug/openssh-6.5p1-1/channels.c:1388 #3 0x000000010041dc07 in channel_connect_stdio_fwd ( host_to_connect=0x600039800 "machine2", port_to_connect=22, in=in at entry=4, out=5) at /usr/src/debug/openssh-6.5p1-1/channels.c:1269 #4 0x0000000100401566 in ssh_init_stdio_forwarding () at /usr/src/debug/openssh-6.5p1-1/ssh.c:1260 #5 0x0000000100454171 in ssh_session2 () at /usr/src/debug/openssh-6.5p1-1/ssh.c:1606 #6 main (ac=, av=) at /usr/src/debug/openssh-6.5p1-1/ssh.c:1130 This is not Cygwin specific. To be really sure I tested this on Linux and the message shows up, too, while it doesn't with 6.4p1. The problem is still present in current portable CVS. The reason is that port_open_helper calls get_local_ipaddr on c->socl unconditionally in port_open_helper without checking the value of c->sock first. I didn't generate a patch because I'm not really sure what's the best way to fix this issue. Hope that helps nevertheless. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From list at eworm.de Thu Feb 20 20:07:57 2014 From: list at eworm.de (Christian Hesse) Date: Thu, 20 Feb 2014 10:07:57 +0100 Subject: [PATCH 1/1] rework printing for visual host key upper border In-Reply-To: <1390908137-2443-1-git-send-email-mail@eworm.de> References: <1390908137-2443-1-git-send-email-mail@eworm.de> Message-ID: <20140220100757.050ed6b9@leda.localdomain> Christian Hesse on Tue, 2014/01/28 12:22: > Key types are getting longer and the current implementation of visual > host key breaks with ED25519, resulting in (note the missing bracket): > > +--[ED25519 256--+ > > This reworks the calculation of visual host key upper border. Please be > aware that this may change the output for other key types as well. Wondering if this is in anybody'y queue... Or did I post to the wrong place? Any reason not to apply this? -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);} -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From dtucker at zip.com.au Thu Feb 20 20:07:11 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 20 Feb 2014 20:07:11 +1100 Subject: Regression in 6.5p1 when using -W option In-Reply-To: <20140220084731.GA6385@calimero.vinschen.de> References: <20140220084731.GA6385@calimero.vinschen.de> Message-ID: On Thu, Feb 20, 2014 at 7:47 PM, Corinna Vinschen wrote: > Hi, > > we got a report on the Cygwin mailing list showing that there's a > spurious error message when using the -W option. This didn't occur with > OpenSSH 6.4p1. Here's an example: > > $ ssh machine1 -W machine2:22 > getsockname failed: Bad file descriptor Thanks for the report. This is https://bugzilla.mindrot.org/show_bug.cgi?id=2200, the fix for which has just been committed. -- 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 Thu Feb 20 20:24:36 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 20 Feb 2014 10:24:36 +0100 Subject: Regression in 6.5p1 when using -W option In-Reply-To: References: <20140220084731.GA6385@calimero.vinschen.de> Message-ID: <20140220092436.GF2246@calimero.vinschen.de> On Feb 20 20:07, Darren Tucker wrote: > On Thu, Feb 20, 2014 at 7:47 PM, Corinna Vinschen wrote: > > Hi, > > > > we got a report on the Cygwin mailing list showing that there's a > > spurious error message when using the -W option. This didn't occur with > > OpenSSH 6.4p1. Here's an example: > > > > $ ssh machine1 -W machine2:22 > > getsockname failed: Bad file descriptor > > Thanks for the report. This is > https://bugzilla.mindrot.org/show_bug.cgi?id=2200, the fix for which > has just been committed. Yes, that fixes it. Any chance for a bugfix release? Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dtucker at zip.com.au Thu Feb 20 20:32:45 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 20 Feb 2014 20:32:45 +1100 Subject: Regression in 6.5p1 when using -W option In-Reply-To: <20140220092436.GF2246@calimero.vinschen.de> References: <20140220084731.GA6385@calimero.vinschen.de> <20140220092436.GF2246@calimero.vinschen.de> Message-ID: On Thu, Feb 20, 2014 at 8:24 PM, Corinna Vinschen wrote: > On Feb 20 20:07, Darren Tucker wrote: [...] >> > getsockname failed: Bad file descriptor >> >> Thanks for the report. This is >> https://bugzilla.mindrot.org/show_bug.cgi?id=2200, the fix for which >> has just been committed. > > Yes, that fixes it. Any chance for a bugfix release? I think the plan (Damien can correct me if I'm wrong) was to do another release to coincide with the next OpenBSD release (ie in the next month or so) picking up all the changes up to that point. -- 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 Yogendra.Kumar at ncr.com Thu Feb 20 23:53:17 2014 From: Yogendra.Kumar at ncr.com (Kumar, Yogendra) Date: Thu, 20 Feb 2014 07:53:17 -0500 Subject: Question Regarding open SSH Message-ID: <0270B60DC8448C4EA47D54E8CA8C55478C96FB072D@susday218.corp.ncr.com> Hi Team, We are facing problem of an open ssh process hung at client end. We do not know why these process are going to hung state while we tried to connect at customer server simultaneously multiple connections. Is there any configuration at client side so that we can kill or reprocess hung process through client end configuration because it very difficult make any change at server end means customer end. Thanks Yogi From ronf at timeheart.net Fri Feb 21 14:37:30 2014 From: ronf at timeheart.net (Ron Frederick) Date: Thu, 20 Feb 2014 19:37:30 -0800 Subject: Regression in 6.5p1 when using -W option In-Reply-To: References: <20140220084731.GA6385@calimero.vinschen.de> <20140220092436.GF2246@calimero.vinschen.de> Message-ID: On Thu, Feb 20, 2014 at 8:24 PM, Corinna Vinschen wrote: > On Feb 20 20:07, Darren Tucker wrote: [...] >>> getsockname failed: Bad file descriptor >> >> Thanks for the report. This is >> https://bugzilla.mindrot.org/show_bug.cgi?id=2200, the fix for which >> has just been committed. > > Yes, that fixes it. Any chance for a bugfix release? Note that get_peer_port() called just after this to get the remote port also calls get_sock_port() and would potentially have a similar issue. However, it appears in that case that it only outputs a debug message rather than calling error(). Also, I see cases where these functions return either -1 or 65535 when they aren?t called on a socket. I wonder if the check here should be made consistent with that. See functions like get_port() at the bottom of canohost.c, or the ?return -1? in get_sock_port() itself when getpeername() fails. -- Ron Frederick ronf at timeheart.net From bdrewery at FreeBSD.org Sat Feb 22 02:12:54 2014 From: bdrewery at FreeBSD.org (Bryan Drewery) Date: Fri, 21 Feb 2014 09:12:54 -0600 Subject: [PATCH] Fix configure warning on FreeBSD Message-ID: <53076CF6.2000809@FreeBSD.org> Hi, Please commit the attached, it fixes a warning on FreeBSD: ./configure: ],: not found Mirrored here: https://github.com/bdrewery/openssh-portable/commit/5860048c64fd41005697473d4985efa454a191c5.patch Thanks! Bryan Drewery -------------- next part -------------- commit 5860048c64fd41005697473d4985efa454a191c5 Author: Bryan Drewery Date: Fri Feb 21 09:08:41 2014 -0600 Remove stray ], in SANDBOX_SKIP_RLIMIT_NOFILE AC_DEFINE diff --git configure.ac configure.ac index 0dd3f45..3e522e5 100644 --- configure.ac +++ configure.ac @@ -785,7 +785,7 @@ mips-sony-bsd|mips-sony-newsos4) # Preauth crypto occasionally uses file descriptors for crypto offload # and will crash if they cannot be opened. AC_DEFINE([SANDBOX_SKIP_RLIMIT_NOFILE], [1], - [define if setrlimit RLIMIT_NOFILE breaks things])], + [define if setrlimit RLIMIT_NOFILE breaks things]) ;; *-*-bsdi*) AC_DEFINE([SETEUID_BREAKS_SETUID]) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: From tim at multitalents.net Sat Feb 22 04:12:17 2014 From: tim at multitalents.net (Tim Rice) Date: Fri, 21 Feb 2014 09:12:17 -0800 (PST) Subject: [PATCH] Fix configure warning on FreeBSD In-Reply-To: <53076CF6.2000809@FreeBSD.org> References: <53076CF6.2000809@FreeBSD.org> Message-ID: On Fri, 21 Feb 2014, Bryan Drewery wrote: > Hi, > > Please commit the attached, it fixes a warning on FreeBSD: > ./configure: ],: not found Thanks for spotting that. Commited. It will show up in the next snapshot. -- Tim Rice Multitalents tim at multitalents.net From andromeda_862000 at yahoo.com Tue Feb 25 02:55:58 2014 From: andromeda_862000 at yahoo.com (Paun Bogdan-Alexandru) Date: Mon, 24 Feb 2014 07:55:58 -0800 (PST) Subject: loginrec.c: bug in construct_utmpx() definition? Message-ID: <1393257358.85261.YahooMailNeo@web140106.mail.bf1.yahoo.com> Hello, I am trying to cross compile OpenSSH_5.8p2 on linux for a powerpc target with uClibc available. My problem is that I get a error when loginrec.c is compiled: openssh/loginrec.c: In function 'construct_utmpx': openssh/loginrec.c:790:10: error: 'ut' undeclared (first use in this function) openssh/loginrec.c:790:10: note: each undeclared identifier is reported only once for each function it appears in My uClibc config includes support for UTMPX. Looking in openssh/loginrec.c at the mentioned line I see that 'ut' structure pointer name is used when HAVE_ADDR_V6_IN_UTMP is defined while in in the rest of the function only 'utx' is used. For my inexperienced coding skills this looks like a bug, wrong variable name 'ut' is used over 'utx'. Changing that code to use 'utx' instead of of 'ut' will lead to a successful compilation of the whole SSH package. I checked and that chunk of code is still unchanged in OpenSSH_6.5p1. However I am not sure if my attempt to fix the error is the correct way so I would really appreciate if someone could help me with this. Thanks for this great software, Bogdan Paun From carsten at wieschiolek.de Wed Feb 26 03:18:43 2014 From: carsten at wieschiolek.de (Carsten Wieschiolek) Date: Tue, 25 Feb 2014 17:18:43 +0100 Subject: Bug: Environment vars are changed before use (locale LANG, LC_*) Message-ID: <530CC263.1000106@wieschiolek.de> Hi I am using OpenSSH_6.2p2 Ubuntu-6ubuntu0.1, OpenSSL 1.0.1e 11 Feb 2013 on a Ubuntu 13.10 release for access to various kinds of systems. This recent Ubuntu OS insists on standard conforming locales, i.e. de_DE.UTF-8 instead of de_DE.utf8 as in the previous release. When I am using SSH to communicate with another system not being able to process the standard conformant setting (in my case HP-UX B.11.31), problems arise, because the new setting cannot be processed. Even when I am specifying the variable in the environment file of SSH in a form usable by the remote system, they are changed into the standard conformant setting first, before being transferred. This is a bug, because these environment variables are intended to be processed on the remote system as given in the local file. SSH should keep the values in the original format specified and rely on translation by the remote system. It is pointless to use setlocale(3) locally. Best Regards C. Wieschiolek From jonathan.P.schaaf at ge.com Wed Feb 26 07:54:58 2014 From: jonathan.P.schaaf at ge.com (Schaaf, Jonathan P (GE Healthcare)) Date: Tue, 25 Feb 2014 20:54:58 +0000 Subject: [ DRAFT PATCH ] - FIPS 140-2 patch for OpenSSH 6.5p1 In-Reply-To: <5301FAF3.8020802@opensslfoundation.com> References: <2977089f92c3694b8d6c506fef3e3639@mail.gmail.com> <5301FAF3.8020802@opensslfoundation.com> Message-ID: > Then there is the additional consideration that FIPS 140-2 is only desirable in a context (USG and DoD) > where x.509 support is also mandatory. OpenSSH has adopted a different (and more robust) certificate > scheme. FIPS 140-2 has always been focused on compliance to a specific ritualized policy and process, > and thus is necessarily less secure in an absolute sense, while OpenSSH is focused on real-world security. > IMHO that discrepancy will probably continue to grow. > So while it remains technically possible to jam the round OpenSSH peg into the square FIPS 140-2 hole, > I'm no longer sure it makes sense to attempt it in the baseline OpenSSH. What the government asks for in any given situation can be highly variable, and in many cases what they explicitly ask for is a round peg squashed into the square hole. I for one am very interested in seeing patches of this nature continue to be maintained. From marquess at opensslfoundation.com Thu Feb 27 00:40:46 2014 From: marquess at opensslfoundation.com (Steve Marquess) Date: Wed, 26 Feb 2014 08:40:46 -0500 Subject: [ DRAFT PATCH ] - FIPS 140-2 patch for OpenSSH 6.5p1 In-Reply-To: References: <2977089f92c3694b8d6c506fef3e3639@mail.gmail.com> <5301FAF3.8020802@opensslfoundation.com> Message-ID: <530DEEDE.1050903@opensslfoundation.com> On 02/25/2014 03:54 PM, Schaaf, Jonathan P (GE Healthcare) wrote: >> Then there is the additional consideration that FIPS 140-2 is only >> desirable in a context (USG and DoD) where x.509 support is also >> mandatory. OpenSSH has adopted a different (and more robust) >> certificate scheme. FIPS 140-2 has always been focused on >> compliance to a specific ritualized policy and process, and thus is >> necessarily less secure in an absolute sense, while OpenSSH is >> focused on real-world security. IMHO that discrepancy will probably >> continue to grow. > >> So while it remains technically possible to jam the round OpenSSH >> peg into the square FIPS 140-2 hole, I'm no longer sure it makes >> sense to attempt it in the baseline OpenSSH. > > What the government asks for in any given situation can be highly > variable, and in many cases what they explicitly ask for is a round > peg squashed into the square hole. How true, and the formal requirements are widely ignored or circumvented. For instance I've been told by many vendors that most of their customers never enable the FIPS mode of operation at runtime. > I for one am very interested in > seeing patches of this nature continue to be maintained. Good point; I should make it clear that I'm not opposed to the continued existence and maintenance of those patches per se. There are many OpenSSH users who have no choice about the constraints imposed by those USG/DoD policies. So the patches serve an important role. However, I'm no longer sure it makes sense to compromise and distort the baseline OpenSSH (or OpenSSL for that matter) to accommodate arbitrary policies that are indifferent or hostile to best security practices. In the case of OpenSSL I have to reluctantly admit that support of the FIPS 140-2 validated module has to some extent impacted the quality of the overall OpenSSL product. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc