From calestyo at scientia.net Sat Nov 1 11:10:42 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 01 Nov 2014 01:10:42 +0100 Subject: ssh_config way to run command before connecting or "around" the connection? In-Reply-To: References: <1414713417.4581.2.camel@scientia.net> <20141031005841.GB6476@linux124.nas.nasa.gov> Message-ID: <1414800642.4541.1.camel@scientia.net> Hey Shawn. On Fri, 2014-10-31 at 06:59 -0400, shawn wilson wrote: > Just to add - google "ppp over ssh" or similar and you'll get tons of > examples (note, don't do the ppp thing if you have tap/tun) What exactly do you mean? I've looked through the top 10-15 websites about that topic, but nothing of this seems to do what I try to solve? Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From maillist-openssh at barfooze.de Mon Nov 3 10:51:34 2014 From: maillist-openssh at barfooze.de (John Spencer) Date: Mon, 03 Nov 2014 00:51:34 +0100 Subject: [BUG] openssh portable configure script disrespects/mispositions user's LDFLAGS Message-ID: <5456C386.8040904@barfooze.de> hello. when trying to add a custom -l flag thats needed for my setup, i noticed that 1) openssh's configure script ignores LDFLAGS passed via environment variables. this is contrary to the expectation of the user and to the behaviour of 99% of autoconf based packages. 2) the LDFLAGS passed via the special --with-ldflags options are not used in the last place on the command line, rendering any -l flags passed unfunctional, because the .c file is passed as last element. that way user passed libraries cannot satisfy missing link dependencies because for static libraries the order on the command line is crucial. example: if i use --with-ldflags=-lfoo the configure tests will look like gcc -lfoo conftest.c and thus references of conftest.c to symbols in libfoo.a not satisfied. that makes it impossible to feed missing libraries manually into the build process without patching the configure script. (in my case the library i want to inject into the build process is related to the stack protector feature of gcc, but there are plenty of other uses, for example when trying to use a static linked openssl/libressl which depends on libz.a or similar). --JS From peter at stuge.se Mon Nov 3 22:30:47 2014 From: peter at stuge.se (Peter Stuge) Date: Mon, 3 Nov 2014 12:30:47 +0100 Subject: [BUG] openssh portable configure script disrespects/mispositions user's LDFLAGS In-Reply-To: <5456C386.8040904@barfooze.de> References: <5456C386.8040904@barfooze.de> Message-ID: <20141103113047.31475.qmail@stuge.se> John Spencer wrote: > 1) openssh's configure script ignores LDFLAGS passed via environment > variables. this is contrary to the expectation of the user and to the > behaviour of 99% of autoconf based packages. > > 2) the LDFLAGS passed via the special --with-ldflags options are not used > in the last place on the command line, Does LIBS work? //Peter From vinschen at redhat.com Mon Nov 3 22:32:13 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 3 Nov 2014 12:32:13 +0100 Subject: [patch/cygwin] Update ssh-user-config for the account db changes in the upcoming Cygwin Message-ID: <20141103113213.GT14051@calimero.vinschen.de> Hi, below is a patch which makes the Cygwin-specific ssh-user-config script independent of the existence of /etc/passwd. The next Cygwin release will allow to generate passwd and group entries from the Windows account DBs, so the scripts have to adapt. Please apply. Thanks, Corinna diff --git a/contrib/cygwin/ssh-host-config b/contrib/cygwin/ssh-host-config index a7ea3e0..301d5eb 100644 --- a/contrib/cygwin/ssh-host-config +++ b/contrib/cygwin/ssh-host-config @@ -1,6 +1,6 @@ #!/bin/bash # -# ssh-host-config, Copyright 2000-2011 Red Hat Inc. +# ssh-host-config, Copyright 2000-2014 Red Hat Inc. # # This file is part of the Cygwin port of OpenSSH. # @@ -353,11 +353,9 @@ check_service_files_ownership() { fi if [ -z "${run_service_as}" ] then - csih_warning "Couldn't determine name of user running sshd service from /etc/passwd!" + csih_warning "Couldn't determine name of user running sshd service from account database!" csih_warning "As a result, this script cannot make sure that the files used" csih_warning "by the sshd service belong to the user running the service." - csih_warning "Please re-run the mkpasswd tool to make sure the /etc/passwd" - csih_warning "file is in a good shape." return 1 fi fi diff --git a/contrib/cygwin/ssh-user-config b/contrib/cygwin/ssh-user-config index 8708b7a..33dc0cb 100644 --- a/contrib/cygwin/ssh-user-config +++ b/contrib/cygwin/ssh-user-config @@ -1,6 +1,6 @@ #!/bin/bash # -# ssh-user-config, Copyright 2000-2008 Red Hat Inc. +# ssh-user-config, Copyright 2000-2014 Red Hat Inc. # # This file is part of the Cygwin port of OpenSSH. # @@ -75,19 +75,18 @@ readonly -f create_identity # pwdhome # ====================================================================== check_user_homedir() { - local uid=$(id -u) - pwdhome=$(awk -F: '{ if ( $3 == '${uid}' ) print $6; }' < ${SYSCONFDIR}/passwd) + pwdhome=$(getent passwd $UID | awk -F: '{ print $6; }') if [ "X${pwdhome}" = "X" ] then csih_error_multi \ - "There is no home directory set for you in ${SYSCONFDIR}/passwd." \ + "There is no home directory set for you in the account database." \ 'Setting $HOME is not sufficient!' fi if [ ! -d "${pwdhome}" ] then csih_error_multi \ - "${pwdhome} is set in ${SYSCONFDIR}/passwd as your home directory" \ + "${pwdhome} is set in the account database as your home directory" \ 'but it is not a valid directory. Cannot create user identity files.' fi @@ -96,7 +95,7 @@ check_user_homedir() { if [ "X${pwdhome}" = "X/" ] then # But first raise a warning! - csih_warning "Your home directory in ${SYSCONFDIR}/passwd is set to root (/). This is not recommended!" + csih_warning "Your home directory in the account database is set to root (/). This is not recommended!" if csih_request "Would you like to proceed anyway?" then pwdhome='' @@ -106,7 +105,7 @@ check_user_homedir() { fi fi - if [ -d "${pwdhome}" -a csih_is_nt -a -n "`chmod -c g-w,o-w "${pwdhome}"`" ] + if [ -d "${pwdhome}" -a -n "`chmod -c g-w,o-w "${pwdhome}"`" ] then echo csih_warning 'group and other have been revoked write permission to your home' @@ -149,9 +148,10 @@ readonly -f check_user_dot_ssh_dir # pwdhome -- check_user_homedir() # ====================================================================== fix_authorized_keys_perms() { - if [ csih_is_nt -a -e "${pwdhome}/.ssh/authorized_keys" ] + if [ -e "${pwdhome}/.ssh/authorized_keys" ] then - if ! setfacl -m "u::rw-,g::---,o::---" "${pwdhome}/.ssh/authorized_keys" + setfacl -b "${pwdhome}/.ssh/authorized_keys" 2>/dev/null || echo -n + if ! chmod u-x,g-wx,o-wx "${pwdhome}/.ssh/authorized_keys" then csih_warning "Setting correct permissions to ${pwdhome}/.ssh/authorized_keys" csih_warning "failed. Please care for the correct permissions. The minimum requirement" @@ -243,15 +243,6 @@ done # Action! # ====================================================================== -# Check passwd file -if [ ! -f ${SYSCONFDIR}/passwd ] -then - csih_error_multi \ - "${SYSCONFDIR}/passwd is nonexistant. Please generate an ${SYSCONFDIR}/passwd file" \ - 'first using mkpasswd. Check if it contains an entry for you and' \ - 'please care for the home directory in your entry as well.' -fi - check_user_homedir check_user_dot_ssh_dir create_identity id_rsa rsa "SSH2 RSA" -- 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 scott_n at xypro.com Tue Nov 4 03:02:32 2014 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 3 Nov 2014 16:02:32 +0000 Subject: [BUG] openssh portable configure script disrespects/mispositions user's LDFLAGS In-Reply-To: <20141103113047.31475.qmail@stuge.se> References: <5456C386.8040904@barfooze.de> <20141103113047.31475.qmail@stuge.se> Message-ID: I'd like to throw in a plug for bug 2261 at this point as well. Configure has a general issue with ignoring or overriding command line options. -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On Behalf Of Peter Stuge Sent: Monday, November 03, 2014 3:31 AM To: openssh-unix-dev at mindrot.org Subject: Re: [BUG] openssh portable configure script disrespects/mispositions user's LDFLAGS John Spencer wrote: > 1) openssh's configure script ignores LDFLAGS passed via environment > variables. this is contrary to the expectation of the user and to the > behaviour of 99% of autoconf based packages. > > 2) the LDFLAGS passed via the special --with-ldflags options are not > used in the last place on the command line, Does LIBS work? //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From rmccorkell at karoshi.org.uk Tue Nov 4 02:09:34 2014 From: rmccorkell at karoshi.org.uk (Robin McCorkell) Date: Mon, 3 Nov 2014 15:09:34 +0000 Subject: CanonicalizeHostname issues with multiple config blocks Message-ID: When using the CanonicalizeHostname and CanonicalDomains directives, the options parsed before the hostname is canonicalized cannot be overridden by more specific blocks after canonicalization. For example: CanonicalizeHostname yes CanonicalDomains foo.bar.com Host *.foo.bar.com GSSAPIAuthentication yes Host * GSSAPIAuthentication no If connecting to 'srv.foo.bar.com', then GSSAPI authentication is enabled. But connecting to 'srv', even though it is canonicalized correctly to ' srv.foo.bar.com', does not enable GSSAPI authentication as the 'Host *' block is parsed before canonicalization and cannot be then overridden by the more specific block. This behaviour was tested with OpenSSH 6.7 on Arch Linux. Thanks, Robin McCorkell The Linux Schools Project http://www.linuxschools.com https://github.com/the-linux-schools-project From mail at ojkastl.de Tue Nov 4 06:14:23 2014 From: mail at ojkastl.de (Johannes Kastl) Date: Mon, 03 Nov 2014 20:14:23 +0100 Subject: Unable to use ssh-agent with confirmation, when logged in on a virtual terminal Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good evening, sorry if this is the wrong list, I found none that seemed to fit better. I am trying to get ssh-add with the -c option to work. But I always get this error: > Agent admitted failure to sign using the key. But to start from the beginning. ################################# On my linux machines (e.g. laptops, ...) I can login without an X session started/used. The ssh-agent is started from .bashrc. I can then add an identity with > ssh-add -c /path/to/keyfile I try to connect to another server, then the error appears. I delete the identity from ssh-agent, and add it again without the -c: > ssh-add /path/to/keyfile And suddenly I can connect without any errors. ################################# - - I see this on different machines, mostly running openSUSE. Some are running ArchLinux, some fedora. All show this error. - - I see this on physical machines, virtual machines connected via a console (libvirt/kvm) - - I get a prompt when trying this using KDE, but although I give my password, the error appears - - I also see this if I start a new bash via > ssh-agent bash So, I'm puzzled. And I do not know how to debug this. Or where to start. Or if I understood something completely wrong about the -c option. Any hints, tipps, tricks are highly appreciated. If you need more information, please dont hesitate to ask. Thanks in advance. Regards, Johannes - -- Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. (Terry Pratchett: The Truth) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlRX1A8ACgkQzi3gQ/xETbJ+cwCfb/7uiIfrkeMdgA4u8xialkgb gOcAn3XxMFLgOJG0SmR0CLLUR7r5k9c+ =RJFL -----END PGP SIGNATURE----- From keisial at gmail.com Tue Nov 4 09:26:36 2014 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Mon, 03 Nov 2014 23:26:36 +0100 Subject: Unable to use ssh-agent with confirmation, when logged in on a virtual terminal In-Reply-To: References: Message-ID: <5458011C.8060404@gmail.com> On 03/11/14 20:14, Johannes Kastl wrote: > Good evening, > > sorry if this is the wrong list, I found none that seemed to fit better. It's the right list. > I am trying to get ssh-add with the -c option to work. But I always > get this error: >> Agent admitted failure to sign using the key. > But to start from the beginning. > > ################################# > > On my linux machines (e.g. laptops, ...) I can login without an X > session started/used. (...) (and instead of asking for confirmation, agent requests fail) > So, I'm puzzled. And I do not know how to debug this. Or where to > start. Or if I understood something completely wrong about the -c option. > > Any hints, tipps, tricks are highly appreciated. If you need more > information, please dont hesitate to ask. > > Thanks in advance. The reason is hidden inside ssh-add(1): > -c Indicates that added identities should be subject to confirmation > before being used for authentication. Confirmation is performed by the > SSH_ASKPASS program > mentioned below. Successful confirmation is signaled by a zero exit > status from the SSH_ASKPASS program, rather than text entered into the > requester. > DISPLAY and SSH_ASKPASS > If ssh-add needs a passphrase, it will read the passphrase from the > current terminal if it was run from a terminal. If ssh-add does not > have a terminal associated with it but DISPLAY and SSH_ASKPASS are > set, it will execute the program specified by SSH_ASKPASS and open an > X11 window to read the passphrase. This is particularly useful when > calling ssh-add from a .xsession or related script. (Note that on some > machines it may be necessary to redirect the input from /dev/null to > make this work.) the man page mixes the request for the key password and the confirmation prompt, and it can be hard to notice, but ssh-agent is calling the X program defined by SSH_ASKPASS variable (defaulting to ssh-askpass). As you are using a virtual terminal, you don't have a X11 connection where you could be prompt, and thus the agent automatically rejects the signing. (confirm_key ? ask_permission ? read_passphrase(, RP_USE_ASKPASS) [ssh-agent.c:202, readpass.c:180,144]) What you can do is to set SSH_ASKPASS to a cli program that requests the confirmation, also you will need to set DISPLAY to some dummy value, since $SSH_ASKPASS won't even be called if the DISPLAY variable is not set. Another solution would be to change openssh to fall back to getpass(1) for ask_permission requests if $DISPLAY is not available, but given that the code explicitly checks that, the developers may have reasons for not doing that (the prompts would on the screen where the agent was originally launched, which -depending on what is running there now- can get messy, but that seems better than not allowing ssh-add -c at all). Best regards From peter at pean.org Tue Nov 4 22:20:59 2014 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Tue, 04 Nov 2014 12:20:59 +0100 Subject: Host based authentication and SSH CA. Message-ID: <5458B69B.8060409@pean.org> Hi, Im currently deploying signed host keys for my environment. Everything seems to work fine but I have one problem with host based authentication. Im running OpenSSH_6.5p1, OpenSSL 1.0.1e-fips 11 Feb 2013 on RHEL 6.5. When trying to login between hosts with host-based authentication configured I cant do so if the host is not in /etc/ssh_knows_hosts. If its there it works even if the public key is wrong. It should be enough to have a single "@cert-authority" line in ssh_known_hosts right? m1# ssh m3 -v ... debug1: Host 'm3' is known and matches the RSA-CERT host certificate. debug1: Found CA key in /etc/ssh/ssh_known_hosts:1 ... debug1: ssh_rsa_verify: signature correct ----- m3# /usr/sbin/sshd -dd ... debug3: load_hostkeys: loading entries for host "m1" from file "/etc/ssh/ssh_known_hosts" debug3: load_hostkeys: found ca key type RSA in file /etc/ssh/ssh_known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug1: check_key_in_hostfiles: key for host m1 not found debug1: check_key_in_hostfiles: key for host m1 not found Why cant I use the CA for host based auth? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3738 bytes Desc: S/MIME Cryptographic Signature URL: From dkg at fifthhorseman.net Wed Nov 5 01:57:05 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 04 Nov 2014 09:57:05 -0500 Subject: ssh-add 6.7 inserts RSA keys into the ssh-agent as "rsa w/o comment" instead of filenames Message-ID: <87h9yfrp32.fsf@alice.fifthhorseman.net> Hi OpenSSH folks-- as of version 6.7 (the first version i noticed this in), it looks to me like adding ssh keys to ssh-agent marks them all as "rsa w/o comment", instead of putting the filename as the comment. This appears to be because of the key function overhaul in 8668706d0f52654fe64c0ca41a96113aeab8d2b8. ssh-add.c loads the secret keys via library-like invocations of functions in sshkey.c, and if the comment returned is NULL, it sets the comment to be the filename. But in practice, these functions now return "rsa w/o comment" as the comment, so the filename never gets applied as a comment. Possible ways to fix: * One fix would be to have the functions return a NULL for the comment. * Another fix would be to have ssh-add just override the comment explicitly. * A third fix would be to pass a "proposed comment" into the library-like call, which could be overridden by future versions if they're aware of a superior comment after having parsed the key. I also note that there is no way for a user of ssh-add to explicitly set the comment directly -- adding something like that would be a distinct feature, i think. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From mail at ojkastl.de Wed Nov 5 06:05:13 2014 From: mail at ojkastl.de (Johannes Kastl) Date: Tue, 04 Nov 2014 20:05:13 +0100 Subject: Unable to use ssh-agent with confirmation, when logged in on a virtual terminal In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good evening, On 03.11.2014 Johannes Kastl wrote: > I am trying to get ssh-add with the -c option to work. But I > always get this error: >> Agent admitted failure to sign using the key. Mark and Angel replied on and off the list, and both suggested that the SSH_ASKPASS variable is set wrong. I thought that these variables are for using *graphical* programs to ask for the passphrase. And on most of my machines, no X server is even installed. So I thought these variables are not necessary, and it does not matter it they are empty. As I replied to Angel, I would have thought that there is a fallback, but apparently this is not the case. Or it is not working. However, when I set SSH_ASKPASS to /usr/lib/ssh/ssh-askpass and the DISPLAY variable to 'foo', I still get the error. I noticed that on the one machine with the graphical gui, I get the prompt via kwallet (KDE's password safe), but it is enough to click OK to allow this request. But I had to unlock my password safe first. And the SSH_ASKPASS variable is set to /usr/lib/ssh/ssh-askpass on this machine. So maybe this is really just a prompt for machines with a running X server... Regards, Johannes - -- Coming back to where you started is not the same as never leaving. (Terry Pratchett) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlRZI2gACgkQzi3gQ/xETbIhDQCeLIoNjCQzwExdizHEbKGC22Jq zhUAnRakl3qIncNvWRaQRao3/f3J3K+/ =FK4z -----END PGP SIGNATURE----- From keisial at gmail.com Wed Nov 5 06:45:41 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 04 Nov 2014 20:45:41 +0100 Subject: Unable to use ssh-agent with confirmation, when logged in on a virtual terminal In-Reply-To: References: Message-ID: <54592CE5.5010406@gmail.com> Johannes Kastl wrote: > On 03.11.2014 Johannes Kastl wrote: > >> I am trying to get ssh-add with the -c option to work. But I >> always get this error: >>> Agent admitted failure to sign using the key. > Mark and Angel replied on and off the list, and both suggested that > the SSH_ASKPASS variable is set wrong. > > I thought that these variables are for using *graphical* programs to > ask for the passphrase. And on most of my machines, no X server is > even installed. So I thought these variables are not necessary, and it > does not matter it they are empty. > > As I replied to Angel, I would have thought that there is a fallback, > but apparently this is not the case. Or it is not working. There's no fallback. > However, when I set SSH_ASKPASS to /usr/lib/ssh/ssh-askpass and the > DISPLAY variable to 'foo', I still get the error. /usr/lib/ssh/ssh-askpass is a graphical application, so it won't work on the console. Try using: DISPLAY=foo SSH_ASKPASS=/bin/true ssh-agent bash > ssh-add -c /path/to/keyfile > ssh machine This time it should work (works here). Using /bin/true means that it will always answer "yes", but enough to show it is working. You should instead make a program using getpass(2) or maybe a shell script that asks you. The SSH_ASKPASS should print the text written on stdin, and return the user answer on stdout (the agent will sign the key if it is "yes" or an empty string). > I noticed that on the one machine with the graphical gui, I get the > prompt via kwallet (KDE's password safe), but it is enough to click OK > to allow this request. But I had to unlock my password safe first. I think you are not using ssh-agent but Kwallet (it can also serve as ssh agent). > And the SSH_ASKPASS variable is set to /usr/lib/ssh/ssh-askpass on > this machine. So maybe this is really just a prompt for machines with > a running X server... That is currently how it works. But the above hack should solve it :) @openssh devs: Is there a reason not to fall back to getpass(2) ? Best regards From mail at ojkastl.de Wed Nov 5 07:50:48 2014 From: mail at ojkastl.de (Johannes Kastl) Date: Tue, 04 Nov 2014 21:50:48 +0100 Subject: Unable to use ssh-agent with confirmation, when logged in on a virtual terminal In-Reply-To: <54592CE5.5010406@gmail.com> References: <54592CE5.5010406@gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04.11.2014 ?ngel Gonz?lez wrote: > /usr/lib/ssh/ssh-askpass is a graphical application, so it won't > work on the console. I found that on openSUSE, openssh-askpass is described as 'A passphrase dialog for OpenSSH and the X Window System'. > DISPLAY=foo SSH_ASKPASS=/bin/true ssh-agent bash >> ssh-add -c /path/to/keyfile ssh machine This works. So it really is the missing application. > This time it should work (works here). Using /bin/true means that > it will always answer "yes", but enough to show it is working. You > should instead make a program using getpass(2) or maybe a shell > script that asks you. I wonder why there is no such application delivered with openssh? Surely someone more capable than me has used this feature before? And, also: In the man page this whole SSH_ASKPASS/DISPLAY-thingy is described as a way for X11-users and if no terminal is associated. But in my case, all of this should not be necessary, as I am running this from a terminal, and ssh just has to ask for the passphrase. As it might ask for the passphrase when adding it to ssh-agent or when ssh'ing without the agent. > I think you are not using ssh-agent but Kwallet (it can also serve > as ssh agent). I'm manually starting ssh-agent on the konsole (KDE's terminal). Regards, Johannes - -- The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners. (unknown) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlRZPCgACgkQzi3gQ/xETbLoDwCfTlXENlGTZ118KopB5E9m+lmG BPcAn0/TmYqSIMO6c7Kbg77zEkctTgB+ =l59J -----END PGP SIGNATURE----- From djm at mindrot.org Wed Nov 5 10:59:36 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 5 Nov 2014 10:59:36 +1100 (EST) Subject: CanonicalizeHostname issues with multiple config blocks In-Reply-To: References: Message-ID: On Mon, 3 Nov 2014, Robin McCorkell wrote: > When using the CanonicalizeHostname and CanonicalDomains directives, the > options parsed before the hostname is canonicalized cannot be overridden by > more specific blocks after canonicalization. For example: > > CanonicalizeHostname yes > CanonicalDomains foo.bar.com > > Host *.foo.bar.com > GSSAPIAuthentication yes > > Host * > GSSAPIAuthentication no > > If connecting to 'srv.foo.bar.com', then GSSAPI authentication is enabled. > But connecting to 'srv', even though it is canonicalized correctly to ' > srv.foo.bar.com', does not enable GSSAPI authentication as the 'Host *' > block is parsed before canonicalization and cannot be then overridden by > the more specific block. That's expected. With CanonicalizeHostname enabled, the config file is parsed twice: once with the short name (and to pick up the CanonicalizeHostname directive itself) and then again with the canonicalised name. OpenSSH 6.8 will offer more control here using some extensions to the Match keyword: a new "canonical" criteria that causes it to match only during the second pass: CanonicalizeHostname yes CanonicalDomains foo.bar.com Match canonical *.foo.bar.com GSSAPIAuthentication yes Match canonical * GSSAPIAuthentication no Sorry I didn't think of this sooner :/ -d From djm at mindrot.org Wed Nov 5 11:03:17 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 5 Nov 2014 11:03:17 +1100 (EST) Subject: [patch/cygwin] Update ssh-user-config for the account db changes in the upcoming Cygwin In-Reply-To: <20141103113213.GT14051@calimero.vinschen.de> References: <20141103113213.GT14051@calimero.vinschen.de> Message-ID: done - thanks again On Mon, 3 Nov 2014, Corinna Vinschen wrote: > Hi, > > below is a patch which makes the Cygwin-specific ssh-user-config script > independent of the existence of /etc/passwd. The next Cygwin release > will allow to generate passwd and group entries from the Windows account > DBs, so the scripts have to adapt. Please apply. > > > Thanks, > Corinna > > > diff --git a/contrib/cygwin/ssh-host-config b/contrib/cygwin/ssh-host-config > index a7ea3e0..301d5eb 100644 > --- a/contrib/cygwin/ssh-host-config > +++ b/contrib/cygwin/ssh-host-config > @@ -1,6 +1,6 @@ > #!/bin/bash > # > -# ssh-host-config, Copyright 2000-2011 Red Hat Inc. > +# ssh-host-config, Copyright 2000-2014 Red Hat Inc. > # > # This file is part of the Cygwin port of OpenSSH. > # > @@ -353,11 +353,9 @@ check_service_files_ownership() { > fi > if [ -z "${run_service_as}" ] > then > - csih_warning "Couldn't determine name of user running sshd service from /etc/passwd!" > + csih_warning "Couldn't determine name of user running sshd service from account database!" > csih_warning "As a result, this script cannot make sure that the files used" > csih_warning "by the sshd service belong to the user running the service." > - csih_warning "Please re-run the mkpasswd tool to make sure the /etc/passwd" > - csih_warning "file is in a good shape." > return 1 > fi > fi > diff --git a/contrib/cygwin/ssh-user-config b/contrib/cygwin/ssh-user-config > index 8708b7a..33dc0cb 100644 > --- a/contrib/cygwin/ssh-user-config > +++ b/contrib/cygwin/ssh-user-config > @@ -1,6 +1,6 @@ > #!/bin/bash > # > -# ssh-user-config, Copyright 2000-2008 Red Hat Inc. > +# ssh-user-config, Copyright 2000-2014 Red Hat Inc. > # > # This file is part of the Cygwin port of OpenSSH. > # > @@ -75,19 +75,18 @@ readonly -f create_identity > # pwdhome > # ====================================================================== > check_user_homedir() { > - local uid=$(id -u) > - pwdhome=$(awk -F: '{ if ( $3 == '${uid}' ) print $6; }' < ${SYSCONFDIR}/passwd) > + pwdhome=$(getent passwd $UID | awk -F: '{ print $6; }') > if [ "X${pwdhome}" = "X" ] > then > csih_error_multi \ > - "There is no home directory set for you in ${SYSCONFDIR}/passwd." \ > + "There is no home directory set for you in the account database." \ > 'Setting $HOME is not sufficient!' > fi > > if [ ! -d "${pwdhome}" ] > then > csih_error_multi \ > - "${pwdhome} is set in ${SYSCONFDIR}/passwd as your home directory" \ > + "${pwdhome} is set in the account database as your home directory" \ > 'but it is not a valid directory. Cannot create user identity files.' > fi > > @@ -96,7 +95,7 @@ check_user_homedir() { > if [ "X${pwdhome}" = "X/" ] > then > # But first raise a warning! > - csih_warning "Your home directory in ${SYSCONFDIR}/passwd is set to root (/). This is not recommended!" > + csih_warning "Your home directory in the account database is set to root (/). This is not recommended!" > if csih_request "Would you like to proceed anyway?" > then > pwdhome='' > @@ -106,7 +105,7 @@ check_user_homedir() { > fi > fi > > - if [ -d "${pwdhome}" -a csih_is_nt -a -n "`chmod -c g-w,o-w "${pwdhome}"`" ] > + if [ -d "${pwdhome}" -a -n "`chmod -c g-w,o-w "${pwdhome}"`" ] > then > echo > csih_warning 'group and other have been revoked write permission to your home' > @@ -149,9 +148,10 @@ readonly -f check_user_dot_ssh_dir > # pwdhome -- check_user_homedir() > # ====================================================================== > fix_authorized_keys_perms() { > - if [ csih_is_nt -a -e "${pwdhome}/.ssh/authorized_keys" ] > + if [ -e "${pwdhome}/.ssh/authorized_keys" ] > then > - if ! setfacl -m "u::rw-,g::---,o::---" "${pwdhome}/.ssh/authorized_keys" > + setfacl -b "${pwdhome}/.ssh/authorized_keys" 2>/dev/null || echo -n > + if ! chmod u-x,g-wx,o-wx "${pwdhome}/.ssh/authorized_keys" > then > csih_warning "Setting correct permissions to ${pwdhome}/.ssh/authorized_keys" > csih_warning "failed. Please care for the correct permissions. The minimum requirement" > @@ -243,15 +243,6 @@ done > # Action! > # ====================================================================== > > -# Check passwd file > -if [ ! -f ${SYSCONFDIR}/passwd ] > -then > - csih_error_multi \ > - "${SYSCONFDIR}/passwd is nonexistant. Please generate an ${SYSCONFDIR}/passwd file" \ > - 'first using mkpasswd. Check if it contains an entry for you and' \ > - 'please care for the home directory in your entry as well.' > -fi > - > check_user_homedir > check_user_dot_ssh_dir > create_identity id_rsa rsa "SSH2 RSA" > > > -- > Corinna Vinschen > Cygwin Maintainer > Red Hat > From djm at mindrot.org Wed Nov 5 11:09:56 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 5 Nov 2014 11:09:56 +1100 (EST) Subject: Host based authentication and SSH CA. In-Reply-To: <5458B69B.8060409@pean.org> References: <5458B69B.8060409@pean.org> Message-ID: On Tue, 4 Nov 2014, Peter Ankerst?l wrote: > Hi, > > Im currently deploying signed host keys for my environment. Everything seems > to work fine but I have one problem with host based authentication. > > Im running OpenSSH_6.5p1, OpenSSL 1.0.1e-fips 11 Feb 2013 on RHEL 6.5. > > When trying to login between hosts with host-based authentication configured I > cant do so if the host is not in /etc/ssh_knows_hosts. If its there it works > even if the public key is wrong. It should be enough to have a single > "@cert-authority" line in ssh_known_hosts right? I don't think host-based auth has ever been properly tested with certified keys (unfortunately, it's barely tested generally due to the difficulty of writing a test script for it). It's entirely possible that there are bugs there. Please file a report at https://bugzilla.mindrot.org/ and include the config files in question and I'll take a look when I have some time next. -d From djm at mindrot.org Wed Nov 5 11:11:14 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 5 Nov 2014 11:11:14 +1100 (EST) Subject: ssh-add 6.7 inserts RSA keys into the ssh-agent as "rsa w/o comment" instead of filenames In-Reply-To: <87h9yfrp32.fsf@alice.fifthhorseman.net> References: <87h9yfrp32.fsf@alice.fifthhorseman.net> Message-ID: hmm, that's a regression - could you please file a bug for it? I'll try to fix it before the next release. On Tue, 4 Nov 2014, Daniel Kahn Gillmor wrote: > Hi OpenSSH folks-- > > as of version 6.7 (the first version i noticed this in), it looks to me > like adding ssh keys to ssh-agent marks them all as "rsa w/o comment", > instead of putting the filename as the comment. > > This appears to be because of the key function overhaul in > 8668706d0f52654fe64c0ca41a96113aeab8d2b8. > > ssh-add.c loads the secret keys via library-like invocations of > functions in sshkey.c, and if the comment returned is NULL, it sets the > comment to be the filename. > > But in practice, these functions now return "rsa w/o comment" as the > comment, so the filename never gets applied as a comment. > > Possible ways to fix: > > * One fix would be to have the functions return a NULL for the comment. > > * Another fix would be to have ssh-add just override the comment > explicitly. > > * A third fix would be to pass a "proposed comment" into the > library-like call, which could be overridden by future versions if > they're aware of a superior comment after having parsed the key. > > I also note that there is no way for a user of ssh-add to explicitly set > the comment directly -- adding something like that would be a distinct > feature, i think. > > Regards, > > --dkg > From peter at pean.org Wed Nov 5 18:46:58 2014 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Wed, 05 Nov 2014 08:46:58 +0100 Subject: Host based authentication and SSH CA. In-Reply-To: References: <5458B69B.8060409@pean.org> Message-ID: <5459D5F2.3090807@pean.org> On 11/05/2014 01:09 AM, Damien Miller wrote: > On Tue, 4 Nov 2014, Peter Ankerst?l wrote: > >> Hi, >> >> Im currently deploying signed host keys for my environment. Everything seems >> to work fine but I have one problem with host based authentication. >> >> Im running OpenSSH_6.5p1, OpenSSL 1.0.1e-fips 11 Feb 2013 on RHEL 6.5. >> >> When trying to login between hosts with host-based authentication configured I >> cant do so if the host is not in /etc/ssh_knows_hosts. If its there it works >> even if the public key is wrong. It should be enough to have a single >> "@cert-authority" line in ssh_known_hosts right? > > I don't think host-based auth has ever been properly tested with certified > keys (unfortunately, it's barely tested generally due to the difficulty of > writing a test script for it). It's entirely possible that there are bugs > there. > > Please file a report at https://bugzilla.mindrot.org/ and include the > config files in question and I'll take a look when I have some time next. > > -d > Thanks. https://bugzilla.mindrot.org/show_bug.cgi?id=2305 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3738 bytes Desc: S/MIME Cryptographic Signature URL: From ekoyle at gmail.com Wed Nov 5 18:37:54 2014 From: ekoyle at gmail.com (Eldon Koyle) Date: Wed, 5 Nov 2014 00:37:54 -0700 Subject: Unable to use ssh-agent with confirmation, when logged in on a virtual terminal In-Reply-To: References: <54592CE5.5010406@gmail.com> Message-ID: <20141105073754.GA1890@esk.usu.edu> On Nov 04 21:50+0100, Johannes Kastl wrote: > > DISPLAY=foo SSH_ASKPASS=/bin/true ssh-agent bash > >> ssh-add -c /path/to/keyfile ssh machine > > This works. So it really is the missing application. > > > This time it should work (works here). Using /bin/true means that > > it will always answer "yes", but enough to show it is working. You > > should instead make a program using getpass(2) or maybe a shell > > script that asks you. > > I wonder why there is no such application delivered with openssh? > Surely someone more capable than me has used this feature before? I think perhaps you are misunderstanding the '-c' option of ssh-add. The -c option is meant as an additional barrier to someone hijacking your agent (ie. if someone gains access as your user, they will be unable to use your key if they don't also have access to your X session). > And, also: In the man page this whole SSH_ASKPASS/DISPLAY-thingy is > described as a way for X11-users and if no terminal is associated. > > But in my case, all of this should not be necessary, as I am running > this from a terminal, and ssh just has to ask for the passphrase. As > it might ask for the passphrase when adding it to ssh-agent or when > ssh'ing without the agent. One purpose of the ssh agent is to avoid having to type in your passphrase as often. The fact that you added the key with '-c' means you want the agent to ask you if it is okay too use this key, but without an X session it doesn't know how to do that (it is not as straightforward as it seems from a terminal; it can hang forever with a prompt that was displayed who-knows-where). -- Eldon Koyle From mail at ojkastl.de Wed Nov 5 22:26:02 2014 From: mail at ojkastl.de (Johannes Kastl) Date: Wed, 05 Nov 2014 12:26:02 +0100 Subject: Unable to use ssh-agent with confirmation, when logged in on a virtual terminal In-Reply-To: <20141105073754.GA1890@esk.usu.edu> References: <54592CE5.5010406@gmail.com> <20141105073754.GA1890@esk.usu.edu> Message-ID: <19B6255E-4131-46CF-83DE-2552B874AFEB@ojkastl.de> Hi Eldon, thanks for your answer. Am 5. November 2014 08:37:54 MEZ, schrieb Eldon Koyle : >I think perhaps you are misunderstanding the '-c' option of ssh-add. Yeah, perhaps I do. >The -c option is meant as an additional barrier to someone hijacking >your agent (ie. if someone gains access as your user, they will be >unable to use your key if they don't also have access to your X >session). I mostly found this option mentioned in connection with agent forwarding, and that's use case I have. The benefit being that no one can use the 'forwarded' key/identity, unless I confirm it. So me forwarding my identity to a server getting hacked does not compromise security. Of course it's more comfortable if it's a window popping up. But what if the forwarding, safe, machine is a machine without x? Maybe this use case was not intended and thus does not work. Funny, that my first tests with the -c option exactly into that corner case... >One purpose of the ssh agent is to avoid having to type in your >passphrase as often. But why it's just clicking a button enough to confirm the use? I world game thought that each use has to be confirmed by the passphrase. So many questions... ;-) Regards, Johannes -- This mail has been sent from my mobile phone. Please excuse the briefness. This mail is not signed cryptographically. From vinschen at redhat.com Thu Nov 6 00:25:23 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 5 Nov 2014 14:25:23 +0100 Subject: [PATCH] Don't read group names from /etc/group In-Reply-To: Message-ID: <20141105132523.GV28636@calimero.vinschen.de> On Nov 5 11:03, Damien Miller wrote: > done - thanks again Thank you. Unfortunately there was still one problem left in ssh-host-config, which at one point reads from /etc/group when printing the user's group membership. Patch below. Thanks, Corinna Signed-off-by: Corinna Vinschen --- contrib/cygwin/ssh-host-config | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/contrib/cygwin/ssh-host-config b/contrib/cygwin/ssh-host-config index 301d5eb..3214829 100644 --- a/contrib/cygwin/ssh-host-config +++ b/contrib/cygwin/ssh-host-config @@ -623,10 +623,7 @@ then csih_warning "However, it seems your account does not have these privileges." csih_warning "Here's the list of groups in your user token:" echo - for i in $(/usr/bin/id -G) - do - /usr/bin/awk -F: "/[^:]*:[^:]*:$i:/{ print \" \" \$1; }" /etc/group - done + /usr/bin/id -Gnz | xargs -0n1 echo " " echo csih_warning "This usually means you're running this script from a non-admin" csih_warning "desktop session, or in a non-elevated shell under UAC control." -- 1.9.3 -- 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 dkg at fifthhorseman.net Thu Nov 6 01:35:47 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 05 Nov 2014 09:35:47 -0500 Subject: ssh-add 6.7 inserts RSA keys into the ssh-agent as "rsa w/o comment" instead of filenames In-Reply-To: References: <87h9yfrp32.fsf@alice.fifthhorseman.net> Message-ID: <545A35C3.6020505@fifthhorseman.net> On 11/04/2014 07:11 PM, Damien Miller wrote: > hmm, that's a regression - could you please file a bug for it? I'll > try to fix it before the next release. Sure, here you go: https://bugzilla.mindrot.org/show_bug.cgi?id=2306 Thanks for looking into it. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From stapelberg+openssh at google.com Thu Nov 6 02:21:25 2014 From: stapelberg+openssh at google.com (Michael Stapelberg) Date: Wed, 5 Nov 2014 07:21:25 -0800 Subject: [PATCH] Early request for comments: U2F authentication Message-ID: Hey, Recently, the FIDO alliance announced U2F [1], and Google announced that it supports U2F tokens (?security keys?) for Google accounts [2]. As the spec is not a very short read, I gave a presentation last week about U2F which may be a good quick introduction to the details [3]. For the rest of this mail, I?ll assume that you read either my presentation or the spec, but feel free to post any questions about U2F and I?ll try to answer them. (side note: I?m not working on U2F, playing around with it and implementing it in OpenSSH is my private fun project :)) I?ve spent some time (together with Christian and Thomas) hacking on U2F support in OpenSSH, and I?m happy to provide a first patch ? it?s not complete, but it should be good enough to get the discussion going :). Please see the two attached files for the patch. Due to their size, I?ve not posted them in-line. The way it currently (!) works: 1) Use ?AuthenticationMethods publickey,u2f? in sshd_config (or ,u2f) 2) Recompile SSH with the patch and change userauth_u2f() to use packet_put_int(0) (== registration) instead of packet_put_int(1) (== authentication). Sorry about that. See my question below. 3) You need to do this step only once: ssh into your server, touch your security key when prompted, and you?ll see a ssh-u2f key line, which you should copy&paste into the server?s ~/.ssh/authorized_keys for the corresponding user. 4) Recompile with packet_put_int(1). 5) ssh into your server, touch your security key when prompted, enjoy the additional security :). There are a couple of open questions: 1) Will you accept this patch (let?s ignore details for now) at all? Everyone I?ve talked to in the last couple of days was pretty excited about having U2F support in OpenSSH, so I think it?d be a great feature. (the rest are detail questions about the implementation) 2) Could we make the server write to authorized_keys to avoid the copy&paste step? Probably not a good idea, but I figured I?d ask anyway. 3) What would be a good way to trigger the different U2F modes on the client? Should we add a new flag to ssh(1)? Registration is very rarely triggered, authentication should be the default. 4) What should we use as U2F appid? Currently I just set ?ssh://localhost? (it must be a URL), and we could use ?ssh://?. Christian suggested using the host key fingerprint, which would decouple the appid from the hostname (which may be good if the hostname frequently changes, because U2F security keys are registered for a specific appid). 5) What should we use as the origin (in the ssh client)? In the case where U2F is used by a web browser, this is set to the canonical representation of the domain (i.e. lowercased, after idn etc.). At the moment, I?m using either the host alias or the hostname. Is that acceptable or is there a better method? 6) Not a question, but a note: the patch does not yet handle multiple registered U2F security keys. 7) I?d like to use SSL_load_error_strings() so that the human-readable error messages actually contain some content and are not just NULL :). It?ll require linking with -lssl. Is that okay or is there a reason why we don?t do it so far? Thank you very much for any replies :). [1] https://fidoalliance.org/ [2] http://googleonlinesecurity.blogspot.ch/2014/10/strengthening-2-step-verification-with.html [3] https://www.noname-ev.de/w/File:C14h-u2f-how-security-keys-work.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-u2f-to-automake.patch Type: text/x-patch Size: 3002 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-add-u2f-auth-module-not-done-yet.patch Type: text/x-patch Size: 42448 bytes Desc: not available URL: From nkadel at gmail.com Thu Nov 6 12:55:17 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 5 Nov 2014 20:55:17 -0500 Subject: [PATCH] Don't read group names from /etc/group In-Reply-To: <20141105132523.GV28636@calimero.vinschen.de> References: <20141105132523.GV28636@calimero.vinschen.de> Message-ID: On Wed, Nov 5, 2014 at 8:25 AM, Corinna Vinschen wrote: > On Nov 5 11:03, Damien Miller wrote: >> done - thanks again > > Thank you. Unfortunately there was still one problem left in > ssh-host-config, which at one point reads from /etc/group when printing > the user's group membership. Patch below. > > > Thanks, > Corinna 'getent group' can also be useful. But yes, parsing /etc/group is useless in an NIS or LDAP based environment. From vinschen at redhat.com Thu Nov 6 19:58:51 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 6 Nov 2014 09:58:51 +0100 Subject: [PATCH] Don't read group names from /etc/group In-Reply-To: References: <20141105132523.GV28636@calimero.vinschen.de> Message-ID: <20141106085851.GA28195@calimero.vinschen.de> On Nov 5 20:55, Nico Kadel-Garcia wrote: > On Wed, Nov 5, 2014 at 8:25 AM, Corinna Vinschen wrote: > > On Nov 5 11:03, Damien Miller wrote: > >> done - thanks again > > > > Thank you. Unfortunately there was still one problem left in > > ssh-host-config, which at one point reads from /etc/group when printing > > the user's group membership. Patch below. > > > > > > Thanks, > > Corinna > > 'getent group' can also be useful. But yes, parsing /etc/group is > useless in an NIS or LDAP based environment. Yes, indeed. It just occured to me that listing the user's group names is much easier by utilizing id's output directly. The original code reading from /etc/group was already much too complicated. 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 vinschen at redhat.com Fri Nov 7 04:00:32 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 6 Nov 2014 18:00:32 +0100 Subject: [PATCH] Patch by Florian Friesdorf : contrib/cygwin/ssh-host-config: Add -N option to allow different service name. Message-ID: <20141106170032.GA22021@calimero.vinschen.de> Hi, today I got a neat patch to ssh-host-config. With the new -N option it allows to install multiple sshd services under different service names. I like the idea, so I thought I send the patch upstream. See below. Thanks, Corinna --- contrib/cygwin/ssh-host-config | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) mode change 100644 => 100755 contrib/cygwin/ssh-host-config diff --git a/contrib/cygwin/ssh-host-config b/contrib/cygwin/ssh-host-config old mode 100644 new mode 100755 index 3214829..d934d09 --- a/contrib/cygwin/ssh-host-config +++ b/contrib/cygwin/ssh-host-config @@ -61,6 +61,7 @@ LOCALSTATEDIR=/var sshd_config_configured=no port_number=22 +service_name=sshd strictmodes=yes privsep_used=yes cygwin_value="" @@ -408,7 +409,7 @@ install_service() { local ret=0 echo - if /usr/bin/cygrunsrv -Q sshd >/dev/null 2>&1 + if /usr/bin/cygrunsrv -Q ${service_name} >/dev/null 2>&1 then csih_inform "Sshd service is already installed." check_service_files_ownership "" || let ret+=$? @@ -464,7 +465,7 @@ install_service() { fi if [ -z "${password}" ] then - if /usr/bin/cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ + if /usr/bin/cygrunsrv -I ${service_name} -d "CYGWIN ${service_name}" -p /usr/sbin/sshd \ -a "-D" -y tcpip "${cygwin_env[@]}" then echo @@ -474,20 +475,20 @@ install_service() { csih_inform "will start automatically after the next reboot." fi else - if /usr/bin/cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ + if /usr/bin/cygrunsrv -I ${service_name} -d "CYGWIN ${service_name}" -p /usr/sbin/sshd \ -a "-D" -y tcpip "${cygwin_env[@]}" \ -u "${run_service_as}" -w "${password}" then /usr/bin/editrights -u "${run_service_as}" -a SeServiceLogonRight echo csih_inform "The sshd service has been installed under the '${run_service_as}'" - csih_inform "account. To start the service now, call \`net start sshd' or" - csih_inform "\`cygrunsrv -S sshd'. Otherwise, it will start automatically" + csih_inform "account. To start the service now, call \`net start ${service_name}' or" + csih_inform "\`cygrunsrv -S ${service_name}'. Otherwise, it will start automatically" csih_inform "after the next reboot." fi fi - if /usr/bin/cygrunsrv -Q sshd >/dev/null 2>&1 + if /usr/bin/cygrunsrv -Q ${service_name} >/dev/null 2>&1 then check_service_files_ownership "${run_service_as}" || let ret+=$? else @@ -561,6 +562,11 @@ do shift ;; + -N | --name ) + service_name=$1 + shift + ;; + -p | --port ) port_number=$1 shift @@ -590,6 +596,7 @@ do echo " --yes -y Answer all questions with \"yes\" automatically." echo " --no -n Answer all questions with \"no\" automatically." echo " --cygwin -c Use \"options\" as value for CYGWIN environment var." + echo " --name -N sshd windows service name." echo " --port -p sshd listens on port n." echo " --user -u privileged user for service, default 'cyg_server'." echo " --pwd -w Use \"pwd\" as password for privileged user." -- 1.9.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From imorgan at nas.nasa.gov Fri Nov 7 08:44:54 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 6 Nov 2014 13:44:54 -0800 Subject: Host based authentication and SSH CA. In-Reply-To: <5459D5F2.3090807@pean.org> References: <5458B69B.8060409@pean.org> <5459D5F2.3090807@pean.org> Message-ID: <20141106214454.GC6476@linux124.nas.nasa.gov> On Wed, Nov 05, 2014 at 08:46:58 +0100, Peter Ankerst?l wrote: > On 11/05/2014 01:09 AM, Damien Miller wrote: > >On Tue, 4 Nov 2014, Peter Ankerst?l wrote: > > > >>Hi, > >> > >>Im currently deploying signed host keys for my environment. Everything seems > >>to work fine but I have one problem with host based authentication. > >> > >>Im running OpenSSH_6.5p1, OpenSSL 1.0.1e-fips 11 Feb 2013 on RHEL 6.5. > >> > >>When trying to login between hosts with host-based authentication configured I > >>cant do so if the host is not in /etc/ssh_knows_hosts. If its there it works > >>even if the public key is wrong. It should be enough to have a single > >>"@cert-authority" line in ssh_known_hosts right? > > > >I don't think host-based auth has ever been properly tested with certified > >keys (unfortunately, it's barely tested generally due to the difficulty of > >writing a test script for it). It's entirely possible that there are bugs > >there. > > > >Please file a report at https://bugzilla.mindrot.org/ and include the > >config files in question and I'll take a look when I have some time next. > > > >-d > > > > Thanks. > > https://bugzilla.mindrot.org/show_bug.cgi?id=2305 > When I submitted the patch that extended certificate support to hostbased aiuthentication, it seemed to be working. However, it is certainly possible that I overlooked something or that my tests were incomplete. A couple of initial questions come to mind: What pattern are you using with the @cert-authority entry? What principals (if any) are associated with the host cert? If I recall correctly, sshd will use the FQDN when validating the key or certificate offered by the client. Thus, if you specified any principals for the certificate, the list must include the FQDN and the pattern for teh @cert-authority entry needs to also match the FQDN. -- Iain Morgan From peter at pean.org Fri Nov 7 18:03:51 2014 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Fri, 07 Nov 2014 08:03:51 +0100 Subject: Host based authentication and SSH CA. In-Reply-To: <20141106214454.GC6476@linux124.nas.nasa.gov> References: <5458B69B.8060409@pean.org> <5459D5F2.3090807@pean.org> <20141106214454.GC6476@linux124.nas.nasa.gov> Message-ID: <545C6ED7.8030101@pean.org> On 11/06/2014 10:44 PM, Iain Morgan wrote: > On Wed, Nov 05, 2014 at 08:46:58 +0100, Peter Ankerst?l wrote: >> On 11/05/2014 01:09 AM, Damien Miller wrote: >>> On Tue, 4 Nov 2014, Peter Ankerst?l wrote: >>> >>>> Hi, >>>> >>>> Im currently deploying signed host keys for my environment. Everything seems >>>> to work fine but I have one problem with host based authentication. >>>> >>>> Im running OpenSSH_6.5p1, OpenSSL 1.0.1e-fips 11 Feb 2013 on RHEL 6.5. >>>> >>>> When trying to login between hosts with host-based authentication configured I >>>> cant do so if the host is not in /etc/ssh_knows_hosts. If its there it works >>>> even if the public key is wrong. It should be enough to have a single >>>> "@cert-authority" line in ssh_known_hosts right? >>> >>> I don't think host-based auth has ever been properly tested with certified >>> keys (unfortunately, it's barely tested generally due to the difficulty of >>> writing a test script for it). It's entirely possible that there are bugs >>> there. >>> >>> Please file a report at https://bugzilla.mindrot.org/ and include the >>> config files in question and I'll take a look when I have some time next. >>> >>> -d >>> >> >> Thanks. >> >> https://bugzilla.mindrot.org/show_bug.cgi?id=2305 >> > > When I submitted the patch that extended certificate support to > hostbased aiuthentication, it seemed to be working. However, it is > certainly possible that I overlooked something or that my tests were > incomplete. > > A couple of initial questions come to mind: > > What pattern are you using with the @cert-authority entry? Right now i use * > What principals (if any) are associated with the host cert? Right now i dont have any principals at all in the host cert. > > > If I recall correctly, sshd will use the FQDN when validating the key or > certificate offered by the client. Thus, if you specified any principals > for the certificate, the list must include the FQDN and the pattern for > teh @cert-authority entry needs to also match the FQDN. When logging with key based authentication the host CA works fine. debug1: Host 'm3' is known and matches the ECDSA-CERT host certificate. debug1: Found CA key in /etc/ssh/ssh_known_hosts:1 But when doing hostbased authentication it first gives me those two lines but then tries to look for m3 specifically in ssh_known_hosts. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3738 bytes Desc: S/MIME Cryptographic Signature URL: From peter at pean.org Fri Nov 7 21:18:24 2014 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Fri, 07 Nov 2014 11:18:24 +0100 Subject: Host based authentication and SSH CA. In-Reply-To: <20141106214454.GC6476@linux124.nas.nasa.gov> References: <5458B69B.8060409@pean.org> <5459D5F2.3090807@pean.org> <20141106214454.GC6476@linux124.nas.nasa.gov> Message-ID: <545C9C70.2010503@pean.org> On 11/06/2014 10:44 PM, Iain Morgan wrote: > On Wed, Nov 05, 2014 at 08:46:58 +0100, Peter Ankerst?l wrote: >> On 11/05/2014 01:09 AM, Damien Miller wrote: >>> On Tue, 4 Nov 2014, Peter Ankerst?l wrote: >>> >>>> Hi, >>>> >>>> Im currently deploying signed host keys for my environment. Everything seems >>>> to work fine but I have one problem with host based authentication. >>>> >>>> Im running OpenSSH_6.5p1, OpenSSL 1.0.1e-fips 11 Feb 2013 on RHEL 6.5. >>>> >>>> When trying to login between hosts with host-based authentication configured I >>>> cant do so if the host is not in /etc/ssh_knows_hosts. If its there it works >>>> even if the public key is wrong. It should be enough to have a single >>>> "@cert-authority" line in ssh_known_hosts right? >>> >>> I don't think host-based auth has ever been properly tested with certified >>> keys (unfortunately, it's barely tested generally due to the difficulty of >>> writing a test script for it). It's entirely possible that there are bugs >>> there. >>> >>> Please file a report at https://bugzilla.mindrot.org/ and include the >>> config files in question and I'll take a look when I have some time next. >>> >>> -d >>> >> >> Thanks. >> >> https://bugzilla.mindrot.org/show_bug.cgi?id=2305 >> > > When I submitted the patch that extended certificate support to > hostbased aiuthentication, it seemed to be working. However, it is > certainly possible that I overlooked something or that my tests were > incomplete. > > A couple of initial questions come to mind: > > What pattern are you using with the @cert-authority entry? > What principals (if any) are associated with the host cert? > > > If I recall correctly, sshd will use the FQDN when validating the key or > certificate offered by the client. Thus, if you specified any principals > for the certificate, the list must include the FQDN and the pattern for > teh @cert-authority entry needs to also match the FQDN. > I have now tried with having the FQDN as principal as host-cert. No help. It is still looking for the host in known_hosts. debug1: check_key_in_hostfiles: key for host "FQDN" not found -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3738 bytes Desc: S/MIME Cryptographic Signature URL: From djm at mindrot.org Fri Nov 7 22:29:36 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 7 Nov 2014 22:29:36 +1100 (EST) Subject: Host based authentication and SSH CA. In-Reply-To: <545C6ED7.8030101@pean.org> References: <5458B69B.8060409@pean.org> <5459D5F2.3090807@pean.org> <20141106214454.GC6476@linux124.nas.nasa.gov> <545C6ED7.8030101@pean.org> Message-ID: On Fri, 7 Nov 2014, Peter Ankerst?l wrote: > > What principals (if any) are associated with the host cert? > > Right now i dont have any principals at all in the host cert. That's likely the problem then. The principals should list the hostname(s) of the server. (I agree that the documentation here is terrible). > > If I recall correctly, sshd will use the FQDN when validating the key or > > certificate offered by the client. Thus, if you specified any principals > > for the certificate, the list must include the FQDN and the pattern for > > teh @cert-authority entry needs to also match the FQDN. > > When logging with key based authentication the host CA works fine. > > debug1: Host 'm3' is known and matches the ECDSA-CERT host certificate. > debug1: Found CA key in /etc/ssh/ssh_known_hosts:1 > > But when doing hostbased authentication it first gives me those two lines but > then tries to look for m3 specifically in ssh_known_hosts. That's strange - I'll take a look via the bug. -d From peter at pean.org Sat Nov 8 01:04:28 2014 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Fri, 07 Nov 2014 15:04:28 +0100 Subject: Host based authentication and SSH CA. In-Reply-To: References: <5458B69B.8060409@pean.org> <5459D5F2.3090807@pean.org> <20141106214454.GC6476@linux124.nas.nasa.gov> <545C6ED7.8030101@pean.org> Message-ID: <545CD16C.4010105@pean.org> On 11/07/2014 12:29 PM, Damien Miller wrote: > On Fri, 7 Nov 2014, Peter Ankerst?l wrote: > >>> What principals (if any) are associated with the host cert? >> >> Right now i dont have any principals at all in the host cert. > > That's likely the problem then. The principals should list the > hostname(s) of the server. > > (I agree that the documentation here is terrible). > >>> If I recall correctly, sshd will use the FQDN when validating the key or >>> certificate offered by the client. Thus, if you specified any principals >>> for the certificate, the list must include the FQDN and the pattern for >>> teh @cert-authority entry needs to also match the FQDN. >> >> When logging with key based authentication the host CA works fine. >> >> debug1: Host 'm3' is known and matches the ECDSA-CERT host certificate. >> debug1: Found CA key in /etc/ssh/ssh_known_hosts:1 >> >> But when doing hostbased authentication it first gives me those two lines but >> then tries to look for m3 specifically in ssh_known_hosts. > > That's strange - I'll take a look via the bug. > > -d > Im am NOT a programmer, but to me it looks like we need some sort of logic about certs around this block of code in auth2-hostbased.c: host_status = check_key_in_hostfiles(pw, key, lookup, _PATH_SSH_SYSTEM_HOSTFILE, options.ignore_user_known_hosts ? NULL : _PATH_SSH_USER_HOSTFILE); -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3738 bytes Desc: S/MIME Cryptographic Signature URL: From calestyo at scientia.net Sat Nov 8 10:16:46 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 08 Nov 2014 00:16:46 +0100 Subject: gssapi-keyex vs. gssapi-with-mic Message-ID: <1415402206.4500.3.camel@scientia.net> Hey. What are the differences (if any) between the authentication methods gssapi-keyex and gssapi-with-mic, especially from a security point of view. I understand, that gssapi-keyex works of course only when the KEX was made via GSS, while gssapi-with-mic works also with normal SSH KEX. gssapi-with-mic in turn works also with GSS KEX. RFC 4462 doesn't seem to tell much about the disadvantages / advantages of the two over each other. And as far as I understand gssapi-keyex uses a MIC as well? Thanks, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From naddy at mips.inka.de Sun Nov 9 03:36:48 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Sat, 8 Nov 2014 16:36:48 +0000 (UTC) Subject: Key fingerprints (not the DNS kind) Message-ID: When you connect to a server for the first time, a fingerprint of the server's public key is presented. The idea is that if you already know the fingerprint and it's a match, you can be confident that you are talking to the server and not a man-in-the-middle. People use this, e.g.: http://www.openbsd.org/anoncvs.html The typical fingerprint is just an MD5 hash over the public key. Given how broken MD5 is, you have to wonder if a MitM can create a new key with the same fingerprint. I'm in particular concerned about RSA keys, which are long and provide material to work with. In fact, isn't this Lenstra/Wang/Weger's "Colliding X.509 Certificates" attack from 2005? Am I missing something? There are three types of fingerprints that are shown to the user: (1) MD5 in hex: 2048 58:32:84:2f:e6:06:be:99:7e:1f:4e:49:c9:ac:04:e5 id_rsa.pub (RSA) (2) MD5 as random art: +---[RSA 2048]----+ | ... | | o.. | | . E.o . | | ..oo.* | | . +..* S | | ..oo . | | =. + | | + .o . | | ... .o | +-----------------+ (3) SHA-1 as Bubble Babble: 2048 xufok-vegum-ralym-tudob-zybyp-donyf-nifor-bocuc-behah-vilis-vexyx id_rsa.pub (RSA) Bubble Babble fingerprints are only displayed by ssh-keygen -B, which is of limited usefulness. It looks like the sort of arcane feature that could just be removed. The other fingerprint formats should switch from MD5 to SHA-256 as the underlying hash. The devil is in the details. How to display a SHA-256 hash compactly? Base64? Truncate (eww, can o' worms)? And how to manage the changeover from old to new fingerprints? -- Christian "naddy" Weisgerber naddy at mips.inka.de From keisial at gmail.com Sun Nov 9 08:29:38 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sat, 08 Nov 2014 22:29:38 +0100 Subject: Key fingerprints (not the DNS kind) In-Reply-To: References: Message-ID: <545E8B42.9030500@gmail.com> On 08/11/14 17:36, Christian Weisgerber wrote: > The other fingerprint formats should switch from MD5 to SHA-256 as > the underlying hash. The devil is in the details. How to display > a SHA-256 hash compactly? Is it so important to compact it? Yes, c4:e8:62:87:71:72:93:2c:c3:93:a8:ae:c5:c0:c2:bf:2f:8a:2c:1c:fa:8c:91:28:c9:1d:aa:0c:f6:0c:f0:fb is quite longer than 87:67:c9:7b:6e:d9:b6:a3:3b:dd:02:0e:de:51:15:8d but the people who check fingerprints will still check a longer one, and the people who doesn't won't care. > Base64? Truncate (eww, can o' worms)? No. If you truncate a N-length hash to M < N, you could (will probably) end up with a weaker hash than the md5 you were trying to replace. The hash resistence is for the full-length hash. If you wanted to provide a short fingerprint, I would simply replace MD5(key) with MD5(SHA256(key)).* The unpredictability of the inner hash protects against the ability of manipulating the key for creating collisions. * Plus something that makes old and new fingerprints look different. > And how to manage the changeover from old to new fingerprints? Provide a ssh argument (a comma-separated list of ways) for choosing which fingerprints to show. If the user was provided a fingerprint of type A, but has a newer ssh defaulting to type B fingerprint, it can use that switch to request that it is shown with the format he was given. Note this is quite similar to hosts with ECDSA and RSA keys. An additional possibility is to change the "Are you sure you want to continue connecting (yes/no)?" prompt to also accept the right fingerprint. If there are several fingerprints, ssh could verify that it matches the provided pubkey, automatically switching to the right algorithm for such fingerprint. From djm at mindrot.org Mon Nov 10 11:07:15 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Nov 2014 11:07:15 +1100 (EST) Subject: Key fingerprints (not the DNS kind) In-Reply-To: References: Message-ID: On Sat, 8 Nov 2014, Christian Weisgerber wrote: > When you connect to a server for the first time, a fingerprint of > the server's public key is presented. The idea is that if you > already know the fingerprint and it's a match, you can be confident > that you are talking to the server and not a man-in-the-middle. > > People use this, e.g.: > http://www.openbsd.org/anoncvs.html > > The typical fingerprint is just an MD5 hash over the public key. > Given how broken MD5 is, you have to wonder if a MitM can create a > new key with the same fingerprint. I'm in particular concerned > about RSA keys, which are long and provide material to work with. > In fact, isn't this Lenstra/Wang/Weger's "Colliding X.509 Certificates" > attack from 2005? > > Am I missing something? It isn't exactly the same attack - certificates have lots of places where the attacker can stash data to set up the hash collision that plain keys lack, but we do really need to switch away from MD5. > Bubble Babble fingerprints are only displayed by ssh-keygen -B, > which is of limited usefulness. It looks like the sort of arcane > feature that could just be removed. No, these are for interop with other SSH implementations. > The other fingerprint formats should switch from MD5 to SHA-256 as > the underlying hash. The devil is in the details. How to display > a SHA-256 hash compactly? Base64? Truncate (eww, can o' worms)? > And how to manage the changeover from old to new fingerprints? I'm not so concerned about how to display the new fingerprints. Say we choose SHA512/224, which yields a 28 byte hash. Rendering this as base64 gives us a 38 character string, well shorter than our current key fingerprints. (e.g. "GIeKHpiBrP7zaEf7Blicgvez5JceCBfSaESlkA") The randomart signatures are a bit more tricky to deal with - there isn't any room to put a hash algorithm identifier in the header line ("ED255519 256" doesn't leave enough characters). Maybe it could go in the footer... The bigger problem is transition. We would need to be able to show both old and new fingerprints for a while, but there is no consistent way to do this for all the tools. ssh and sshd could use a config option easily enough, but the other tools don't generally read the config files and there are AFAIK no getopt chars left that can be consistently used between all the tools. I guess we're going to be stuck with an config knob for ssh/sshd and an flag for ssh-add/ssh-keygen (but no flag for ssh/sshd). -d From djm at mindrot.org Mon Nov 10 11:11:12 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Nov 2014 11:11:12 +1100 (EST) Subject: Key fingerprints (not the DNS kind) In-Reply-To: References: Message-ID: On Mon, 10 Nov 2014, Damien Miller wrote: > I'm not so concerned about how to display the new fingerprints. Say > we choose SHA512/224, which yields a 28 byte hash. Rendering this as > base64 gives us a 38 character string, well shorter than our current > key fingerprints. (e.g. "GIeKHpiBrP7zaEf7Blicgvez5JceCBfSaESlkA") Actually, better still would be embeddeding an algorithm identifier at the start of the hash, i.e. "A:GIeKHpiBrP7zaEf7Blicgvez5JceCBfSaESlkA" in case some time in the distant future we need to rotate away from whatever we choose to replace MD5. -d From ag4ve.us at gmail.com Mon Nov 10 12:26:00 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 9 Nov 2014 20:26:00 -0500 Subject: Key fingerprints (not the DNS kind) In-Reply-To: References: Message-ID: On Sun, Nov 9, 2014 at 7:11 PM, Damien Miller wrote: > On Mon, 10 Nov 2014, Damien Miller wrote: > >> I'm not so concerned about how to display the new fingerprints. Say >> we choose SHA512/224, which yields a 28 byte hash. Rendering this as >> base64 gives us a 38 character string, well shorter than our current >> key fingerprints. (e.g. "GIeKHpiBrP7zaEf7Blicgvez5JceCBfSaESlkA") > > Actually, better still would be embeddeding an algorithm identifier at > the start of the hash, i.e. "A:GIeKHpiBrP7zaEf7Blicgvez5JceCBfSaESlkA" > in case some time in the distant future we need to rotate away from > whatever we choose to replace MD5. > That's always a good idea, but try not to reinvent the wheel too much here: http://hashcat.net/wiki/doku.php?id=example_hashes There's no m5(sha512(word)) but $foo$fpr or $foo$host$fpr should maybe be used? From djm at mindrot.org Mon Nov 10 12:42:21 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Nov 2014 12:42:21 +1100 (EST) Subject: Key fingerprints (not the DNS kind) In-Reply-To: References: Message-ID: On Sun, 9 Nov 2014, shawn wilson wrote: > On Sun, Nov 9, 2014 at 7:11 PM, Damien Miller wrote: > > That's always a good idea, but try not to reinvent the wheel too much > here: http://hashcat.net/wiki/doku.php?id=example_hashes > There's no m5(sha512(word)) but $foo$fpr or $foo$host$fpr should maybe > be used? I don't think password hashes are a good model for key fingerprints. Password hashes are intended for consumption in password databases, key fingerprints are intended for rapid and accurate comparison by humans. BTW I think md5(inner_hash(x)) is a terrible idea :) From ag4ve.us at gmail.com Mon Nov 10 14:01:19 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Sun, 9 Nov 2014 22:01:19 -0500 Subject: Key fingerprints (not the DNS kind) In-Reply-To: References: Message-ID: On Nov 9, 2014 8:42 PM, "Damien Miller" wrote: > > On Sun, 9 Nov 2014, shawn wilson wrote: > > > On Sun, Nov 9, 2014 at 7:11 PM, Damien Miller wrote: > > > > That's always a good idea, but try not to reinvent the wheel too much > > here: http://hashcat.net/wiki/doku.php?id=example_hashes > > There's no m5(sha512(word)) but $foo$fpr or $foo$host$fpr should maybe > > be used? > > I don't think password hashes are a good model for key fingerprints. > Password hashes are intended for consumption in password databases, > key fingerprints are intended for rapid and accurate comparison by > humans. > It is to identify a hash. Who cares what the hash is of. I was pointing out prior design that'd be good to use here. > BTW I think md5(inner_hash(x)) is a terrible idea :) I don't see a benefit to doing this but also no harm. From philcerf at gmail.com Mon Nov 10 14:28:23 2014 From: philcerf at gmail.com (Philippe Cerfon) Date: Mon, 10 Nov 2014 04:28:23 +0100 Subject: ControlMaster question Message-ID: Hello. I'd like to spread the use of control channel muxing at our institute, so the plan was to change the defaults for our ssh to, e.g. ControlMaster auto ControlPath /tmp/%C.ssh-mux ControlPersist 0 The idea was: - use opportunistic muxing - not all users may have actually homedirs, therefore something like /tmp needs to be used - the mux process should be backgrounded (and not block the original ssh process to remain open) and it should immediately close when it's no longer used by anyone Some problems/questions: 1) Is it a security issue, when the sockets are created in /tmp? E.g. could a malevolent user create such a socket and intercept the other user's connection? Or does ssh check whether the socket is owned by BOTH it's own user/group? I think normally there shouldn't be a way for a user a to create a file owned by user b,... it may be possible that user a creates a file which is owned by group b... but if ssh checks BOTH user and group, it should be fine, right? So does it do such checks? Are there any other things to obey (thinking of all the different kinds of /tmp-dir hacks)? 2) Apparently ControlPersist 0 is actually the same as yes and the mux process isn't stopped 0s (i.e. immediately) after the last connection has gone, but never. Is this a bug? Sincerely, Philippe From philcerf at gmail.com Mon Nov 10 14:35:05 2014 From: philcerf at gmail.com (Philippe Cerfon) Date: Mon, 10 Nov 2014 04:35:05 +0100 Subject: multiple tun devices per single ssh connection? Message-ID: Hello. One more question. It seems that it's not possible to have multiple tun devices forwarded within one ssh connection (especially with different modes p2p / ethernet), right? Or do I just invoke it wrong? If not, is this planned to be implemented or is the way to go to make multiple ssh connections? Thanks, Philippe From calestyo at scientia.net Mon Nov 10 15:00:16 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Mon, 10 Nov 2014 05:00:16 +0100 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: References: Message-ID: <1415592016.4565.23.camel@scientia.net> Hey. Interesting that you bring this up now... I've actually looked into this a week ago but forgot to write a bug report. A simple test showed, that ssh doesn't employ any security checks... when it is able to open the socket, it'll use it apparently: I tried last week something like this: user at hostA:~$ ssh -o ControlMaster=yes -o ControlPath=/tmp/sshmux hostB and then: root at hostA:~$ ssh -o ControlMaster=no -o ControlPath=/tmp/sshmux hostC As you can see, the socket is created by user, and root "accidentally" uses it, even trying to connect to another node. ssh will just do so without any complains. And even when one uses something like %h, %p or that like, an attacker can easily guess these. Since it doesn't seem to be documented that the socket must be created in a secure location and since neither there are any owner checks like sshd's StrictMode... I'd probably consider that a security hole. upstream what do you think? Cheers, Chris. btw: I cannot answer your second question, perhaps one of the developers knows more about that. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From calestyo at scientia.net Mon Nov 10 15:07:12 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Mon, 10 Nov 2014 05:07:12 +0100 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: <1415592016.4565.23.camel@scientia.net> References: <1415592016.4565.23.camel@scientia.net> Message-ID: <1415592432.4565.24.camel@scientia.net> I've just filed https://bugzilla.mindrot.org/show_bug.cgi?id=2311 to keep track on this. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From mancha1 at zoho.com Mon Nov 10 19:14:36 2014 From: mancha1 at zoho.com (mancha) Date: Mon, 10 Nov 2014 08:14:36 +0000 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: <1415592016.4565.23.camel@scientia.net> References: <1415592016.4565.23.camel@scientia.net> Message-ID: <20141110081436.GA15934@zoho.com> On Mon, Nov 10, 2014 at 05:00:16AM +0100, Christoph Anton Mitterer wrote: > Hey. > > Interesting that you bring this up now... I've actually looked into > this a week ago but forgot to write a bug report. > > A simple test showed, that ssh doesn't employ any security checks... > when it is able to open the socket, it'll use it apparently: > > I tried last week something like this: user at hostA:~$ ssh -o > ControlMaster=yes -o ControlPath=/tmp/sshmux hostB > > and then: root at hostA:~$ ssh -o ControlMaster=no -o > ControlPath=/tmp/sshmux hostC > > As you can see, the socket is created by user, and root "accidentally" > uses it, even trying to connect to another node. ssh will just do so > without any complains. > > And even when one uses something like %h, %p or that like, an attacker > can easily guess these. > > > Since it doesn't seem to be documented that the socket must be created > in a secure location and since neither there are any owner checks like > sshd's StrictMode... I'd probably consider that a security hole. The socket is created with a umask of 0177 so you should end up with socket perms of 0600 or thereabouts. Standard ACLs kick in. If the threat model includes an evil root though, there's not much to do (and in fact a lot more to worry about: trojaned ssh binary, tapped tty, etc.). Abandon ship. Regarding possible racey mischief, the socket is created "pseudo atomically". That said, an ownership check that prevents, among other things, root from accidentally falling through a wormhole wouldn't be bad. Attached patch against 6.7p1 should do. --mancha PS Patch also at: http://sf.net/projects/mancha/files/misc/openssh-6.7p1_socket-owner.diff -------------- next part -------------- From 4f9aabcbf3b633f6d0e066efaf28349fc610d2b6 Mon Sep 17 00:00:00 2001 From: mancha Date: Mon, 10 Nov 2014 Subject: Check shared connection socket Before allowing a new session to share an existing connection make sure user owns the file specified by ControlPath. --- mux.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/mux.c +++ b/mux.c @@ -2087,6 +2087,7 @@ muxclient(const char *path) socklen_t sun_len; int sock; u_int pid; + struct stat filestat; if (muxclient_command == 0) { if (stdio_forward_host != NULL) @@ -2106,6 +2107,11 @@ muxclient(const char *path) return; } + /* Check file ownership */ + if (stat(path, &filestat) == 0 && filestat.st_uid != geteuid()) + fatal("You do not own the file specified by ControlPath " + "\"%.100s\"", path); + memset(&addr, '\0', sizeof(addr)); addr.sun_family = AF_UNIX; sun_len = offsetof(struct sockaddr_un, sun_path) + -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From fergalme at gmail.com Tue Nov 11 00:46:53 2014 From: fergalme at gmail.com (Fergal Meath) Date: Mon, 10 Nov 2014 13:46:53 +0000 Subject: tun channel FDs changed to -1? In-Reply-To: References: Message-ID: Hi, I eventually found the offender. do_child sets up the environment and before executing the command (ifconfig) it tries to close the "connection descriptors". In my use case, the effect is that the ssh tun channel 0 file descriptors are all set to -1. The patch below prevents the problem and everything seems to work fine - my tunnel now passes traffic. I have also tested that interactive login and command execution works okay and tidies up FD's when finished. I suspect that this is an issue with uClinux vfork and would be very interested in any uClinux user/developer feedback. Also I would like to do more testing before submitting the patch below. diff --git a/SW/source/user/ssh/session.c b/SW/source/user/ssh/session.c index e0e5555..62ecb7a 100755 --- a/SW/source/user/ssh/session.c +++ b/SW/source/user/ssh/session.c @@ -1725,7 +1725,9 @@ do_child(Session *s, const char *command) * closed before building the environment, as we call * get_remote_ipaddr there. */ +#ifndef __uClinux__ child_close_fds(); +#endif /* * Must take new environment into use so that .ssh/rc, Regards, Fergal On Wed, Oct 22, 2014 at 1:58 PM, Fergal Meath wrote: > Hi, > > I have sshd (OpenSSH_5.8p1) running on uCLinux (Linux version 2.6.19-uc1) > Interactive sessions are working okay. > Tunnel device seems to be set up but is not passing any traffic to other > end. > Debug output shows that tun channel 0 file descriptors are changed from > 8/8 to -1/-1. > Does anyone know how or what could be causing this? > > Client command is? > ssh ?w0:0 root at 192.168.1.100 ifconfig tun0 10.0.0.1 pointopoint 10.0.0.2 > netmask 255.255.255.255 > > My sshd debug output is shown below. > > Any help or tips would be appreciated, > Regards, > > Fergal > > ---------- SSHD DEBUG OUTPUT > ---------------------------------------------------- > Jan 1 01:50:09 (none) auth.info sshd[2344]: Accepted password for root > from 192.168.1.200 port 55408 ssh2 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: Entering interactive > session for SSH2. > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: fd 6 setting > O_NONBLOCK > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: fd 7 setting > O_NONBLOCK > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: > server_init_dispatch_20 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: > server_input_channel_open: ctype tun at openssh.com rchan 0 win 2097152 max > 32768 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: sys_tun_open: tun0 > mode 1 fd 8 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: fd 8 setting > O_NONBLOCK > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug3: fd 8 is O_NONBLOCK > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: channel 0: new [tun] > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: > server_input_channel_open: confirm tun at openssh.com > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: > server_input_channel_open: ctype session rchan 2 win 2097152 max 32768 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: input_session_request > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: channel 1: new > [server-session] > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: session_new: > allocate (allocated 0 max 10) > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug3: session_unused: > session id 0 unused > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: session_new: session > 0 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: session_open: > channel 1 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: session_open: > session 0: link with channel 1 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: > server_input_channel_open: confirm session > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: > server_input_channel_req: channel 1 request env reply 0 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: session_by_channel: > session 0 channel 1 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: > session_input_channel_req: session 0 req env > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: Ignoring env request > LANG: disallowed name > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: > server_input_channel_req: channel 1 request exec reply 1 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: session_by_channel: > session 0 channel 1 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug1: > session_input_channel_req: session 0 req exec > Jan 1 01:50:09 (none) auth.debug sshd[2415]: debug1: permanently_set_uid: > 0/0 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: fd 4 setting > TCP_NODELAY > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug3: packet_set_tos: set > IP_TOS 0x08 > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: fd 11 setting > O_NONBLOCK > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: fd 10 setting > O_NONBLOCK > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: fd 13 setting > O_NONBLOCK > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: channel 1: rcvd eof > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: channel 1: output > open -> drain > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: channel 1: obuf empty > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: channel 1: > close_write > Jan 1 01:50:09 (none) auth.debug sshd[2344]: debug2: channel 1: output > drain -> closed > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug1: Received SIGCHLD. > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug1: session_by_pid: pid > 2415 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug1: > session_exit_message: session 0 channel 1 pid 2415 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: request > exit-status confirm 0 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug1: > session_exit_message: release channel 1 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: read<=0 > rfd 11 len 0 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: read > failed > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: close_read > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: input > open -> drain > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: read 0 > from efd 13 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: closing > read-efd 13 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: ibuf empty > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: send eof > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: input > drain -> closed > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: send close > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: notify_done: reading > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug3: channel 1: will not > send data after close > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: rcvd close > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug3: channel 1: will not > send data after close > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: is dead > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: gc: > notify user > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug1: session_by_channel: > session 0 channel 1 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug1: > session_close_by_channel: channel 1 child 0 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug1: session_close: > session 0 pid 0 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug3: session_unused: > session id 0 unused > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: gc: user > detached > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: is dead > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug2: channel 1: garbage > collecting > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug1: channel 1: free: > server-session, nchannels 2 > Jan 1 01:50:10 (none) auth.debug sshd[2344]: debug3: channel 1: status: > The following connections are open:\r\n #0 tun (t4 r0 i0/0 o0/0 fd -1/-1 > cc -1)\r\n #1 server-session (t4 r2 i3/0 o3/0 fd -1/-1 cc -1)\r\n > > From calestyo at scientia.net Tue Nov 11 04:20:21 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Mon, 10 Nov 2014 18:20:21 +0100 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: <20141110081436.GA15934@zoho.com> References: <1415592016.4565.23.camel@scientia.net> <20141110081436.GA15934@zoho.com> Message-ID: <1415640021.4683.2.camel@scientia.net> On Mon, 2014-11-10 at 08:14 +0000, mancha wrote: > The socket is created with a umask of 0177 so you should end up with > socket perms of 0600 or thereabouts. Standard ACLs kick in. Sure,... but that alone doesn't help... > If the > threat model includes an evil root though Uhm... no I talk an about evil user,... As long as the user can create the socket, he can at least trick root into using it (if that uses the socket from a location as /tmp), just as my example has shown. The socket there was owned by user:user and had mode 600... yet root connected to it without noting. If one does it the other way round, i.e. root creates the mux: I tried last week something like this: root at hostA:~$ ssh -o ControlMaster=yes -o ControlPath=/tmp/sshmux hostC and then: user at hostA:~$ ssh -o ControlMaster=no -o ControlPath=/tmp/sshmux hostB It "fails" of course, at least it cannot open the socket and then goes on an connects normally. Now assuming root wouldn't be evil, but accidentally set o+rw: root at hostA:~$ chmod o+rw /tmp/sshmux and then trying: user at hostA:~$ ssh -o ControlMaster=no -o ControlPath=/tmp/sshmux hostB ssh exits with $?=141 but not giving any further warning/error The ssh of the mux however (when in -v) gives: >debug1: multiplexing control connection >multiplex uid mismatch: peer euid 1000 != uid 0 to stderr The same seems to be the case when trying with two normal users, i.e. user1 at hostA:~$ ssh -o ControlMaster=yes -o ControlPath=/tmp/sshmux hostC user1 at hostA:~$ chmod o+rw /tmp/sshmux user2 at hostA:~$ ssh -o ControlMaster=no -o ControlPath=/tmp/sshmux hostB debug1: multiplexing control connection multiplex uid mismatch: peer euid 1000 != uid 1001 So it only seems to work that a normal user tricks root into using an alien socket. That being said,... I haven't checked for any racey hacks... > Regarding possible racey mischief, the socket is created "pseudo > atomically". > > That said, an ownership check that prevents, among other things, root > from accidentally falling through a wormhole wouldn't be bad. Attached > patch against 6.7p1 should do. Wouldn't it be the enough to simply check whether - the socket is owned by the same user - has mode 600 - and directory permissions are such, that another user couldn't have changed this (thinking of ACLs for that) > PS Patch also at: > http://sf.net/projects/mancha/files/misc/openssh-6.7p1_socket-owner.diff mhh I get a HTTP 500 internal server error?! Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From sfrost at snowman.net Tue Nov 11 05:28:20 2014 From: sfrost at snowman.net (Stephen Frost) Date: Mon, 10 Nov 2014 13:28:20 -0500 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: <1415640021.4683.2.camel@scientia.net> References: <1415592016.4565.23.camel@scientia.net> <20141110081436.GA15934@zoho.com> <1415640021.4683.2.camel@scientia.net> Message-ID: <20141110182820.GN28859@tamriel.snowman.net> * Christoph Anton Mitterer (calestyo at scientia.net) wrote: > > That said, an ownership check that prevents, among other things, root > > from accidentally falling through a wormhole wouldn't be bad. Attached > > patch against 6.7p1 should do. > > Wouldn't it be the enough to simply check whether > - the socket is owned by the same user > - has mode 600 > - and directory permissions are such, that another user couldn't have > changed this (thinking of ACLs for that) Should there be a hard-link count check also..? Haven't really thought it all the way through, but that's a common thing to check also.. Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From calestyo at scientia.net Tue Nov 11 05:41:02 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Mon, 10 Nov 2014 19:41:02 +0100 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: <20141110182820.GN28859@tamriel.snowman.net> References: <1415592016.4565.23.camel@scientia.net> <20141110081436.GA15934@zoho.com> <1415640021.4683.2.camel@scientia.net> <20141110182820.GN28859@tamriel.snowman.net> Message-ID: <1415644862.4683.7.camel@scientia.net> On Mon, 2014-11-10 at 13:28 -0500, Stephen Frost wrote: > Should there be a hard-link count check also..? Haven't really thought > it all the way through, but that's a common thing to check also.. hmm not sure if that helps anything... A normal user cannot create hardlinks on files owned by other users, right? So if the owner check already shows that the socket belongs to the current user, then no on (but a evil root) could have created such hardlink, except the user itself. And since no one but root can chown the owern of a file, it should neither work, that a evil userB creates a mux socket, hardlinks it and then changes the owner to good userA of one of the hardlinks. Or am I wrong? (I'm truly no expert in these kind of filesystem level hacks) Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From keisial at gmail.com Tue Nov 11 05:46:51 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Mon, 10 Nov 2014 19:46:51 +0100 Subject: BUG: simple attack when control channel muxing is used In-Reply-To: <1415640021.4683.2.camel@scientia.net> References: <1415592016.4565.23.camel@scientia.net> <20141110081436.GA15934@zoho.com> <1415640021.4683.2.camel@scientia.net> Message-ID: <5461081B.3070700@gmail.com> On 10/11/14 18:20, Christoph Anton Mitterer wrote: > Uhm... no I talk an about evil user,... > As long as the user can create the socket, he can at least trick root > into using it (if that uses the socket from a location as /tmp), just as > my example has shown. > The socket there was owned by user:user and had mode 600... yet root > connected to it without noting. > > > If one does it the other way round, i.e. root creates the mux: > I tried last week something like this: > root at hostA:~$ ssh -o ControlMaster=yes -o ControlPath=/tmp/sshmux hostC > > and then: > user at hostA:~$ ssh -o ControlMaster=no -o ControlPath=/tmp/sshmux hostB > > It "fails" of course, at least it cannot open the socket and then goes > on an connects normally. Note that Linux enforces the discretionary permissions set on unix sockets but other Unix (including the BSD family) doesn't. The ssh check > if ((euid != 0) && (getuid() != euid)) { error("multiplex uid > mismatch: peer euid %u != uid %u", (u_int)euid, (u_int)getuid()); seems precisely to be trying to protect from this (euid is the peer euid). I guess the (euid != 0) checkis there in case ssh was root setuid? It should probably be changed to if ((euid != 0 && (getuid() != uid)) && (getuid() != euid)) not to make it so easy for a malicious root to use your remote connections (yes, it would need receiving the peer ruid). However, for the attack shown, there's not so much to win from improving the check at the socket server side. It should be the connecting ssh (ie. root's) the one verifying that the socket is owned by himself. > That being said,... I haven't checked for any racey hacks... Sadly, the provided patch has a race condition between the stat and the connect. And I don't think fstat()ing a connected unix socket would give us the owner of the socket inode... :( Regards From djm at mindrot.org Tue Nov 11 08:00:04 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 11 Nov 2014 08:00:04 +1100 (EST) Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: <1415592016.4565.23.camel@scientia.net> References: <1415592016.4565.23.camel@scientia.net> Message-ID: On Mon, 10 Nov 2014, Christoph Anton Mitterer wrote: > Hey. > > Interesting that you bring this up now... I've actually looked into this > a week ago but forgot to write a bug report. > > A simple test showed, that ssh doesn't employ any security checks... > when it is able to open the socket, it'll use it apparently: > > I tried last week something like this: > user at hostA:~$ ssh -o ControlMaster=yes -o ControlPath=/tmp/sshmux hostB > > and then: > root at hostA:~$ ssh -o ControlMaster=no -o ControlPath=/tmp/sshmux hostC > > As you can see, the socket is created by user, and root "accidentally" > uses it, even trying to connect to another node. > ssh will just do so without any complains. > > And even when one uses something like %h, %p or that like, an attacker > can easily guess these. > > Since it doesn't seem to be documented that the socket must be created > in a secure location and since neither there are any owner checks like > sshd's StrictMode... I'd probably consider that a security hole. > > upstream what do you think? This behaviour is intentional. root is allowed to connect to users' control sockets for a number of reasons. These include making them work across sudo and it being mostly pointless to restrict root on a system. If you want to avoid root connecting to a suspect socket, then ensure root's sockets are created in a directory that is not writable by untrusted users. I use "ControlPath ~/.ssh/ctl-%C" From calestyo at scientia.net Tue Nov 11 08:18:26 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Mon, 10 Nov 2014 22:18:26 +0100 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: References: <1415592016.4565.23.camel@scientia.net> Message-ID: <1415654306.25595.3.camel@scientia.net> On Tue, 2014-11-11 at 08:00 +1100, Damien Miller wrote: > This behaviour is intentional. root is allowed to connect to users' > control sockets for a number of reasons. Even if,... shouldn't it then be properly documented or better: the checks should be in place per default for root as well, and only with some additional option ControlMasterConnectUnownedSockets=yes (or something like this), which defaults to no, root should be allowed to do this? I mean most people will likely never need that features you mentioned, but it happens rather easy that people place such things in /tmp or /run . Apart from that, have you seen ?ngel's post where he says the check would happen on the socket server side? That would of course make any user (not just root) attackable. > If you want to avoid root connecting to a suspect socket, then ensure > root's sockets are created in a directory that is not writable by > untrusted users. I use "ControlPath ~/.ssh/ctl-%C" Or there should be a StrictModes option like on the sshd side, which prohibits taking sockets from insecure locations per default. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From calestyo at scientia.net Tue Nov 11 08:18:20 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Mon, 10 Nov 2014 22:18:20 +0100 Subject: BUG: simple attack when control channel muxing is used In-Reply-To: <5461081B.3070700@gmail.com> References: <1415592016.4565.23.camel@scientia.net> <20141110081436.GA15934@zoho.com> <1415640021.4683.2.camel@scientia.net> <5461081B.3070700@gmail.com> Message-ID: <1415654300.25595.2.camel@scientia.net> On Mon, 2014-11-10 at 19:46 +0100, ?ngel Gonz?lez wrote: > Note that Linux enforces the discretionary permissions set on unix > sockets but other What exactly does that mean? > I guess the (euid != 0) checkis there in case ssh was root setuid? Or it's really to exclude root from the check, as Damien mentioned. > It > should probably be > changed to if ((euid != 0 && (getuid() != uid)) && (getuid() != euid)) > not to make it so easy > for a malicious root to use your remote connections (yes, it would need > receiving the peer ruid). Let's see what upstream thinks > However, for the attack shown, there's not so much to win from improving > the check at the > socket server side. It should be the connecting ssh (ie. root's) the one > verifying that the socket > is owned by himself. Yes... let's see what upstream replies :) Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Nov 11 08:19:31 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 10 Nov 2014 11:19:31 -1000 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: <1415644862.4683.7.camel@scientia.net> References: <1415592016.4565.23.camel@scientia.net> <20141110081436.GA15934@zoho.com> <1415640021.4683.2.camel@scientia.net> <20141110182820.GN28859@tamriel.snowman.net> <1415644862.4683.7.camel@scientia.net> Message-ID: <877fz2ycrg.fsf@alice.fifthhorseman.net> On Mon 2014-11-10 08:41:02 -1000, Christoph Anton Mitterer wrote: > A normal user cannot create hardlinks on files owned by other users, > right? This depends on your kernel. Some recent Linux kernels prohibit this kind of behavior, but many older Linux kernels (and i'm sure some non-Linux kernels) freely allow the creation of hardlinks to files not owned by the linking user. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From djm at mindrot.org Tue Nov 11 09:20:50 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 11 Nov 2014 09:20:50 +1100 (EST) Subject: ControlMaster question In-Reply-To: References: Message-ID: On Mon, 10 Nov 2014, Philippe Cerfon wrote: > Some problems/questions: > 1) Is it a security issue, when the sockets are created in /tmp? E.g. > could a malevolent user create such a socket and intercept the other > user's connection? Or does ssh check whether the socket is owned by > BOTH it's own user/group? It allows the user who created the socket and root (subject to file permissions). It's best not to mix users' control sockets in the same directory. Could you arrange a per-user temporary directory be created at login time? (e.g. via PAM) If so, then you could put the sockets there. > 2) Apparently ControlPersist 0 is actually the same as yes and the mux > process isn't stopped 0s (i.e. immediately) after the last connection > has gone, but never. > Is this a bug? Kind of - '0' is used internally to implement ControlPersist=yes and this leaked through to the UI. It's probably not a good idea to ban it retrospectively, so I'll add a note to the manual page. -d From djm at mindrot.org Tue Nov 11 09:22:25 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 11 Nov 2014 09:22:25 +1100 (EST) Subject: multiple tun devices per single ssh connection? In-Reply-To: References: Message-ID: On Mon, 10 Nov 2014, Philippe Cerfon wrote: > Hello. > > One more question. > > It seems that it's not possible to have multiple tun devices forwarded > within one ssh connection (especially with different modes p2p / > ethernet), right? > Or do I just invoke it wrong? > > If not, is this planned to be implemented or is the way to go to make > multiple ssh connections? No, it's not implemented and I don't know if anyone plans to implement it. If you need more than one network device forwarded then you could probably rig it up with ppp or the new Unix domain socket forwarding mumble socat mumble. -d From calestyo at scientia.net Tue Nov 11 11:43:56 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Tue, 11 Nov 2014 01:43:56 +0100 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: <1415654306.25595.3.camel@scientia.net> References: <1415592016.4565.23.camel@scientia.net> <1415654306.25595.3.camel@scientia.net> Message-ID: <1415666636.27780.1.camel@scientia.net> I've also just noted that %C is usually not enough to prevent collisions when used in multi-user locations: %C is the hash hover (local host, remote user, hostname, port) I'd guess local host is needed in case of shared homedirs,.. but when it comes to ControlPaths in locations used by multiple users, one obviously needs local user as well. This has of course less todo to with helping against the attacks described above,... but more with preventing accidental collisions. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From mancha1 at zoho.com Tue Nov 11 12:20:38 2014 From: mancha1 at zoho.com (mancha) Date: Tue, 11 Nov 2014 01:20:38 +0000 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: References: <1415592016.4565.23.camel@scientia.net> Message-ID: <20141111012038.GA17301@zoho.com> On Tue, Nov 11, 2014 at 08:00:04AM +1100, Damien Miller wrote: > On Mon, 10 Nov 2014, Christoph Anton Mitterer wrote: [SNIP] > This behaviour is intentional. root is allowed to connect to users' > control sockets for a number of reasons. These include making them > work across sudo and it being mostly pointless to restrict root on a > system. > > If you want to avoid root connecting to a suspect socket, then ensure > root's sockets are created in a directory that is not writable by > untrusted users. I use "ControlPath ~/.ssh/ctl-%C" Before I got Damien's response I had already cooked up a new patch that imposes three restrictions on control socket usage: 1. must be owned by user, 2. perms must be 600, and 3. hard link count can't exceed one. Those who want the more stringent conditions are welcome to it. Modify to your heart's content. It's a bit less racey but if you have a more atomic (and still portable) approach, go for it. I won't be spending any more time on this. --mancha Patch attached and mirrored at: http://sf.net/projects/mancha/files/misc/openssh-6.7p1_socket-hardening.diff -------------- next part -------------- From d08ff5729992bf628932565f4ca45867f04be6f8 Mon Sep 17 00:00:00 2001 From: mancha Date: Mon, 10 Nov 2014 Subject: Stricter conditions on control socket Before allowing access to a control socket make sure: a) user owns the file; b) it has perms 600; and c) its hard link count is not greater than one. --- mux.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/mux.c +++ b/mux.c @@ -2087,6 +2087,7 @@ muxclient(const char *path) socklen_t sun_len; int sock; u_int pid; + struct stat filestat; if (muxclient_command == 0) { if (stdio_forward_host != NULL) @@ -2118,6 +2119,19 @@ muxclient(const char *path) if ((sock = socket(PF_UNIX, SOCK_STREAM, 0)) < 0) fatal("%s socket(): %s", __func__, strerror(errno)); + /* Check file perms, hard link count, and ownership */ + if (stat(path, &filestat) == 0) { + if (filestat.st_uid != geteuid()) + fatal("You do not own the file specified by " + "ControlPath \"%.100s\"", path); + if (filestat.st_mode & 0177) + fatal("File specified by ControlPath \"%.100s\" " + "must have permissions 600", path); + if (filestat.st_nlink > 1) + fatal("File specified by ControlPath \"%.100s\" " + "has more than one hard link", path); + } + if (connect(sock, (struct sockaddr *)&addr, sun_len) == -1) { switch (muxclient_command) { case SSHMUX_COMMAND_OPEN: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From ag4ve.us at gmail.com Tue Nov 11 13:55:06 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Mon, 10 Nov 2014 21:55:06 -0500 Subject: BUG: simple attack when control channel muxing is used (was: Re: ControlMaster question) In-Reply-To: <20141111012038.GA17301@zoho.com> References: <1415592016.4565.23.camel@scientia.net> <20141111012038.GA17301@zoho.com> Message-ID: On Nov 10, 2014 8:26 PM, "mancha" wrote: > > On Tue, Nov 11, 2014 at 08:00:04AM +1100, Damien Miller wrote: > > On Mon, 10 Nov 2014, Christoph Anton Mitterer wrote: > > [SNIP] > > > This behaviour is intentional. root is allowed to connect to users' > > control sockets for a number of reasons. These include making them > > work across sudo and it being mostly pointless to restrict root on a > > system. > > > > If you want to avoid root connecting to a suspect socket, then ensure > > root's sockets are created in a directory that is not writable by > > untrusted users. I use "ControlPath ~/.ssh/ctl-%C" > > Before I got Damien's response I had already cooked up a new patch that > imposes three restrictions on control socket usage: 1. must be owned by > user, 2. perms must be 600, and 3. hard link count can't exceed one. > > Those who want the more stringent conditions are welcome to it. Modify > to your heart's content. > > It's a bit less racey but if you have a more atomic (and still portable) > approach, go for it. I won't be spending any more time on this. > Great for general use. However there should be an option to turn the owner and perms check off. I like single use accounts (I haven't done this but now that I'm thinking about it) so a repo user who handles repo interactions. I wouldn't want it to have access to my ssh private keys but would setup a ControlMaster for it to use. Also, it'd be cool if I could report on the parameters a ControlMaster was initialized with (host, port, user, key, etc) - if this information could be kept in memory and be retrieved via the file that might help with this issue (and its something that's been on my mind besides :P ). From michael at stroeder.com Tue Nov 11 21:28:55 2014 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 11 Nov 2014 11:28:55 +0100 Subject: Key fingerprints (not the DNS kind) In-Reply-To: References: Message-ID: <5461E4E7.2040003@stroeder.com> shawn wilson wrote: > On Nov 9, 2014 8:42 PM, "Damien Miller" wrote: >> >> On Sun, 9 Nov 2014, shawn wilson wrote: >> >>> On Sun, Nov 9, 2014 at 7:11 PM, Damien Miller wrote: >>> >>> That's always a good idea, but try not to reinvent the wheel too much >>> here: http://hashcat.net/wiki/doku.php?id=example_hashes >>> There's no m5(sha512(word)) but $foo$fpr or $foo$host$fpr should maybe >>> be used? >> >> I don't think password hashes are a good model for key fingerprints. >> Password hashes are intended for consumption in password databases, >> key fingerprints are intended for rapid and accurate comparison by >> humans. > > It is to identify a hash. Who cares what the hash is of. Password hash schemes also needs a salt specification and maybe more (rounds etc.) => not usable It seems some people define URN name spaces for such fingerprints: https://tools.ietf.org/html/draft-seantek-certspec http://www.aaronsw.com/2002/draft-swartz-pgp-urn-00.html Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4252 bytes Desc: S/MIME Cryptographic Signature URL: From kirschju at sec.in.tum.de Tue Nov 11 22:10:15 2014 From: kirschju at sec.in.tum.de (Julian Kirsch) Date: Tue, 11 Nov 2014 12:10:15 +0100 Subject: [PATCH] Add TCP Stealth support to OpenSSH Message-ID: <5461EE97.4010202@sec.in.tum.de> Hi list, as revealed earlier this year, secret services are actively scanning the net for vulnerable services in context of programs like CSEC's LANDMARK and GCHQ's HACIENDA [0]. We assume that OpenSSH is one of the most lucrative targets of these programs by using 0-day exploits. Furthermore, there is a long-running worm on the Internet brute-forcing access to systems by guessing usernames and passwords, which thanks to "cloud" computing is virtually impossible to contain. (see, for example, [1]) TCP Stealth is a IETF draft [2] which has to goal of locking out port scanners by introducing a symmetric secret which has to be known to both sides for a connection to succeed. This functionality is mplemented by patching the respective operating system's kernel - in case of Linux this is done by the Knock patch [3] which introduces a new setsockopt(). In order to broaden support for TCP Stealth on the user side, we've created patches for the OpenBSD and Linux versions of OpenSSH which introduce the -z command line option and a new TCPStealthSecret configuration option if the running kernel/libc exports the TCP_STEALTH constant. (PGP-Signatures of the patch are available at the project homepage [3].) We would be glad if the maintainers decided to incorporate our patch into the standard track of OpenSSH. Best regards, Julian --- [0] http://www.heise.de/ct/artikel/NSA-GCHQ-The-HACIENDA-Program-for-Internet-Colonization-2292681.html [1] http://blog.sucuri.net/2013/07/ssh-brute-force-the-10-year-old-attack-that-still-persists.html [2] http://datatracker.ietf.org/doc/draft-kirsch-ietf-tcp-stealth/ [3] https://gnunet.org/knock -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-bsd-knock-patch.diff Type: text/x-patch Size: 13791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-linux-knock-patch.diff Type: text/x-patch Size: 19457 bytes Desc: not available URL: From peter at pean.org Tue Nov 11 22:40:48 2014 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Tue, 11 Nov 2014 12:40:48 +0100 Subject: Host based authentication and SSH CA. In-Reply-To: References: <5458B69B.8060409@pean.org> <5459D5F2.3090807@pean.org> <20141106214454.GC6476@linux124.nas.nasa.gov> <545C6ED7.8030101@pean.org> Message-ID: <5461F5C0.2080700@pean.org> On 11/07/2014 12:29 PM, Damien Miller wrote: > On Fri, 7 Nov 2014, Peter Ankerst?l wrote: > >>> What principals (if any) are associated with the host cert? >> >> Right now i dont have any principals at all in the host cert. > > That's likely the problem then. The principals should list the > hostname(s) of the server. > > (I agree that the documentation here is terrible). > >>> If I recall correctly, sshd will use the FQDN when validating the key or >>> certificate offered by the client. Thus, if you specified any principals >>> for the certificate, the list must include the FQDN and the pattern for >>> teh @cert-authority entry needs to also match the FQDN. >> >> When logging with key based authentication the host CA works fine. >> >> debug1: Host 'm3' is known and matches the ECDSA-CERT host certificate. >> debug1: Found CA key in /etc/ssh/ssh_known_hosts:1 >> >> But when doing hostbased authentication it first gives me those two lines but >> then tries to look for m3 specifically in ssh_known_hosts. > > That's strange - I'll take a look via the bug. > > -d > Any news on this? This is really starting to bug me. /Peter. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3738 bytes Desc: S/MIME Cryptographic Signature URL: From stapelberg+openssh at google.com Wed Nov 12 01:30:24 2014 From: stapelberg+openssh at google.com (Michael Stapelberg) Date: Tue, 11 Nov 2014 06:30:24 -0800 Subject: [PATCH] Early request for comments: U2F authentication In-Reply-To: References: Message-ID: On Wed, Nov 5, 2014 at 7:21 AM, Michael Stapelberg wrote: > Hey, > > Recently, the FIDO alliance announced U2F [1], and Google announced > that it supports U2F tokens (?security keys?) for Google accounts [2]. > As the spec is not a very short read, I gave a presentation last week > about U2F which may be a good quick introduction to the details [3]. > For the rest of this mail, I?ll assume that you read either my > presentation or the spec, but feel free to post any questions about > U2F and I?ll try to answer them. (side note: I?m not working on U2F, > playing around with it and implementing it in OpenSSH is my private > fun project :)) > > I?ve spent some time (together with Christian and Thomas) hacking on > U2F support in OpenSSH, and I?m happy to provide a first patch ? it?s > not complete, but it should be good enough to get the discussion going > :). Please see the two attached files for the patch. Due to their > size, I?ve not posted them in-line. > > The way it currently (!) works: > > 1) Use ?AuthenticationMethods publickey,u2f? in sshd_config (or ,u2f) > 2) Recompile SSH with the patch and change userauth_u2f() to use > packet_put_int(0) (== registration) instead of packet_put_int(1) (== > authentication). Sorry about that. See my question below. > 3) You need to do this step only once: ssh into your server, touch > your security key when prompted, and you?ll see a ssh-u2f key line, > which you should copy&paste into the server?s ~/.ssh/authorized_keys > for the corresponding user. > 4) Recompile with packet_put_int(1). > 5) ssh into your server, touch your security key when prompted, enjoy > the additional security :). > > There are a couple of open questions: > > 1) Will you accept this patch (let?s ignore details for now) at all? > Everyone I?ve talked to in the last couple of days was pretty excited > about having U2F support in OpenSSH, so I think it?d be a great > feature. > > (the rest are detail questions about the implementation) > > 2) Could we make the server write to authorized_keys to avoid the > copy&paste step? Probably not a good idea, but I figured I?d ask > anyway. > > 3) What would be a good way to trigger the different U2F modes on the > client? Should we add a new flag to ssh(1)? Registration is very > rarely triggered, authentication should be the default. > > 4) What should we use as U2F appid? Currently I just set > ?ssh://localhost? (it must be a URL), and we could use > ?ssh://?. Christian suggested using the host key > fingerprint, which would decouple the appid from the hostname (which > may be good if the hostname frequently changes, because U2F security > keys are registered for a specific appid). > > 5) What should we use as the origin (in the ssh client)? In the case > where U2F is used by a web browser, this is set to the canonical > representation of the domain (i.e. lowercased, after idn etc.). At the > moment, I?m using either the host alias or the hostname. Is that > acceptable or is there a better method? > > 6) Not a question, but a note: the patch does not yet handle multiple > registered U2F security keys. > > 7) I?d like to use SSL_load_error_strings() so that the human-readable > error messages actually contain some content and are not just NULL :). > It?ll require linking with -lssl. Is that okay or is there a reason > why we don?t do it so far? > > Thank you very much for any replies :). I haven?t seen any replies yet, and it?s been almost a week. It could just be that none of you care, or all who care are incredibly busy. Still, I?d appreciate a ?don?t know about the details, but we?ll most likely merge your patch? so that I know any further work on this is not in vain :). Thank you! > > [1] https://fidoalliance.org/ > [2] http://googleonlinesecurity.blogspot.ch/2014/10/strengthening-2-step-verification-with.html > [3] https://www.noname-ev.de/w/File:C14h-u2f-how-security-keys-work.pdf From djm at mindrot.org Wed Nov 12 09:37:23 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 12 Nov 2014 09:37:23 +1100 (EST) Subject: Host based authentication and SSH CA. In-Reply-To: <5461F5C0.2080700@pean.org> References: <5458B69B.8060409@pean.org> <5459D5F2.3090807@pean.org> <20141106214454.GC6476@linux124.nas.nasa.gov> <545C6ED7.8030101@pean.org> <5461F5C0.2080700@pean.org> Message-ID: On Tue, 11 Nov 2014, Peter Ankerst?l wrote: > Any news on this? This is really starting to bug me. No, sorry - I'm not likely to have much time to work on OpenSSH for a few weeks. -d From philcerf at gmail.com Wed Nov 12 12:10:04 2014 From: philcerf at gmail.com (Philippe Cerfon) Date: Wed, 12 Nov 2014 02:10:04 +0100 Subject: multiple tun devices per single ssh connection? In-Reply-To: References: Message-ID: Thanks. Is there a feature request ticket on this, so that I could subscribe to be notified once it would be implemented, if ever? Sincerely, Philippe On Mon, Nov 10, 2014 at 11:22 PM, Damien Miller wrote: > On Mon, 10 Nov 2014, Philippe Cerfon wrote: > >> Hello. >> >> One more question. >> >> It seems that it's not possible to have multiple tun devices forwarded >> within one ssh connection (especially with different modes p2p / >> ethernet), right? >> Or do I just invoke it wrong? >> >> If not, is this planned to be implemented or is the way to go to make >> multiple ssh connections? > > No, it's not implemented and I don't know if anyone plans to implement it. > If you need more than one network device forwarded then you could probably > rig it up with ppp or the new Unix domain socket forwarding mumble socat > mumble. > > -d From philcerf at gmail.com Wed Nov 12 12:28:12 2014 From: philcerf at gmail.com (Philippe Cerfon) Date: Wed, 12 Nov 2014 02:28:12 +0100 Subject: ControlMaster question In-Reply-To: References: Message-ID: Hello Damien. Okay I'll see. So the recipe right now is to depend on something to not mix user's sockets. Since this sounds a bit error prone, though, and I've also read the other user's comments now, wouldn't it be better to fix this in a way proposed there? I saw some patches and someone suggested to either apply the check for root as well or make something like StrictModes for the ~/.ssh for the sockets. I've also seem that claim that this user ID check would happen on the socket server side, which would be the one trying to attack, right? So can that be copied to the socket client side as well? Good, thanks for the note. Do you think it's easy to write a patch that makes 0s behave like "immediately exit after the last one is gone"? Would sound like a compelling default :-) Best wishes, Philippe From dkg at fifthhorseman.net Wed Nov 12 14:09:12 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 11 Nov 2014 17:09:12 -1000 Subject: [PATCH] UseDNS should default to "no" Message-ID: <1415761752-7940-1-git-send-email-dkg@fifthhorseman.net> In the dnsop (DNS Operations) working group at the IETF meeting today, there was a strong sense in the room that OpenSSH's sshd should not be checking reverse DNS of clients during connection by default, since it provides no real security benefit. This patch changes the default for UseDNS from "yes" to "no". --- servconf.c | 2 +- sshd_config | 2 +- sshd_config.5 | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/servconf.c b/servconf.c index b317e9c..93ea0cf 100644 --- a/servconf.c +++ b/servconf.c @@ -290,7 +290,7 @@ fill_default_server_options(ServerOptions *options) if (options->max_sessions == -1) options->max_sessions = DEFAULT_SESSIONS_MAX; if (options->use_dns == -1) - options->use_dns = 1; + options->use_dns = 0; if (options->client_alive_interval == -1) options->client_alive_interval = 0; if (options->client_alive_count_max == -1) diff --git a/sshd_config b/sshd_config index e9045bc..9ac96f3 100644 --- a/sshd_config +++ b/sshd_config @@ -112,7 +112,7 @@ UsePrivilegeSeparation sandbox # Default for new installations. #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 -#UseDNS yes +#UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no diff --git a/sshd_config.5 b/sshd_config.5 index 43cc826..93cd581 100644 --- a/sshd_config.5 +++ b/sshd_config.5 @@ -1304,7 +1304,7 @@ should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is -.Dq yes . +.Dq no . .It Cm UseLogin Specifies whether .Xr login 1 -- 2.1.1 From nkadel at gmail.com Wed Nov 12 17:34:55 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 12 Nov 2014 01:34:55 -0500 Subject: [PATCH] UseDNS should default to "no" In-Reply-To: <1415761752-7940-1-git-send-email-dkg@fifthhorseman.net> References: <1415761752-7940-1-git-send-email-dkg@fifthhorseman.net> Message-ID: Is it still doing the reverse DNS, and *logging* the result, unless you use 'sshd -u0'? There's a noticeable difference between doing a reverse DNS for mere logging purposes, which can be very burdensome in some high performance situations where you don't control external NAT reverse DNS space, and *verifying* that the reverse DNS matches. For various performance reasons when managing hundreds or thousands of servers from a single SSH *push* host, I wound up setting their init scripts to use 'sshd -u0'. That trick dates back to..... 2000, for me. On Tue, Nov 11, 2014 at 10:09 PM, Daniel Kahn Gillmor wrote: > In the dnsop (DNS Operations) working group at the IETF meeting today, > there was a strong sense in the room that OpenSSH's sshd should not be > checking reverse DNS of clients during connection by default, since it > provides no real security benefit. > > This patch changes the default for UseDNS from "yes" to "no". > --- > servconf.c | 2 +- > sshd_config | 2 +- > sshd_config.5 | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/servconf.c b/servconf.c > index b317e9c..93ea0cf 100644 > --- a/servconf.c > +++ b/servconf.c > @@ -290,7 +290,7 @@ fill_default_server_options(ServerOptions *options) > if (options->max_sessions == -1) > options->max_sessions = DEFAULT_SESSIONS_MAX; > if (options->use_dns == -1) > - options->use_dns = 1; > + options->use_dns = 0; > if (options->client_alive_interval == -1) > options->client_alive_interval = 0; > if (options->client_alive_count_max == -1) > diff --git a/sshd_config b/sshd_config > index e9045bc..9ac96f3 100644 > --- a/sshd_config > +++ b/sshd_config > @@ -112,7 +112,7 @@ UsePrivilegeSeparation sandbox # Default for new installations. > #Compression delayed > #ClientAliveInterval 0 > #ClientAliveCountMax 3 > -#UseDNS yes > +#UseDNS no > #PidFile /var/run/sshd.pid > #MaxStartups 10:30:100 > #PermitTunnel no > diff --git a/sshd_config.5 b/sshd_config.5 > index 43cc826..93cd581 100644 > --- a/sshd_config.5 > +++ b/sshd_config.5 > @@ -1304,7 +1304,7 @@ should look up the remote host name and check that > the resolved host name for the remote IP address maps back to the > very same IP address. > The default is > -.Dq yes . > +.Dq no . > .It Cm UseLogin > Specifies whether > .Xr login 1 > -- > 2.1.1 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dkg at fifthhorseman.net Wed Nov 12 22:43:15 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 12 Nov 2014 01:43:15 -1000 Subject: [PATCH] UseDNS should default to "no" In-Reply-To: References: <1415761752-7940-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <546347D3.40509@fifthhorseman.net> On 11/11/2014 08:34 PM, Nico Kadel-Garcia wrote: > Is it still doing the reverse DNS, and *logging* the result, unless > you use 'sshd -u0'? There's a noticeable difference between doing a > reverse DNS for mere logging purposes, which can be very burdensome > in some high performance situations where you don't control external > NAT reverse DNS space, and *verifying* that the reverse DNS matches. hm, i think you're right that it is likely to still be doing the reverse lookup and logging the information by default, even though it wouldn't then go ahead and check the forward DNS again. It's not clear that this offers significant gains either, and it provides an extra avenue of attack for things like broken local recursive resolvers, like this bug just reported today against systemd-resolved: http://www.openwall.com/lists/oss-security/2014/11/12/5 > For various performance reasons when managing hundreds or thousands of > servers from a single SSH *push* host, I wound up setting their init > scripts to use 'sshd -u0'. That trick dates back to..... 2000, for me. i can see why that would help. I kind of think that the default should be -u0 as well, to avoid the extra codepath exposure, information leakage, and network access by default. That would have a noticable change in terms of what get stored in utmp, though. I'm also slightly concerned that even "sshd -u0" could be subverted (and sshd made to do network queries remotely) by an end-user adding from="pattern-list" to their ~/.ssh/authorized_keys file, which could be an even more serious regression, if people are using named hosts in that way. Perhaps a better approach here is to leave UseDNS=yes as the default, but also default to -u0, and generate a deprecation warning when encountering any need for DNS while -u0 is set, so that future versions of openssh can get away with disabling those lookups entirely. What do other folks think is the right way to improve the default behavior here? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From alex at alex.org.uk Thu Nov 13 03:54:20 2014 From: alex at alex.org.uk (Alex Bligh) Date: Wed, 12 Nov 2014 16:54:20 +0000 Subject: [PATCH] UseDNS should default to "no" In-Reply-To: <546347D3.40509@fifthhorseman.net> References: <1415761752-7940-1-git-send-email-dkg@fifthhorseman.net> <546347D3.40509@fifthhorseman.net> Message-ID: On 12 Nov 2014, at 11:43, Daniel Kahn Gillmor wrote: > Perhaps a better approach here is to leave UseDNS=yes as the default, > but also default to -u0, and generate a deprecation warning when > encountering any need for DNS while -u0 is set, so that future versions > of openssh can get away with disabling those lookups entirely. > > What do other folks think is the right way to improve the default > behavior here? The first thing I do to a host on install is disable every bit of ssh/DNS interaction I can, plus GSSAPI (I know that's not upstream) as both significantly slow connection times. If you're happy disabling tcpwrappers and ripping it out the source code, this is a rather more minor change, I'd suggest. -- Alex Bligh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From calestyo at scientia.net Thu Nov 13 06:00:31 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Wed, 12 Nov 2014 20:00:31 +0100 Subject: [PATCH] UseDNS should default to "no" In-Reply-To: <546347D3.40509@fifthhorseman.net> References: <1415761752-7940-1-git-send-email-dkg@fifthhorseman.net> <546347D3.40509@fifthhorseman.net> Message-ID: <1415818831.6285.6.camel@scientia.net> On Wed, 2014-11-12 at 01:43 -1000, Daniel Kahn Gillmor wrote: > What do other folks think is the right way to improve the default > behavior here? I'd probably: - default UseDNS = no, since it provides a false sense of security - I'd also go for -u0 per default, even though one should probably double check if that might somehow affect logging as used by prominent software like fail2ban - not sure what to do about from="pattern-list"... perhaps adding a warning there that using domainnames may be insecure anyway,.. perhaps adding a further option that enables/disables DNS for it? Apart form that UseDNS seems to be kinda misnomer... normally I'd expect from the name, that if I say UseDNS=no, then DNS is never used. But actually it's something different... Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From peter at pean.org Fri Nov 14 01:25:28 2014 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Thu, 13 Nov 2014 15:25:28 +0100 Subject: Corrupt KRL file when using multiple CA. Message-ID: <5464BF58.7070504@pean.org> Hi! It seems to be a problem when I have revoked keys from multiple CAs in one KRL file. ssh refuses access and says: Nov 13 13:32:15 q sshd[35438]: error: buffer_get_string_ptr: bad string length 268032 Nov 13 13:32:15 q sshd[35438]: error: parse_revoked_certs: buffer error Nov 13 13:32:15 q sshd[35438]: error: Invalid KRL, refusing public key authentication How would I revoke keys from multiple CAs then? if I put multiple RevokedKeys it only considers one file. The KRL is generated by: ssh-keygen -k -u -f revoked_keys.bin -s ca1.pub revoked_keys1 ssh-keygen -k -u -f revoked_keys.bin -s ca2.pub revoked_keys2 revokes_keys[1-2] has the format: serial: 2134 serial: 2343 serial: 2842 serial: 8795 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3738 bytes Desc: S/MIME Cryptographic Signature URL: From daniel at pocos.nl Fri Nov 14 03:13:06 2014 From: daniel at pocos.nl (Daniel Tryba) Date: Thu, 13 Nov 2014 17:13:06 +0100 Subject: internal-sftp stuck on 'ls' with chrootdirectory Message-ID: <201411131713.06776.daniel@pocos.nl> >Actually I am connecting mysql via IP, so I assume it is not the connection >causing the problem, but maybe some dependencies issues. I have to say that >on another linux box (same configuration but older debian version) the >chroot setup including libnss-mysql does work. So I am missing something >else here. Same problem here, my solution was to create /etc/group (in the context of the chroot) with all system groups, just the 2 visible groups root/sftponly are not enough to get output from ls. -- POCOS B.V. - Croy 9c - 5653 LC Eindhoven Telefoon: 040 293 8661 - Fax: 040 293 8658 http://www.pocos.nl/ - http://www.sipo.nl/ K.v.K. Eindhoven 17097024 From djm at mindrot.org Fri Nov 14 13:34:36 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 14 Nov 2014 13:34:36 +1100 (EST) Subject: Corrupt KRL file when using multiple CA. In-Reply-To: <5464BF58.7070504@pean.org> References: <5464BF58.7070504@pean.org> Message-ID: What version of OpenSSH are you using? I fixed a bug in KRL generation a few months ago: https://anongit.mindrot.org/openssh.git/commit/krl.c?id=2cd7929250cf9e9f658d70dcd452f529ba08c942 On Thu, 13 Nov 2014, Peter Ankerst?l wrote: > Hi! > > It seems to be a problem when I have revoked keys from multiple CAs in one KRL > file. > > ssh refuses access and says: > Nov 13 13:32:15 q sshd[35438]: error: buffer_get_string_ptr: bad string length > 268032 > Nov 13 13:32:15 q sshd[35438]: error: parse_revoked_certs: buffer error > Nov 13 13:32:15 q sshd[35438]: error: Invalid KRL, refusing public key > authentication > > How would I revoke keys from multiple CAs then? if I put multiple RevokedKeys > it only considers one file. > > The KRL is generated by: > ssh-keygen -k -u -f revoked_keys.bin -s ca1.pub revoked_keys1 > ssh-keygen -k -u -f revoked_keys.bin -s ca2.pub revoked_keys2 > > > revokes_keys[1-2] has the format: > serial: 2134 > serial: 2343 > serial: 2842 > serial: 8795 > > From peter at pean.org Fri Nov 14 16:33:13 2014 From: peter at pean.org (=?utf-8?Q?Peter_Ankerst=C3=A5l?=) Date: Fri, 14 Nov 2014 06:33:13 +0100 Subject: Corrupt KRL file when using multiple CA. In-Reply-To: References: <5464BF58.7070504@pean.org> Message-ID: 6.5p1 H?lsningar / regards Peter Ankerst?l > On 14 nov 2014, at 03:34, Damien Miller wrote: > > What version of OpenSSH are you using? I fixed a bug in KRL generation > a few months ago: > > https://anongit.mindrot.org/openssh.git/commit/krl.c?id=2cd7929250cf9e9f658d70dcd452f529ba08c942 > >> On Thu, 13 Nov 2014, Peter Ankerst?l wrote: >> >> Hi! >> >> It seems to be a problem when I have revoked keys from multiple CAs in one KRL >> file. >> >> ssh refuses access and says: >> Nov 13 13:32:15 q sshd[35438]: error: buffer_get_string_ptr: bad string length >> 268032 >> Nov 13 13:32:15 q sshd[35438]: error: parse_revoked_certs: buffer error >> Nov 13 13:32:15 q sshd[35438]: error: Invalid KRL, refusing public key >> authentication >> >> How would I revoke keys from multiple CAs then? if I put multiple RevokedKeys >> it only considers one file. >> >> The KRL is generated by: >> ssh-keygen -k -u -f revoked_keys.bin -s ca1.pub revoked_keys1 >> ssh-keygen -k -u -f revoked_keys.bin -s ca2.pub revoked_keys2 >> >> >> revokes_keys[1-2] has the format: >> serial: 2134 >> serial: 2343 >> serial: 2842 >> serial: 8795 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2532 bytes Desc: not available URL: From peter at pean.org Fri Nov 14 18:26:31 2014 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Fri, 14 Nov 2014 08:26:31 +0100 Subject: Corrupt KRL file when using multiple CA. In-Reply-To: References: <5464BF58.7070504@pean.org> Message-ID: <5465AEA7.7030104@pean.org> On 11/14/2014 03:34 AM, Damien Miller wrote: > What version of OpenSSH are you using? I fixed a bug in KRL generation > a few months ago: > > https://anongit.mindrot.org/openssh.git/commit/krl.c?id=2cd7929250cf9e9f658d70dcd452f529ba08c942 > > On Thu, 13 Nov 2014, Peter Ankerst?l wrote: > >> Hi! >> >> It seems to be a problem when I have revoked keys from multiple CAs in one KRL >> file. >> >> ssh refuses access and says: >> Nov 13 13:32:15 q sshd[35438]: error: buffer_get_string_ptr: bad string length >> 268032 >> Nov 13 13:32:15 q sshd[35438]: error: parse_revoked_certs: buffer error >> Nov 13 13:32:15 q sshd[35438]: error: Invalid KRL, refusing public key >> authentication >> >> How would I revoke keys from multiple CAs then? if I put multiple RevokedKeys >> it only considers one file. >> >> The KRL is generated by: >> ssh-keygen -k -u -f revoked_keys.bin -s ca1.pub revoked_keys1 >> ssh-keygen -k -u -f revoked_keys.bin -s ca2.pub revoked_keys2 >> >> >> revokes_keys[1-2] has the format: >> serial: 2134 >> serial: 2343 >> serial: 2842 >> serial: 8795 >> >> > I recompiled openssh with that line added to krl.c but it gives the same result: debug1: KRL version 0 generated at 20141114T080704 debug3: ssh_krl_from_blob: first pass, section 0x01 debug3: ssh_krl_from_blob: first pass, section 0x01 debug3: ssh_krl_from_blob: second pass, section 0x01 debug3: parse_revoked_certs: subsection type 0x20 debug3: revoked_certs_for_ca_key: new CA RSA debug3: parse_revoked_certs: subsection type 0x22 debug3: parse_revoked_certs: subsection type 0x20 debug3: ssh_krl_from_blob: second pass, section 0x01 debug3: parse_revoked_certs: subsection type 0x20 debug3: parse_revoked_certs: subsection type 0x22 debug3: parse_revoked_certs: subsection type 0x20 buffer_get_string_ptr: bad string length 268032 parse_revoked_certs: buffer error Invalid KRL, refusing public key authentication -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3738 bytes Desc: S/MIME Cryptographic Signature URL: From chandra.kumara at shipxpress.com Sat Nov 15 05:32:12 2014 From: chandra.kumara at shipxpress.com (Chandra Kumara) Date: Sat, 15 Nov 2014 00:02:12 +0530 Subject: openssh upgrading. Message-ID: <54664b86.ab12450a.7f65.fffff089@mx.google.com> Hi Openssh support, I have upgraded openssh from 5.3p1 to 6.2p2 in a RHEL 6.6 - 64 bit server and now i can't login to server remotely using same root password. It always prompting the password saying "Permission denied, please try again." Please help me to resolve the issue. Following are the steps i have followd. ---------------------------------------------------------------- [root at test ~]# ssh -V OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 [root at test ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.6 (Santiago) [root at test ~]# rpm -qa |grep openssh openssh-server-5.3p1-104.el6.x86_64 openssh-clients-5.3p1-104.el6.x86_64 openssh-5.3p1-104.el6.x86_64 yum install rpm-build yum install gcc glibc-devel pam-devel libX11-devel krb5-devel zlib-devel yum install openssh-devel openssl-devel tcp_wrappers-devel libXt-devel imake gtk2-devel wget http://ftp.spline.de/pub/OpenBSD/OpenSSH/portable/openssh-6.2p2.tar.gz wget http://pkgs.fedoraproject.org/repo/pkgs/openssh/x11-ssh-askpass-1.2.4.1.tar. gz/8f2e41f3f7eaa8543a2440454637f3c3/x11-ssh-askpass-1.2.4.1.tar.gz tar zxvf openssh-6.2p2.tar.gz cp openssh-6.2p2/contrib/redhat/openssh.spec . rpmbuild -bb openssh.spec cp x11-ssh-askpass-1.2.4.1.tar.gz /root/rpmbuild/SOURCES/ cp openssh-6.2p2.tar.gz /root/rpmbuild/SOURCES/ cp openssh.spec /root/rpmbuild/SOURCES/ rpmbuild -bb openssh.spec cd /root/rpmbuild/RPMS/x86_64/ rpm -Uvh * /etc/init.d/sshd restart [root at test ~]# rpm -qa |grep openss openssl-devel-1.0.1e-30.el6_6.4.x86_64 openssh-server-6.2p2-1.x86_64 openssl-1.0.1e-30.el6_6.4.x86_64 openssh-askpass-gnome-6.2p2-1.x86_64 openssh-debuginfo-6.2p2-1.x86_64 openssh-6.2p2-1.x86_64 openssh-clients-6.2p2-1.x86_64 [root at plutotest .ssh]# ssh -v root at 192.168.0.38 OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to 192.168.0.38 [192.168.0.38] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/identity-cert type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2 debug1: match: OpenSSH_6.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none 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 debug1: Host '192.168.0.38' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:9 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information Cannot determine realm for numeric host address debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/identity debug1: Trying private key: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug1: Next authentication method: password root at 192.168.0.38's password: debug1: Authentications that can continue: publickey,gssapi-with-mic,password Permission denied, please try again. root at 192.168.0.38's password: ---------------------------------------------------------------- Regards, Chandra Kumara, SSA ShipXpress. 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 phone: +94 11 2826814/15 || website: http://www.shipxpress.com From mouring at offwriting.org Sat Nov 15 05:59:08 2014 From: mouring at offwriting.org (Ben Lindstrom) Date: Fri, 14 Nov 2014 12:59:08 -0600 Subject: openssh upgrading. In-Reply-To: <54664b86.ab12450a.7f65.fffff089@mx.google.com> References: <54664b86.ab12450a.7f65.fffff089@mx.google.com> Message-ID: <640E3F64-DD19-469E-A3DC-A9106908335C@offwriting.org> Have you checked your /etc/ssh/sshd_config after the upgrade? By default most platforms disable root as a valid login user via: "PermitRootLogin" - Ben > On Nov 14, 2014, at 12:32 PM, Chandra Kumara wrote: > > Hi Openssh support, > > > > I have upgraded openssh from 5.3p1 to 6.2p2 in a RHEL 6.6 - 64 bit server > and now i can't login to server remotely using same root password. It always > prompting the password saying "Permission denied, please try again." > > > > Please help me to resolve the issue. > > > > Following are the steps i have followd. > > > > ---------------------------------------------------------------- > > [root at test ~]# ssh -V > > OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 > > > > [root at test ~]# cat /etc/redhat-release > > Red Hat Enterprise Linux Server release 6.6 (Santiago) > > > > [root at test ~]# rpm -qa |grep openssh > > openssh-server-5.3p1-104.el6.x86_64 > > openssh-clients-5.3p1-104.el6.x86_64 > > openssh-5.3p1-104.el6.x86_64 > > > > yum install rpm-build > > yum install gcc glibc-devel pam-devel libX11-devel krb5-devel zlib-devel > > yum install openssh-devel openssl-devel tcp_wrappers-devel libXt-devel imake > gtk2-devel > > > > wget http://ftp.spline.de/pub/OpenBSD/OpenSSH/portable/openssh-6.2p2.tar.gz > > wget > http://pkgs.fedoraproject.org/repo/pkgs/openssh/x11-ssh-askpass-1.2.4.1.tar. > gz/8f2e41f3f7eaa8543a2440454637f3c3/x11-ssh-askpass-1.2.4.1.tar.gz > > > > tar zxvf openssh-6.2p2.tar.gz > > cp openssh-6.2p2/contrib/redhat/openssh.spec . > > rpmbuild -bb openssh.spec > > > > cp x11-ssh-askpass-1.2.4.1.tar.gz /root/rpmbuild/SOURCES/ > > cp openssh-6.2p2.tar.gz /root/rpmbuild/SOURCES/ > > cp openssh.spec /root/rpmbuild/SOURCES/ > > > > rpmbuild -bb openssh.spec > > > > cd /root/rpmbuild/RPMS/x86_64/ > > rpm -Uvh * > > /etc/init.d/sshd restart > > > > [root at test ~]# rpm -qa |grep openss > > openssl-devel-1.0.1e-30.el6_6.4.x86_64 > > openssh-server-6.2p2-1.x86_64 > > openssl-1.0.1e-30.el6_6.4.x86_64 > > openssh-askpass-gnome-6.2p2-1.x86_64 > > openssh-debuginfo-6.2p2-1.x86_64 > > openssh-6.2p2-1.x86_64 > > openssh-clients-6.2p2-1.x86_64 > > > > > > [root at plutotest .ssh]# ssh -v root at 192.168.0.38 > > OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug1: Applying options for * > > debug1: Connecting to 192.168.0.38 [192.168.0.38] port 22. > > debug1: Connection established. > > debug1: permanently_set_uid: 0/0 > > debug1: identity file /root/.ssh/identity type -1 > > debug1: identity file /root/.ssh/identity-cert type -1 > > debug1: identity file /root/.ssh/id_rsa type -1 > > debug1: identity file /root/.ssh/id_rsa-cert type -1 > > debug1: identity file /root/.ssh/id_dsa type -1 > > debug1: identity file /root/.ssh/id_dsa-cert type -1 > > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2 > > debug1: match: OpenSSH_6.2 pat OpenSSH* > > debug1: Enabling compatibility mode for protocol 2.0 > > debug1: Local version string SSH-2.0-OpenSSH_5.3 > > debug1: SSH2_MSG_KEXINIT sent > > debug1: SSH2_MSG_KEXINIT received > > debug1: kex: server->client aes128-ctr hmac-md5 none > > debug1: kex: client->server aes128-ctr hmac-md5 none > > 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 > > debug1: Host '192.168.0.38' is known and matches the RSA host key. > > debug1: Found key in /root/.ssh/known_hosts:9 > > debug1: ssh_rsa_verify: signature correct > > debug1: SSH2_MSG_NEWKEYS sent > > debug1: expecting SSH2_MSG_NEWKEYS > > debug1: SSH2_MSG_NEWKEYS received > > debug1: SSH2_MSG_SERVICE_REQUEST sent > > debug1: SSH2_MSG_SERVICE_ACCEPT received > > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password > > debug1: Next authentication method: gssapi-with-mic > > debug1: Unspecified GSS failure. Minor code may provide more information > > Cannot determine realm for numeric host address > > > > debug1: Unspecified GSS failure. Minor code may provide more information > > Cannot determine realm for numeric host address > > > > debug1: Unspecified GSS failure. Minor code may provide more information > > > > > > debug1: Unspecified GSS failure. Minor code may provide more information > > Cannot determine realm for numeric host address > > > > debug1: Next authentication method: publickey > > debug1: Trying private key: /root/.ssh/identity > > debug1: Trying private key: /root/.ssh/id_rsa > > debug1: Trying private key: /root/.ssh/id_dsa > > debug1: Next authentication method: password > > root at 192.168.0.38's password: > > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password > > Permission denied, please try again. > > root at 192.168.0.38's password: > > ---------------------------------------------------------------- > > Regards, > > Chandra Kumara, SSA > > ShipXpress. > > 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 > > phone: +94 11 2826814/15 || website: > http://www.shipxpress.com > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From reinhard.karbas at unify.com Sat Nov 15 08:26:23 2014 From: reinhard.karbas at unify.com (Karbas, Reinhard) Date: Fri, 14 Nov 2014 21:26:23 +0000 Subject: Removal of tcp wrapper support Message-ID: <045659F4145C0D4181694A2003AE9BC943208AB8@MCHP03MSX.global-ad.net> Based on the release notes I found for openssh 6.7p1 the support for ftp wrappers was removed How do I re-enable the enforcing of hosts.allow and hosts.deny with this version of openssh? Thx Reinhard Reinhard Karbas [http://www.unify.com/images/signature/unify-logo.gif] Tel: +1 (561) 923-1843 email: reinhard.karbas at unify.com Unify Inc. 5500 Broken Sound Blvd., Boca Raton, FL 33487 unify.com [http://www.unify.com/images/signature/icon-twitter.jpg] [http://www.unify.com/images/signature/icon-facebook.jpg] [http://www.unify.com/images/signature/icon-linkedin.jpg] [http://www.unify.com/images/signature/icon-googleplus.jpg] This message and any attachments are solely for the use of intended recipients. They contain privileged and/or confidential information, attorney work product or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation. From mancha1 at zoho.com Sat Nov 15 10:36:01 2014 From: mancha1 at zoho.com (mancha) Date: Fri, 14 Nov 2014 23:36:01 +0000 Subject: Removal of tcp wrapper support In-Reply-To: <045659F4145C0D4181694A2003AE9BC943208AB8@MCHP03MSX.global-ad.net> References: <045659F4145C0D4181694A2003AE9BC943208AB8@MCHP03MSX.global-ad.net> Message-ID: <20141114233601.GA7960@zoho.com> On Fri, Nov 14, 2014 at 09:26:23PM +0000, Karbas, Reinhard wrote: > Based on the release notes I found for openssh 6.7p1 the support for > ftp wrappers was removed How do I re-enable the enforcing of > hosts.allow and hosts.deny with this version of openssh? > > Thx > > Reinhard TCP Wrapper support was dropped as of OpenSSH 6.7. However, the day 6.7 released I posted a patch for those who wish to resurrect the feature: http://marc.info/?l=openssh-unix-dev&m=141265241623747&w=3 The patch changes configure.ac so don't forget to autoreconf -fiv after applying it. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From nkadel at gmail.com Sat Nov 15 12:15:08 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 14 Nov 2014 20:15:08 -0500 Subject: openssh upgrading. In-Reply-To: <54664b86.ab12450a.7f65.fffff089@mx.google.com> References: <54664b86.ab12450a.7f65.fffff089@mx.google.com> Message-ID: On Fri, Nov 14, 2014 at 1:32 PM, Chandra Kumara wrote: > Hi Openssh support, > > > > I have upgraded openssh from 5.3p1 to 6.2p2 in a RHEL 6.6 - 64 bit server > and now i can't login to server remotely using same root password. It always > prompting the password saying "Permission denied, please try again." I just tried the 6.7p1 tarball with this procedure. Seems to work fine. The .spec file is missing the BuildRequires dependency of "/usr/bin/xmkmf" in the dependencies for the openssh-x11-aspass module, but othewise seems to work fine. > Please help me to resolve the issue. > > > > Following are the steps i have followd. > > > > ---------------------------------------------------------------- > > [root at test ~]# ssh -V > > OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 > > > > [root at test ~]# cat /etc/redhat-release > > Red Hat Enterprise Linux Server release 6.6 (Santiago) > > > > [root at test ~]# rpm -qa |grep openssh > > openssh-server-5.3p1-104.el6.x86_64 > > openssh-clients-5.3p1-104.el6.x86_64 > > openssh-5.3p1-104.el6.x86_64 > > > > yum install rpm-build > > yum install gcc glibc-devel pam-devel libX11-devel krb5-devel zlib-devel > > yum install openssh-devel openssl-devel tcp_wrappers-devel libXt-devel imake > gtk2-devel > > > > wget http://ftp.spline.de/pub/OpenBSD/OpenSSH/portable/openssh-6.2p2.tar.gz > > wget > http://pkgs.fedoraproject.org/repo/pkgs/openssh/x11-ssh-askpass-1.2.4.1.tar. > gz/8f2e41f3f7eaa8543a2440454637f3c3/x11-ssh-askpass-1.2.4.1.tar.gz > > > > tar zxvf openssh-6.2p2.tar.gz > > cp openssh-6.2p2/contrib/redhat/openssh.spec . > > rpmbuild -bb openssh.spec > > > > cp x11-ssh-askpass-1.2.4.1.tar.gz /root/rpmbuild/SOURCES/ > > cp openssh-6.2p2.tar.gz /root/rpmbuild/SOURCES/ > > cp openssh.spec /root/rpmbuild/SOURCES/ > > > > rpmbuild -bb openssh.spec > > > > cd /root/rpmbuild/RPMS/x86_64/ > > rpm -Uvh * > > /etc/init.d/sshd restart > > > > [root at test ~]# rpm -qa |grep openss > > openssl-devel-1.0.1e-30.el6_6.4.x86_64 > > openssh-server-6.2p2-1.x86_64 > > openssl-1.0.1e-30.el6_6.4.x86_64 > > openssh-askpass-gnome-6.2p2-1.x86_64 > > openssh-debuginfo-6.2p2-1.x86_64 > > openssh-6.2p2-1.x86_64 > > openssh-clients-6.2p2-1.x86_64 > > > > > > [root at plutotest .ssh]# ssh -v root at 192.168.0.38 > > OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug1: Applying options for * > > debug1: Connecting to 192.168.0.38 [192.168.0.38] port 22. > > debug1: Connection established. > > debug1: permanently_set_uid: 0/0 > > debug1: identity file /root/.ssh/identity type -1 > > debug1: identity file /root/.ssh/identity-cert type -1 > > debug1: identity file /root/.ssh/id_rsa type -1 > > debug1: identity file /root/.ssh/id_rsa-cert type -1 > > debug1: identity file /root/.ssh/id_dsa type -1 > > debug1: identity file /root/.ssh/id_dsa-cert type -1 > > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2 > > debug1: match: OpenSSH_6.2 pat OpenSSH* > > debug1: Enabling compatibility mode for protocol 2.0 > > debug1: Local version string SSH-2.0-OpenSSH_5.3 > > debug1: SSH2_MSG_KEXINIT sent > > debug1: SSH2_MSG_KEXINIT received > > debug1: kex: server->client aes128-ctr hmac-md5 none > > debug1: kex: client->server aes128-ctr hmac-md5 none > > 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 > > debug1: Host '192.168.0.38' is known and matches the RSA host key. > > debug1: Found key in /root/.ssh/known_hosts:9 > > debug1: ssh_rsa_verify: signature correct > > debug1: SSH2_MSG_NEWKEYS sent > > debug1: expecting SSH2_MSG_NEWKEYS > > debug1: SSH2_MSG_NEWKEYS received > > debug1: SSH2_MSG_SERVICE_REQUEST sent > > debug1: SSH2_MSG_SERVICE_ACCEPT received > > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password > > debug1: Next authentication method: gssapi-with-mic > > debug1: Unspecified GSS failure. Minor code may provide more information > > Cannot determine realm for numeric host address > > > > debug1: Unspecified GSS failure. Minor code may provide more information > > Cannot determine realm for numeric host address > > > > debug1: Unspecified GSS failure. Minor code may provide more information > > > > > > debug1: Unspecified GSS failure. Minor code may provide more information > > Cannot determine realm for numeric host address > > > > debug1: Next authentication method: publickey > > debug1: Trying private key: /root/.ssh/identity > > debug1: Trying private key: /root/.ssh/id_rsa > > debug1: Trying private key: /root/.ssh/id_dsa > > debug1: Next authentication method: password > > root at 192.168.0.38's password: > > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password > > Permission denied, please try again. > > root at 192.168.0.38's password: > > ---------------------------------------------------------------- > > Regards, > > Chandra Kumara, SSA > > ShipXpress. > > 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 > > phone: +94 11 2826814/15 || website: > http://www.shipxpress.com > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From calestyo at scientia.net Sat Nov 15 14:23:46 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 15 Nov 2014 04:23:46 +0100 Subject: ControlMaster question In-Reply-To: References: Message-ID: <1416021826.12026.2.camel@scientia.net> Hey folks. Damien added a commit[0] which already suggests users to place their sockets in safe directories only. But I think this is only part of a proper solution, so I made some effort and collected all the information from this thread, and placed it into the ticket[1] I've had created previously: I've also reported ticket #2318[2] which is loosely related Ideally, any further discussions, patches, would be placed there. Cheers, Chris. [0] https://github.com/openssh/openssh-portable/commit/fc302561369483bb755b17f671f70fb894aec01d [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2311#c1 [2] https://bugzilla.mindrot.org/show_bug.cgi?id=2318 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From dtucker at zip.com.au Sat Nov 15 17:51:26 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 15 Nov 2014 17:51:26 +1100 Subject: Removal of tcp wrapper support In-Reply-To: <20141114233601.GA7960@zoho.com> References: <045659F4145C0D4181694A2003AE9BC943208AB8@MCHP03MSX.global-ad.net> <20141114233601.GA7960@zoho.com> Message-ID: An alternative is to start sshd via inetd and the tcpd wrapper program. On Nov 15, 2014 9:37 AM, "mancha" wrote: > On Fri, Nov 14, 2014 at 09:26:23PM +0000, Karbas, Reinhard wrote: > > Based on the release notes I found for openssh 6.7p1 the support for > > ftp wrappers was removed How do I re-enable the enforcing of > > hosts.allow and hosts.deny with this version of openssh? > > > > Thx > > > > Reinhard > > TCP Wrapper support was dropped as of OpenSSH 6.7. However, the day 6.7 > released I posted a patch for those who wish to resurrect the feature: > http://marc.info/?l=openssh-unix-dev&m=141265241623747&w=3 > > The patch changes configure.ac so don't forget to autoreconf -fiv after > applying it. > > --mancha > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > From djm at mindrot.org Sat Nov 15 21:16:51 2014 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Nov 2014 21:16:51 +1100 (EST) Subject: Corrupt KRL file when using multiple CA. In-Reply-To: <5465AEA7.7030104@pean.org> References: <5464BF58.7070504@pean.org> <5465AEA7.7030104@pean.org> Message-ID: On Fri, 14 Nov 2014, Peter Ankerst?l wrote: > I recompiled openssh with that line added to krl.c but it gives the same > result: > > debug1: KRL version 0 generated at 20141114T080704 > debug3: ssh_krl_from_blob: first pass, section 0x01 > debug3: ssh_krl_from_blob: first pass, section 0x01 > debug3: ssh_krl_from_blob: second pass, section 0x01 > debug3: parse_revoked_certs: subsection type 0x20 > debug3: revoked_certs_for_ca_key: new CA RSA > debug3: parse_revoked_certs: subsection type 0x22 > debug3: parse_revoked_certs: subsection type 0x20 > debug3: ssh_krl_from_blob: second pass, section 0x01 > debug3: parse_revoked_certs: subsection type 0x20 > debug3: parse_revoked_certs: subsection type 0x22 > debug3: parse_revoked_certs: subsection type 0x20 > buffer_get_string_ptr: bad string length 268032 > parse_revoked_certs: buffer error > Invalid KRL, refusing public key authentication Did you regenerate the KRL after patching OpenSSH? The bug is in KRL generation, not reading. -d From peter at pean.org Sat Nov 15 22:22:17 2014 From: peter at pean.org (=?utf-8?Q?Peter_Ankerst=C3=A5l?=) Date: Sat, 15 Nov 2014 12:22:17 +0100 Subject: Corrupt KRL file when using multiple CA. In-Reply-To: References: <5464BF58.7070504@pean.org> <5465AEA7.7030104@pean.org> Message-ID: <46C14754-3397-4D10-8E51-44C83336F219@pean.org> > On 15 Nov 2014, at 11:16, Damien Miller wrote: > > On Fri, 14 Nov 2014, Peter Ankerst?l wrote: > >> I recompiled openssh with that line added to krl.c but it gives the same >> result: >> >> debug1: KRL version 0 generated at 20141114T080704 >> debug3: ssh_krl_from_blob: first pass, section 0x01 >> debug3: ssh_krl_from_blob: first pass, section 0x01 >> debug3: ssh_krl_from_blob: second pass, section 0x01 >> debug3: parse_revoked_certs: subsection type 0x20 >> debug3: revoked_certs_for_ca_key: new CA RSA >> debug3: parse_revoked_certs: subsection type 0x22 >> debug3: parse_revoked_certs: subsection type 0x20 >> debug3: ssh_krl_from_blob: second pass, section 0x01 >> debug3: parse_revoked_certs: subsection type 0x20 >> debug3: parse_revoked_certs: subsection type 0x22 >> debug3: parse_revoked_certs: subsection type 0x20 >> buffer_get_string_ptr: bad string length 268032 >> parse_revoked_certs: buffer error >> Invalid KRL, refusing public key authentication > > Did you regenerate the KRL after patching OpenSSH? The bug is in KRL > generation, not reading. > Yes, exactly. > -d -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4124 bytes Desc: not available URL: From chandra.kumara at shipxpress.com Mon Nov 17 02:47:06 2014 From: chandra.kumara at shipxpress.com (Chandra Kumara) Date: Sun, 16 Nov 2014 21:17:06 +0530 Subject: openssh upgrading. In-Reply-To: References: <54664b86.ab12450a.7f65.fffff089@mx.google.com> Message-ID: <5468c79d.a58c460a.4a99.fffff5e2@mx.google.com> Hi Nico, I couldn't connect to the server remotely not only to root but also any secondary user. My issue was with "openssh-debuginfo" rpm. I used "yum remove openssh" and reinstall rpm build 6.2p2 version again (openssh, openssh-clients and openssh-server) except "openssh-debuginfo" Then upgraded to 6.6p1 also and working fine. This time i didn't use http://pkgs.fedoraproject.org/repo/pkgs/openssh/x11-ssh-askpass-1.2.4.1.tar.gz to do rpm build, instead used, sed -i -e "s/%define no_gnome_askpass 0/%define no_gnome_askpass 1/g" openssh.spec sed -i -e "s/%define no_x11_askpass 0/%define no_x11_askpass 1/g" openssh.spec sed -i -e "s/BuildPreReq/BuildRequires/g" openssh.spec Regards, Chandra Kumara, SSA ShipXpress. 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 phone: +94 11 2826814/15 || website: http://www.shipxpress.com -----Original Message----- From: Nico Kadel-Garcia [mailto:nkadel at gmail.com] Sent: Saturday, November 15, 2014 6:45 AM To: Chandra Kumara Cc: openssh at openssh.com; openssh-unix-announce at mindrot.org; openssh-unix-dev at mindrot.org Subject: Re: openssh upgrading. On Fri, Nov 14, 2014 at 1:32 PM, Chandra Kumara wrote: > Hi Openssh support, > > > > I have upgraded openssh from 5.3p1 to 6.2p2 in a RHEL 6.6 - 64 bit > server and now i can't login to server remotely using same root > password. It always prompting the password saying "Permission denied, please try again." I just tried the 6.7p1 tarball with this procedure. Seems to work fine. The .spec file is missing the BuildRequires dependency of "/usr/bin/xmkmf" in the dependencies for the openssh-x11-aspass module, but othewise seems to work fine. > Please help me to resolve the issue. > > > > Following are the steps i have followd. > > > > ---------------------------------------------------------------- > > [root at test ~]# ssh -V > > OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 > > > > [root at test ~]# cat /etc/redhat-release > > Red Hat Enterprise Linux Server release 6.6 (Santiago) > > > > [root at test ~]# rpm -qa |grep openssh > > openssh-server-5.3p1-104.el6.x86_64 > > openssh-clients-5.3p1-104.el6.x86_64 > > openssh-5.3p1-104.el6.x86_64 > > > > yum install rpm-build > > yum install gcc glibc-devel pam-devel libX11-devel krb5-devel > zlib-devel > > yum install openssh-devel openssl-devel tcp_wrappers-devel libXt-devel > imake gtk2-devel > > > > wget > http://ftp.spline.de/pub/OpenBSD/OpenSSH/portable/openssh-6.2p2.tar.gz > > wget > http://pkgs.fedoraproject.org/repo/pkgs/openssh/x11-ssh-askpass-1.2.4.1.tar. > gz/8f2e41f3f7eaa8543a2440454637f3c3/x11-ssh-askpass-1.2.4.1.tar.gz > > > > tar zxvf openssh-6.2p2.tar.gz > > cp openssh-6.2p2/contrib/redhat/openssh.spec . > > rpmbuild -bb openssh.spec > > > > cp x11-ssh-askpass-1.2.4.1.tar.gz /root/rpmbuild/SOURCES/ > > cp openssh-6.2p2.tar.gz /root/rpmbuild/SOURCES/ > > cp openssh.spec /root/rpmbuild/SOURCES/ > > > > rpmbuild -bb openssh.spec > > > > cd /root/rpmbuild/RPMS/x86_64/ > > rpm -Uvh * > > /etc/init.d/sshd restart > > > > [root at test ~]# rpm -qa |grep openss > > openssl-devel-1.0.1e-30.el6_6.4.x86_64 > > openssh-server-6.2p2-1.x86_64 > > openssl-1.0.1e-30.el6_6.4.x86_64 > > openssh-askpass-gnome-6.2p2-1.x86_64 > > openssh-debuginfo-6.2p2-1.x86_64 > > openssh-6.2p2-1.x86_64 > > openssh-clients-6.2p2-1.x86_64 > > > > > > [root at plutotest .ssh]# ssh -v root at 192.168.0.38 > > OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug1: Applying options for * > > debug1: Connecting to 192.168.0.38 [192.168.0.38] port 22. > > debug1: Connection established. > > debug1: permanently_set_uid: 0/0 > > debug1: identity file /root/.ssh/identity type -1 > > debug1: identity file /root/.ssh/identity-cert type -1 > > debug1: identity file /root/.ssh/id_rsa type -1 > > debug1: identity file /root/.ssh/id_rsa-cert type -1 > > debug1: identity file /root/.ssh/id_dsa type -1 > > debug1: identity file /root/.ssh/id_dsa-cert type -1 > > debug1: Remote protocol version 2.0, remote software version > OpenSSH_6.2 > > debug1: match: OpenSSH_6.2 pat OpenSSH* > > debug1: Enabling compatibility mode for protocol 2.0 > > debug1: Local version string SSH-2.0-OpenSSH_5.3 > > debug1: SSH2_MSG_KEXINIT sent > > debug1: SSH2_MSG_KEXINIT received > > debug1: kex: server->client aes128-ctr hmac-md5 none > > debug1: kex: client->server aes128-ctr hmac-md5 none > > 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 > > debug1: Host '192.168.0.38' is known and matches the RSA host key. > > debug1: Found key in /root/.ssh/known_hosts:9 > > debug1: ssh_rsa_verify: signature correct > > debug1: SSH2_MSG_NEWKEYS sent > > debug1: expecting SSH2_MSG_NEWKEYS > > debug1: SSH2_MSG_NEWKEYS received > > debug1: SSH2_MSG_SERVICE_REQUEST sent > > debug1: SSH2_MSG_SERVICE_ACCEPT received > > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password > > debug1: Next authentication method: gssapi-with-mic > > debug1: Unspecified GSS failure. Minor code may provide more > information > > Cannot determine realm for numeric host address > > > > debug1: Unspecified GSS failure. Minor code may provide more > information > > Cannot determine realm for numeric host address > > > > debug1: Unspecified GSS failure. Minor code may provide more > information > > > > > > debug1: Unspecified GSS failure. Minor code may provide more > information > > Cannot determine realm for numeric host address > > > > debug1: Next authentication method: publickey > > debug1: Trying private key: /root/.ssh/identity > > debug1: Trying private key: /root/.ssh/id_rsa > > debug1: Trying private key: /root/.ssh/id_dsa > > debug1: Next authentication method: password > > root at 192.168.0.38's password: > > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password > > Permission denied, please try again. > > root at 192.168.0.38's password: > > ---------------------------------------------------------------- > > Regards, > > Chandra Kumara, SSA > > ShipXpress. > > 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 > > phone: +94 11 2826814/15 || website: > http://www.shipxpress.com > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From nkadel at gmail.com Mon Nov 17 03:49:36 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 16 Nov 2014 11:49:36 -0500 Subject: openssh upgrading. In-Reply-To: <5468c79d.a58c460a.4a99.fffff5e2@mx.google.com> References: <54664b86.ab12450a.7f65.fffff089@mx.google.com> <5468c79d.a58c460a.4a99.fffff5e2@mx.google.com> Message-ID: On Sun, Nov 16, 2014 at 10:47 AM, Chandra Kumara wrote: > Hi Nico, > > I couldn't connect to the server remotely not only to root but also any secondary user. > > My issue was with "openssh-debuginfo" rpm. I used "yum remove openssh" and reinstall rpm build 6.2p2 version again (openssh, openssh-clients and openssh-server) except "openssh-debuginfo" You mean that installing openssh-debuginfo broke it? And uninstalling openssh-debuginfo fixed it? > Then upgraded to 6.6p1 also and working fine. Why are you continuing to use out of date releases? 6.7p1 is out and in production use. > This time i didn't use http://pkgs.fedoraproject.org/repo/pkgs/openssh/x11-ssh-askpass-1.2.4.1.tar.gz to do rpm build, instead used, > > sed -i -e "s/%define no_gnome_askpass 0/%define no_gnome_askpass 1/g" openssh.spec > sed -i -e "s/%define no_x11_askpass 0/%define no_x11_askpass 1/g" openssh.spec > sed -i -e "s/BuildPreReq/BuildRequires/g" openssh.spec You could have just reset the 'define' statements to have value '1' %define no_gnome_askpass 1 %define no_x11_askpass 1 That way, your SRPM would still have the relevant tarball if you want it. Becasue, you see, that 'BuildPreReq' also cleared outer prereqs.such as 'glibc-devel' and 'pam'. So you actually wound up changing several things more than you needed. And in fact, there is a 'build6x' option you may want to set for your operating system. > > Regards, > Chandra Kumara, SSA > ShipXpress. > 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 > phone: +94 11 2826814/15 || website: http://www.shipxpress.com > > -----Original Message----- > From: Nico Kadel-Garcia [mailto:nkadel at gmail.com] > Sent: Saturday, November 15, 2014 6:45 AM > To: Chandra Kumara > Cc: openssh at openssh.com; openssh-unix-announce at mindrot.org; openssh-unix-dev at mindrot.org > Subject: Re: openssh upgrading. > > On Fri, Nov 14, 2014 at 1:32 PM, Chandra Kumara wrote: >> Hi Openssh support, >> >> >> >> I have upgraded openssh from 5.3p1 to 6.2p2 in a RHEL 6.6 - 64 bit >> server and now i can't login to server remotely using same root >> password. It always prompting the password saying "Permission denied, please try again." > > I just tried the 6.7p1 tarball with this procedure. Seems to work fine. The .spec file is missing the BuildRequires dependency of "/usr/bin/xmkmf" in the dependencies for the openssh-x11-aspass module, but othewise seems to work fine. > > >> Please help me to resolve the issue. >> >> >> >> Following are the steps i have followd. >> >> >> >> ---------------------------------------------------------------- >> >> [root at test ~]# ssh -V >> >> OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 >> >> >> >> [root at test ~]# cat /etc/redhat-release >> >> Red Hat Enterprise Linux Server release 6.6 (Santiago) >> >> >> >> [root at test ~]# rpm -qa |grep openssh >> >> openssh-server-5.3p1-104.el6.x86_64 >> >> openssh-clients-5.3p1-104.el6.x86_64 >> >> openssh-5.3p1-104.el6.x86_64 >> >> >> >> yum install rpm-build >> >> yum install gcc glibc-devel pam-devel libX11-devel krb5-devel >> zlib-devel >> >> yum install openssh-devel openssl-devel tcp_wrappers-devel libXt-devel >> imake gtk2-devel >> >> >> >> wget >> http://ftp.spline.de/pub/OpenBSD/OpenSSH/portable/openssh-6.2p2.tar.gz >> >> wget >> http://pkgs.fedoraproject.org/repo/pkgs/openssh/x11-ssh-askpass-1.2.4.1.tar. >> gz/8f2e41f3f7eaa8543a2440454637f3c3/x11-ssh-askpass-1.2.4.1.tar.gz >> >> >> >> tar zxvf openssh-6.2p2.tar.gz >> >> cp openssh-6.2p2/contrib/redhat/openssh.spec . >> >> rpmbuild -bb openssh.spec >> >> >> >> cp x11-ssh-askpass-1.2.4.1.tar.gz /root/rpmbuild/SOURCES/ >> >> cp openssh-6.2p2.tar.gz /root/rpmbuild/SOURCES/ >> >> cp openssh.spec /root/rpmbuild/SOURCES/ >> >> >> >> rpmbuild -bb openssh.spec >> >> >> >> cd /root/rpmbuild/RPMS/x86_64/ >> >> rpm -Uvh * >> >> /etc/init.d/sshd restart >> >> >> >> [root at test ~]# rpm -qa |grep openss >> >> openssl-devel-1.0.1e-30.el6_6.4.x86_64 >> >> openssh-server-6.2p2-1.x86_64 >> >> openssl-1.0.1e-30.el6_6.4.x86_64 >> >> openssh-askpass-gnome-6.2p2-1.x86_64 >> >> openssh-debuginfo-6.2p2-1.x86_64 >> >> openssh-6.2p2-1.x86_64 >> >> openssh-clients-6.2p2-1.x86_64 >> >> >> >> >> >> [root at plutotest .ssh]# ssh -v root at 192.168.0.38 >> >> OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 >> >> debug1: Reading configuration data /etc/ssh/ssh_config >> >> debug1: Applying options for * >> >> debug1: Connecting to 192.168.0.38 [192.168.0.38] port 22. >> >> debug1: Connection established. >> >> debug1: permanently_set_uid: 0/0 >> >> debug1: identity file /root/.ssh/identity type -1 >> >> debug1: identity file /root/.ssh/identity-cert type -1 >> >> debug1: identity file /root/.ssh/id_rsa type -1 >> >> debug1: identity file /root/.ssh/id_rsa-cert type -1 >> >> debug1: identity file /root/.ssh/id_dsa type -1 >> >> debug1: identity file /root/.ssh/id_dsa-cert type -1 >> >> debug1: Remote protocol version 2.0, remote software version >> OpenSSH_6.2 >> >> debug1: match: OpenSSH_6.2 pat OpenSSH* >> >> debug1: Enabling compatibility mode for protocol 2.0 >> >> debug1: Local version string SSH-2.0-OpenSSH_5.3 >> >> debug1: SSH2_MSG_KEXINIT sent >> >> debug1: SSH2_MSG_KEXINIT received >> >> debug1: kex: server->client aes128-ctr hmac-md5 none >> >> debug1: kex: client->server aes128-ctr hmac-md5 none >> >> 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 >> >> debug1: Host '192.168.0.38' is known and matches the RSA host key. >> >> debug1: Found key in /root/.ssh/known_hosts:9 >> >> debug1: ssh_rsa_verify: signature correct >> >> debug1: SSH2_MSG_NEWKEYS sent >> >> debug1: expecting SSH2_MSG_NEWKEYS >> >> debug1: SSH2_MSG_NEWKEYS received >> >> debug1: SSH2_MSG_SERVICE_REQUEST sent >> >> debug1: SSH2_MSG_SERVICE_ACCEPT received >> >> debug1: Authentications that can continue: >> publickey,gssapi-with-mic,password >> >> debug1: Next authentication method: gssapi-with-mic >> >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> >> Cannot determine realm for numeric host address >> >> >> >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> >> Cannot determine realm for numeric host address >> >> >> >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> >> >> >> >> >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> >> Cannot determine realm for numeric host address >> >> >> >> debug1: Next authentication method: publickey >> >> debug1: Trying private key: /root/.ssh/identity >> >> debug1: Trying private key: /root/.ssh/id_rsa >> >> debug1: Trying private key: /root/.ssh/id_dsa >> >> debug1: Next authentication method: password >> >> root at 192.168.0.38's password: >> >> debug1: Authentications that can continue: >> publickey,gssapi-with-mic,password >> >> Permission denied, please try again. >> >> root at 192.168.0.38's password: >> >> ---------------------------------------------------------------- >> >> Regards, >> >> Chandra Kumara, SSA >> >> ShipXpress. >> >> 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 >> >> phone: +94 11 2826814/15 || website: >> http://www.shipxpress.com >> >> >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From nkadel at gmail.com Mon Nov 17 06:32:11 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 16 Nov 2014 14:32:11 -0500 Subject: RHEL .spec file patches for openssh-6.7p1 Message-ID: A recent thread about someone building 6.7p1 caused me to take a look at the contrib/redhat/openssh.spec file, and I have a few suggested changes in the attached patch file. * Eliminate the '--with-rsh' option, it's no longer supported. * Hardcode the openssh-devel version dependency, the autoconf expects at least openssl-0.9.8f That's also why it won't compile on RHEL 5 anymore. * Always include the source tarball for openssh-x11-askpass in the SRPM, even if unused, so that the SRPM is always complete for compilation in other environments. * Explicitly list dependencies for openssh-x11-askpass: when building OpenSSH in a 'mock' environment, one can't rely on 'imagke' or 'libXT-devel' or 'gek2-devel' being available. * Activate some logic for the 'build_6x' option to be derived from the 'rhel' macro value. It's not really equipped to handle RHEL 7 or Fedora, which ideally should be using systemd instead of SysV init scripts, but I think folks can work from those RHEL published sources if they feel the need. RHEL is no longer upenly publishing SRPM's to the community, the code is now available via git at https://git.centos.org/. I've attacked a patch file, and the git clone is at https://github.com/nkadel/nkadel-openssh-portable/. Nico Kadel-Garcia From djm at mindrot.org Mon Nov 17 11:25:26 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Nov 2014 11:25:26 +1100 (EST) Subject: Corrupt KRL file when using multiple CA. In-Reply-To: <46C14754-3397-4D10-8E51-44C83336F219@pean.org> References: <5464BF58.7070504@pean.org> <5465AEA7.7030104@pean.org> <46C14754-3397-4D10-8E51-44C83336F219@pean.org> Message-ID: On Sat, 15 Nov 2014, Peter Ankerst?l wrote: > > Did you regenerate the KRL after patching OpenSSH? The bug is in KRL > > generation, not reading. > > > Yes, exactly. Found the problem. The certificates section was being written out incorrectly. This fixes it and adds test coverage for it: commit 9f9fad0191028edc43d100d0ded39419b6895fdf Author: djm at openbsd.org Date: Mon Nov 17 00:21:40 2014 +0000 upstream commit fix KRL generation when multiple CAs are in use We would generate an invalid KRL when revoking certs by serial number for multiple CA keys due to a section being written out twice. Also extend the regress test to catch this case by having it produce a multi-CA KRL. Reported by peter AT pean.org diff --git a/krl.c b/krl.c index eb31df9..832ac8b 100644 --- a/krl.c +++ b/krl.c @@ -14,7 +14,7 @@ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $OpenBSD: krl.c,v 1.17 2014/06/24 01:13:21 djm Exp $ */ +/* $OpenBSD: krl.c,v 1.18 2014/11/17 00:21:40 djm Exp $ */ #include "includes.h" @@ -686,6 +686,7 @@ ssh_krl_to_blob(struct ssh_krl *krl, Buffer *buf, const Key **sign_keys, /* Store sections for revoked certificates */ TAILQ_FOREACH(rc, &krl->revoked_certs, entry) { + buffer_clear(§); if (revoked_certs_generate(rc, §) != 0) goto out; buffer_put_char(buf, KRL_SECTION_CERTIFICATES); From peter at pean.org Mon Nov 17 18:04:55 2014 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Mon, 17 Nov 2014 08:04:55 +0100 Subject: Corrupt KRL file when using multiple CA. In-Reply-To: References: <5464BF58.7070504@pean.org> <5465AEA7.7030104@pean.org> <46C14754-3397-4D10-8E51-44C83336F219@pean.org> Message-ID: <54699E17.4020907@pean.org> On 11/17/2014 01:25 AM, Damien Miller wrote: > On Sat, 15 Nov 2014, Peter Ankerst?l wrote: > >>> Did you regenerate the KRL after patching OpenSSH? The bug is in KRL >>> generation, not reading. >>> >> Yes, exactly. > > Found the problem. The certificates section was being written out > incorrectly. This fixes it and adds test coverage for it: > > commit 9f9fad0191028edc43d100d0ded39419b6895fdf > Author: djm at openbsd.org > Date: Mon Nov 17 00:21:40 2014 +0000 > > upstream commit > > fix KRL generation when multiple CAs are in use > > We would generate an invalid KRL when revoking certs by serial > number for multiple CA keys due to a section being written out > twice. > > Also extend the regress test to catch this case by having it > produce a multi-CA KRL. > > Reported by peter AT pean.org > > diff --git a/krl.c b/krl.c > index eb31df9..832ac8b 100644 > --- a/krl.c > +++ b/krl.c > @@ -14,7 +14,7 @@ > * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > */ > > -/* $OpenBSD: krl.c,v 1.17 2014/06/24 01:13:21 djm Exp $ */ > +/* $OpenBSD: krl.c,v 1.18 2014/11/17 00:21:40 djm Exp $ */ > > #include "includes.h" > > @@ -686,6 +686,7 @@ ssh_krl_to_blob(struct ssh_krl *krl, Buffer *buf, const Key **sign_keys, > > /* Store sections for revoked certificates */ > TAILQ_FOREACH(rc, &krl->revoked_certs, entry) { > + buffer_clear(§); > if (revoked_certs_generate(rc, §) != 0) > goto out; > buffer_put_char(buf, KRL_SECTION_CERTIFICATES); > > I have confirmed that this fixes my problem. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3738 bytes Desc: S/MIME Cryptographic Signature URL: From vinschen at redhat.com Mon Nov 17 19:49:14 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 17 Nov 2014 09:49:14 +0100 Subject: [PATCH] Patch by Florian Friesdorf : contrib/cygwin/ssh-host-config: Add -N option to allow different service name. In-Reply-To: <20141106170032.GA22021@calimero.vinschen.de> References: <20141106170032.GA22021@calimero.vinschen.de> Message-ID: <20141117084914.GB28219@calimero.vinschen.de> Ping? Thanks, Corinna On Nov 6 18:00, Corinna Vinschen wrote: > Hi, > > today I got a neat patch to ssh-host-config. With the new -N option it > allows to install multiple sshd services under different service names. > I like the idea, so I thought I send the patch upstream. See below. > > > Thanks, > Corinna > > > --- > contrib/cygwin/ssh-host-config | 19 +++++++++++++------ > 1 file changed, 13 insertions(+), 6 deletions(-) > mode change 100644 => 100755 contrib/cygwin/ssh-host-config > > diff --git a/contrib/cygwin/ssh-host-config b/contrib/cygwin/ssh-host-config > old mode 100644 > new mode 100755 > index 3214829..d934d09 > --- a/contrib/cygwin/ssh-host-config > +++ b/contrib/cygwin/ssh-host-config > @@ -61,6 +61,7 @@ LOCALSTATEDIR=/var > > sshd_config_configured=no > port_number=22 > +service_name=sshd > strictmodes=yes > privsep_used=yes > cygwin_value="" > @@ -408,7 +409,7 @@ install_service() { > local ret=0 > > echo > - if /usr/bin/cygrunsrv -Q sshd >/dev/null 2>&1 > + if /usr/bin/cygrunsrv -Q ${service_name} >/dev/null 2>&1 > then > csih_inform "Sshd service is already installed." > check_service_files_ownership "" || let ret+=$? > @@ -464,7 +465,7 @@ install_service() { > fi > if [ -z "${password}" ] > then > - if /usr/bin/cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ > + if /usr/bin/cygrunsrv -I ${service_name} -d "CYGWIN ${service_name}" -p /usr/sbin/sshd \ > -a "-D" -y tcpip "${cygwin_env[@]}" > then > echo > @@ -474,20 +475,20 @@ install_service() { > csih_inform "will start automatically after the next reboot." > fi > else > - if /usr/bin/cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ > + if /usr/bin/cygrunsrv -I ${service_name} -d "CYGWIN ${service_name}" -p /usr/sbin/sshd \ > -a "-D" -y tcpip "${cygwin_env[@]}" \ > -u "${run_service_as}" -w "${password}" > then > /usr/bin/editrights -u "${run_service_as}" -a SeServiceLogonRight > echo > csih_inform "The sshd service has been installed under the '${run_service_as}'" > - csih_inform "account. To start the service now, call \`net start sshd' or" > - csih_inform "\`cygrunsrv -S sshd'. Otherwise, it will start automatically" > + csih_inform "account. To start the service now, call \`net start ${service_name}' or" > + csih_inform "\`cygrunsrv -S ${service_name}'. Otherwise, it will start automatically" > csih_inform "after the next reboot." > fi > fi > > - if /usr/bin/cygrunsrv -Q sshd >/dev/null 2>&1 > + if /usr/bin/cygrunsrv -Q ${service_name} >/dev/null 2>&1 > then > check_service_files_ownership "${run_service_as}" || let ret+=$? > else > @@ -561,6 +562,11 @@ do > shift > ;; > > + -N | --name ) > + service_name=$1 > + shift > + ;; > + > -p | --port ) > port_number=$1 > shift > @@ -590,6 +596,7 @@ do > echo " --yes -y Answer all questions with \"yes\" automatically." > echo " --no -n Answer all questions with \"no\" automatically." > echo " --cygwin -c Use \"options\" as value for CYGWIN environment var." > + echo " --name -N sshd windows service name." > echo " --port -p sshd listens on port n." > echo " --user -u privileged user for service, default 'cyg_server'." > echo " --pwd -w Use \"pwd\" as password for privileged user." -- 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 vinschen at redhat.com Mon Nov 17 19:48:42 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 17 Nov 2014 09:48:42 +0100 Subject: [PATCH] Don't read group names from /etc/group In-Reply-To: <20141105132523.GV28636@calimero.vinschen.de> References: <20141105132523.GV28636@calimero.vinschen.de> Message-ID: <20141117084842.GA28219@calimero.vinschen.de> Ping? Thanks, Corinna On Nov 5 14:25, Corinna Vinschen wrote: > On Nov 5 11:03, Damien Miller wrote: > > done - thanks again > > Thank you. Unfortunately there was still one problem left in > ssh-host-config, which at one point reads from /etc/group when printing > the user's group membership. Patch below. > > > Thanks, > Corinna > > > Signed-off-by: Corinna Vinschen > --- > contrib/cygwin/ssh-host-config | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/contrib/cygwin/ssh-host-config b/contrib/cygwin/ssh-host-config > index 301d5eb..3214829 100644 > --- a/contrib/cygwin/ssh-host-config > +++ b/contrib/cygwin/ssh-host-config > @@ -623,10 +623,7 @@ then > csih_warning "However, it seems your account does not have these privileges." > csih_warning "Here's the list of groups in your user token:" > echo > - for i in $(/usr/bin/id -G) > - do > - /usr/bin/awk -F: "/[^:]*:[^:]*:$i:/{ print \" \" \$1; }" /etc/group > - done > + /usr/bin/id -Gnz | xargs -0n1 echo " " > echo > csih_warning "This usually means you're running this script from a non-admin" > csih_warning "desktop session, or in a non-elevated shell under UAC control." -- 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 philcerf at gmail.com Tue Nov 18 14:45:00 2014 From: philcerf at gmail.com (Philippe Cerfon) Date: Tue, 18 Nov 2014 04:45:00 +0100 Subject: can compression be safely used with SSH? Message-ID: Hello. At work we collect logs (via ssh) from all kinds of hosts on one central node which has no connection to the internet and is tried to kept secure. The idea is, as you can imagine, that in case of a compromise we'd have at least all the logs up to the break without any forgeries. The logging is done continuously and compression is used. Now the following is not really that much relevant for the our scenario, where all nodes are in one intranet, but I was speculating with a colleague of mine, whether this (and SSH in general) could be abused for CRIME/BREACH like attacks. Now I'm aware that at least OpenSSH uses the delayed compression so it's not so easy as with webservers, but when you look at how we use it - it should be quite simple for an attacker to inject some chosen plain texts in our logs (e.g. logs from a webserver). As war as I understood, the idea of CRIME and friends was that one knows the parts of the plain text, sees how the ciphertext changes and can then use the change of length in cryptoanalysis. So what exactly does that mean? Can it be used to get more knowledge on the used session keys? Or can it be used to possibly decrypt that block of data which contained the plaintext? Of course in SSH it wouldn't be that easy, where one might have something like: GET /fobar?password=secret&chosenPlainText=gotcha So there is not such direct way to extract a secret as it was made possible in an attack like CRIME, but yet it may theoretically be possible to get out something useful, or wouldn't it? So I could be stupid and have a log format in Apache httpd which is like: myrootpassword=iamdumb Now in the above scenario and attacker that could eavesdrop our log collector's connections, could also make arbitrary requests to our company's webserver, thereby change places chosen plaintexts and by the compression deduce the password. As I've said, the whole thing is probably no real world thread. I'm rather wondering whether SSH would be in principle vulnerable too I found http://thread.gmane.org/gmane.network.openssh.devel/20016 in the archives, which implies that the delayed compression would make it secure. a) So how would that prevent the basic idea of the attack as outlined above? b) Why would the non-delayed compression be insecure? Okay there might be a valuable secret involved (e.g. the passphrase) which is then compressed, but an attacker can likely not inject and chosen plain texts at that step of protocol negotiation between a valid client and the server? And what would it help him, if the attacker on himself makes gazillion connections requests, altering e.g. the user- or algo names? Nothing valuable should have been sent to an unauthenticated client by the server at that stage. Regards, Philippe. From naddy at mips.inka.de Wed Nov 19 03:33:45 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Tue, 18 Nov 2014 16:33:45 +0000 (UTC) Subject: can compression be safely used with SSH? References: Message-ID: On 2014-11-18, Philippe Cerfon wrote: > Now the following is not really that much relevant for the our > scenario, where all nodes are in one intranet, but I was speculating > with a colleague of mine, whether this (and SSH in general) could be > abused for CRIME/BREACH like attacks. These attacks apply when the adversary can monitor your traffic and you mix secret data with public data injected (or at least observed) by the attacker. This results in a compression oracle: the size of the compressed packet can be used to infer matches between the secret and public data and thus leaks secret information. > Now I'm aware that at least OpenSSH uses the delayed compression so > it's not so easy as with webservers, but when you look at how we use > it - it should be quite simple for an attacker to inject some chosen > plain texts in our logs (e.g. logs from a webserver). Yes, but do your logging connections carry any secrets? > So what exactly does that mean? Can it be used to get more knowledge > on the used session keys? No. > Or can it be used to possibly decrypt that block of data which > contained the plaintext? Not decrypt, but deduce. The attacker doesn't need the ciphertext at all, they just need its size. This allows them to make inferences about the secret plaintext. > Of course in SSH it wouldn't be that easy, where one might have something like: > GET /fobar?password=secret&chosenPlainText=gotcha That is a great example for a construct that is vulnerable to this sort of attack. The underlying encryption--IPsec, SSL, SSH, whatever--doesn't matter. > So I could be stupid and have a log format in Apache httpd which is like: > myrootpassword=iamdumb > > Now in the above scenario and attacker that could eavesdrop our log > collector's connections, could also make arbitrary requests to our > company's webserver, thereby change places chosen plaintexts URI> and by the compression deduce the password. Yes. > As I've said, the whole thing is probably no real world thread. I'm > rather wondering whether SSH would be in principle vulnerable too It is. Strictly speaking, SSH proper isn't, but your overall protocol construct that uses SSH as encryption layer is vulnerable. Banning SSH's compression doesn't solve this problem: If you compress the data yourself before sending it over SSH, you're vulnerable just the same. Anything with a layering like this +------------------------------+ | secret | injected plaintext | +------------------------------+ | compression | +------------------------------+ | encryption | +------------------------------+ is affected. > I found http://thread.gmane.org/gmane.network.openssh.devel/20016 in > the archives, which implies that the delayed compression would make it > secure. No, this only refers to SSH's password authentication. Delaying compression until after authentication, as zlib at openssh.com does, means that the password isn't compressed, thus there can be no compression oracle. > a) So how would that prevent the basic idea of the attack as outlined above? For data that you pass after authentication, it doesn't. > b) Why would the non-delayed compression be insecure? Okay there might > be a valuable secret involved (e.g. the passphrase) which is then > compressed, but an attacker can likely not inject and chosen plain > texts at that step of protocol negotiation between a valid client and > the server? Indeed, this is unlikely to be exploitable. Delayed compression wasn't introduced to protect against this (I think), but to guard against bugs in the compression code, like a buffer overflow in the decompressor. With delayed compression, you can't attack the compression code unless you can authenticate, and once you're authenticated, you can only attack an sshd child process that has dropped permissions. > And what would it help him, if the attacker on himself makes gazillion > connections requests, altering e.g. the user- or algo names? Nothing > valuable should have been sent to an unauthenticated client by the > server at that stage. Right. -- Christian "naddy" Weisgerber naddy at mips.inka.de From philcerf at gmail.com Wed Nov 19 09:17:08 2014 From: philcerf at gmail.com (Philippe Cerfon) Date: Tue, 18 Nov 2014 23:17:08 +0100 Subject: can compression be safely used with SSH? In-Reply-To: References: Message-ID: Hi Christian. Thanks for your answers! >Yes, but do your logging connections carry any secrets? No, sure, as I've said, it's more a theoretical thinking based on the paradigm "everything is secret" >> Of course in SSH it wouldn't be that easy, where one might have something like: >> GET /fobar?password=secret&chosenPlainText=gotcha >That is a great example for a construct that is vulnerable to this >sort of attack. The underlying encryption--IPsec, SSL, SSH, >whatever--doesn't matter. Of course it works with any protocol, I didn't meant to blame SSH. >It is. Strictly speaking, SSH proper isn't, but your overall >protocol construct that uses SSH as encryption layer is vulnerable. >Banning SSH's compression doesn't solve this problem: If you compress >the data yourself before sending it over SSH, you're vulnerable >just the same. Anything with a layering like this > > +------------------------------+ > | secret | injected plaintext | > +------------------------------+ > | compression | > +------------------------------+ > | encryption | > +------------------------------+ > >is affected. Sure, but the manual case should be much harder to exploit, unless there is some automatic compression that happens which attacker knows about and where chosen plaintext can be injected. Of course this is exactly what could happen in an example similar to mine, SSH compression disabled, but regularly copying logrotated and gzipped files from the hosts to the collector host. But there an attacker would have basically no idea which of his chosen plaintexts went into which file, which portion of the file he's currently seeing and so on. This may very well render the attack impracticable, right? Perhaps this goes a bit off topic, but are there any general countermeasures being developed against these kinds of attacks, which could then also used with SSH? Like salting the length of transmitted packets with some 1-30 random bytes (I mean for every packet using a different salt length)? >Delayed compression wasn't introduced to protect against this >(I think), but to guard against bugs in the compression code, like >a buffer overflow in the decompressor. With delayed compression, >you can't attack the compression code unless you can authenticate, >and once you're authenticated, you can only attack an sshd child >process that has dropped permissions. I see. Again, the following is rather theoretical: I usually try to educate my colleagues to use better crypto respectively care about security, so I wondered whether I could whitelist SSH level compression for certain accounts on the server side. Of course this still doesn't solve the principal vulnerability of any manually compressed data (being composed of chosen plaintext + secret data) but I'd guess that this is anyway far more difficult to exploit and preventing at least only one of them is better than nothing. So I imagined that I could do something like: Compression no in my global sshd_config but add a Match User sue,larry Compression delayed Assuming that I've educated sue and larry about the attack, and thus they wouldn't use ssh to transfer possibly injected data (like logs) when compression is on, they would still be allowed to do so. My nagios-probe user however, would be denied per the global default. Unfortunately it seems that Compression cannot be used inside Match :-( Regards, Philippe From naddy at mips.inka.de Thu Nov 20 03:34:29 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Wed, 19 Nov 2014 16:34:29 +0000 (UTC) Subject: can compression be safely used with SSH? References: Message-ID: On 2014-11-18, Philippe Cerfon wrote: > Sure, but the manual case should be much harder to exploit, unless > there is some automatic compression that happens which attacker knows > about and where chosen plaintext can be injected. > Of course this is exactly what could happen in an example similar to > mine, SSH compression disabled, but regularly copying logrotated and > gzipped files from the hosts to the collector host. Or rsync -z, or people building their own compression layer, etc. > Perhaps this goes a bit off topic, but are there any general > countermeasures being developed against these kinds of attacks, which > could then also used with SSH? Like salting the length of transmitted > packets with some 1-30 random bytes (I mean for every packet using a > different salt length)? OpenSSH already adds the minimum random padding required: "Arbitrary-length padding, such that the total length of (packet_length || padding_length || payload || random padding) is a multiple of the cipher block size or 8, whichever is larger. There MUST be at least four bytes of padding." https://tools.ietf.org/html/rfc4253#section-6 I don't know how much this interferes with compression oracle attacks in practice. > I usually try to educate my colleagues to use better crypto > respectively care about security, so I wondered whether I could > whitelist SSH level compression for certain accounts on the server > side. > Of course this still doesn't solve the principal vulnerability of any > manually compressed data (being composed of chosen plaintext + secret > data) but I'd guess that this is anyway far more difficult to exploit > and preventing at least only one of them is better than nothing. I think SSH is the wrong layer to address this. People need to be wary of building application protocols that combine an authentication token (cookie, password) and known plaintext into frequent queries. The vast majority of SSH compression uses aren't concerned by this. -- Christian "naddy" Weisgerber naddy at mips.inka.de From dflatley at us.ibm.com Thu Nov 20 08:57:22 2014 From: dflatley at us.ibm.com (David Flatley) Date: Wed, 19 Nov 2014 16:57:22 -0500 Subject: Fw: version question Message-ID: I am trying to build Openssh 6.7p1 on a Red Hat 5.6 x86_64 system with Red Hat openssl-0.9.8e-31, which is the latest Red Hat openssl version. The Openssh build checks openssl versions and requires 0.9.8f. Is there a work around for this? Thanks. David Flatley From philcerf at gmail.com Thu Nov 20 10:41:38 2014 From: philcerf at gmail.com (Philippe Cerfon) Date: Thu, 20 Nov 2014 00:41:38 +0100 Subject: can compression be safely used with SSH? In-Reply-To: References: Message-ID: >I think SSH is the wrong layer to address this. Sure,... as it was said, it's a general problem. But I'd guess the more systematic compression is deployed (e.g. on a protocol level) the easier it gets to exploit. >People need to be >wary of building application protocols that combine an authentication >token (cookie, password) and known plaintext into frequent queries. Well most of our people here using SSH aren't wary of very much - one can basically be happy if they check fingerprints. ;-) >The vast majority of SSH compression uses aren't concerned by this. Sure, nevertheless, I've had a short glance at the source code: Wouldn't it basically work to change in servconf.c: { "compression", sCompression, SSHCFG_GLOBAL }, to { "compression", sCompression, SSHCFG_ALL }, and when it was actually set in Match section, bail out with an error when "yes" was used? Since delayed compression happens only after authentication, this should make it possible to use it with Match User. Or do I miss something? Sincerely, Philippe From nkadel at gmail.com Thu Nov 20 14:18:55 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 19 Nov 2014 22:18:55 -0500 Subject: Fw: version question In-Reply-To: References: Message-ID: Use 6.6p1, or consider patching the check for openssl version in openbsd-compat/openssl-compat.h to ignore the failure, on the basis that RHEL has been backporting patches to openssl for RHEL 5.. Or get the heck off RHEL 5 and hop to RHEL 6, which I'd urge for many other reasons. On Wed, Nov 19, 2014 at 4:57 PM, David Flatley wrote: > > I am trying to build Openssh 6.7p1 on a Red Hat 5.6 x86_64 system > with Red Hat openssl-0.9.8e-31, which is the latest Red Hat openssl > version. The Openssh build checks openssl versions and requires 0.9.8f. > Is there a work around for this? > Thanks. > > David Flatley > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From naddy at mips.inka.de Fri Nov 21 02:56:01 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Thu, 20 Nov 2014 15:56:01 +0000 (UTC) Subject: can compression be safely used with SSH? References: Message-ID: On 2014-11-19, Philippe Cerfon wrote: > Since delayed compression happens only after authentication, this > should make it possible to use it with Match User. > Or do I miss something? Even if delayed compression is only activated after authentication, the the fact that delayed compression will be used has already been negotiated before authentication and can't be changed retroactively. -- Christian "naddy" Weisgerber naddy at mips.inka.de From djm at mindrot.org Fri Nov 21 08:59:12 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Nov 2014 08:59:12 +1100 (EST) Subject: Fw: version question In-Reply-To: References: Message-ID: On Wed, 19 Nov 2014, David Flatley wrote: > > I am trying to build Openssh 6.7p1 on a Red Hat 5.6 x86_64 system > with Red Hat openssl-0.9.8e-31, which is the latest Red Hat openssl > version. The Openssh build checks openssl versions and requires 0.9.8f. > Is there a work around for this? Build a more recent OpenSSL (perhaps configured to make static libraries) and build OpenSSH against it. -d From nkadel at gmail.com Fri Nov 21 12:54:25 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 20 Nov 2014 20:54:25 -0500 Subject: Fw: version question In-Reply-To: References: Message-ID: On Thu, Nov 20, 2014 at 4:59 PM, Damien Miller wrote: > On Wed, 19 Nov 2014, David Flatley wrote: > >> >> I am trying to build Openssh 6.7p1 on a Red Hat 5.6 x86_64 system >> with Red Hat openssl-0.9.8e-31, which is the latest Red Hat openssl >> version. The Openssh build checks openssl versions and requires 0.9.8f. >> Is there a work around for this? > > Build a more recent OpenSSL (perhaps configured to make static libraries) > and build OpenSSH against it. > > -d Then you've got *two* packages not directly supported by Red Hat or included in CentOS or Scientific Linux to support, and little to no traction with the upstream support community if any other components interact badly with it. I see the patch where the version check was added, in https://github.com/openssh/openssh-portable/commit/d7c81e216a7bd9eed6e239c970d9261bb1651947. Is the check because of the documented 'HeartBleed' bug? That has been patched in the RHEL 5 OpenSSL, even though they did not update the OpenSSL release version? Or are there other features of the latest OpenSSL that OpenSSH 6.7 is reliant on? If it was primarily the HearBleed bug, then it should be acceptable for RHEL 5 compilation to disable that check as long as the developer is sure the minor release version is recent enough. I'd be happy to submit such a patch for the contrib/redhat/openssh.spec file, if folks would consider it useful. From djm at mindrot.org Fri Nov 21 13:31:40 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Nov 2014 13:31:40 +1100 (EST) Subject: Fw: version question In-Reply-To: References: Message-ID: On Wed, 19 Nov 2014, Nico Kadel-Garcia wrote: > Use 6.6p1, or consider patching the check for openssl version in > openbsd-compat/openssl-compat.h to ignore the failure, on the basis > that RHEL has been backporting patches to openssl for RHEL 5.. Do you understand why that check exists in the first place? From nkadel at gmail.com Fri Nov 21 14:03:05 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 20 Nov 2014 22:03:05 -0500 Subject: Fw: version question In-Reply-To: References: Message-ID: On Thu, Nov 20, 2014 at 9:31 PM, Damien Miller wrote: > On Wed, 19 Nov 2014, Nico Kadel-Garcia wrote: > >> Use 6.6p1, or consider patching the check for openssl version in >> openbsd-compat/openssl-compat.h to ignore the failure, on the basis >> that RHEL has been backporting patches to openssl for RHEL 5.. > > Do you understand why that check exists in the first place? That's why I asked. A bit more digging shows that the HeartBleed bug apparently never applied to 0.9.8 versions of OpenSSL, the version used in RHEL 5, so that shouldn't be an issue there. OpenSSH version 6.6 was indeed, compatible with that older OpenSSL on RHEL 5, I even just tested its basic functionalit, so I assume it's not a major API incompatibility introduced with OpenSSH 6.7p1. So I'm now quite curious. From djm at mindrot.org Fri Nov 21 14:19:41 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Nov 2014 14:19:41 +1100 (EST) Subject: Fw: version question In-Reply-To: References: Message-ID: On Thu, 20 Nov 2014, Nico Kadel-Garcia wrote: > On Thu, Nov 20, 2014 at 9:31 PM, Damien Miller > wrote: > On Wed, 19 Nov 2014, Nico Kadel-Garcia wrote: > >> Use > 6.6p1, or consider patching the check for openssl version in >> > openbsd-compat/openssl-compat.h to ignore the failure, on the basis >> > that RHEL has been backporting patches to openssl for RHEL 5.. > > Do > you understand why that check exists in the first place? > > That's why I asked. Maybe you should ask _before_ recommending people disable checks in their security software. > A bit more digging shows that the HeartBleed bug apparently never > applied to 0.9.8 versions of OpenSSL, the version used in RHEL 5, so > that shouldn't be an issue there. OpenSSH version 6.6 was indeed, > compatible with that older OpenSSL on RHEL 5, I even just tested its > basic functionalit, so I assume it's not a major API incompatibility > introduced with OpenSSH 6.7p1. It has nothing to do with heartbleed - that is an SSL bug that doesn't affect OpenSSH at all. OpenSSL made a small API change in their 0.9.8 stable series that we previously carried a compat hack for. The impact of not having this hack is that EVP_CIPHER_CTX_key_length() returns an incorrect length. This could cause connection problems or possibly insecurity in sshd. -d From dflatley at us.ibm.com Fri Nov 21 23:58:20 2014 From: dflatley at us.ibm.com (David Flatley) Date: Fri, 21 Nov 2014 07:58:20 -0500 Subject: Fw: version question In-Reply-To: References: Message-ID: Thanks for the responses. I ended up editing our Openssh install script so it will check Red Hat versions and install 6.6p1 on Red Hat 5 and 6.7p1 on 6 and 7 systems. David Flatley From: Damien Miller To: Nico Kadel-Garcia , Cc: David Flatley/Burlington/IBM at IBMUS, "openssh-unix-dev at mindrot.org" Date: 11/20/2014 10:19 PM Subject: Re: Fw: version question On Thu, 20 Nov 2014, Nico Kadel-Garcia wrote: > On Thu, Nov 20, 2014 at 9:31 PM, Damien Miller > wrote: > On Wed, 19 Nov 2014, Nico Kadel-Garcia wrote: > >> Use > 6.6p1, or consider patching the check for openssl version in >> > openbsd-compat/openssl-compat.h to ignore the failure, on the basis >> > that RHEL has been backporting patches to openssl for RHEL 5.. > > Do > you understand why that check exists in the first place? > > That's why I asked. Maybe you should ask _before_ recommending people disable checks in their security software. > A bit more digging shows that the HeartBleed bug apparently never > applied to 0.9.8 versions of OpenSSL, the version used in RHEL 5, so > that shouldn't be an issue there. OpenSSH version 6.6 was indeed, > compatible with that older OpenSSL on RHEL 5, I even just tested its > basic functionalit, so I assume it's not a major API incompatibility > introduced with OpenSSH 6.7p1. It has nothing to do with heartbleed - that is an SSL bug that doesn't affect OpenSSH at all. OpenSSL made a small API change in their 0.9.8 stable series that we previously carried a compat hack for. The impact of not having this hack is that EVP_CIPHER_CTX_key_length() returns an incorrect length. This could cause connection problems or possibly insecurity in sshd. -d From nkadel at gmail.com Sat Nov 22 00:03:18 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 21 Nov 2014 08:03:18 -0500 Subject: Fw: version question In-Reply-To: References: Message-ID: On Thu, Nov 20, 2014 at 10:19 PM, Damien Miller wrote: > On Thu, 20 Nov 2014, Nico Kadel-Garcia wrote: >> A bit more digging shows that the HeartBleed bug apparently never >> applied to 0.9.8 versions of OpenSSL, the version used in RHEL 5, so >> that shouldn't be an issue there. OpenSSH version 6.6 was indeed, >> compatible with that older OpenSSL on RHEL 5, I even just tested its >> basic functionalit, so I assume it's not a major API incompatibility >> introduced with OpenSSH 6.7p1. > > It has nothing to do with heartbleed - that is an SSL bug that doesn't > affect OpenSSH at all. > > OpenSSL made a small API change in their 0.9.8 stable series that we > previously carried a compat hack for. The impact of not having this hack > is that EVP_CIPHER_CTX_key_length() returns an incorrect length. This > could cause connection problems or possibly insecurity in sshd. Interesting, and thank you. I'm not sure how I got it built and tested in RHEL 5 without seeing that, I don't have a record of touching configure.ac, but I might have done so in the testing setup. That wasn't evident from the git log for the check in openbsd-compat.h was patched, but that's the *second* check: the one in configure.ac is much better labeled, as well one might expect from a well written check.. I do see openssl 1.0.1 available for RHEL 5 over at ftp://ftp.pramberger.at/systems/linux/contrib/rhel5. Might be worth checking out, if anyone *really* needs OpenSSH 6.7p1 for RHEL 5. As nice as it is of that packer to make, I'd personally want to review the SRPM and build locally, rather than simply deploying from an unfamiliar 3rd party repositor for software as security sensitive as OpenSSL. Personally, if I were David, the original posterr, I'd consider this another reason to upgrade to CentOS 6 or CentOS 7. CentOS 5 is now 7 years old, and this kind of backporting gets more and more painful over time. From openssh at roumenpetrov.info Sat Nov 22 20:38:21 2014 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 22 Nov 2014 11:38:21 +0200 Subject: Fw: version question In-Reply-To: References: Message-ID: <5470598D.4060700@roumenpetrov.info> Hi David, David Flatley wrote: > Thanks for the responses. I ended up editing our Openssh install script > so it will check Red Hat versions and install 6.6p1 on Red Hat 5 and 6.7p1 > on 6 and 7 systems. > Please check source RPM . If I remember well Redhat distribute 0.9.8e with corrected version of EVP_CIPHER_CTX_key_length. So if redhat is with corrected code the you could relax openssh versoin check. Regards, Roumen Petrov -- Get SSH with X.509 certificate support http://roumenpetrov.info/openssh/ From philcerf at gmail.com Sun Nov 23 05:19:29 2014 From: philcerf at gmail.com (Philippe Cerfon) Date: Sat, 22 Nov 2014 19:19:29 +0100 Subject: can compression be safely used with SSH? In-Reply-To: References: Message-ID: Hello. >Even if delayed compression is only activated after authentication, >the the fact that delayed compression will be used has already been >negotiated before authentication and can't be changed retroactively. Couldn't the server simply abort a connection in the case that it sees that the negotiated compression algorithm doesn't fit, once the user is determined? Bailing out with some error message, before the client could have done anything. This is perhaps not the cleanest way, but in practise it should do quite well, and the same could possibly be done to allow many others of directives to be used inside Match, for which this is currently impossible. One could for example restrict certain authentication methods (or their options) to certain users/groups. Regards, Philippe From djm at mindrot.org Mon Nov 24 09:47:23 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 24 Nov 2014 09:47:23 +1100 (EST) Subject: can compression be safely used with SSH? In-Reply-To: References: Message-ID: On Sat, 22 Nov 2014, Philippe Cerfon wrote: > Hello. > > >Even if delayed compression is only activated after authentication, > >the the fact that delayed compression will be used has already been > >negotiated before authentication and can't be changed retroactively. > > Couldn't the server simply abort a connection in the case that it sees > that the negotiated compression algorithm doesn't fit, once the user > is determined? > Bailing out with some error message, before the client could have done anything. > > This is perhaps not the cleanest way, but in practise it should do > quite well, and the same could possibly be done to allow many others > of directives to be used inside Match, for which this is currently > impossible. Killing the connection if the client suggests the wrong option is quite hostile to the user. I don't think we'd want that. It's theoretically possible to force a rekeying after authentication with new options, but this is slow: several client/server round-trips plus the potentially very slow key exchange crypto. IMO it's too slow and confusing to be worth implementing. > One could for example restrict certain authentication methods (or > their options) to certain users/groups. OpenSSH has supported this for years; see the documentation for 'Match' in sshd_config(5). -d From djm at mindrot.org Wed Nov 26 13:39:28 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 26 Nov 2014 13:39:28 +1100 (EST) Subject: [PATCH] Patch by Florian Friesdorf : contrib/cygwin/ssh-host-config: Add -N option to allow different service name. In-Reply-To: <20141117084914.GB28219@calimero.vinschen.de> References: <20141106170032.GA22021@calimero.vinschen.de> <20141117084914.GB28219@calimero.vinschen.de> Message-ID: applied - thanks On Mon, 17 Nov 2014, Corinna Vinschen wrote: > Ping? > > > Thanks, > Corinna > > On Nov 6 18:00, Corinna Vinschen wrote: > > Hi, > > > > today I got a neat patch to ssh-host-config. With the new -N option it > > allows to install multiple sshd services under different service names. > > I like the idea, so I thought I send the patch upstream. See below. > > > > > > Thanks, > > Corinna > > > > > > --- > > contrib/cygwin/ssh-host-config | 19 +++++++++++++------ > > 1 file changed, 13 insertions(+), 6 deletions(-) > > mode change 100644 => 100755 contrib/cygwin/ssh-host-config > > > > diff --git a/contrib/cygwin/ssh-host-config b/contrib/cygwin/ssh-host-config > > old mode 100644 > > new mode 100755 > > index 3214829..d934d09 > > --- a/contrib/cygwin/ssh-host-config > > +++ b/contrib/cygwin/ssh-host-config > > @@ -61,6 +61,7 @@ LOCALSTATEDIR=/var > > > > sshd_config_configured=no > > port_number=22 > > +service_name=sshd > > strictmodes=yes > > privsep_used=yes > > cygwin_value="" > > @@ -408,7 +409,7 @@ install_service() { > > local ret=0 > > > > echo > > - if /usr/bin/cygrunsrv -Q sshd >/dev/null 2>&1 > > + if /usr/bin/cygrunsrv -Q ${service_name} >/dev/null 2>&1 > > then > > csih_inform "Sshd service is already installed." > > check_service_files_ownership "" || let ret+=$? > > @@ -464,7 +465,7 @@ install_service() { > > fi > > if [ -z "${password}" ] > > then > > - if /usr/bin/cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ > > + if /usr/bin/cygrunsrv -I ${service_name} -d "CYGWIN ${service_name}" -p /usr/sbin/sshd \ > > -a "-D" -y tcpip "${cygwin_env[@]}" > > then > > echo > > @@ -474,20 +475,20 @@ install_service() { > > csih_inform "will start automatically after the next reboot." > > fi > > else > > - if /usr/bin/cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd \ > > + if /usr/bin/cygrunsrv -I ${service_name} -d "CYGWIN ${service_name}" -p /usr/sbin/sshd \ > > -a "-D" -y tcpip "${cygwin_env[@]}" \ > > -u "${run_service_as}" -w "${password}" > > then > > /usr/bin/editrights -u "${run_service_as}" -a SeServiceLogonRight > > echo > > csih_inform "The sshd service has been installed under the '${run_service_as}'" > > - csih_inform "account. To start the service now, call \`net start sshd' or" > > - csih_inform "\`cygrunsrv -S sshd'. Otherwise, it will start automatically" > > + csih_inform "account. To start the service now, call \`net start ${service_name}' or" > > + csih_inform "\`cygrunsrv -S ${service_name}'. Otherwise, it will start automatically" > > csih_inform "after the next reboot." > > fi > > fi > > > > - if /usr/bin/cygrunsrv -Q sshd >/dev/null 2>&1 > > + if /usr/bin/cygrunsrv -Q ${service_name} >/dev/null 2>&1 > > then > > check_service_files_ownership "${run_service_as}" || let ret+=$? > > else > > @@ -561,6 +562,11 @@ do > > shift > > ;; > > > > + -N | --name ) > > + service_name=$1 > > + shift > > + ;; > > + > > -p | --port ) > > port_number=$1 > > shift > > @@ -590,6 +596,7 @@ do > > echo " --yes -y Answer all questions with \"yes\" automatically." > > echo " --no -n Answer all questions with \"no\" automatically." > > echo " --cygwin -c Use \"options\" as value for CYGWIN environment var." > > + echo " --name -N sshd windows service name." > > echo " --port -p sshd listens on port n." > > echo " --user -u privileged user for service, default 'cyg_server'." > > echo " --pwd -w Use \"pwd\" as password for privileged user." > > -- > Corinna Vinschen > Cygwin Maintainer > Red Hat > From djm at mindrot.org Wed Nov 26 13:39:39 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 26 Nov 2014 13:39:39 +1100 (EST) Subject: [PATCH] Don't read group names from /etc/group In-Reply-To: <20141117084842.GA28219@calimero.vinschen.de> References: <20141105132523.GV28636@calimero.vinschen.de> <20141117084842.GA28219@calimero.vinschen.de> Message-ID: applied too - thanks On Mon, 17 Nov 2014, Corinna Vinschen wrote: > Ping? > > > Thanks, > Corinna > > On Nov 5 14:25, Corinna Vinschen wrote: > > On Nov 5 11:03, Damien Miller wrote: > > > done - thanks again > > > > Thank you. Unfortunately there was still one problem left in > > ssh-host-config, which at one point reads from /etc/group when printing > > the user's group membership. Patch below. > > > > > > Thanks, > > Corinna > > > > > > Signed-off-by: Corinna Vinschen > > --- > > contrib/cygwin/ssh-host-config | 5 +---- > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > diff --git a/contrib/cygwin/ssh-host-config b/contrib/cygwin/ssh-host-config > > index 301d5eb..3214829 100644 > > --- a/contrib/cygwin/ssh-host-config > > +++ b/contrib/cygwin/ssh-host-config > > @@ -623,10 +623,7 @@ then > > csih_warning "However, it seems your account does not have these privileges." > > csih_warning "Here's the list of groups in your user token:" > > echo > > - for i in $(/usr/bin/id -G) > > - do > > - /usr/bin/awk -F: "/[^:]*:[^:]*:$i:/{ print \" \" \$1; }" /etc/group > > - done > > + /usr/bin/id -Gnz | xargs -0n1 echo " " > > echo > > csih_warning "This usually means you're running this script from a non-admin" > > csih_warning "desktop session, or in a non-elevated shell under UAC control." > > -- > Corinna Vinschen > Cygwin Maintainer > Red Hat > From vinschen at redhat.com Wed Nov 26 20:44:20 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 26 Nov 2014 10:44:20 +0100 Subject: [PATCH] Patch by Florian Friesdorf : contrib/cygwin/ssh-host-config: Add -N option to allow different service name. In-Reply-To: References: <20141106170032.GA22021@calimero.vinschen.de> <20141117084914.GB28219@calimero.vinschen.de> Message-ID: <20141126094420.GA25264@calimero.vinschen.de> On Nov 26 13:39, Damien Miller wrote: > applied - thanks > > On Mon, 17 Nov 2014, Corinna Vinschen wrote: > > > Ping? > > > > > > Thanks, > > Corinna > > > > On Nov 6 18:00, Corinna Vinschen wrote: > > > Hi, > > > > > > today I got a neat patch to ssh-host-config. With the new -N option it > > > allows to install multiple sshd services under different service names. > > > I like the idea, so I thought I send the patch upstream. See below. > > > [...] Thanks a lot! 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 chandra.kumara at shipxpress.com Fri Nov 28 22:23:40 2014 From: chandra.kumara at shipxpress.com (Chandra Kumara) Date: Fri, 28 Nov 2014 16:53:40 +0530 Subject: openssh upgrading. In-Reply-To: References: <54664b86.ab12450a.7f65.fffff089@mx.google.com> <5468c79d.a58c460a.4a99.fffff5e2@mx.google.com> Message-ID: <54785b41.4304460a.6f7c.ffffbe98@mx.google.com> Hi Nico, Thank you very much for your instructions. I set the following values in openssh.spec before the rpm build. %define no_gnome_askpass 1 %define no_x11_askpass 1 %define build6x 1 %{?build_6x:%define build6x 0} Then rebuild the following rpms. Installed all of them and no any connectivity issued encountered this time. openssh-6.6p1-1.x86_64.rpm openssh-clients-6.6p1-1.x86_64.rpm openssh-debuginfo-6.6p1-1.x86_64.rpm openssh-server-6.6p1-1.x86_64.rpm Regards, Chandra Kumara, SSA ShipXpress. 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 phone: +94 11 2826814/15 || website: http://www.shipxpress.com -----Original Message----- From: Nico Kadel-Garcia [mailto:nkadel at gmail.com] Sent: Sunday, November 16, 2014 10:20 PM To: Chandra Kumara Cc: openssh at openssh.com; openssh-unix-announce at mindrot.org; openssh-unix-dev at mindrot.org Subject: Re: openssh upgrading. On Sun, Nov 16, 2014 at 10:47 AM, Chandra Kumara wrote: > Hi Nico, > > I couldn't connect to the server remotely not only to root but also any secondary user. > > My issue was with "openssh-debuginfo" rpm. I used "yum remove openssh" and reinstall rpm build 6.2p2 version again (openssh, openssh-clients and openssh-server) except "openssh-debuginfo" You mean that installing openssh-debuginfo broke it? And uninstalling openssh-debuginfo fixed it? > Then upgraded to 6.6p1 also and working fine. Why are you continuing to use out of date releases? 6.7p1 is out and in production use. > This time i didn't use > http://pkgs.fedoraproject.org/repo/pkgs/openssh/x11-ssh-askpass-1.2.4. > 1.tar.gz to do rpm build, instead used, > > sed -i -e "s/%define no_gnome_askpass 0/%define no_gnome_askpass 1/g" > openssh.spec sed -i -e "s/%define no_x11_askpass 0/%define > no_x11_askpass 1/g" openssh.spec sed -i -e > "s/BuildPreReq/BuildRequires/g" openssh.spec You could have just reset the 'define' statements to have value '1' %define no_gnome_askpass 1 %define no_x11_askpass 1 That way, your SRPM would still have the relevant tarball if you want it. Becasue, you see, that 'BuildPreReq' also cleared outer prereqs.such as 'glibc-devel' and 'pam'. So you actually wound up changing several things more than you needed. And in fact, there is a 'build6x' option you may want to set for your operating system. > > Regards, > Chandra Kumara, SSA > ShipXpress. > 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 > phone: +94 11 2826814/15 || website: http://www.shipxpress.com > > -----Original Message----- > From: Nico Kadel-Garcia [mailto:nkadel at gmail.com] > Sent: Saturday, November 15, 2014 6:45 AM > To: Chandra Kumara > Cc: openssh at openssh.com; openssh-unix-announce at mindrot.org; > openssh-unix-dev at mindrot.org > Subject: Re: openssh upgrading. > > On Fri, Nov 14, 2014 at 1:32 PM, Chandra Kumara wrote: >> Hi Openssh support, >> >> >> >> I have upgraded openssh from 5.3p1 to 6.2p2 in a RHEL 6.6 - 64 bit >> server and now i can't login to server remotely using same root >> password. It always prompting the password saying "Permission denied, please try again." > > I just tried the 6.7p1 tarball with this procedure. Seems to work fine. The .spec file is missing the BuildRequires dependency of "/usr/bin/xmkmf" in the dependencies for the openssh-x11-aspass module, but othewise seems to work fine. > > >> Please help me to resolve the issue. >> >> >> >> Following are the steps i have followd. >> >> >> >> ---------------------------------------------------------------- >> >> [root at test ~]# ssh -V >> >> OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 >> >> >> >> [root at test ~]# cat /etc/redhat-release >> >> Red Hat Enterprise Linux Server release 6.6 (Santiago) >> >> >> >> [root at test ~]# rpm -qa |grep openssh >> >> openssh-server-5.3p1-104.el6.x86_64 >> >> openssh-clients-5.3p1-104.el6.x86_64 >> >> openssh-5.3p1-104.el6.x86_64 >> >> >> >> yum install rpm-build >> >> yum install gcc glibc-devel pam-devel libX11-devel krb5-devel >> zlib-devel >> >> yum install openssh-devel openssl-devel tcp_wrappers-devel >> libXt-devel imake gtk2-devel >> >> >> >> wget >> http://ftp.spline.de/pub/OpenBSD/OpenSSH/portable/openssh-6.2p2.tar.g >> z >> >> wget >> http://pkgs.fedoraproject.org/repo/pkgs/openssh/x11-ssh-askpass-1.2.4.1.tar. >> gz/8f2e41f3f7eaa8543a2440454637f3c3/x11-ssh-askpass-1.2.4.1.tar.gz >> >> >> >> tar zxvf openssh-6.2p2.tar.gz >> >> cp openssh-6.2p2/contrib/redhat/openssh.spec . >> >> rpmbuild -bb openssh.spec >> >> >> >> cp x11-ssh-askpass-1.2.4.1.tar.gz /root/rpmbuild/SOURCES/ >> >> cp openssh-6.2p2.tar.gz /root/rpmbuild/SOURCES/ >> >> cp openssh.spec /root/rpmbuild/SOURCES/ >> >> >> >> rpmbuild -bb openssh.spec >> >> >> >> cd /root/rpmbuild/RPMS/x86_64/ >> >> rpm -Uvh * >> >> /etc/init.d/sshd restart >> >> >> >> [root at test ~]# rpm -qa |grep openss >> >> openssl-devel-1.0.1e-30.el6_6.4.x86_64 >> >> openssh-server-6.2p2-1.x86_64 >> >> openssl-1.0.1e-30.el6_6.4.x86_64 >> >> openssh-askpass-gnome-6.2p2-1.x86_64 >> >> openssh-debuginfo-6.2p2-1.x86_64 >> >> openssh-6.2p2-1.x86_64 >> >> openssh-clients-6.2p2-1.x86_64 >> >> >> >> >> >> [root at plutotest .ssh]# ssh -v root at 192.168.0.38 >> >> OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 >> >> debug1: Reading configuration data /etc/ssh/ssh_config >> >> debug1: Applying options for * >> >> debug1: Connecting to 192.168.0.38 [192.168.0.38] port 22. >> >> debug1: Connection established. >> >> debug1: permanently_set_uid: 0/0 >> >> debug1: identity file /root/.ssh/identity type -1 >> >> debug1: identity file /root/.ssh/identity-cert type -1 >> >> debug1: identity file /root/.ssh/id_rsa type -1 >> >> debug1: identity file /root/.ssh/id_rsa-cert type -1 >> >> debug1: identity file /root/.ssh/id_dsa type -1 >> >> debug1: identity file /root/.ssh/id_dsa-cert type -1 >> >> debug1: Remote protocol version 2.0, remote software version >> OpenSSH_6.2 >> >> debug1: match: OpenSSH_6.2 pat OpenSSH* >> >> debug1: Enabling compatibility mode for protocol 2.0 >> >> debug1: Local version string SSH-2.0-OpenSSH_5.3 >> >> debug1: SSH2_MSG_KEXINIT sent >> >> debug1: SSH2_MSG_KEXINIT received >> >> debug1: kex: server->client aes128-ctr hmac-md5 none >> >> debug1: kex: client->server aes128-ctr hmac-md5 none >> >> 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 >> >> debug1: Host '192.168.0.38' is known and matches the RSA host key. >> >> debug1: Found key in /root/.ssh/known_hosts:9 >> >> debug1: ssh_rsa_verify: signature correct >> >> debug1: SSH2_MSG_NEWKEYS sent >> >> debug1: expecting SSH2_MSG_NEWKEYS >> >> debug1: SSH2_MSG_NEWKEYS received >> >> debug1: SSH2_MSG_SERVICE_REQUEST sent >> >> debug1: SSH2_MSG_SERVICE_ACCEPT received >> >> debug1: Authentications that can continue: >> publickey,gssapi-with-mic,password >> >> debug1: Next authentication method: gssapi-with-mic >> >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> >> Cannot determine realm for numeric host address >> >> >> >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> >> Cannot determine realm for numeric host address >> >> >> >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> >> >> >> >> >> debug1: Unspecified GSS failure. Minor code may provide more >> information >> >> Cannot determine realm for numeric host address >> >> >> >> debug1: Next authentication method: publickey >> >> debug1: Trying private key: /root/.ssh/identity >> >> debug1: Trying private key: /root/.ssh/id_rsa >> >> debug1: Trying private key: /root/.ssh/id_dsa >> >> debug1: Next authentication method: password >> >> root at 192.168.0.38's password: >> >> debug1: Authentications that can continue: >> publickey,gssapi-with-mic,password >> >> Permission denied, please try again. >> >> root at 192.168.0.38's password: >> >> ---------------------------------------------------------------- >> >> Regards, >> >> Chandra Kumara, SSA >> >> ShipXpress. >> >> 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 >> >> phone: +94 11 2826814/15 || website: >> http://www.shipxpress.com >> >> >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From nkadel at gmail.com Sat Nov 29 03:00:04 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 28 Nov 2014 11:00:04 -0500 Subject: openssh upgrading. In-Reply-To: <54785b41.4304460a.6f7c.ffffbe98@mx.google.com> References: <54664b86.ab12450a.7f65.fffff089@mx.google.com> <5468c79d.a58c460a.4a99.fffff5e2@mx.google.com> <54785b41.4304460a.6f7c.ffffbe98@mx.google.com> Message-ID: On Fri, Nov 28, 2014 at 6:23 AM, Chandra Kumara wrote: > Hi Nico, > > Thank you very much for your instructions. > > I set the following values in openssh.spec before the rpm build. > > %define no_gnome_askpass 1 > %define no_x11_askpass 1 > %define build6x 1 > %{?build_6x:%define build6x 0} > > Then rebuild the following rpms. Installed all of them and no any connectivity issued encountered this time. > > openssh-6.6p1-1.x86_64.rpm > openssh-clients-6.6p1-1.x86_64.rpm > openssh-debuginfo-6.6p1-1.x86_64.rpm > openssh-server-6.6p1-1.x86_64.rpm > > > Regards, > Chandra Kumara, SSA > ShipXpress. > 2315 Beach Blvd - Suite 104 || Jacksonville Beach, FL 32250 > phone: +94 11 2826814/15 || website: http://www.shipxpress.com Good! I'm glad that is working out so much better fo ryou. From calestyo at scientia.net Sat Nov 29 13:09:02 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 29 Nov 2014 03:09:02 +0100 Subject: strange ssh_config inheritance Message-ID: <1417226942.17700.1.camel@scientia.net> Hi. I was playing around a bit and noticed the following behaviour which doesn't seem to match the documentation (which basically says the first time an option is set, that value is used). Having the following ~/.ssh/config: Host foo bar HostName %h.example.org Host foo.example.org User root ControlMaster auto ControlPersist 1h Host bar.example.org User root ControlMaster auto ControlPersist 1h Host * ControlPath ~/.ssh/control-mux/%l_%r@%h:%p ControlPersist 1s ...the following happens when one logs in to foo or bar (without the domain). 1) Apparently, using HostName works in a way so that ssh_config is parsed again with the new name, because a socket is actually created. This behaviour seems to be undocumented, i.e. from the documentation I'd have expected that logging in to "foo" wouldn't cause the config from "foo.example.org" be used. I'd write a patch, but since all my previous pull requests improving the docs have been ignored even after asking back several times I don't bother. 2) Since ControlMaster=auto applies to just "foo" or "bar", one would expect that ControlPersist=1h does so as well. But it doesn't (the 1s is taken). As soon as I exit, the mux process quits (after 1s) and the socket gets removed. That's not how I'd interpret how inheritance works from the manpage... is it a bug? ControlPath in turn is taken up again correctly. Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From philcerf at gmail.com Sun Nov 30 16:28:21 2014 From: philcerf at gmail.com (Philippe Cerfon) Date: Sun, 30 Nov 2014 06:28:21 +0100 Subject: can compression be safely used with SSH? In-Reply-To: References: Message-ID: > Killing the connection if the client suggests the wrong option is > quite hostile to the user. I don't think we'd want that. > > It's theoretically possible to force a rekeying after authentication > with new options, but this is slow: several client/server round-trips > plus the potentially very slow key exchange crypto. IMO it's too slow > and confusing to be worth implementing. Would it be difficult to implement? I guess it's the only clean way then to restrict compression to certain users (if killing the connection isn't an option). And the slowness would probably not really matter, since it's only necessary to work like that, when being used in a Match section, which most people will never do. Shall I open a wishlist ticket about that? Thanks, Philippe