From scott_n at xypro.com Wed Oct 1 03:47:22 2014 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 30 Sep 2014 17:47:22 +0000 Subject: Privsep question Message-ID: Why is the Privsep user specified at config time rather than in sshd_config? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | From mancha1 at zoho.com Wed Oct 1 08:53:48 2014 From: mancha1 at zoho.com (mancha) Date: Tue, 30 Sep 2014 22:53:48 +0000 Subject: Port Forward Limit? In-Reply-To: References: Message-ID: <20140930225348.GA12628@zoho.com> On Tue, Sep 30, 2014 at 03:21:17PM +1000, Damien Miller wrote: > On Tue, 30 Sep 2014, Damien Miller wrote: > > > I'm not sure how to disable this check (which is broken) without > > turning off the rest of FORTIFY_SOURCE (which gives some good > > hardening). Suggestions welcome. > > This is the best that I've come up with for now: Impressive detective work. Maybe one day the throwbacks will decide to support poll(). POSIX 2008 conformance requires it, after all. Small bug...your FORTIFY_SOURCE #undef is missing a leading underscore. Should be: #undef _FORTIFY_SOURCE --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From djm at mindrot.org Wed Oct 1 09:42:58 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 1 Oct 2014 09:42:58 +1000 (EST) Subject: Privsep question In-Reply-To: References: Message-ID: On Tue, 30 Sep 2014, Scott Neugroschl wrote: > Why is the Privsep user specified at config time rather than in sshd_config? Most OpenBSD-derived daemons do it this way and most OS distributions just statically assign one too. -d From djm at mindrot.org Wed Oct 1 09:43:40 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 1 Oct 2014 09:43:40 +1000 (EST) Subject: Port Forward Limit? In-Reply-To: <20140930225348.GA12628@zoho.com> References: <20140930225348.GA12628@zoho.com> Message-ID: On Tue, 30 Sep 2014, mancha wrote: > On Tue, Sep 30, 2014 at 03:21:17PM +1000, Damien Miller wrote: > > On Tue, 30 Sep 2014, Damien Miller wrote: > > > > > I'm not sure how to disable this check (which is broken) without > > > turning off the rest of FORTIFY_SOURCE (which gives some good > > > hardening). Suggestions welcome. > > > > This is the best that I've come up with for now: > > Impressive detective work. Maybe one day the throwbacks will decide to > support poll(). POSIX 2008 conformance requires it, after all. Our not using poll() is also due to our inertia :/ > Small bug...your FORTIFY_SOURCE #undef is missing a leading underscore. > Should be: > > #undef _FORTIFY_SOURCE thanks, fixed From plautrba at redhat.com Wed Oct 1 23:33:42 2014 From: plautrba at redhat.com (Petr Lautrbach) Date: Wed, 01 Oct 2014 15:33:42 +0200 Subject: [patch] postauth processes to log via monitor Message-ID: <542C02B6.2050802@redhat.com> Hi, there is a long standing problem with logging in chroots. Especially, when you use %u in ChrootDirectory, it is nearly impossible to have /dev/log in every possible chroot for all users. It seems to be important mainly for sftp-internal session which are simply configurable to be chrooted and where admins would like to log sftp session commands. I have put together a patch which introduces a new configuration option LogViaMonitor. When this option is 'yes', then postauth unprivileged processes log via their monitor process instead of via standard channels (syslog, stderr). I've removed closefrom() from close_child_fds() in order not to close m_log_send_fd socket before sftp_server_main() is called. And I've put it to a part of code where it's clear that there will be exec(). I'd appreciate any comment or suggestion. Petr -- Petr Lautrbach -------------- next part -------------- A non-text attachment was scrubbed... Name: log-via-monitor.patch Type: text/x-patch Size: 10936 bytes Desc: not available URL: From jan.pechanec at oracle.com Thu Oct 2 03:43:01 2014 From: jan.pechanec at oracle.com (Jan Pechanec) Date: Wed, 1 Oct 2014 10:43:01 -0700 (PDT) Subject: VPN via tun interfaces on Mac OS Message-ID: hi, when I tried to setup VPN over OpenSSH on my Mac laptop I found out that it does not natively support tun interfaces. There is an existing project adding such support in a kernel module but it was not updated since 2011 so I haven't even tried that. I understand that Mac OS supports utun (user tunnel) interface which is automatically created (without creating the device under /dev) on behalf of the user when one connects to a special PF_SYSTEM socket. I verified that and have a piece of code that does it. However, it needs more privileges than an unprivileged user so more investigation is needed before I can try to modify the client code. the reason I'm writing this is that I'm wondering whether anyone already tried that so that I don't attempt implementing the same thing. I cannot find anyone mentioning it in this list though. thanks, Jan. -- Jan Pechanec From imorgan at nas.nasa.gov Fri Oct 3 07:01:13 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 2 Oct 2014 14:01:13 -0700 Subject: Typo in sshd_config(5) Message-ID: <20141002210113.GC6678@linux124.nas.nasa.gov> Hi, There's a typo in the section describing ChallengeResponseAuthentication: ChallengeResponseAuthentication Specifies whether challenge-response authentication is allowed (e.g. via PAM or though authentication styles supported in login.conf(5)) The default is ?yes?. It shoud be "through" not "though." -- Iain Morgan From djm at mindrot.org Fri Oct 3 09:21:21 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 3 Oct 2014 09:21:21 +1000 (EST) Subject: VPN via tun interfaces on Mac OS In-Reply-To: References: Message-ID: On Wed, 1 Oct 2014, Jan Pechanec wrote: > the reason I'm writing this is that I'm wondering whether anyone > already tried that so that I don't attempt implementing the same thing. > I cannot find anyone mentioning it in this list though. I'm not aware of anyone making tun networking work on OS X before, so AFAIK you would be the first. I'd be happy to merge patches for this too. -d From djm at mindrot.org Fri Oct 3 09:26:26 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 3 Oct 2014 09:26:26 +1000 (EST) Subject: Typo in sshd_config(5) In-Reply-To: <20141002210113.GC6678@linux124.nas.nasa.gov> References: <20141002210113.GC6678@linux124.nas.nasa.gov> Message-ID: On Thu, 2 Oct 2014, Iain Morgan wrote: > It shoud be "through" not "though." Applied - thanks. Also, irony :) From jan.pechanec at oracle.com Fri Oct 3 10:00:38 2014 From: jan.pechanec at oracle.com (Jan Pechanec) Date: Thu, 2 Oct 2014 17:00:38 -0700 (PDT) Subject: VPN via tun interfaces on Mac OS In-Reply-To: References: Message-ID: On Fri, 3 Oct 2014, Damien Miller wrote: >> the reason I'm writing this is that I'm wondering whether anyone >> already tried that so that I don't attempt implementing the same thing. >> I cannot find anyone mentioning it in this list though. > >I'm not aware of anyone making tun networking work on OS X before, so >AFAIK you would be the first. I'd be happy to merge patches for this too. hi Damien, thanks. I hope I will get to it within a few weeks. No promises :-) J. -- Jan Pechanec From mancha1 at zoho.com Sat Oct 4 03:35:30 2014 From: mancha1 at zoho.com (mancha) Date: Fri, 3 Oct 2014 17:35:30 +0000 Subject: Typo in sshd_config(5) In-Reply-To: References: <20141002210113.GC6678@linux124.nas.nasa.gov> Message-ID: <20141003173529.GB6960@zoho.com> On Fri, Oct 03, 2014 at 09:26:26AM +1000, Damien Miller wrote: > On Thu, 2 Oct 2014, Iain Morgan wrote: > > > It shoud be "through" not "though." > > Applied - thanks. Also, irony :) Since you're in a manpage-fixing mood, did you get a chance to see this thread? http://marc.info/?t=141080533100003&r=1&w=3 --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From patrick.preuss at gmail.com Sat Oct 4 17:14:04 2014 From: patrick.preuss at gmail.com (Patrick Marc Preuss) Date: Sat, 04 Oct 2014 09:14:04 +0200 Subject: Key Selection with agent Message-ID: <542F9E3C.2000905@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All is it possible to select the presented key based on the hash? The Situation is following: Workstatation is running the Agent with some keys Need to use a jump host to connect to other hosts. best regards Patrick - -- Patrick Marc Preuss -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUL548AAoJEOtOgOL+nQWDTOoH/RAI4npcaqcY0RusB60kVQCS 8K5+octOqRK3WRnd0YbQ0pFaVeCZFGmfJ9TZJkqNsmHnzThrk33ibGYu6HomovzA yUnwyYzqgurCEl7wPpyXV/xDaDbY8U0b2AJwMtbB1pKUmZmUJ635F1KBsmbA3heK mdS9RAVDJjf00vAHCTmt3SUpfl7I+pAvlxiYuEMnIYhA80ChFfNrzo3oX0KyXg9W 5thpPMuDYPDvagp+BW4dpjPEKxmN2OLStS2Pkl0Vh0+A11OWRXRKTsLGOJs3ypKB vsI7KLZPzxGkIlnsNdNbAMk5Fy0WCjpXPWlFDY+W1urVKxleZ8hXgdCbifg91wo= =Dy8+ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: patrick_preuss.vcf Type: text/x-vcard Size: 197 bytes Desc: not available URL: From djm at mindrot.org Mon Oct 6 11:47:27 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 6 Oct 2014 11:47:27 +1100 (EST) Subject: Typo in sshd_config(5) In-Reply-To: <20141003173529.GB6960@zoho.com> References: <20141002210113.GC6678@linux124.nas.nasa.gov> <20141003173529.GB6960@zoho.com> Message-ID: On Fri, 3 Oct 2014, mancha wrote: > On Fri, Oct 03, 2014 at 09:26:26AM +1000, Damien Miller wrote: > > On Thu, 2 Oct 2014, Iain Morgan wrote: > > > > > It shoud be "through" not "though." > > > > Applied - thanks. Also, irony :) > > Since you're in a manpage-fixing mood, did you get a chance to see this > thread? http://marc.info/?t=141080533100003&r=1&w=3 done - thanks From djm at mindrot.org Mon Oct 6 11:50:21 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 6 Oct 2014 11:50:21 +1100 (EST) Subject: Key Selection with agent In-Reply-To: <542F9E3C.2000905@gmail.com> References: <542F9E3C.2000905@gmail.com> Message-ID: On Sat, 4 Oct 2014, Patrick Marc Preuss wrote: > Hi All > > is it possible to select the presented key based on the hash? I don't know what hash you are talking about. > The Situation is following: > > Workstatation is running the Agent with some keys > Need to use a jump host to connect to other hosts. You can use something like the following in your ~/.ssh/config Host foo IdentitiesOnly yes IdentityFile ~/.ssh/id_foo.pub Host bar IdentitiesOnly yes IdentityFile ~/.ssh/id_bar.pub ssh will use the specified key from the agent, even if it offers others. Unfortunately there is no way to select/filter keys when an agent is forwarded yet. It would be a nice feature though. -d From djm at cvs.openbsd.org Tue Oct 7 10:16:40 2014 From: djm at cvs.openbsd.org (Damien Miller) Date: Mon, 6 Oct 2014 17:16:40 -0600 (MDT) Subject: Announce: OpenSSH 6.7 released Message-ID: <11168654333636927008.enqueue@cvs.openbsd.org> OpenSSH 6.7 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html Changes since OpenSSH 6.6 ========================= Potentially-incompatible changes * sshd(8): The default set of ciphers and MACs has been altered to remove unsafe algorithms. In particular, CBC ciphers and arcfour* are disabled by default. The full set of algorithms remains available if configured explicitly via the Ciphers and MACs sshd_config options. * sshd(8): Support for tcpwrappers/libwrap has been removed. * OpenSSH 6.5 and 6.6 have a bug that causes ~0.2% of connections using the curve25519-sha256 at libssh.org KEX exchange method to fail when connecting with something that implements the specification correctly. OpenSSH 6.7 disables this KEX method when speaking to one of the affected versions. New Features * Major internal refactoring to begin to make part of OpenSSH usable as a library. So far the wire parsing, key handling and KRL code has been refactored. Please note that we do not consider the API stable yet, nor do we offer the library in separable form. * ssh(1), sshd(8): Add support for Unix domain socket forwarding. A remote TCP port may be forwarded to a local Unix domain socket and vice versa or both ends may be a Unix domain socket. * ssh(1), ssh-keygen(1): Add support for SSHFP DNS records for ED25519 key types. * sftp(1): Allow resumption of interrupted uploads. * ssh(1): When rekeying, skip file/DNS lookups of the hostkey if it is the same as the one sent during initial key exchange; bz#2154 * sshd(8): Allow explicit ::1 and 127.0.0.1 forwarding bind addresses when GatewayPorts=no; allows client to choose address family; bz#2222 * sshd(8): Add a sshd_config PermitUserRC option to control whether ~/.ssh/rc is executed, mirroring the no-user-rc authorized_keys option; bz#2160 * ssh(1): Add a %C escape sequence for LocalCommand and ControlPath that expands to a unique identifer based on a hash of the tuple of (local host, remote user, hostname, port). Helps avoid exceeding miserly pathname limits for Unix domain sockets in multiplexing control paths; bz#2220 * sshd(8): Make the "Too many authentication failures" message include the user, source address, port and protocol in a format similar to the authentication success / failure messages; bz#2199 * Added unit and fuzz tests for refactored code. These are run automatically in portable OpenSSH via the "make tests" target. Bugfixes * sshd(8): Fix remote forwarding with the same listen port but different listen address. * ssh(1): Fix inverted test that caused PKCS#11 keys that were explicitly listed in ssh_config or on the commandline not to be preferred. * ssh-keygen(1): Fix bug in KRL generation: multiple consecutive revoked certificate serial number ranges could be serialised to an invalid format. Readers of a broken KRL caused by this bug will fail closed, so no should-have-been-revoked key will be accepted. * ssh(1): Reflect stdio-forward ("ssh -W host:port ...") failures in exit status. Previously we were always returning 0; bz#2255 * ssh(1), ssh-keygen(1): Make Ed25519 keys' title fit properly in the randomart border; bz#2247 * ssh-agent(1): Only cleanup agent socket in the main agent process and not in any subprocesses it may have started (e.g. forked askpass). Fixes agent sockets being zapped when askpass processes fatal(); bz#2236 * ssh-add(1): Make stdout line-buffered; saves partial output getting lost when ssh-add fatal()s part-way through (e.g. when listing keys from an agent that supports key types that ssh-add doesn't); bz#2234 * ssh-keygen(1): When hashing or removing hosts, don't choke on @revoked markers and don't remove @cert-authority markers; bz#2241 * ssh(1): Don't fatal when hostname canonicalisation fails and a ProxyCommand is in use; continue and allow the ProxyCommand to connect anyway (e.g. to a host with a name outside the DNS behind a bastion) * scp(1): When copying local->remote fails during read, don't send uninitialised heap to the remote end. * sftp(1): Fix fatal "el_insertstr failed" errors when tab-completing filenames with a single quote char somewhere in the string; bz#2238 * ssh-keyscan(1): Scan for Ed25519 keys by default. * ssh(1): When using VerifyHostKeyDNS with a DNSSEC resolver, down- convert any certificate keys to plain keys and attempt SSHFP resolution. Prevents a server from skipping SSHFP lookup and forcing a new-hostkey dialog by offering only certificate keys. * sshd(8): Avoid crash at exit via NULL pointer reference; bz#2225 * Fix some strict-alignment errors. Portable OpenSSH * Portable OpenSSH now supports building against libressl-portable. * Portable OpenSSH now requires openssl 0.9.8f or greater. Older versions are no longer supported. * In the OpenSSL version check, allow fix version upgrades (but not downgrades. Debian bug #748150. * sshd(8): On Cygwin, determine privilege separation user at runtime, since it may need to be a domain account. * sshd(8): Don't attempt to use vhangup on Linux. It doesn't work for non-root users, and for them it just messes up the tty settings. * Use CLOCK_BOOTTIME in preference to CLOCK_MONOTONIC when it is available. It considers time spent suspended, thereby ensuring timeouts (e.g. for expiring agent keys) fire correctly. bz#2228 * Add support for ed25519 to opensshd.init init script. * sftp-server(8): On platforms that support it, use prctl() to prevent sftp-server from accessing /proc/self/{mem,maps} Checksums: ========== - SHA1 (openssh-6.7.tar.gz) = 315497b27a0186e4aef67987cfc9f3d9ba561cd8 - SHA256 (openssh-6.7.tar.gz) = /me/hPxDw9Tfd3siNKQubSQph84qiKwftiMsgj6nh5E= - SHA1 (openssh-6.7p1.tar.gz) = 14e5fbed710ade334d65925e080d1aaeb9c85bf6 - SHA256 (openssh-6.7p1.tar.gz) = svg5Tq6Fjau9732sELma7ADJVGJ1PoA0LlMLu29yVQc= Please note that the PGP key used to sign releases was recently rotated. The new key has been signed by the old key to provide continuity. It is available from the mirror sites as RELEASE_KEY.asc. Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From mancha1 at zoho.com Tue Oct 7 14:31:19 2014 From: mancha1 at zoho.com (mancha) Date: Tue, 7 Oct 2014 03:31:19 +0000 Subject: OpenSSH 6.7p1 TCP Wrapper support Message-ID: <20141007033119.GA25530@zoho.com> Hello. Those who want TCP Wrapper support in OpenSSH 6.7p1 can apply my patch which resurrects the feature: http://sf.net/projects/mancha/files/misc/openssh-6.7p1-libwrap.diff Don't forget to autoreconf. --mancha SHA1(openssh-6.7p1-libwrap.diff)=1912538b1a4747d7aab9c338da17f854ae14c1e1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From plautrba at redhat.com Tue Oct 7 19:02:43 2014 From: plautrba at redhat.com (Petr Lautrbach) Date: Tue, 07 Oct 2014 10:02:43 +0200 Subject: Announce: OpenSSH 6.7 released In-Reply-To: <11168654333636927008.enqueue@cvs.openbsd.org> References: <11168654333636927008.enqueue@cvs.openbsd.org> Message-ID: <54339E23.3030803@redhat.com> On 10/07/2014 01:16 AM, Damien Miller wrote: > More information on donations may be found at: > http://www.openssh.com/donations.html > This page doesn't exist: $ wget http://www.openssh.com/donations.html --2014-10-07 10:01:54-- http://www.openssh.com/donations.html Resolving www.openssh.com (www.openssh.com)... 129.128.5.196 Connecting to www.openssh.com (www.openssh.com)|129.128.5.196|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2014-10-07 10:01:55 ERROR 404: Not Found. Petr -- Petr Lautrbach From djm at mindrot.org Tue Oct 7 21:48:22 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 7 Oct 2014 21:48:22 +1100 (EST) Subject: Portable OpenSSH source repository switched to git Message-ID: Hi, Now that the 6.7 release is out, we're switching the portable OpenSSH development repository from CVS to git. The public CVS rsync and ViewVC will not be updated and will soon be switched off. Public git mirrors can be found at: https://anongit.mindrot.org/openssh.git/ https://github.com/openssh/openssh-portable.git Both allow source browsing and clone. Please report any problems to myself and/or this list and bear with us while we make the inevitable bumbles as we adjust our workflow. -d From djm at mindrot.org Tue Oct 7 21:50:39 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 7 Oct 2014 21:50:39 +1100 (EST) Subject: Announce: OpenSSH 6.7 released In-Reply-To: <54339E23.3030803@redhat.com> References: <11168654333636927008.enqueue@cvs.openbsd.org> <54339E23.3030803@redhat.com> Message-ID: On Tue, 7 Oct 2014, Petr Lautrbach wrote: > On 10/07/2014 01:16 AM, Damien Miller wrote: > > More information on donations may be found at: > > http://www.openssh.com/donations.html > > > > This page doesn't exist: doh, I can't remember how long I've been using that URL. I'll see if I can fix it. -d From micah at addictivecode.org Fri Oct 10 05:38:06 2014 From: micah at addictivecode.org (Micah Cowan) Date: Thu, 9 Oct 2014 11:38:06 -0700 Subject: Feature rqst/Patch: Attempted key's fp in env to AuthorizedKeysCommand Message-ID: <20141009183806.GA20489@ambrose.micah.cowan.name> Hello. My employer (Akamai Technologies) had a case where they wanted to manage a large number (tens of thousands) of authorized keys for a single user. I'm sure there may be alternatives to that sort of use case, but at any rate it was decided that the simplest way to proceed would be to use OpenSSH's AuthorizedKeysCommand config option, with the extension that the attempted key's fingerprint would be placed in the environment of the command, so that it could use it as an index, and limit its output to only the relevant key, so that OpenSSH wouldn't spin around, linearly processing large number of keys to be thrown away in a moment. It was thought that it might be worth providing the patch in case it was thought to be useful to a wider audience. NOTES: - The patch below is similar to, but not quite the same, as the patch that was actually created for Akamai's use. Our patch uses a different name for the env var, and was written against Ubuntu's openssh source package, with a variety of other custom in-house patches atop it. - It is thus UNTESTED. It didn't seem worthwhile to me to set up a proper testing environment, as I suspect there's a strong chance it won't be applied upstream unchanged, and that at any rate you folks probably test more thoroughly than I would know to. (And the patch is trivial in any case.) - Are the results from this command cached in any way, and then reused if the user is trying multiple keys (say, from ssh-agent)? That won't be the way we're using it, so probably doesn't matter for us; but it'd be reasonable for a general-audience implementation to take that into account. This patch assumes no, and expects subsequent key attempts would result in additional invocations of user_key_command_allowed2 for each attempted key, but I hadn't actually confirmed this to be the case. - We're just using the SHA256 fingerprint, but it doesn't seem like it'd be a bad idea just to get all three sum-types, and throw them all into the environment, so users could use whichever they preferred for the index lookup (or whatever use they're putting it to). I originally wrote the patch to use MD5, but was then asked to use a stronger hash instead. But when the purpose is indexing, and not verification or direct authentication, I don't see much harm in using "weak" hashes. Patch follows. Thanks for your attention/feedback! -mjc diff -urNp openssh-6.7.orig/auth2-pubkey.c openssh-6.7/auth2-pubkey.c --- openssh-6.7.orig/auth2-pubkey.c 2014-07-15 08:54:14.000000000 -0700 +++ openssh-6.7/auth2-pubkey.c 2014-10-09 11:07:02.620077981 -0700 @@ -507,6 +507,7 @@ user_key_command_allowed2(struct passwd int status, devnull, p[2], i; pid_t pid; char *username, errmsg[512]; + char *envsha256; if (options.authorized_keys_command == NULL || options.authorized_keys_command[0] != '/') @@ -595,6 +596,20 @@ user_key_command_allowed2(struct passwd _exit(1); } + /* + * Put attempted key's fingerprint in environment, so + * users with many authorized keys can use indexing and + * return only the single relevant key for processing. + */ + envsha256 = key_fingerprint(key, SSH_FP_SHA256, + SSH_FP_HEX); + if (setenv(SSH_ATTEMPT_KEY_SHA256_ENV_NAME, envsha256, 1) + == -1) { + error("%s: setenv: %s", __func__, strerror(errno)); + _exit(1); + } + free(envsha256); /* Key has been copied into env. */ + execl(options.authorized_keys_command, options.authorized_keys_command, user_pw->pw_name, NULL); diff -urNp openssh-6.7.orig/ssh.h openssh-6.7/ssh.h --- openssh-6.7.orig/ssh.h 2010-06-25 00:14:46.000000000 -0700 +++ openssh-6.7/ssh.h 2014-10-09 11:04:28.720082528 -0700 @@ -69,6 +69,12 @@ #define SSH_ASKPASS_ENV "SSH_ASKPASS" /* + * Name of the environment variable used to pass the key fingerprint to the + * command named by the AuthorizedKeyCommand configuration setting. + */ +#define SSH_ATTEMPT_KEY_SHA256_ENV_NAME "SSH_ATTEMPT_KEY_SHA256" + +/* * Force host key length and server key length to differ by at least this * many bits. This is to make double encryption with rsaref work. */ (End of message.) From dkg at fifthhorseman.net Fri Oct 10 05:55:21 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 09 Oct 2014 14:55:21 -0400 Subject: Feature rqst/Patch: Attempted key's fp in env to AuthorizedKeysCommand In-Reply-To: <20141009183806.GA20489@ambrose.micah.cowan.name> References: <20141009183806.GA20489@ambrose.micah.cowan.name> Message-ID: <5436DA19.6050507@fifthhorseman.net> On 10/09/2014 02:38 PM, Micah Cowan wrote: > Hello. My employer (Akamai Technologies) had a case where they wanted to > manage a large number (tens of thousands) of authorized keys for a > single user. > > I'm sure there may be alternatives to that sort of use case, but at any > rate it was decided that the simplest way to proceed would be to use > OpenSSH's AuthorizedKeysCommand config option, with the extension that > the attempted key's fingerprint would be placed in the environment of > the command, so that it could use it as an index, and limit its output > to only the relevant key, so that OpenSSH wouldn't spin around, > linearly processing large number of keys to be thrown away in a moment. Thanks for working on this, Micah, and for publishing your patch. are you aware of: https://bugzilla.mindrot.org/show_bug.cgi?id=2081 This feedback should probably go to that bug report. fwiw, i think if we're supplying the key, there's no sense in supplying just the fingerprint -- go ahead and supply the whole key, and let the authorizedkeyscommand do whatever digesting it wants to do. --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 micah at addictivecode.org Fri Oct 10 06:15:33 2014 From: micah at addictivecode.org (Micah Cowan) Date: Thu, 9 Oct 2014 12:15:33 -0700 Subject: Feature rqst/Patch: Attempted key's fp in env to AuthorizedKeysCommand In-Reply-To: <5436DA19.6050507@fifthhorseman.net> References: <20141009183806.GA20489@ambrose.micah.cowan.name> <5436DA19.6050507@fifthhorseman.net> Message-ID: <20141009191533.GA20972@ambrose.micah.cowan.name> On Thu, Oct 09, 2014 at 02:55:21PM -0400, Daniel Kahn Gillmor wrote: > On 10/09/2014 02:38 PM, Micah Cowan wrote: ... > > it was decided that the simplest way to proceed would be to use > > OpenSSH's AuthorizedKeysCommand config option, with the extension that > > the attempted key's fingerprint would be placed in the environment of > > the command, so that it could use it as an index, and limit its output > > to only the relevant key, ... > Thanks for working on this, Micah, and for publishing your patch. are > you aware of: > > https://bugzilla.mindrot.org/show_bug.cgi?id=2081 Ah - I wasn't. Thanks for bringing it to my attention! > This feedback should probably go to that bug report. I'm not sure what I have to add to it, other than a "Me, too!" ;) I don't know whether we'd have a preference in the debate over env versus arg (but I'll ask around); I suspect our own choice to use env was based just on not wanting to maintain a patch with too large a code change, or that introduces serious differences between how we specify the option versus how upstream does it. -mjc From keisial at gmail.com Fri Oct 10 06:41:27 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 09 Oct 2014 21:41:27 +0200 Subject: Key Selection with agent In-Reply-To: References: <542F9E3C.2000905@gmail.com> Message-ID: <5436E4E7.6090408@gmail.com> On 06/10/14 02:50, Damien Miller wrote: >> The Situation is following: >> >> Workstatation is running the Agent with some keys >> Need to use a jump host to connect to other hosts. > You can use something like the following in your ~/.ssh/config > > Host foo > IdentitiesOnly yes > IdentityFile ~/.ssh/id_foo.pub > > Host bar > IdentitiesOnly yes > IdentityFile ~/.ssh/id_bar.pub > > ssh will use the specified key from the agent, even if it offers others. > Unfortunately there is no way to select/filter keys when an agent is > forwarded yet. However, I suspect he can get away with forwarding the agent by using a ProxyCommand: > ProxyCommand ssh -W %h:%p bar > It would be a nice feature though. +1 I think someone sent some time ago to this list a script for switching agents precisely for this kind of usecase. Maybe that's useful for you, Patrick. From imorgan at nas.nasa.gov Sat Oct 11 06:50:31 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 10 Oct 2014 12:50:31 -0700 Subject: Key Selection with agent In-Reply-To: References: <542F9E3C.2000905@gmail.com> Message-ID: <20141010195031.GD6678@linux124.nas.nasa.gov> On Mon, Oct 06, 2014 at 11:50:21 +1100, Damien Miller wrote: > On Sat, 4 Oct 2014, Patrick Marc Preuss wrote: > > > Hi All > > > > is it possible to select the presented key based on the hash? > > I don't know what hash you are talking about. > > > The Situation is following: > > > > Workstatation is running the Agent with some keys > > Need to use a jump host to connect to other hosts. > > You can use something like the following in your ~/.ssh/config > > Host foo > IdentitiesOnly yes > IdentityFile ~/.ssh/id_foo.pub > > Host bar > IdentitiesOnly yes > IdentityFile ~/.ssh/id_bar.pub > > ssh will use the specified key from the agent, even if it offers others. > > Unfortunately there is no way to select/filter keys when an agent is > forwarded yet. It would be a nice feature though. > > -d If you place a copy of the public key on a remote system, and add appropriate entries for IdentiesOnly and IdentityFile into the ~/.ssh/config on that system, you can control which key is used when connecting to other systems. What would be nice is if you could specify a key fingerprint with IdentityFile rather than having to provide the actual public key. This may have been what Patrick was referring to. -- Iain Morgan From patrick.preuss at gmail.com Sat Oct 11 10:57:00 2014 From: patrick.preuss at gmail.com (=?utf-8?Q?Patrick_Marc_Preu=C3=9F?=) Date: Sat, 11 Oct 2014 01:57:00 +0200 Subject: Key Selection with agent In-Reply-To: <20141010195031.GD6678@linux124.nas.nasa.gov> References: <542F9E3C.2000905@gmail.com> <20141010195031.GD6678@linux124.nas.nasa.gov> Message-ID: <1AAE6E07-2E21-4146-95CC-691D21607C59@gmail.com> Hi guys Yes i was Regfering to provide the key via the agent. First placeing the Key on a Remote system might be insecure. Your workstation can be assumed as Trusted enviroment. Second You can have multiple Keyes in use And obsolet one system (System group) Third you will not have failed Logins due to wrong keys . Will be useable for a wider Range of People So The question is must this be done in The Remote System or can The agent have The rule On The other Hand when using Gss api and kerberos can we forward the tgt or the request back to The workstation ? As we assume The workstation as an Trusted Source . ---- Patrick Marc Preuss Mobil: 0172/7411263 | Email: patrick.preuss at me.com > Am 10.10.2014 um 21:50 schrieb Iain Morgan : > >> On Mon, Oct 06, 2014 at 11:50:21 +1100, Damien Miller wrote: >>> On Sat, 4 Oct 2014, Patrick Marc Preuss wrote: >>> >>> Hi All >>> >>> is it possible to select the presented key based on the hash? >> >> I don't know what hash you are talking about. >> >>> The Situation is following: >>> >>> Workstatation is running the Agent with some keys >>> Need to use a jump host to connect to other hosts. >> >> You can use something like the following in your ~/.ssh/config >> >> Host foo >> IdentitiesOnly yes >> IdentityFile ~/.ssh/id_foo.pub >> >> Host bar >> IdentitiesOnly yes >> IdentityFile ~/.ssh/id_bar.pub >> >> ssh will use the specified key from the agent, even if it offers others. >> >> Unfortunately there is no way to select/filter keys when an agent is >> forwarded yet. It would be a nice feature though. >> >> -d > > If you place a copy of the public key on a remote system, and add > appropriate entries for IdentiesOnly and IdentityFile into the > ~/.ssh/config on that system, you can control which key is used when > connecting to other systems. > > What would be nice is if you could specify a key fingerprint with > IdentityFile rather than having to provide the actual public key. This > may have been what Patrick was referring to. > > -- > Iain Morgan From nkadel at gmail.com Sun Oct 12 02:02:21 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 11 Oct 2014 11:02:21 -0400 Subject: Feature rqst/Patch: Attempted key's fp in env to AuthorizedKeysCommand In-Reply-To: <20141009183806.GA20489@ambrose.micah.cowan.name> References: <20141009183806.GA20489@ambrose.micah.cowan.name> Message-ID: On Thu, Oct 9, 2014 at 2:38 PM, Micah Cowan wrote: > Hello. My employer (Akamai Technologies) had a case where they wanted to > manage a large number (tens of thousands) of authorized keys for a > single user. Did you talk to Andy or Brian over in the security group before publishing this? Feel free to tell them I said "Hi". I worked with them back when I was in the old Systems Engineering group, there over 10 years ago. And I did the tools to switch them from a commercial to the available OpenSSH based server back then. I was *very, very glad* that restarting sshd did not kill the SSH session you were currently using, but as a belt and suspenders move I'd start up the old sshd on a separate port before switching to the new one, just in case things got interrupted. And when you deal with that many hosts, some interruptions are *inevitable*. > I'm sure there may be alternatives to that sort of use case, but at any > rate it was decided that the simplest way to proceed would be to use > OpenSSH's AuthorizedKeysCommand config option, with the extension that > the attempted key's fingerprint would be placed in the environment of > the command, so that it could use it as an index, and limit its output > to only the relevant key, so that OpenSSH wouldn't spin around, > linearly processing large number of keys to be thrown away in a moment. That... sounds workable, and might scale well for other quite large environments. I'm particularly thinking of github and Sourceforge and other large 'git' or 'svn+ssh' environments. I also see that you've not included any documentation whatsoever for the user. Can I encourage you to add documentation in the relevant man pages along with your patch? > It was thought that it might be worth providing the patch in case it was > thought to be useful to a wider audience. > > NOTES: > - The patch below is similar to, but not quite the same, as the patch > that was actually created for Akamai's use. Our patch uses a > different name for the env var, and was written against Ubuntu's > openssh source package, with a variety of other custom in-house > patches atop it. Heh-heh-heh-heh. Oh, I could guess at some of them, including one I ripped out by the roots way back when. That was the old 'turn off reverse DNS lookups' patch, which is better handled by using 'sshd -u0' in the init scripts. > - It is thus UNTESTED. It didn't seem worthwhile to me to set up a > proper testing environment, as I suspect there's a strong chance it > won't be applied upstream unchanged, and that at any rate you folks > probably test more thoroughly than I would know to. (And the patch is > trivial in any case.) OK, now I'm laughing *really* hard. I used to do hardware evaluations there, as well as OS image building, and completely rebuilt the tools used to build test environments and new hosts. I certainly hope they still have that flexibile "rebuild at whim" capability. I'm afraid I've not personally been testing 6.7 yet. I tend to test in personal VM's on my laptop these days, so if I can find time to test it on an RHEL environment, I'll do so. No promises right now. > - Are the results from this command cached in any way, and then reused > if the user is trying multiple keys (say, from ssh-agent)? That > won't be the way we're using it, so probably doesn't matter for us; > but it'd be reasonable for a general-audience implementation to take > that into account. This patch assumes no, and expects subsequent > key attempts would result in additional invocations of > user_key_command_allowed2 for each attempted key, but I hadn't > actually confirmed this to be the case. > - We're just using the SHA256 fingerprint, but it doesn't seem like > it'd be a bad idea just to get all three sum-types, and throw them > all into the environment, so users could use whichever they > preferred for the index lookup (or whatever use they're putting it > to). I originally wrote the patch to use MD5, but was then asked to > use a stronger hash instead. But when the purpose is indexing, and > not verification or direct authentication, I don't see much harm in > using "weak" hashes. I personally agree with your risk assessment. > Patch follows. Thanks for your attention/feedback! > -mjc > > diff -urNp openssh-6.7.orig/auth2-pubkey.c openssh-6.7/auth2-pubkey.c > --- openssh-6.7.orig/auth2-pubkey.c 2014-07-15 08:54:14.000000000 -0700 > +++ openssh-6.7/auth2-pubkey.c 2014-10-09 11:07:02.620077981 -0700 > @@ -507,6 +507,7 @@ user_key_command_allowed2(struct passwd > int status, devnull, p[2], i; > pid_t pid; > char *username, errmsg[512]; > + char *envsha256; > > if (options.authorized_keys_command == NULL || > options.authorized_keys_command[0] != '/') > @@ -595,6 +596,20 @@ user_key_command_allowed2(struct passwd > _exit(1); > } > > + /* > + * Put attempted key's fingerprint in environment, so > + * users with many authorized keys can use indexing and > + * return only the single relevant key for processing. > + */ > + envsha256 = key_fingerprint(key, SSH_FP_SHA256, > + SSH_FP_HEX); > + if (setenv(SSH_ATTEMPT_KEY_SHA256_ENV_NAME, envsha256, 1) > + == -1) { > + error("%s: setenv: %s", __func__, strerror(errno)); > + _exit(1); > + } > + free(envsha256); /* Key has been copied into env. */ > + > execl(options.authorized_keys_command, > options.authorized_keys_command, user_pw->pw_name, NULL); > > diff -urNp openssh-6.7.orig/ssh.h openssh-6.7/ssh.h > --- openssh-6.7.orig/ssh.h 2010-06-25 00:14:46.000000000 -0700 > +++ openssh-6.7/ssh.h 2014-10-09 11:04:28.720082528 -0700 > @@ -69,6 +69,12 @@ > #define SSH_ASKPASS_ENV "SSH_ASKPASS" > > /* > + * Name of the environment variable used to pass the key fingerprint to the > + * command named by the AuthorizedKeyCommand configuration setting. > + */ > +#define SSH_ATTEMPT_KEY_SHA256_ENV_NAME "SSH_ATTEMPT_KEY_SHA256" > + > +/* > * Force host key length and server key length to differ by at least this > * many bits. This is to make double encryption with rsaref work. > */ > > (End of message.) > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From netheril96 at gmail.com Mon Oct 13 01:52:14 2014 From: netheril96 at gmail.com (Ren Siyuan) Date: Sun, 12 Oct 2014 22:52:14 +0800 Subject: Download OpenSSH through secure channel? Message-ID: I am trying to download a version of OpenSSH newer than the one preinstalled with my OS. But sadly I find that I can only download it through *unsecured* plain http/ftp/rsync protocol, vulnerable to attacks by anyone in the network path. It is odd that *the* software about security and encryption across untrusted network is distributed to everyone insecurely and not encrypted. Is there any future plan to distribute OpenSSH over secured channel, such as https? From hahn at mcmaster.ca Mon Oct 13 02:02:33 2014 From: hahn at mcmaster.ca (Mark Hahn) Date: Sun, 12 Oct 2014 11:02:33 -0400 (EDT) Subject: Download OpenSSH through secure channel? In-Reply-To: References: Message-ID: > insecurely and not encrypted. Is there any future plan to distribute > OpenSSH over secured channel, such as https? why? the sources are signed. also, anoncvs is over ssh. From yves at zioup.com Mon Oct 13 02:04:12 2014 From: yves at zioup.com (Yves Dorfsman) Date: Sun, 12 Oct 2014 09:04:12 -0600 Subject: Download OpenSSH through secure channel? In-Reply-To: References: Message-ID: <543A986C.6090101@zioup.com> On 2014-10-12 08:52, Ren Siyuan wrote: > I am trying to download a version of OpenSSH newer than the one preinstalled with my OS. But sadly I find that I can only download it through *unsecured* plain http/ftp/rsync protocol, vulnerable to attacks by anyone in the network path. It is odd that *the* software about security and encryption across untrusted network is distributed to everyone insecurely and not encrypted. Is there any future plan to distribute OpenSSH over secured channel, such as https? Are you saying you cannot trust the checksum posted on openssh.com? -- Yves. From raubvogel at gmail.com Mon Oct 13 02:00:37 2014 From: raubvogel at gmail.com (Mauricio Tavares) Date: Sun, 12 Oct 2014 11:00:37 -0400 Subject: Download OpenSSH through secure channel? In-Reply-To: References: Message-ID: On Sun, Oct 12, 2014 at 10:52 AM, Ren Siyuan wrote: > I am trying to download a version of OpenSSH newer than the one preinstalled with my OS. But sadly I find that I can only download it through *unsecured* plain http/ftp/rsync protocol, vulnerable to attacks by anyone in the network path. It is odd that *the* software about security and encryption across untrusted network is distributed to everyone insecurely and not encrypted. Is there any future plan to distribute OpenSSH over secured channel, such as https? Er, what about checksum? > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From robertabcd at gmail.com Mon Oct 13 02:03:08 2014 From: robertabcd at gmail.com (Robert) Date: Sun, 12 Oct 2014 23:03:08 +0800 Subject: Warn instead of a fatal error when ciphers do not exist. Message-ID: Hi, Not sure if this is the right place to post. When one of the ciphers listed under "Ciphers" in sshd_config does not exist, it refuses to start. This can happen when admins set their preferred ciphers and an update removed some ciphers. Admins can be locked out of remote machines after a reboot. I think it is better just ignore non-exist ciphers and generates warnings. Only exit when there is no ciphers available. Regards, Robert From mail at eworm.de Mon Oct 13 02:05:17 2014 From: mail at eworm.de (Christian Hesse) Date: Sun, 12 Oct 2014 17:05:17 +0200 Subject: Download OpenSSH through secure channel? In-Reply-To: References: Message-ID: <20141012170517.57689fdf@leda.localdomain> Ren Siyuan on Sun, 2014/10/12 22:52: > I am trying to download a version of OpenSSH newer than the one > preinstalled with my OS. But sadly I find that I can only download it > through *unsecured* plain http/ftp/rsync protocol, vulnerable to attacks by > anyone in the network path. It is odd that *the* software about security > and encryption across untrusted network is distributed to everyone > insecurely and not encrypted. Is there any future plan to distribute > OpenSSH over secured channel, such as https? OpenSSH development team provides GPG signature for their source tarballs. So download the tarball with whatever (unsecure) protocol you prefer, download the gpg signature file (ending .asc) and verify with gpg: % gpg --verify openssh-6.7p1.tar.gz.asc gpg: Signature made Mon 06 Oct 2014 05:40:59 AM CEST using RSA key ID 6D920D30 gpg: Good signature from "Damien Miller " [unknown] Primary key fingerprint: 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30 HTTPS does provide secure data transfer, but does not guaranty data is what developers intended to provide. If you download a compromised source tarball via HTTPS it is still compromised. -- Schoene Gruesse Chris O< ascii ribbon campaign stop html mail - www.asciiribbon.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From netheril96 at gmail.com Mon Oct 13 02:11:08 2014 From: netheril96 at gmail.com (Ren Siyuan) Date: Sun, 12 Oct 2014 23:11:08 +0800 Subject: Download OpenSSH through secure channel? In-Reply-To: <20141012170517.57689fdf@leda.localdomain> References: <20141012170517.57689fdf@leda.localdomain> Message-ID: <30974C91-7EBA-4EAC-B006-489D7E630114@gmail.com> How do I trust the key then? On Oct 12, 2014, at 23:05, Christian Hesse wrote: > Ren Siyuan on Sun, 2014/10/12 22:52: >> I am trying to download a version of OpenSSH newer than the one >> preinstalled with my OS. But sadly I find that I can only download it >> through *unsecured* plain http/ftp/rsync protocol, vulnerable to attacks by >> anyone in the network path. It is odd that *the* software about security >> and encryption across untrusted network is distributed to everyone >> insecurely and not encrypted. Is there any future plan to distribute >> OpenSSH over secured channel, such as https? > > OpenSSH development team provides GPG signature for their source tarballs. So > download the tarball with whatever (unsecure) protocol you prefer, download > the gpg signature file (ending .asc) and verify with gpg: > > % gpg --verify openssh-6.7p1.tar.gz.asc > gpg: Signature made Mon 06 Oct 2014 05:40:59 AM CEST using RSA key ID 6D920D30 > gpg: Good signature from "Damien Miller " [unknown] > Primary key fingerprint: 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30 > > HTTPS does provide secure data transfer, but does not guaranty data is what > developers intended to provide. If you download a compromised source tarball > via HTTPS it is still compromised. > -- > Schoene Gruesse > Chris > O< ascii ribbon campaign > stop html mail - www.asciiribbon.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From netheril96 at gmail.com Mon Oct 13 02:23:30 2014 From: netheril96 at gmail.com (Ren Siyuan) Date: Sun, 12 Oct 2014 23:23:30 +0800 Subject: Download OpenSSH through secure channel? In-Reply-To: References: Message-ID: <884F09F9-673A-4BE5-BB61-57FB974ACFAF@gmail.com> How do I get the checksum *securely* then? On Oct 12, 2014, at 23:00, Mauricio Tavares wrote: > On Sun, Oct 12, 2014 at 10:52 AM, Ren Siyuan wrote: >> I am trying to download a version of OpenSSH newer than the one preinstalled with my OS. But sadly I find that I can only download it through *unsecured* plain http/ftp/rsync protocol, vulnerable to attacks by anyone in the network path. It is odd that *the* software about security and encryption across untrusted network is distributed to everyone insecurely and not encrypted. Is there any future plan to distribute OpenSSH over secured channel, such as https? > > Er, what about checksum? > >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From netheril96 at gmail.com Mon Oct 13 02:29:54 2014 From: netheril96 at gmail.com (Ren Siyuan) Date: Sun, 12 Oct 2014 23:29:54 +0800 Subject: Download OpenSSH through secure channel? In-Reply-To: References: Message-ID: But how can I verify that the key with which to sign comes from a real OpenSSH developer? For the SSH connection, how do I verify the server? It is mostly paranoia, because I am sure no hacker would choose such a convoluted way when there are many more easier alternatives to compromise a certain computer. But I thought that the people developing security software would distribute their software almost completely securely. On Oct 12, 2014, at 23:02, Mark Hahn wrote: >> insecurely and not encrypted. Is there any future plan to distribute >> OpenSSH over secured channel, such as https? > > why? the sources are signed. also, anoncvs is over ssh. From keisial at gmail.com Mon Oct 13 02:53:58 2014 From: keisial at gmail.com (=?windows-1252?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 12 Oct 2014 17:53:58 +0200 Subject: Download OpenSSH through secure channel? In-Reply-To: <30974C91-7EBA-4EAC-B006-489D7E630114@gmail.com> References: <20141012170517.57689fdf@leda.localdomain> <30974C91-7EBA-4EAC-B006-489D7E630114@gmail.com> Message-ID: <543AA416.3090805@gmail.com> On 12/10/14 17:11, Ren Siyuan wrote: > How do I trust the key then? Travel to where they live, arrange a meeting where they can give you the fingerprint of his gpg key (this way you). Note they should also show you some id documents to verify that you really are in front of the person you think you are (although the name isn't that important, it's the fact that it's a openssh developer that matters). Or you can attempt to use the web-of-trust trying to know someone who has signed the key of someone who has signed the key of one of them? From peter at stuge.se Mon Oct 13 07:47:32 2014 From: peter at stuge.se (Peter Stuge) Date: Sun, 12 Oct 2014 22:47:32 +0200 Subject: Warn instead of a fatal error when ciphers do not exist. In-Reply-To: References: Message-ID: <20141012204732.11343.qmail@stuge.se> Robert wrote: > Not sure if this is the right place to post. File a bug in bugzilla. If you have a patch, attach it to the bug. Thanks! //Peter From angelosching at clustertech.com Mon Oct 13 21:12:03 2014 From: angelosching at clustertech.com (Angelos Ching) Date: Mon, 13 Oct 2014 18:12:03 +0800 Subject: Generating the corresponding public key of a private key Message-ID: <543BA573.3090003@clustertech.com> Hi, Can I always expect the following commands, when given the same private key, to generate the same public key albeit in different format? # ssh-keygen -y -f id_rsa # ssh-keygen -e -f id_rsa Because I'm dealing with one private key that is generating different public key when the above commands were executed. The output between the 2 commands are different, but they are consistent for any number of runs. Moreover, if I copy id_rsa to, say, id_rsa.priv: # ssh-keygen -y -f id_rsa.priv # ssh-keygen -e -f id_rsa.priv would generate the same public key output. Running OpenSSL 1.0.0-fips 29 Mar 2010 Best regards, Angelos From keisial at gmail.com Tue Oct 14 03:45:35 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Mon, 13 Oct 2014 18:45:35 +0200 Subject: Generating the corresponding public key of a private key In-Reply-To: <543BA573.3090003@clustertech.com> References: <543BA573.3090003@clustertech.com> Message-ID: <543C01AF.7050806@gmail.com> On 13/10/14 12:12, Angelos Ching wrote: > Hi, > > Can I always expect the following commands, when given the same > private key, to generate the same public key albeit in different format? > # ssh-keygen -y -f id_rsa > # ssh-keygen -e -f id_rsa Both commands are defined as outputting the public key for id_rsa, so yes. Otherwise, it's a bug. > Because I'm dealing with one private key that is generating different > public key when the above commands were executed. How are you detecting that it is a different public key? -e by default uses RFC4716, so other than the wrapping, it should be the same content. You should be able to go from -e format to -y one with: > echo ssh-rsa $(echo $(ssh-keygen -e -f id_rsa | sed > '/--/d;/^Comment:/d') | tr -d \ ) > The output between the 2 commands are different, but they are > consistent for any number of runs. > Moreover, if I copy id_rsa to, say, id_rsa.priv: > # ssh-keygen -y -f id_rsa.priv > # ssh-keygen -e -f id_rsa.priv > would generate the same public key output. Are you saying that the output is different if you rename the file to id_rsa.priv ?? > Running OpenSSL 1.0.0-fips 29 Mar 2010 May I also ask for the openssh version, too? :) > > Best regards, > Angelos Cheers From Jitendra.Hushare at sungard.com Thu Oct 16 17:53:12 2014 From: Jitendra.Hushare at sungard.com (Jitendra.Hushare at sungard.com) Date: Thu, 16 Oct 2014 06:53:12 +0000 Subject: Character Set conversion from EBCIDIC to ASCII Message-ID: <7752F0D05CB8ED4685D04E651E088A153AE04BED@emea-tc2-mb04.internal.sungard.corp> Hello, We as an organization are going to use SFTP for our data transfer. Our requirement is to SFTP the file from IBM Mainframe (z/390) to Unix or Windows. Currently we are using FTP, which converts the character set from EBCIDIC to ASCII and also take care of CR and LF aspect. My question is, do the same feature is available in SFTP, where it smartly understand the source and destination operating system and does the character set conversion and take care of CR and LF as FTP does currently. Please suggest. Thank you Jitendra From djm at mindrot.org Fri Oct 17 10:10:38 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 17 Oct 2014 10:10:38 +1100 (EST) Subject: Character Set conversion from EBCIDIC to ASCII In-Reply-To: <7752F0D05CB8ED4685D04E651E088A153AE04BED@emea-tc2-mb04.internal.sungard.corp> References: <7752F0D05CB8ED4685D04E651E088A153AE04BED@emea-tc2-mb04.internal.sungard.corp> Message-ID: On Thu, 16 Oct 2014, Jitendra.Hushare at sungard.com wrote: > Hello, > > We as an organization are going to use SFTP for our data transfer. > Our requirement is to SFTP the file from IBM Mainframe (z/390) to Unix > or Windows. Currently we are using FTP, which converts the character > set from EBCIDIC to ASCII and also take care of CR and LF aspect. > > My question is, do the same feature is available in SFTP, where it > smartly understand the source and destination operating system and > does the character set conversion and take care of CR and LF as FTP > does currently. Please suggest. No, OpenSSH does not and will not implement character set conversion. You might be able to find a 3rd-party sftp client or server that does it. -d From scott_n at xypro.com Fri Oct 17 10:12:35 2014 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 16 Oct 2014 23:12:35 +0000 Subject: Character Set conversion from EBCIDIC to ASCII In-Reply-To: References: <7752F0D05CB8ED4685D04E651E088A153AE04BED@emea-tc2-mb04.internal.sungard.corp> Message-ID: Use "dd conv=ascii" after transfer for inbound data on your client, or "dd conv=ebcdic" for outbound data before you send it. -----Original Message----- From: openssh-unix-dev [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On Behalf Of Damien Miller Sent: Thursday, October 16, 2014 4:11 PM To: Jitendra.Hushare at sungard.com Cc: openssh-unix-dev at mindrot.org Subject: Re: Character Set conversion from EBCIDIC to ASCII On Thu, 16 Oct 2014, Jitendra.Hushare at sungard.com wrote: > Hello, > > We as an organization are going to use SFTP for our data transfer. > Our requirement is to SFTP the file from IBM Mainframe (z/390) to Unix > or Windows. Currently we are using FTP, which converts the character > set from EBCIDIC to ASCII and also take care of CR and LF aspect. > > My question is, do the same feature is available in SFTP, where it > smartly understand the source and destination operating system and > does the character set conversion and take care of CR and LF as FTP > does currently. Please suggest. No, OpenSSH does not and will not implement character set conversion. You might be able to find a 3rd-party sftp client or server that does it. -d _______________________________________________ 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 Fri Oct 17 14:36:29 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 16 Oct 2014 23:36:29 -0400 Subject: Character Set conversion from EBCIDIC to ASCII In-Reply-To: References: <7752F0D05CB8ED4685D04E651E088A153AE04BED@emea-tc2-mb04.internal.sungard.corp> Message-ID: On Thu, Oct 16, 2014 at 7:10 PM, Damien Miller wrote: > On Thu, 16 Oct 2014, Jitendra.Hushare at sungard.com wrote: > >> Hello, >> >> We as an organization are going to use SFTP for our data transfer. >> Our requirement is to SFTP the file from IBM Mainframe (z/390) to Unix >> or Windows. Currently we are using FTP, which converts the character >> set from EBCIDIC to ASCII and also take care of CR and LF aspect. >> >> My question is, do the same feature is available in SFTP, where it >> smartly understand the source and destination operating system and >> does the character set conversion and take care of CR and LF as FTP >> does currently. Please suggest. > > No, OpenSSH does not and will not implement character set conversion. > You might be able to find a 3rd-party sftp client or server that does > it. There are some long standing problems with FTP. The occasionally erroneous and daa corrupting EOL handling and character transformations are two of them. If you really need to do something like this, may I suggest that you SFTP or rsync-over-ssh to a staging area, and push from there to a publication as needed? That lets you verify the files before transmission, especially if you use rsync. From calestyo at scientia.net Sun Oct 19 03:35:29 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 18 Oct 2014 18:35:29 +0200 Subject: some questions on OpenSSH alogs Message-ID: <1413650129.4721.1.camel@scientia.net> Hey folks I'd have some questions on algos in OpenSSH,... perhaps one of you can shed a bit light.... not sure if I'm still up-to-date everywhere in cryptology,... but I read Damien's nice blog post[0] I usually want to use the most securest algos and I don't particularly look at much backwards compatibility for older clients. Neither do I care a lot about speed. Actually I think others may be interested in this, too, and one could publish it in the end in a blog or so. I) Ciphers 3des-cbc blowfish-cbc cast128-cbc arcfour arcfour128 arcfour256 aes128-cbc aes192-cbc aes256-cbc rijndael-cbc at lysator.liu.se aes128-ctr aes192-ctr aes256-ctr aes128-gcm at openssh.com aes256-gcm at openssh.com chacha20-poly1305 at openssh.com Okay we can drop 3des and arcfour for security, that's clear. And I'd also have my doubts about blowfish and cast128, right?! Apparently the CBC versions are all insecure (at least as used in ssh) now? So we remain with: aes128-ctr aes192-ctr aes256-ctr aes128-gcm at openssh.com aes256-gcm at openssh.com chacha20-poly1305 at openssh.com 1) I understand that only the later 3 use authenticating encryption,... does this mean thought that aes*-ctr are generally less secure? Or are they secure again in combination with the right MAC? Cause I may actually need to still enable these three for older clients at the university. 2) Regarding the AES with GCM (and also with all other algos, not only Ciphers but MACs and so on)... why do you always default to using the versions with the smaller block size? 3) Now chacha20/poly1305... it's fairly new and apart from the fact that it allows you to encrypt the packet sizes again... can one consider it to be at least as secure as the aes*-ctr modes? Or is e.g. aes256-ctr + an EtM MAC mode a more secure choice? AFAIU, Poly1305-AES is basically as secure as AES. I haven't much knowledge on the security of ChaCha20,... there seem to be some first attack trials though (https://en.wikipedia.org/wiki/Salsa20#ChaCha_variant). 4) Oh and btw: When an authenticating encryption Cipher is used... do the MACs (directive) still play a role? In the sense, does SSH even calculate MACs then? 5) Wouldn't (note the changed ordering of block sizes 256/192/128): chacha20-poly1305 at openssh.com,aes256-gcm at openssh.com,aes128-gcm at openssh.com,aes256-ctr,aes192-ctr,aes128-ctr or perhaps even just: chacha20-poly1305 at openssh.com,aes256-gcm at openssh.com,aes128-gcm at openssh.com be a safer default then the current: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ? II) MACs hmac-sha1 hmac-sha1-96 hmac-sha2-256 hmac-sha2-512 hmac-md5 hmac-md5-96 hmac-ripemd160 hmac-ripemd160 at openssh.com umac-64 at openssh.com umac-128 at openssh.com hmac-sha1-etm at openssh.com hmac-sha1-96-etm at openssh.com hmac-sha2-256-etm at openssh.com hmac-sha2-512-etm at openssh.com hmac-md5-etm at openssh.com hmac-md5-96-etm at openssh.com hmac-ripemd160-etm at openssh.com umac-64-etm at openssh.com umac-128-etm at openssh.com I'm so bold an remove anything MD5, SHA1 and ripemd160 based (yeah, I know that HMACs aren't so strongly affected by collisions in their underlying hash algos as those themselves, but nevertheless). Next one would probably want to remove all non EtM modes, right, or is there any cipher combination left in which they can be used securely? So one would be left back with: hmac-sha2-256-etm at openssh.com hmac-sha2-512-etm at openssh.com umac-64-etm at openssh.com umac-128-etm at openssh.com 6) So how does the security of HMAC compare to UMAC? I couldn't really find much about this. 7) I found however, that UMAC is optimised for 32bit architectures... are there any plans to integrate a VMAC algo? 8) Wouldn't (note the changed ordering of block sizes 512/256 respectively 128/64): umac-128-etm at openssh.com,umac-64-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha2-256-etm at openssh.com be a safer default then the current: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512 ? III) Key Exchange Alogs diffie-hellman-group1-sha1 diffie-hellman-group14-sha1 diffie-hellman-group-exchange-sha1 diffie-hellman-group-exchange-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 curve25519-sha256 at libssh.org Okay I haven't much clue here... I'd again drop sha1 based stuff. Perhaps one cannot trust the NIST curves (but can one trust SHA2 then?) so I'd definitely prefer DJBs curve when it comes to ECC. 9) Which of them do provide (perfect) forward secrecy? 10) What's the difference between the DH group and the group-exchange ones? 11) How would one order them based on security? I'd probably go for: curve25519-sha256 at libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256, maybe also just: curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256 or even just: curve25519-sha256 at libssh.org At least assuming that Curve 25519 is used with ECDH, therefore also having PFS. IV) HostKeyAlgorithms Actually I'm a bit unsure what these actually mean shouldn't those depend on the used KEx? I.e. that e.g. ssh-ed25519 can only be used with KEx=curve25519-sha256 at libssh.org? We have in total these: ssh-ed25519 ssh-ed25519-cert-v01 at openssh.com ssh-rsa ssh-dss ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-rsa-cert-v01 at openssh.com ssh-dss-cert-v01 at openssh.com ecdsa-sha2-nistp256-cert-v01 at openssh.com ecdsa-sha2-nistp384-cert-v01 at openssh.com ecdsa-sha2-nistp521-cert-v01 at openssh.com ssh-rsa-cert-v00 at openssh.com ssh-dss-cert-v00 at openssh.com I'd drop dss, due to the key size limitations. I'd guess the -cert-v* algos are the ones for SSH Certificate Authentication... and AFAIU this is not more or less secure than the use of traditional SSH keys, just that you have the certificate based way of "replacing" known_hosts and authorized keys. So I let them in, with the exception of cert-v00? What's the matter with them? As for the NIST curves the same goes as above. So one ends up with: ssh-ed25519 ssh-ed25519-cert-v01 at openssh.com ssh-rsa ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 ssh-rsa-cert-v01 at openssh.com ecdsa-sha2-nistp256-cert-v01 at openssh.com ecdsa-sha2-nistp384-cert-v01 at openssh.com ecdsa-sha2-nistp521-cert-v01 at openssh.com Since I distrust NIST, I'd probably choose this (note the changed ordering of block sizes 256/192/128): ssh-ed25519,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa,ssh-rsa-cert-v01 at openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01 at openssh.com or really just: ssh-ed25519,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa,ssh-rsa-cert-v01 at openssh.com Wouldn't that be a better default then the current: ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-ed25519-cert-v01 at openssh.com, ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com, ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa,ssh-dss I especially do not understand why you sort the cert algos before their "normal" counterparts" and why the NIST curves come before ED25519, while KexAlgorithms already haves the curve25519 at first. The manpage says "If hostkeys are known for the destination host then this default is modified to prefer their algorithms." But does that mean it modifies the ordering, even when I manually set something? Cheers, Chris. [0] http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html -------------- 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 Sun Oct 19 03:58:17 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 18 Oct 2014 18:58:17 +0200 Subject: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters Message-ID: <1413651497.4721.3.camel@scientia.net> Hey. AFAIU, all the key exchange algorithms in SSH (or perhaps better said OpenSSH, since the RFCs would allow for MQV) are basically Diffie-Hellman based[0]. Or the ECC versions (the ECDH versions with NIST curves or curve25519). 1) I guess ALL these are ephemeral versions of DH/ECDC, in order to get FS/PFS, right? Just out of curiosity,... what is done to make the the DH authenticated? I guess it depends on the chosen HostKeyAlogrithm (so either RSA, DSS, ECDSA or EdDSA)... but do client/server exchange the DH parameters signed or doe they exchange a signed version of the agreed key? 2) Now the security of DH/ECDH obviously depends on the parameters, e.g. having a 16 bit DH group makes it useless.... AFAIU for diffie-hellman-group1-sha1 anddiffie-hellman-group14-sha1 and the parameters are fixed (with 1024 and 2048 bit groups) The same for the the four ECDH versions (ecdh-sha2-nistp* and curve25519-sha256 at libssh.org), they all have fixed values So if I'd find that to be too weak, then the only thing one could do is disable those, right? But for the diffie-hellman-group-exchange-sha1 diffie-hellman-group-exchange-sha256 the /etc/ssh/moduli file is used to find parameters, right? a) Documentations seems to imply that this is only used by sshd? So how does the ssh client come to his accepted parameters? Does he simply take anything a SSH server proposes? b) How can I restrict what the server accepts as parameters? E.g. if I think 1024 bit groups are to weak, can I simply remove those entries from the moduli file and such groups will no longer be used? c) How can I do the same for the client? Thanks, Chris. [0] diffie-hellman-group1-sha1,diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256, ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521, curve25519-sha256 at libssh.org -------------- 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 Oct 19 09:22:01 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Sat, 18 Oct 2014 22:22:01 +0000 (UTC) Subject: some questions on OpenSSH alogs References: <1413650129.4721.1.camel@scientia.net> Message-ID: On 2014-10-18, Christoph Anton Mitterer wrote: > I'd have some questions on algos in OpenSSH,... perhaps one of you can > shed a bit light.... not sure if I'm still up-to-date everywhere in=20 > cryptology,... but I read Damien's nice blog post[0] Let me preface this with a remark: I think if there has been anything to take away from the recent crypto disasters and spying revelations, it's the confirmation that crypto systems are not exploited by breaking cryptographic primitives. Much of this "securest algo" talk is armchair generalmanship that misses the point. You'll also find that OpenSSH 6.6 has already trimmed the list of default algorithms. > aes128-ctr > aes192-ctr > aes256-ctr > aes128-gcm at openssh.com > aes256-gcm at openssh.com > chacha20-poly1305 at openssh.com > > 1) I understand that only the later 3 use authenticating encryption,... > does this mean thought that aes*-ctr are generally less secure? Or are > they secure again in combination with the right MAC? They provide authenticated encryption in combination with a MAC. > 2) Regarding the AES with GCM (and also with all other algos, not only > Ciphers but MACs and so on)... why do you always default to using the > versions with the smaller block size? With the smaller _key_ size. AES always has a 128-bit block size, regardless of the key size. AES-128 is good enough. Larger key sizes incur a performance cost. There is also the issue of balancing the various components of the overall system (KEX, keys, cipher, MAC) so that they all have similar strength. > 3) Now chacha20/poly1305... it's fairly new and apart from the fact that > it allows you to encrypt the packet sizes again... can one consider it > to be at least as secure as the aes*-ctr modes? > Or is e.g. aes256-ctr + an EtM MAC mode a more secure choice? For whatever it's worth, Chacha20 has received less scrutiny than AES. But see my remark at the beginning of this message. > AFAIU, Poly1305-AES is basically as secure as AES. Poly1305, U/VMAC, and GMAC all run the data through a noncryptographic hash and encrypt the result with AES. > 4) Oh and btw: When an authenticating encryption Cipher is used... do > the MACs (directive) still play a role? No. Compare the ssh -v output: debug1: kex: server->client aes128-ctr umac-64-etm at openssh.com none debug1: kex: client->server aes128-ctr umac-64-etm at openssh.com none debug1: kex: server->client aes128-gcm at openssh.com none debug1: kex: client->server aes128-gcm at openssh.com none (The fields are cipher, MAC, compression.) > 6) So how does the security of HMAC compare to UMAC? I couldn't really > find much about this. Until somebody manages to break them, their strength is directly related to the size of the tag. For GMAC (AES-GCM) there has been at least one paper on how truncating the MAC is bad, but we don't do that. > 7) I found however, that UMAC is optimised for 32bit architectures... > are there any plans to integrate a VMAC algo? I considered it, but decided I didn't want to further expand the algorithm zoo we already have. UMAC is plenty fast and the trend is towards AEAD ciphers (authenticated encryption with associated data) like AES-GCM or the Chacha20+Poly1305 construct. VMAC could be used to be build one; Chacha20+VMAC might have been interesting and would have been faster than Chacha20+Poly1305, but everybody is currently high on Daniel J. Bernstein's primitives, and while U/VMAC are fast, they aren't pretty. *shrug* > III) Key Exchange Alogs > Perhaps one cannot trust the NIST curves (but can one trust SHA2 then?) > so I'd definitely prefer DJBs curve when it comes to ECC. There is no reason to distrust SHA2. Even Ed25519 uses it. > 9) Which of them do provide (perfect) forward secrecy? All. > 10) What's the difference between the DH group and the group-exchange > ones? "The original key agreement methods defined in the transport protocol use fixed, well-known groups for the Diffie-Hellman algorithm. This method allows a server to use a set of locally configured groups, and the client to request a preferred group size." (RFC4419) > 11) How would one order them based on security? > I'd probably go for: > curve25519-sha256 at libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha= > 2-nistp256,diffie-hellman-group-exchange-sha256, Strength-wise, Curse25519 compares to NIST-P256, so it depends how you feel about the NIST curves. > IV) HostKeyAlgorithms > Actually I'm a bit unsure what these actually mean shouldn't those > depend on the used KEx? No, they are completely independent. > I'd guess the -cert-v* algos are the ones for SSH Certificate > Authentication... and AFAIU this is not more or less secure than the use > of traditional SSH keys, just that you have the certificate based way of > "replacing" known_hosts and authorized keys. > So I let them in, with the exception of cert-v00? What's the matter with > them? As per the commit message: Revised certificate format ssh-{dss,rsa}-cert-v01 at openssh.com with the following changes: * Move the nonce field to the beginning of the certificate where it can better protect against chosen-prefix attacks on the signature hash * Rename "constraints" field to "critical options" * Add a new non-critical "extensions" field * Add a serial number > I especially do not understand why you sort the cert algos before their > "normal" counterparts" and why the NIST curves come before ED25519, > while KexAlgorithms already haves the curve25519 at first. I don't know. I prefer Ed25519 keys, so I use (what a mouthful!) -oHostKeyAlgorithms=ssh-ed25519 when connecting to a host for the first time. > The manpage says "If hostkeys are known for the destination host then > this default is modified to prefer their algorithms." > But does that mean it modifies the ordering, even when I manually set > something? If you connect to a host, the default server key type is ecdsa-sha2-nistp256, and if you connect to a host for the first time, that key will be saved in known_hosts. However, if known_hosts already contains a different type of key, that one will be chosen instead. I have ssh-ed25519 keys in my known_hosts file for all destination hosts that support it, and this key will be picked to authenticate the host (instead of ecdsa-sha2-nistp256). No explicit setting of HostKeyAlgorithms is required. > [0] http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html "Back in the dark ages of the SSH2 protocol's design, there wasn't consensus among cryptographers on the best order to apply encryption and authentication in protocols - in fact, the three main cryptographic protocols to emerge from the 1990s - SSL, SSH and IPsec - all use different choices" So true. IPsec got it right. SSL got it wrong and that decision keeps on giving, see this week's POODLE excitement. SSH has gotten better. -- Christian "naddy" Weisgerber naddy at mips.inka.de From jsr at dex.edzone.net Sun Oct 19 10:21:38 2014 From: jsr at dex.edzone.net (Jay Rouman) Date: Sat, 18 Oct 2014 19:21:38 -0400 (EDT) Subject: Random connect failures with openssh-6.7p1 Message-ID: I have been experiencing random connection failures after upgrading to openssh-6.7p1 from 6.6p1. The server is built against openssl-1.0.1j and is running on a Slackware-14.0 machine. The client is VX-ConnectBot 1.7.1-41.beta. I am using the beta version because it is the only one which supports ecdsa public keys, which is what I am using to authenticate. The symptom is that ConnectBot prints: Connecting to :22 via ssh Verified host 'EC' key: Then it freezes. If you use the Disconnect option, you can try again and it may or may not complete the authentication. If it works, the rest of the session is fine. I have observed the same problem on two Android devices, a Motorola Maxx phone and a Nexus 7 (2013) tablet, so I don't think it's funky hardware. 6.6 built against the same openssl works every time. I have debug logs of a failed and successful logins but I am not sure it is appropriate to post them here and I don't know enough for them to be meaningful to me. I have been through several iterations of openssh with this ConnectBot client and the ecdsa key and everything has been fine up until now. Development on VX-ConnectBot seems to have stalled so upgrading the client isn't an option. -- Jay Rouman (jsr at dexter.mi.org jsr at edzone.net) From jtjacques at gmail.com Sun Oct 19 14:26:42 2014 From: jtjacques at gmail.com (Jason Jacques) Date: Sun, 19 Oct 2014 04:26:42 +0100 Subject: Username case sensitivity issue with multiple variants in /etc/passwd Message-ID: <8CFC6E8B-E4CD-4EDE-9089-F99C975BA96E@gmail.com> Hi, I recently upgraded from 4.3 to 6.7 on Windows with cygwin and noticed that case sensitivity had been introduced for Windows usernames as per this discussion: http://marc.info/?l=openssh-unix-dev&m=126505289206175&w=2 It seems there is still a bug in the handling of usernames regarding case sensitivity however. The following /etc/passwd allows me to login as either Jason or dave to the same uid (case-sensitive, therefore jason and Dave do not work as expected): Jason:unused:1006:513:Jason Jacques,U-SERVER\jason,S-1-5-21-XXXXXXXXXX-436374069-527237240-1006:/home/jason:/bin/bash dave:unused:1006:513:Jason Jacques,U-SERVER\jason,S-1-5-21-XXXXXXXXXX-436374069-527237240-1006:/home/jason:/bin/bash If I change the /etc/passwd to the following however, I can only login with the username Jason. jason (lower-case) does not work. This is dependant on which occurs first in the /etc/passwd file (i.e. if lowercase is first, that is the allowed variant): Jason:unused:1006:513:Jason Jacques,U-SERVER\jason,S-1-5-21-XXXXXXXXXX-436374069-527237240-1006:/home/jason:/bin/bash jason:unused:1006:513:Jason Jacques,U-SERVER\jason,S-1-5-21-XXXXXXXXXX-436374069-527237240-1006:/home/jason:/bin/bash In essence, it seems OpenSSH is now treating Jason and jason as different accounts based on unix practices, but if different cases are specified in /etc/passwd only the first variant is evaluated before determining if the login should proceed. Thanks, Jason Jacques Email: jtjacques at gmail.com Web: http://jasonjacques.co.uk From naddy at mips.inka.de Mon Oct 20 00:37:51 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Sun, 19 Oct 2014 13:37:51 +0000 (UTC) Subject: some questions on OpenSSH alogs References: <1413650129.4721.1.camel@scientia.net> Message-ID: On 2014-10-18, Christian Weisgerber wrote: > You'll also find that OpenSSH 6.6 has already trimmed the list of > default algorithms. That's actually OpenSSH 6.7. >> 7) I found however, that UMAC is optimised for 32bit architectures... >> are there any plans to integrate a VMAC algo? > > I considered it, but decided I didn't want to further expand the > algorithm zoo we already have. This tickled some half-buried memory and made me look again. VMAC's core operation is a 64 by 64 to 128 bits multiplication. This can't be expressed in portable C and even if you resort to inline assembly, not all 64-bit archs may support this operation. (E.g., I don't see a corresponding instruction in the SPARCv9 manual.) -- Christian "naddy" Weisgerber naddy at mips.inka.de From naddy at mips.inka.de Mon Oct 20 04:07:32 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Sun, 19 Oct 2014 17:07:32 +0000 (UTC) Subject: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters References: <1413651497.4721.3.camel@scientia.net> Message-ID: On 2014-10-18, Christoph Anton Mitterer wrote: > 1) I guess ALL these are ephemeral versions of DH/ECDC, in order to get > FS/PFS, right? Yes. > Just out of curiosity,... what is done to make the the DH authenticated? > I guess it depends on the chosen HostKeyAlogrithm (so either RSA, DSS, > ECDSA or EdDSA)... but do client/server exchange the DH parameters > signed or doe they exchange a signed version of the agreed key? https://tools.ietf.org/html/rfc4253#section-8 > AFAIU for diffie-hellman-group1-sha1 anddiffie-hellman-group14-sha1 and > the parameters are fixed (with 1024 and 2048 bit groups) > > The same for the the four ECDH versions (ecdh-sha2-nistp* and > curve25519-sha256 at libssh.org), they all have fixed values > > So if I'd find that to be too weak, then the only thing one could do is > disable those, right? Right. > But for the diffie-hellman-group-exchange-sha1 > diffie-hellman-group-exchange-sha256 the /etc/ssh/moduli file is used to > find parameters, right? > > a) Documentations seems to imply that this is only used by sshd? > So how does the ssh client come to his accepted parameters? Does he > simply take anything a SSH server proposes? The client sends the minimal/preferred/maximal group size, and the server picks a group and responds with the modulus and generator for the group. https://tools.ietf.org/html/rfc4419 > b) How can I restrict what the server accepts as parameters? > E.g. if I think 1024 bit groups are to weak, can I simply remove those > entries from the moduli file and such groups will no longer be used? If the server doesn't find (a suitable group in) /etc/moduli, it will fall back to the group from diffie-hellman-group14-sha1. The elliptic curve key exchanges have pretty much obsoleted the Diffie-Hellman group exchange. -- Christian "naddy" Weisgerber naddy at mips.inka.de From calestyo at scientia.net Mon Oct 20 05:02:49 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sun, 19 Oct 2014 20:02:49 +0200 Subject: some questions on OpenSSH alogs In-Reply-To: References: <1413650129.4721.1.camel@scientia.net> Message-ID: <1413741769.6290.1.camel@scientia.net> Hey Christian. Thanks for your replies. On Sat, 2014-10-18 at 22:22 +0000, Christian Weisgerber wrote: > Let me preface this with a remark: I think if there has been anything > to take away from the recent crypto disasters and spying revelations, > it's the confirmation that crypto systems are not exploited by > breaking cryptographic primitives. Much of this "securest algo" > talk is armchair generalmanship that misses the point. I agree, well at least in parts: IMHO the recent disasters only showed, how we are attacked on a broad range - it doesn't prove anything, whether the crypto primitives themselves are still secure. They might very well be, and we haven't much prove that they wouldn't (well except some like TLS/SSL+RC4 or SSLv3/CBC, etc.), but this alone doesn't guarantee they really still are. And any power who was really capable of breaking one of the stronger crypto-primitives will likely handle that like a top-level state secret, and only use in in rare circumstances,... so it's unlikely that we would have gathered knowledge about this from e.g. Snowden. Anyway, my point in they "securest algo" thingy is mostly this: I cannot do much about exploits and security holes in software (which can be used to avoid the crypto at all), neither about someone like the NSA simply coming to my home and beating me up so severely till I give them any password/key with pleasure... but when I have no interoperability or performance issues, why shouldn't I increase the crypto primitives to the strongest possible? :) > You'll also find that OpenSSH 6.6 has already trimmed the list of > default algorithms. Sure,... but at work I've noticed that many people still use so old clients, that they only have hmac-sha1 and -md5... :( > > 1) I understand that only the later 3 use authenticating encryption,... > > does this mean thought that aes*-ctr are generally less secure? Or are > > they secure again in combination with the right MAC? > They provide authenticated encryption in combination with a MAC. Mhh sure,... but is there any advantage (apart from performance and ease of implementation), of using an AE cipher instead of an encrypting-only cipher in combination with a MAC? > > 2) Regarding the AES with GCM (and also with all other algos, not only > > Ciphers but MACs and so on)... why do you always default to using the > > versions with the smaller block size? > With the smaller _key_ size. AES always has a 128-bit block size, > regardless of the key size. Sorry,.. of course... > AES-128 is good enough. Larger key > sizes incur a performance cost. There is also the issue of balancing > the various components of the overall system (KEX, keys, cipher, > MAC) so that they all have similar strength. okay... I see,... regarding that I mostly go for the ECRYPT II and NIST recommendations (http://www.keylength.com/en/3/)... But especially when you want to go in the "Forseeable Future" range,... it seems to be tough to actually do that with the current curves. So for ED25519 and ECDH with the NIST curves... all the DH parameters and sizes are fixed anyway, right? > > 3) Now chacha20/poly1305... it's fairly new and apart from the fact that > > it allows you to encrypt the packet sizes again... can one consider it > > to be at least as secure as the aes*-ctr modes? > > Or is e.g. aes256-ctr + an EtM MAC mode a more secure choice? > > For whatever it's worth, Chacha20 has received less scrutiny than > AES. Mhh that's basically my concern... right now I actually default to Chacha20,... but as you said,... AES/GCM is probably much better analysed... tough decision ;) > > AFAIU, Poly1305-AES is basically as secure as AES. > > Poly1305, U/VMAC, and GMAC all run the data through a noncryptographic > hash and encrypt the result with AES. How important is the size there? I mean umac-128 and especially -64 sounds little in comparison to the hash sizes of e.g. sha2-512 with HMAC. > > 7) I found however, that UMAC is optimised for 32bit architectures... > > are there any plans to integrate a VMAC algo? > I considered it, but decided I didn't want to further expand the > algorithm zoo we already have. UMAC is plenty fast and the trend > is towards AEAD ciphers (authenticated encryption with associated > data) like AES-GCM or the Chacha20+Poly1305 construct. VMAC could > be used to be build one; Chacha20+VMAC might have been interesting > and would have been faster than Chacha20+Poly1305, but everybody > is currently high on Daniel J. Bernstein's primitives, and while > U/VMAC are fast, they aren't pretty. *shrug* I see... Well, let's hope it pays off, that people are high on DJB primitives ;) > "The original key agreement methods defined in the transport protocol use > fixed, well-known groups for the Diffie-Hellman algorithm. This method > allows a server to use a set of locally configured groups, and the > client to request a preferred group size." (RFC4419) Thanks,... even found that out later on myslef O;-) > > 11) How would one order them based on security? > > I'd probably go for: > > curve25519-sha256 at libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha= > > 2-nistp256,diffie-hellman-group-exchange-sha256, > > Strength-wise, Curse25519 compares to NIST-P256, so it depends how > you feel about the NIST curves. So you said it uses SHA2 as well,... is there going to be an alternative that uses Keccak? Or one which is, from the key size POV, more int eh P521 range? > As per the commit message: > Revised certificate format ssh-{dss,rsa}-cert-v01 at openssh.com with the > following changes: > * Move the nonce field to the beginning of the certificate where it can > better protect against chosen-prefix attacks on the signature hash > * Rename "constraints" field to "critical options" > * Add a new non-critical "extensions" field > * Add a serial number So basically, when I don't have interoperability issues (people using the v.00 certs) it's probably better to disable them. > > The manpage says "If hostkeys are known for the destination host then > > this default is modified to prefer their algorithms." > > But does that mean it modifies the ordering, even when I manually set > > something? > > If you connect to a host, the default server key type is > ecdsa-sha2-nistp256, and if you connect to a host for the first > time, that key will be saved in known_hosts. However, if known_hosts > already contains a different type of key, that one will be chosen > instead. > > I have ssh-ed25519 keys in my known_hosts file for all destination > hosts that support it, and this key will be picked to authenticate > the host (instead of ecdsa-sha2-nistp256). No explicit setting of > HostKeyAlgorithms is required. Okay,... now I get what it means... was on a completely different lead (though hostkeys really means "non-certificate" keys here). > So true. IPsec got it right. SSL got it wrong and that decision > keeps on giving, see this week's POODLE excitement. SSH has gotten > better. Jup,... tightening my servers' TLS is probably the next thing to go for,... unfortunately things seem to be a lot more confusing there. Most of my services (apache, postfix, and that like) use OpenSSL,... one has nothing (yet) like Curve25519 or Chacha2,... OpenSSL also seems to have anonymous [EC]DH and non-ephemeral [EC]DH cipher suites... so it's a bit tricky to determine to best cipher selection string ;) And it seems one mostly cannot configure the DH params... :( Cheers & 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 calestyo at scientia.net Mon Oct 20 07:15:25 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sun, 19 Oct 2014 22:15:25 +0200 Subject: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters In-Reply-To: References: <1413651497.4721.3.camel@scientia.net> Message-ID: <1413749725.6290.5.camel@scientia.net> On Sun, 2014-10-19 at 17:07 +0000, Christian Weisgerber wrote: > > Just out of curiosity,... what is done to make the the DH authenticated? > > I guess it depends on the chosen HostKeyAlogrithm (so either RSA, DSS, > > ECDSA or EdDSA)... but do client/server exchange the DH parameters > > signed or doe they exchange a signed version of the agreed key? > https://tools.ietf.org/html/rfc4253#section-8 So it's basically the signature s over H, which includes amongst others K from the server. Why is there never a step, in which the server S somehow verifies that e actually comes from C (i.e. authenticating C)? > > a) Documentations seems to imply that this is only used by sshd? > > So how does the ssh client come to his accepted parameters? Does he > > simply take anything a SSH server proposes? > > The client sends the minimal/preferred/maximal group size, and the > server picks a group and responds with the modulus and generator > for the group. > https://tools.ietf.org/html/rfc4419 So with DH group exchange, I have no way to tell the client to only accept larger groups, or is there any configuration option where I can say, e.g. minimal=4096 or whatever? Wouldn't it be nice to have an option to set min/pref/max? And it basically also means, the client checks just for the group size,... and has no way to accept/reject certain moduli? Now for ECDH, we know that some curves may be insecure,... is the same known for DH? I.e. could a server accidentally propose the client an insecure moduli (which the client takes without any check except for the group size)? > > b) How can I restrict what the server accepts as parameters? > > E.g. if I think 1024 bit groups are to weak, can I simply remove those > > entries from the moduli file and such groups will no longer be used? > > If the server doesn't find (a suitable group in) /etc/moduli, it > will fall back to the group from diffie-hellman-group14-sha1. So that means, that even when I have diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 disabled... and when I only have e.g. 8129 bit groups in /etc/ssh/moduli... It will still fall back to using the "weak" groups from diffie-hellman-group14-sha1? Wouldn't it be good to have an option to disable this fallback? So in other words, as soon as I have normal DH kex algos enabled, I can neither force the client (who will anyway accept what the server gives him in the min/max range) nor the server to use "stronger" groups, and they'll always fall back to at least the - what was it? - 2048bit group from diffie-hellman-group14-sha1. 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 plsuh at goodeast.com Mon Oct 20 13:56:14 2014 From: plsuh at goodeast.com (Paul Suh) Date: Sun, 19 Oct 2014 22:56:14 -0400 Subject: Problem logging in over GRE/IPSec tunnel? Message-ID: <1BCD061E-FADD-41BC-99C2-5B12D2381B92@goodeast.com> Hello, First time posting here, but I?ve been using OpenBSD for since 2.7 or so. I hope this is the right place to ask. Anyway, I?m running into a puzzler. I have an OpenBSD 5.5 system in a data center and a second OpenBSD 5.5 router at my apartment. I set up a GRE over IPSec tunnel from my apartment?s private subnet to the data center internal subnet as per the instructions on the gre(4) man page. I can connect to other systems inside the private subnet at the data center via SSH with no problem. If I connect via SSH to an external address of the router (which does not pass through the tunnel), everything functions as expected. I double-checked that this connection does not go through the tunnel by sniffing traffic on enc0. If I connect via SSH to the internal address of the router (through the tunnel, confirmed by tcpdump on enc0), the connection fails with the error message on the client system: > Read from socket failed: Connection reset by peer When I use -vvv on the connection attempt, the log looks like: > Paul-Suh-Core-i5:~ plsuh$ ssh -vvv locadmin at 192.168.140.251 > OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 > debug1: Reading configuration data /etc/ssh_config > debug1: /etc/ssh_config line 20: Applying options for * > debug1: /etc/ssh_config line 53: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 192.168.140.251 [192.168.140.251] port 22. > debug1: Connection established. > debug3: Incorrect RSA1 identifier > debug3: Could not load "/Users/plsuh/.ssh/id_rsa" as a RSA1 public key > debug1: identity file /Users/plsuh/.ssh/id_rsa type 1 > debug1: identity file /Users/plsuh/.ssh/id_rsa-cert type -1 > debug3: Incorrect RSA1 identifier > debug3: Could not load "/Users/plsuh/.ssh/id_dsa" as a RSA1 public key > debug1: identity file /Users/plsuh/.ssh/id_dsa type 2 > debug1: identity file /Users/plsuh/.ssh/id_dsa-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.2 > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 > debug1: match: OpenSSH_6.6.1 pat OpenSSH* > debug2: fd 3 setting O_NONBLOCK > debug3: load_hostkeys: loading entries for host "192.168.140.251" from file "/Users/plsuh/.ssh/known_hosts" > debug2: key_type_from_name: unknown key type 'ecdsa-sha2-nistp256' > debug3: key_read: missing keytype > debug3: load_hostkeys: loaded 0 keys > debug1: SSH2_MSG_KEXINIT sent > Read from socket failed: Connection reset by peer > Paul-Suh-Core-i5:~ plsuh$ ssh -vvv locadmin at 192.168.140.1 On the server, I get this line in /var/log/authlog: > Oct 19 22:42:17 ravelin sshd[5880]: fatal: Read from socket failed: Connection reset by peer [preauth] I tried moving aside the ~/.ssh/known_hosts file, but the behavior is the same. In the debug trace the line "debug2: key_type_from_name: unknown key type 'ecdsa-sha2-nistp256'? is missing, but other than that nothing changed. I don?t understand how connecting to the same system, to the same sshd instance -- one way works, the other doesn?t. Client is OS X 10.9.5, OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011. Any ideas? ?Paul FYI - the debug trace from a successful connection > Paul-Suh-Core-i5:~ plsuh$ ssh -vvv -p 2022 locadmin at ravelin-ext.goodeast.com > OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011 > debug1: Reading configuration data /etc/ssh_config > debug1: /etc/ssh_config line 20: Applying options for * > debug1: /etc/ssh_config line 53: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to ravelin-ext.goodeast.com [209.190.244.103] port 2022. > debug1: Connection established. > debug3: Incorrect RSA1 identifier > debug3: Could not load "/Users/plsuh/.ssh/id_rsa" as a RSA1 public key > debug1: identity file /Users/plsuh/.ssh/id_rsa type 1 > debug1: identity file /Users/plsuh/.ssh/id_rsa-cert type -1 > debug3: Incorrect RSA1 identifier > debug3: Could not load "/Users/plsuh/.ssh/id_dsa" as a RSA1 public key > debug1: identity file /Users/plsuh/.ssh/id_dsa type 2 > debug1: identity file /Users/plsuh/.ssh/id_dsa-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.2 > debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1 > debug1: match: OpenSSH_6.6.1 pat OpenSSH* > debug2: fd 3 setting O_NONBLOCK > debug3: put_host_port: [ravelin-ext.goodeast.com]:2022 > debug3: load_hostkeys: loading entries for host "[ravelin-ext.goodeast.com]:2022" from file "/Users/plsuh/.ssh/known_hosts" > debug3: load_hostkeys: found key type RSA in file /Users/plsuh/.ssh/known_hosts:251 > debug3: load_hostkeys: loaded 1 keys > debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-rsa > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-rsa,ssh-dss-cert-v01 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-dss > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_setup: found hmac-md5-etm at openssh.com > debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none > debug2: mac_setup: found hmac-md5-etm at openssh.com > debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug2: dh_gen_key: priv key bits set: 129/256 > debug2: bits set: 520/1024 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Server host key: RSA 97:df:ac:ab:c2:05:af:01:68:61:32:65:18:5a:f8:81 > debug3: put_host_port: [209.190.244.103]:2022 > debug3: put_host_port: [ravelin-ext.goodeast.com]:2022 > debug3: load_hostkeys: loading entries for host "[ravelin-ext.goodeast.com]:2022" from file "/Users/plsuh/.ssh/known_hosts" > debug3: load_hostkeys: found key type RSA in file /Users/plsuh/.ssh/known_hosts:251 > debug3: load_hostkeys: loaded 1 keys > debug3: load_hostkeys: loading entries for host "[209.190.244.103]:2022" from file "/Users/plsuh/.ssh/known_hosts" > debug3: load_hostkeys: found key type RSA in file /Users/plsuh/.ssh/known_hosts:250 > debug3: load_hostkeys: loaded 1 keys > debug1: Host '[ravelin-ext.goodeast.com]:2022' is known and matches the RSA host key. > debug1: Found key in /Users/plsuh/.ssh/known_hosts:251 > debug2: bits set: 498/1024 > debug1: ssh_rsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: Roaming not allowed by server > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: /Users/plsuh/.ssh/id_rsa (0x7fe2b940b6e0), > debug2: key: /Users/plsuh/.ssh/id_dsa (0x7fe2b940bde0), > debug1: Authentications that can continue: publickey,password,keyboard-interactive > debug3: start over, passed a different list publickey,password,keyboard-interactive > debug3: preferred publickey,keyboard-interactive,password > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering RSA public key: /Users/plsuh/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Server accepts key: pkalg ssh-rsa blen 533 > debug2: input_userauth_pk_ok: fp d9:b9:38:41:b2:bd:ec:6d:15:4b:36:3a:12:4b:57:12 > debug3: sign_and_send_pubkey: RSA d9:b9:38:41:b2:bd:ec:6d:15:4b:36:3a:12:4b:57:12 > debug1: Authentication succeeded (publickey). > Authenticated to ravelin-ext.goodeast.com ([209.190.244.103]:2022). > debug1: channel 0: new [client-session] > debug3: ssh_session2_open: channel_new: 0 > debug2: channel 0: send open > debug1: Requesting no-more-sessions at openssh.com > debug1: Entering interactive session. > debug2: callback start > debug2: fd 3 setting TCP_NODELAY > debug3: packet_set_tos: set IP_TOS 0x10 > debug2: client_session2_setup: id 0 > debug2: channel 0: request pty-req confirm 1 > debug1: Sending environment. > debug3: Ignored env TERM_PROGRAM > debug3: Ignored env SHELL > debug3: Ignored env TERM > debug3: Ignored env TMPDIR > debug3: Ignored env Apple_PubSub_Socket_Render > debug3: Ignored env TERM_PROGRAM_VERSION > debug3: Ignored env TERM_SESSION_ID > debug3: Ignored env USER > debug3: Ignored env SSH_AUTH_SOCK > debug3: Ignored env __CF_USER_TEXT_ENCODING > debug3: Ignored env PATH > debug3: Ignored env __CHECKFIX1436934 > debug3: Ignored env PWD > debug3: Ignored env DBUS_LAUNCHD_SESSION_BUS_SOCKET > debug1: Sending env LANG = en_US.UTF-8 > debug2: channel 0: request env confirm 0 > debug3: Ignored env SHLVL > debug3: Ignored env HOME > debug3: Ignored env LOGNAME > debug3: Ignored env DISPLAY > debug3: Ignored env _ > debug2: channel 0: request shell confirm 1 > debug2: callback done > debug2: channel 0: open confirm rwindow 0 rmax 32768 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: PTY allocation request accepted on channel 0 > debug2: channel 0: rcvd adjust 2097152 > debug2: channel_input_status_confirm: type 99 id 0 > debug2: shell request accepted on channel 0 > Last login: Sun Oct 19 20:02:46 2014 from 24.231.37.237 > OpenBSD 5.5-stable (FLASHRD.MP) #1: Mon Jun 9 09:53:13 EDT 2014 > > Welcome to OpenBSD: The proactively secure Unix-like operating system. > > Please use the sendbug(1) utility to report bugs in the system. > Before reporting a bug, please try to reproduce it with the latest > version of the code. With bug reports, please try to ensure that > enough information to reproduce the problem is enclosed, and if a > known fix for it exists, include that as well. > > $ > From djm at mindrot.org Mon Oct 20 14:08:05 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 20 Oct 2014 14:08:05 +1100 (EST) Subject: Problem logging in over GRE/IPSec tunnel? In-Reply-To: <1BCD061E-FADD-41BC-99C2-5B12D2381B92@goodeast.com> References: <1BCD061E-FADD-41BC-99C2-5B12D2381B92@goodeast.com> Message-ID: On Sun, 19 Oct 2014, Paul Suh wrote: > Hello, > > First time posting here, but I?ve been using OpenBSD for since 2.7 or > so. I hope this is the right place to ask. > > Anyway, I?m running into a puzzler. [...] > On the server, I get this line in /var/log/authlog: > > > Oct 19 22:42:17 ravelin sshd[5880]: fatal: Read from socket failed: > > Connection reset by peer [preauth] Whatever the problem is, it's happening at a lower level than ssh/sshd. Can you connect the the sshd using telnet or netcat from the client? If not, then that's your problem. If so, then the problem is more subtle. In the absence of further information, I'd expect a MTU blackhole in one/both directions, since the KEXINIT packet is likely to be the first bit of data sent that is >1KB. You might be able to check this using ping's size and don't-fragment options (make sure you test both the client->server and server->client directions). -d From plsuh at goodeast.com Mon Oct 20 14:51:42 2014 From: plsuh at goodeast.com (Paul Suh) Date: Sun, 19 Oct 2014 23:51:42 -0400 Subject: Problem logging in over GRE/IPSec tunnel? In-Reply-To: References: <1BCD061E-FADD-41BC-99C2-5B12D2381B92@goodeast.com> Message-ID: <4E5FF9D1-325F-4E77-9D25-D870E6EA085C@goodeast.com> On Oct 19, 2014, at 11:08 PM, Damien Miller wrote: > On Sun, 19 Oct 2014, Paul Suh wrote: > >> Hello, >> >> First time posting here, but I?ve been using OpenBSD for since 2.7 or >> so. I hope this is the right place to ask. >> >> Anyway, I?m running into a puzzler. > > [...] > >> On the server, I get this line in /var/log/authlog: >> >>> Oct 19 22:42:17 ravelin sshd[5880]: fatal: Read from socket failed: >>> Connection reset by peer [preauth] > > Whatever the problem is, it's happening at a lower level than ssh/sshd. > > Can you connect the the sshd using telnet or netcat from the client? > If not, then that's your problem. > > If so, then the problem is more subtle. In the absence of further > information, I'd expect a MTU blackhole in one/both directions, > since the KEXINIT packet is likely to be the first bit of data sent > that is >1KB. You might be able to check this using ping's size > and don't-fragment options (make sure you test both the client->server > and server->client directions). Damien, I can connect to port 22 via telnet and get the "SSH-2.0-OpenSSH_6.6.1? response, so it?s something more subtle. Sweep pings fail at the MTU, 1476, both directions. There is some sort of flakiness when I set the packet size to 1460 or 1450, as the first three or four packets will go through, then I get errors back from the router. I tried cranking the MTU for the path down to 1400 in both directions using the route(8) command, but that doesn?t seem to help. Thanks for any pointers that you can give me. ?Paul From djm at mindrot.org Mon Oct 20 15:08:41 2014 From: djm at mindrot.org (Damien Miller) Date: Mon, 20 Oct 2014 15:08:41 +1100 (EST) Subject: Problem logging in over GRE/IPSec tunnel? In-Reply-To: <4E5FF9D1-325F-4E77-9D25-D870E6EA085C@goodeast.com> References: <1BCD061E-FADD-41BC-99C2-5B12D2381B92@goodeast.com> <4E5FF9D1-325F-4E77-9D25-D870E6EA085C@goodeast.com> Message-ID: On Sun, 19 Oct 2014, Paul Suh wrote: > > If so, then the problem is more subtle. In the absence of further > > information, I'd expect a MTU blackhole in one/both directions, > > since the KEXINIT packet is likely to be the first bit of data sent > > that is >1KB. You might be able to check this using ping's size > > and don't-fragment options (make sure you test both the client->server > > and server->client directions). I was probably mistaken in my speculation - the connection isn't hanging like you'd expect from a PMTU blackhole but both ends are getting TCP reset ('connection reset by peer') I'd check any packet filter logs and, if they are empty, watch a connection with tcpdump to see where the resets are coming from. From naddy at mips.inka.de Wed Oct 22 07:43:28 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Tue, 21 Oct 2014 20:43:28 +0000 (UTC) Subject: some questions on OpenSSH alogs References: <1413650129.4721.1.camel@scientia.net> <1413741769.6290.1.camel@scientia.net> Message-ID: On 2014-10-19, Christoph Anton Mitterer wrote: > Mhh sure,... but is there any advantage (apart from performance and ease > of implementation), of using an AE cipher instead of an encrypting-only > cipher in combination with a MAC? Nope. > So for ED25519 and ECDH with the NIST curves... all the DH parameters > and sizes are fixed anyway, right? Right. This is a good thing. It means there is no need or opportunity for people to compulsively fiddle with parameters and shoot themselves in the foot. >> Poly1305, U/VMAC, and GMAC all run the data through a noncryptographic >> hash and encrypt the result with AES. > How important is the size there? I mean umac-128 and especially -64 > sounds little in comparison to the hash sizes of e.g. sha2-512 with > HMAC. A priori, the probability of a successful forgery with an n-bit authentication tag is 1/2^n. The question is if attack strategies can improve on this. RFC4418 gives a boundary of 1/2^60 for UMAC-64. An important consideration is that the SSH protocol severely limits the number of possible forgery attempts: If MAC verification fails, the session is killed. Attacks that require a substantial number of verification queries, as discussed for instance here http://link.springer.com/chapter/10.1007%2F978-3-540-85174-5_9 are not applicable. >> Strength-wise, Curse25519 compares to NIST-P256, so it depends how >> you feel about the NIST curves. > So you said it uses SHA2 as well,... is there going to be an alternative > that uses Keccak? The Curve25519 key exchange and Ed25519 signing could be replaced with analogous schemes that swap SHA2 for SHA3, yes. I doubt anybody will bother until SHA2 is shown to be weak. > Or one which is, from the key size POV, more int eh P521 range? Curve25519/Ed25519 are good enough. Let's regain some perspective here: The purpose of SSH is to provide mutually authenticated and confidential remote login/command execution/ data transfer. It is not intended to be a comprehensive collection of cryptographic algorithms. It is supposed to just work and not require tweaking and magic incantations. "Buttons are for idiots", "knobs are for knobs", etc. -- Christian "naddy" Weisgerber naddy at mips.inka.de From naddy at mips.inka.de Wed Oct 22 08:15:43 2014 From: naddy at mips.inka.de (Christian Weisgerber) Date: Tue, 21 Oct 2014 21:15:43 +0000 (UTC) Subject: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters References: <1413651497.4721.3.camel@scientia.net> <1413749725.6290.5.camel@scientia.net> Message-ID: On 2014-10-19, Christoph Anton Mitterer wrote: >> https://tools.ietf.org/html/rfc4253#section-8 > So it's basically the signature s over H, which includes amongst others > K from the server. > Why is there never a step, in which the server S somehow verifies that e > actually comes from C (i.e. authenticating C)? That's just the overall protocol design. There is no client authentication at this stage, only server authentication. Client authentication happens in the SSH authentication protocol https://tools.ietf.org/html/rfc4252 Typical client authentication relies on the user's public key or password. What would be gained by authenticating the client's host? >> https://tools.ietf.org/html/rfc4419 > > So with DH group exchange, I have no way to tell the client to only > accept larger groups, or is there any configuration option where I can > say, e.g. minimal=4096 or whatever? No. > Wouldn't it be nice to have an option to set min/pref/max? No. > And it basically also means, the client checks just for the group > size,... and has no way to accept/reject certain moduli? > Now for ECDH, we know that some curves may be insecure,... is the same > known for DH? I.e. could a server accidentally propose the client an > insecure moduli (which the client takes without any check except for the > group size)? What is your attack scenario here? If the server can't be trusted, your session isn't protected. That is trivial. Hey, the server might accidentally use a weak random number generator. That isn't even hypothetical. -- Christian "naddy" Weisgerber naddy at mips.inka.de From tomas.kuthan at oracle.com Wed Oct 22 17:38:21 2014 From: tomas.kuthan at oracle.com (Tomas Kuthan) Date: Wed, 22 Oct 2014 08:38:21 +0200 Subject: Portable OpenSSH source repository switched to git In-Reply-To: References: Message-ID: <544750DD.1070407@oracle.com> On 10/07/14 12:48, Damien Miller wrote: > Hi, > > Now that the 6.7 release is out, we're switching the portable OpenSSH > development repository from CVS to git. The public CVS rsync and > ViewVC will not be updated and will soon be switched off. > > Public git mirrors can be found at: > > https://anongit.mindrot.org/openssh.git/ > https://github.com/openssh/openssh-portable.git > > Both allow source browsing and clone. Please report any problems to > myself and/or this list and bear with us while we make the inevitable > bumbles as we adjust our workflow. Hi, Reporting Bugs [1] still list attaching a patch to Bugzilla bug as the only way to contribute code. Are there plans to accept git pull requests? Thanks, Tomas [1] http://www.openssh.com/report.html From djm at mindrot.org Wed Oct 22 21:06:51 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 22 Oct 2014 21:06:51 +1100 (EST) Subject: Portable OpenSSH source repository switched to git In-Reply-To: <544750DD.1070407@oracle.com> References: <544750DD.1070407@oracle.com> Message-ID: On Wed, 22 Oct 2014, Tomas Kuthan wrote: > Hi, > > Reporting Bugs [1] still list attaching a patch to Bugzilla bug as the only > way to contribute code. > > Are there plans to accept git pull requests? I've received a few already, but I'd prefer people create bugs. If you want to create a bug containing just a brief description and link to the pull request, that's fine though. -d From fergalme at gmail.com Wed Oct 22 23:58:36 2014 From: fergalme at gmail.com (Fergal Meath) Date: Wed, 22 Oct 2014 13:58:36 +0100 Subject: tun channel FDs changed to -1? Message-ID: 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 dkg at fifthhorseman.net Thu Oct 23 20:58:43 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 23 Oct 2014 11:58:43 +0200 Subject: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters In-Reply-To: References: <1413651497.4721.3.camel@scientia.net> <1413749725.6290.5.camel@scientia.net> Message-ID: <874muv3y5o.fsf@alice.fifthhorseman.net> On Tue 2014-10-21 23:15:43 +0200, Christian Weisgerber wrote: > On 2014-10-19, Christoph Anton Mitterer wrote: >> And it basically also means, the client checks just for the group >> size,... and has no way to accept/reject certain moduli? >> Now for ECDH, we know that some curves may be insecure,... is the same >> known for DH? I.e. could a server accidentally propose the client an >> insecure moduli (which the client takes without any check except for the >> group size)? > > What is your attack scenario here? If the server can't be trusted, > your session isn't protected. That is trivial. > > Hey, the server might accidentally use a weak random number generator. > That isn't even hypothetical. Christoph is pointing out that the client might actually have a way to verify that the group is strong. The client doesn't have a way to know if the server is using a weak rng. For weaknesses that are detectable by the client, it does make sense that the client should be willing to detect and abort the session before compromising it. We already allow clients to constrain the set of choosable ciphers, for example, so clients who talk to a misconfigured/old/busted server that tries to select arcfour can reject the connection. It's not implausible that a client would also want to reject a server that offers an obviously non-prime DH modulus,, or a server's ephemeral DH public key if it is clearly bad (e.g. p-1 or 1). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From djm at mindrot.org Fri Oct 24 11:40:31 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 24 Oct 2014 11:40:31 +1100 (EST) Subject: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters In-Reply-To: <874muv3y5o.fsf@alice.fifthhorseman.net> References: <1413651497.4721.3.camel@scientia.net> <1413749725.6290.5.camel@scientia.net> <874muv3y5o.fsf@alice.fifthhorseman.net> Message-ID: On Thu, 23 Oct 2014, Daniel Kahn Gillmor wrote: > For weaknesses that are detectable by the client, it does make sense > that the client should be willing to detect and abort the session > before compromising it. > > We already allow clients to constrain the set of choosable ciphers, > for example, so clients who talk to a misconfigured/old/busted server > that tries to select arcfour can reject the connection. It's not > implausible that a client would also want to reject a server that > offers an obviously non-prime DH modulus, Checking for trivially non-prime is easy and maybe worthwhile to catch broken implementations, but IMO there's little point when "subtly non-prime" is still too expensive for the client to check - even a few Miller-Rabin checks are too slow at the prime sizes required for reasonable security in modp groups. Moreover, there are many, many ways for an evil server to compromise the connection that are completely undetectable (e.g. leak an encrypted copy of the server's PRNG key in the KEXINIT cookie field). I'd rather people use one of the EC DH modes - they are waaay faster for the same security level. > or a server's ephemeral DH public key if it is clearly bad (e.g. p-1 > or 1). dh.c:dh_pub_is_valid() does this for modp values sshkey.c:sshkey_ec_validate_public() does it for EC values (which AFAIK are more sensitive for the NIST curve types) -d PS. it's amusing to see similar paranoia that motivated DH-GEX echoed in the recent criticism of the NIST EC groups... From calestyo at scientia.net Fri Oct 24 13:37:01 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 24 Oct 2014 04:37:01 +0200 Subject: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters In-Reply-To: References: <1413651497.4721.3.camel@scientia.net> <1413749725.6290.5.camel@scientia.net> Message-ID: <1414118221.15807.13.camel@scientia.net> On Tue, 2014-10-21 at 21:15 +0000, Christian Weisgerber wrote: > > Why is there never a step, in which the server S somehow verifies that e > > actually comes from C (i.e. authenticating C)? > That's just the overall protocol design. There is no client > authentication at this stage, only server authentication. > Client authentication happens in the SSH authentication protocol > https://tools.ietf.org/html/rfc4252 > Typical client authentication relies on the user's public key or > password. What would be gained by authenticating the client's host? I rather wondered here, how one defends against Mallory at this stage of the DH handshake... but it's probably enough to check at either client or server side that e respectively f is from the authenticated Alice or Bob, in order to prevent MitM, right? Cause already if one side notices the attack, the handshake won't complete. > > Wouldn't it be nice to have an option to set min/pref/max? > No. Well why not? There what's the current value for min/max? #define DH_GRP_MIN 1024 #define DH_GRP_MAX 8192 Right? When you go for the ECRYPT II estimations, 1024 is only enough for the very short term. Of course an "evil" server can just always publish your data, stronger DH params or not... but I think the question is mainly about avoiding "accidental" weak defaults. And 8192 is at least to small for the forseeable future. Now I understand that there is this limit from the RFC, but AFAICS this is only a suggested limit and not a hard one, isn't it? > What is your attack scenario here? If the server can't be trusted, > your session isn't protected. That is trivial. See above: it's all about simple checks against weak defaults. If this wouldn't make sense, then one could also set min=0 and simply blindly trust the server. > Hey, the server might accidentally use a weak random number generator. > That isn't even hypothetical. Sure, but that's nothing we could check. 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 Fri Oct 24 13:46:45 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 24 Oct 2014 04:46:45 +0200 Subject: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters In-Reply-To: <874muv3y5o.fsf@alice.fifthhorseman.net> References: <1413651497.4721.3.camel@scientia.net> <1413749725.6290.5.camel@scientia.net> <874muv3y5o.fsf@alice.fifthhorseman.net> Message-ID: <1414118805.15807.16.camel@scientia.net> On Thu, 2014-10-23 at 11:58 +0200, Daniel Kahn Gillmor wrote: > Christoph is pointing out that the client might actually have a way to > verify that the group is strong. Well that's even already one step ahead, my main point was, that right now I have (AFAIU) not really a chance to disallow weak groups (in the sense of size) at both sides - server and client. OpenSSH's ssh will accept 1024 (which I personally would feel more comfortable if I could harden it, and e.g. only selectively allow smaller groups for older server's I'm speaking to). And AFAIU Christian, the server will always fall back to the 2048bit group from diffie-hellman-group14-sha1, even if I "harden" my sshd's moduli file by removing all smaller groups. But really checking the moduli goes already one step further. 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 Fri Oct 24 13:55:18 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 24 Oct 2014 04:55:18 +0200 Subject: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters In-Reply-To: References: <1413651497.4721.3.camel@scientia.net> <1413749725.6290.5.camel@scientia.net> <874muv3y5o.fsf@alice.fifthhorseman.net> Message-ID: <1414119318.15807.18.camel@scientia.net> On Fri, 2014-10-24 at 11:40 +1100, Damien Miller wrote: > Checking for trivially non-prime is easy and maybe worthwhile to catch > broken implementations, but IMO there's little point when "subtly > non-prime" is still too expensive for the client to check - even a > few Miller-Rabin checks are too slow at the prime sizes required for > reasonable security in modp groups. Perhaps a stupid idea, but most OpenSSH packages seem to simply use the pregenerated moduli file from the sources. Since many people never use anything else then OpenSSH, once could this use as a whitelist for "trusted" moduli, which ssh wouldn't check further. And what do you think about allowing people to specify their min/max acceptible DH group sizes at client/server level? > Moreover, there are many, many ways > for an evil server to compromise the connection that are completely > undetectable (e.g. leak an encrypted copy of the server's PRNG key in > the KEXINIT cookie field). Well as said just before,... it's quite clear, that this is not about protecting against evil servers, which is impossible per se. > I'd rather people use one of the EC DH modes Sure,... but DH isn't broken either,... and I think it never harms to have alternatives. *And* there are still many old clients out in the wild which only support DH. > - they are waaay faster > for the same security level. Shouldn't these have much higher security levels than e.g. DH with a 1024bit group? Cheers, Chris. btw: I made some pull requests on github, largely for documentation stuff, do you notice that there? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From gwartney at gmail.com Tue Oct 28 09:02:55 2014 From: gwartney at gmail.com (G. G.) Date: Mon, 27 Oct 2014 17:02:55 -0500 Subject: Username has a slash at the end Message-ID: One of my unfortunate users decided to put a slash at the end of his username "username/". Is there any way to use ssh to specify that the slash is part of the username? I've tried every combination of escape characters that I can think of but sshd always removes the slash. Examples: ssh -l "username/" ssh "username/"@ ssh 'username/'@ ssh username\/@ ssh -o User="username/" I've tried many more combinations, but have not had any luck. The sshd version is 1:5.1p1-5 and upgrading is not an option. No other remote access is allowed except for this one user, so will have to make a field visit if I can't get it working. Thank you for your time! From nkadel at gmail.com Tue Oct 28 13:54:07 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 27 Oct 2014 22:54:07 -0400 Subject: Username has a slash at the end In-Reply-To: References: Message-ID: On Mon, Oct 27, 2014 at 6:02 PM, G. G. wrote: > One of my unfortunate users decided to put a slash at the end of his > username "username/". Is there any way to use ssh to specify that the slash > is part of the username? I've tried every combination of escape characters > that I can think of but sshd always removes the slash. On which operating system was this allowed???? > Examples: > ssh -l "username/" > ssh "username/"@ > ssh 'username/'@ > ssh username\/@ > ssh -o User="username/" > > I've tried many more combinations, but have not had any luck. The sshd > version is 1:5.1p1-5 and upgrading is not an option. Change the username is probalby your fastest solution. The normal "useradd' commands should have blocked this. > No other remote access is allowed except for this one user, so will have to > make a field visit if I can't get it working. Thank you for your time! > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Tue Oct 28 14:42:35 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 27 Oct 2014 23:42:35 -0400 Subject: Username has a slash at the end In-Reply-To: References: Message-ID: On Mon, Oct 27, 2014 at 6:02 PM, G. G. wrote: > One of my unfortunate users decided to put a slash at the end of his > username "username/". Is there any way to use ssh to specify that the slash > is part of the username? I've tried every combination of escape characters > that I can think of but sshd always removes the slash. I just built stock openssh-5.5p1's on a recent Fedora, and sshd actually accepts it if you manually edit /etc/{passwd,shadow}, both with and without PAM enabled. $ ssh -p 2022 -l "testuser/" localhost Password: [...] USER=testuser/ LOGNAME=testuser/ Sorry, but whatever the problem is, it's not in the stock sshd. There may be some modification in the sshd, or it could be some other problem. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From gwartney at gmail.com Wed Oct 29 00:53:03 2014 From: gwartney at gmail.com (G. G.) Date: Tue, 28 Oct 2014 08:53:03 -0500 Subject: Username has a slash at the end In-Reply-To: References: Message-ID: The operating system is a modified version of debian so there probably are modifications in sshd. Thank you for your responses; I just wanted to make sure I wasn't loosing it. :) On Mon, Oct 27, 2014 at 10:42 PM, Darren Tucker wrote: > On Mon, Oct 27, 2014 at 6:02 PM, G. G. wrote: > >> One of my unfortunate users decided to put a slash at the end of his >> username "username/". Is there any way to use ssh to specify that the >> slash >> is part of the username? I've tried every combination of escape characters >> that I can think of but sshd always removes the slash. > > > I just built stock openssh-5.5p1's on a recent Fedora, and sshd actually > accepts it if you manually edit /etc/{passwd,shadow}, both with and without > PAM enabled. > > $ ssh -p 2022 -l "testuser/" localhost > Password: > [...] > USER=testuser/ > LOGNAME=testuser/ > > Sorry, but whatever the problem is, it's not in the stock sshd. There may > be some modification in the sshd, or it could be some other problem. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From calestyo at scientia.net Wed Oct 29 07:27:03 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Tue, 28 Oct 2014 21:27:03 +0100 Subject: [EC]DH KEx and how to restrict ssh/sshd to secure(er) DH parameters In-Reply-To: <1414119318.15807.18.camel@scientia.net> References: <1413651497.4721.3.camel@scientia.net> <1413749725.6290.5.camel@scientia.net> <874muv3y5o.fsf@alice.fifthhorseman.net> <1414119318.15807.18.camel@scientia.net> Message-ID: <1414528023.9550.1.camel@scientia.net> Hey. Since there was no real conclusion on this, neither against nor clearly in favour, I've opened two tickets for the records: #2302 (https://bugzilla.mindrot.org/show_bug.cgi?id=2302) Asking to not fall back to diffie-hellman-group14-sha1 when this was "explicitly" disabled via the KEX algo preference list of either ssh or sshd. #2303 (https://bugzilla.mindrot.org/show_bug.cgi?id=2303) Asking one to allow to specify the min and max values for DH GEX on the ssh/libssh side. I actually tried to write a small patch for #2303,... but while adding a new config options is quite easy,... correctly feeding min/max values through all the function calls to kexgex[c|s] seems to bit more tricky (I guess one would need to add these to the Kex struct and probably this would also change the ABI of libssh?) 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 ras at anzio.com Thu Oct 30 06:30:11 2014 From: ras at anzio.com (Bob Rasmussen) Date: Wed, 29 Oct 2014 12:30:11 -0700 (PDT) Subject: Incompatibility of configure with recent OpenSSL versions Message-ID: I am attempting to build OpenSSH on a Linux box. In running ./configure, when it tests for OpenSSL compatibility, I get the following: checking OpenSSL header version... 009081cf (OpenSSL 0.9.8zc 15 Oct 2014) checking OpenSSL library version... configure: error: OpenSSL >= 0.9.8f required It would appear that 0.9.8zc is in fact >= 0.9.8f. I believe there is a problem in how the 009081cf is parsed. Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From djm at mindrot.org Thu Oct 30 10:48:27 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 30 Oct 2014 10:48:27 +1100 (EST) Subject: Incompatibility of configure with recent OpenSSL versions In-Reply-To: References: Message-ID: On Wed, 29 Oct 2014, Bob Rasmussen wrote: > I am attempting to build OpenSSH on a Linux box. In running ./configure, when > it tests for OpenSSL compatibility, I get the following: > > checking OpenSSL header version... 009081cf (OpenSSL 0.9.8zc 15 Oct 2014) > checking OpenSSL library version... configure: error: OpenSSL >= 0.9.8f > required > > It would appear that 0.9.8zc is in fact >= 0.9.8f. I believe there is a > problem in how the 009081cf is parsed. I'm surprised it matched - the test is: # Check version is supported. case "$ssl_library_ver" in 0090[[0-7]]*|009080[[0-5]]*) AC_MSG_ERROR([OpenSSL >= 0.9.8f required]) ;; *) ;; esac Are you sure your library matches your header? You can see what configure found by looking at the 'result' line in config.log that follows 'checking OpenSSL library version'. I've altered the error message to include the actual version found. -d From ras at anzio.com Thu Oct 30 11:29:56 2014 From: ras at anzio.com (Bob Rasmussen) Date: Wed, 29 Oct 2014 17:29:56 -0700 (PDT) Subject: Incompatibility of configure with recent OpenSSL versions In-Reply-To: References: Message-ID: I agree, it doesn't look like it should match. Is the conftest.c file left behind somewhere? Below is the relevant section (I think) of the log file. Perhaps the compile warning is a clue. configure:11850: checking OpenSSL library version configure:11889: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized -W sign-compare -Wformat-security -Wno-pointer-sign -fno-strict-aliasing -D_FORTIFY _SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-all -std=gnu99 -fPIE - Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-all -pie conftest.c -lcrypto -lrt -ldl -lutil -lz -lnsl >&5 conftest.c: In function 'main': conftest.c:226: warning: format '%08x' expects type 'unsigned int', but argument 4 has type 'long unsigned int' configure:11889: $? = 0 configure:11889: ./conftest configure:11889: $? = 0 configure:11895: error: OpenSSL >= 0.9.8f required On Thu, 30 Oct 2014, Damien Miller wrote: > On Wed, 29 Oct 2014, Bob Rasmussen wrote: > >> I am attempting to build OpenSSH on a Linux box. In running ./configure, when >> it tests for OpenSSL compatibility, I get the following: >> >> checking OpenSSL header version... 009081cf (OpenSSL 0.9.8zc 15 Oct 2014) >> checking OpenSSL library version... configure: error: OpenSSL >= 0.9.8f >> required >> >> It would appear that 0.9.8zc is in fact >= 0.9.8f. I believe there is a >> problem in how the 009081cf is parsed. > > I'm surprised it matched - the test is: > > # Check version is supported. > case "$ssl_library_ver" in > 0090[[0-7]]*|009080[[0-5]]*) > AC_MSG_ERROR([OpenSSL >= 0.9.8f required]) > ;; > *) ;; > esac > > Are you sure your library matches your header? You can see what configure > found by looking at the 'result' line in config.log that follows > 'checking OpenSSL library version'. > > I've altered the error message to include the actual version found. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > Regards, ....Bob Rasmussen, President, Rasmussen Software, Inc. personal e-mail: ras at anzio.com company e-mail: rsi at anzio.com voice: (US) 503-624-0360 (9:00-6:00 Pacific Time) fax: (US) 503-624-0760 web: http://www.anzio.com street address: Rasmussen Software, Inc. 10240 SW Nimbus, Suite L9 Portland, OR 97223 USA From djm at mindrot.org Thu Oct 30 12:37:42 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 30 Oct 2014 12:37:42 +1100 (EST) Subject: Incompatibility of configure with recent OpenSSL versions In-Reply-To: References: Message-ID: On Wed, 29 Oct 2014, Bob Rasmussen wrote: > I agree, it doesn't look like it should match. > > Is the conftest.c file left behind somewhere? > > Below is the relevant section (I think) of the log file. Perhaps the compile > warning is a clue. No, unfortunately I was mistaken - it is the previous test that includes the version number. You could try the patch that I just committed to see what is going wrong: commit 7d0ba5336651731949762eb8877ce9e3b52df436 Author: Damien Miller Date: Thu Oct 30 10:45:41 2014 +1100 include version number in OpenSSL-too-old error diff --git a/configure.ac b/configure.ac index 67c4486..8b59d91 100644 --- a/configure.ac +++ b/configure.ac @@ -2296,7 +2296,7 @@ AC_RUN_IFELSE( # Check version is supported. case "$ssl_library_ver" in 0090[[0-7]]*|009080[[0-5]]*) - AC_MSG_ERROR([OpenSSL >= 0.9.8f required]) + AC_MSG_ERROR([OpenSSL >= 0.9.8f required (have "$ssl_library_ver")]) ;; *) ;; esac From calestyo at scientia.net Fri Oct 31 10:56:57 2014 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Fri, 31 Oct 2014 00:56:57 +0100 Subject: ssh_config way to run command before connecting or "around" the connection? Message-ID: <1414713417.4581.2.camel@scientia.net> Hi. Is there a way via ssh_config (i.e. not talking about shell script wrappers around ssh, which of course could somehow do the job) to start a command before ssh connects? I think about e.g. a command (or series of commands) that does provide the necessary credentials (e.g. kinit, aklog) or perhaps does some port knocking on the remote server to open up ssh. Even better would be (well especially with looking at kerberos) to have and additional option to have the actual session process started by another command, e.g. k5start[0] or krenew[0]. That would make it much easier to handle connections that go to different realms. Perhaps at least the later can be done with ProxyCommand? Thanks, Chris. [0] http://www.eyrie.org/~eagle/software/kstart/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available URL: From imorgan at nas.nasa.gov Fri Oct 31 11:58:41 2014 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 30 Oct 2014 17:58:41 -0700 Subject: ssh_config way to run command before connecting or "around" the connection? In-Reply-To: <1414713417.4581.2.camel@scientia.net> References: <1414713417.4581.2.camel@scientia.net> Message-ID: <20141031005841.GB6476@linux124.nas.nasa.gov> On Fri, Oct 31, 2014 at 00:56:57 +0100, Christoph Anton Mitterer wrote: > Hi. > > Is there a way via ssh_config (i.e. not talking about shell script > wrappers around ssh, which of course could somehow do the job) to start > a command before ssh connects? > > I think about e.g. a command (or series of commands) that does provide > the necessary credentials (e.g. kinit, aklog) or perhaps does some port > knocking on the remote server to open up ssh. > > > Even better would be (well especially with looking at kerberos) to have > and additional option to have the actual session process started by > another command, e.g. k5start[0] or krenew[0]. > That would make it much easier to handle connections that go to > different realms. > > > Perhaps at least the later can be done with ProxyCommand? > The traditional answer would be "use a shell script or alias." However, in some cases you could probably abuse ProxyCommand to do your bidding -- keeping in mind that its stdio is connected to the ssh process. If you are using the latest OpenSSH, you might also be able to abuse teh "Match exec" support. However, I'm not sure if that will work if the command requires user input. I suspect that it won't. -- Iain Morgan From ag4ve.us at gmail.com Fri Oct 31 21:59:36 2014 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 31 Oct 2014 06:59:36 -0400 Subject: ssh_config way to run command before connecting or "around" the connection? In-Reply-To: <20141031005841.GB6476@linux124.nas.nasa.gov> References: <1414713417.4581.2.camel@scientia.net> <20141031005841.GB6476@linux124.nas.nasa.gov> Message-ID: 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) On Thu, Oct 30, 2014 at 8:58 PM, Iain Morgan wrote: > On Fri, Oct 31, 2014 at 00:56:57 +0100, Christoph Anton Mitterer wrote: >> Hi. >> >> Is there a way via ssh_config (i.e. not talking about shell script >> wrappers around ssh, which of course could somehow do the job) to start >> a command before ssh connects? >> >> I think about e.g. a command (or series of commands) that does provide >> the necessary credentials (e.g. kinit, aklog) or perhaps does some port >> knocking on the remote server to open up ssh. >> >> >> Even better would be (well especially with looking at kerberos) to have >> and additional option to have the actual session process started by >> another command, e.g. k5start[0] or krenew[0]. >> That would make it much easier to handle connections that go to >> different realms. >> >> >> Perhaps at least the later can be done with ProxyCommand? >> > > The traditional answer would be "use a shell script or alias." However, > in some cases you could probably abuse ProxyCommand to do your bidding > -- keeping in mind that its stdio is connected to the ssh process. > > If you are using the latest OpenSSH, you might also be able to abuse teh > "Match exec" support. However, I'm not sure if that will work if the > command requires user input. I suspect that it won't. > > -- > Iain Morgan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev