From dativecase at gmail.com  Fri Sep  2 13:22:49 2011
From: dativecase at gmail.com (Benjamin Myers)
Date: Thu, 1 Sep 2011 22:22:49 -0500
Subject: pkcs and host keys
Message-ID: <CAPKO79sZLa+yAzWEXh=Py0ahytpK8-S8N3ASkQEaFB69LzjD0Q@mail.gmail.com>

Hi Damien,

I see in your asia bsdcon presentation you mentioned the possibility
of storing host keys in PKCS #11.  I'm interested in using a usb rsa
fob for host keys and am interested in this feature.  What's the
current status?  As you said:  root compromise != persistent hostkey
theft.

THanks much,
Ben

From dtucker at zip.com.au  Fri Sep  2 22:33:58 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 2 Sep 2011 22:33:58 +1000
Subject: Call for testing: OpenSSH-5.9
In-Reply-To: <CALDDTe2XZZis2D3BJwM_pROM+i+G7s6QdV+O_-VMLFWU=iy+xw@mail.gmail.com>
References: <alpine.BSO.2.00.1108141014180.23174@natsu.mindrot.org>
 <20110818060840.GB26471@red-sonja>
 <CALDDTe2L9g_PPjo_2FRGv0dx-1oJPNzv7X+shSE_d76NG8j9fQ@mail.gmail.com>
 <CALDDTe2_phViw2Fvh_e6Umq5vFsncEzboqmBpBpBSJ6MGoHcCg@mail.gmail.com>
 <CALDDTe2XZZis2D3BJwM_pROM+i+G7s6QdV+O_-VMLFWU=iy+xw@mail.gmail.com>
Message-ID: <CALDDTe1ughKVJqwZ0zE4AaC-JEL3P84676hL8dUCooN4La_VYQ@mail.gmail.com>

On Mon, Aug 29, 2011 at 6:31 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> On Mon, Aug 29, 2011 at 2:48 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> [...]
>> confirmed: it's poll.
>
> Actually now I'm not sure about that. ?Or rather I still think it's
> poll, but maybe not in the place I originally thought.

OK, I think I have it figured out.  Here's my theory:

1. it's poll()
2. some platforms (eg Solaris) implement select() on top of poll().
Those are the ones where the test fails.
3. platforms that implement select() natively (eg Linux) are the ones that work.
4. the problem is not in atomicio, because poll is only used to
prevent busy-waiting on EAGAIN.  if poll() fails it'll busy-wait on
EAGAIN but otherwise work.  rather, the failure is in the main select
loop.

On Solaris 10 x86 (same test passes for both on Linux):
$ cat selecttest.c
#include <sys/types.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <sys/select.h>
#include <sys/socket.h>
#include <stdio.h>
#include <poll.h>
#include <errno.h>
#include <fcntl.h>

int main(int argc, char **argv)
{
        struct rlimit rl_zero;
        struct pollfd pfd;
        int fd, r, enforce_limit = 0;
        fd_set fds;

        if (argc == 2 && strcmp(argv[1], "limit") == 0)
                enforce_limit = 1;

        fd = open("/dev/null", O_RDONLY);
        FD_ZERO(&fds);
        FD_SET(fd, &fds);

        if (enforce_limit) {
                rl_zero.rlim_cur = rl_zero.rlim_max = 0;
                setrlimit(RLIMIT_FSIZE, &rl_zero);
                setrlimit(RLIMIT_NOFILE, &rl_zero);
        }

        r = select(fd+1, &fds, NULL, NULL, NULL);
        printf("select = %d, error: %s\n", r, strerror(errno));
}
$ gcc selecttest.c ; ./a.out ; ./a.out limit
select = 1, error: Error 0
select = -1, error: Invalid argument

-- 
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 rdugal at certicom.com  Fri Sep  2 21:33:39 2011
From: rdugal at certicom.com (Robert Dugal)
Date: Fri, 2 Sep 2011 07:33:39 -0400
Subject: problems building openssh-5.8p1 on qnx
Message-ID: <7C6BDB4BD9974646856544650C016B8209C8E047@XCH117CNC.rim.net>

I am having trouble figuring out how to build openssh-5.8p1 for QNX 6.5. I am trying to build on linux, cross-compiling for armv7.
If I configure like this:
        configure  CC=ntoarmv7-gcc --host=i686-pc-linux-gnu --target=arm-unknown-nto-qnx6.5.0

then I get these errors:
        sshconnect.o: In function `timeout_connect':
        sshconnect.c:(.text+0x778): undefined reference to `howmany'
        sshconnect.o: In function `ssh_exchange_identification':
        sshconnect.c:(.text+0xe60): undefined reference to `howmany'
        ./libssh.a(channels.o): In function `channel_prepare_select':
        channels.c:(.text+0x60dc): undefined reference to `howmany'
        ./libssh.a(packet.o): In function `packet_read_seqnr':
        packet.c:(.text+0x26d4): undefined reference to `howmany'
        packet.c:(.text+0x27d4): undefined reference to `howmany'
        ./libssh.a(packet.o):packet.c:(.text+0x4100): more undefined references to `howmany' follow



If I manually edit config.h after configure, adding #define MISSING_HOWMANY then I get these errors when I build:
        loginrec.c: In function 'record_failed_login':
        loginrec.c:1700: error: 'struct utmp' has no member named 'ut_host'
        loginrec.c:1700: error: 'struct utmp' has no member named 'ut_host'
        loginrec.c:1708: error: 'struct utmp' has no member named 'ut_addr'
        loginrec.c:1709: error: 'struct utmp' has no member named 'ut_addr'
        loginrec.c:1709: error: 'struct utmp' has no member named 'ut_addr'

I tried adding --disable-utmp --disable-utmpx but that did not change the behavior. I still get the same errors compiling loginrec.c



Here is complete output for the configure:

./configure  --target=arm-unknown-nto-qnx6.5.0 --host=i686-pc-linux-gnu --disable-utmp --disable-utmpx --prefix=/home/builder/openssh CC=ntoarmv7-gcc CPPFLAGS='-I/home/builder/stage/nto/usr/include' LDFLAGS='-L/home/builder/stage/nto/armle-v7/lib -L/home/builder/stage/nto/armle-v7/usr/lib'
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking for i686-pc-linux-gnu-gcc... ntoarmv7-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether ntoarmv7-gcc accepts -g... yes
checking for ntoarmv7-gcc option to accept ISO C89... none needed
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking how to run the C preprocessor... ntoarmv7-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for gawk... gawk
checking how to run the C preprocessor... ntoarmv7-gcc -E
checking for i686-pc-linux-gnu-ranlib... no
checking for ranlib... ranlib
configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet.  If you think this
configuration is useful to you, please write to autoconf at gnu.org.
checking for a BSD-compatible install... /usr/bin/install -c
checking for egrep... (cached) /bin/grep -E
checking for ar... /usr/bin/ar
checking for cat... /bin/cat
checking for kill... /bin/kill
checking for perl5... no
checking for perl... /usr/bin/perl
checking for sed... /bin/sed
checking for ent... no
checking for bash... /bin/bash
checking for ksh... (cached) /bin/bash
checking for sh... (cached) /bin/bash
checking for sh... /bin/sh
checking for groff... /usr/bin/groff
checking for nroff... /usr/bin/nroff
checking for mandoc... no
checking for groupadd... /usr/sbin/groupadd
checking for useradd... /usr/sbin/useradd
checking for pkgmk... no
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for login... /bin/login
checking for passwd... /usr/bin/passwd
checking for inline... inline
checking whether LLONG_MAX is declared... yes
checking if ntoarmv7-gcc supports -Wall... yes
checking if ntoarmv7-gcc supports -Wpointer-arith... yes
checking if ntoarmv7-gcc supports -Wuninitialized... yes
checking if ntoarmv7-gcc supports -Wsign-compare... yes
checking if ntoarmv7-gcc supports -Wformat-security... yes
checking if ntoarmv7-gcc supports -Wno-pointer-sign... yes
checking if ntoarmv7-gcc supports -Wno-unused-result... yes
checking if ntoarmv7-gcc supports -fno-strict-aliasing... yes
checking gcc version... 4.4.2
checking if ntoarmv7-gcc accepts -fno-builtin-memset... yes
checking if ntoarmv7-gcc supports -fstack-protector-all... no
checking if ntoarmv7-gcc supports -fstack-protector... no
checking bstring.h usability... no
checking bstring.h presence... no
checking for bstring.h... no
checking crypt.h usability... no
checking crypt.h presence... no
checking for crypt.h... no
checking crypto/sha2.h usability... no
checking crypto/sha2.h presence... no
checking for crypto/sha2.h... no
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking endian.h usability... no
checking endian.h presence... no
checking for endian.h... no
checking features.h usability... no
checking features.h presence... no
checking for features.h... no
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking floatingpoint.h usability... no
checking floatingpoint.h presence... no
checking for floatingpoint.h... no
checking getopt.h usability... no
checking getopt.h presence... no
checking for getopt.h... no
checking glob.h usability... yes
checking glob.h presence... yes
checking for glob.h... yes
checking ia.h usability... no
checking ia.h presence... no
checking for ia.h... no
checking iaf.h usability... no
checking iaf.h presence... no
checking for iaf.h... no
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking login.h usability... yes
checking login.h presence... yes
checking for login.h... yes
checking maillock.h usability... no
checking maillock.h presence... no
checking for maillock.h... no
checking ndir.h usability... no
checking ndir.h presence... no
checking for ndir.h... no
checking net/if_tun.h usability... yes
checking net/if_tun.h presence... yes
checking for net/if_tun.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking netgroup.h usability... no
checking netgroup.h presence... no
checking for netgroup.h... no
checking pam/pam_appl.h usability... no
checking pam/pam_appl.h presence... no
checking for pam/pam_appl.h... no
checking paths.h usability... yes
checking paths.h presence... yes
checking for paths.h... yes
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking pty.h usability... no
checking pty.h presence... no
checking for pty.h... no
checking readpassphrase.h usability... no
checking readpassphrase.h presence... no
checking for readpassphrase.h... no
checking rpc/types.h usability... yes
checking rpc/types.h presence... yes
checking for rpc/types.h... yes
checking security/pam_appl.h usability... no
checking security/pam_appl.h presence... no
checking for security/pam_appl.h... no
checking sha2.h usability... no
checking sha2.h presence... no
checking for sha2.h... no
checking shadow.h usability... yes
checking shadow.h presence... yes
checking for shadow.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdint.h... (cached) yes
checking for string.h... (cached) yes
checking for strings.h... (cached) yes
checking sys/audit.h usability... no
checking sys/audit.h presence... no
checking for sys/audit.h... no
checking sys/bitypes.h usability... no
checking sys/bitypes.h presence... no
checking for sys/bitypes.h... no
checking sys/bsdtty.h usability... no
checking sys/bsdtty.h presence... no
checking for sys/bsdtty.h... no
checking sys/cdefs.h usability... yes
checking sys/cdefs.h presence... yes
checking for sys/cdefs.h... yes
checking sys/dir.h usability... yes
checking sys/dir.h presence... yes
checking for sys/dir.h... yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking sys/ndir.h usability... no
checking sys/ndir.h presence... no
checking for sys/ndir.h... no
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking sys/prctl.h usability... no
checking sys/prctl.h presence... no
checking for sys/prctl.h... no
checking sys/pstat.h usability... no
checking sys/pstat.h presence... no
checking for sys/pstat.h... no
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking for sys/stat.h... (cached) yes
checking sys/stream.h usability... no
checking sys/stream.h presence... no
checking for sys/stream.h... no
checking sys/stropts.h usability... no
checking sys/stropts.h presence... no
checking for sys/stropts.h... no
checking sys/strtio.h usability... no
checking sys/strtio.h presence... no
checking for sys/strtio.h... no
checking sys/statvfs.h usability... yes
checking sys/statvfs.h presence... yes
checking for sys/statvfs.h... yes
checking sys/sysmacros.h usability... yes
checking sys/sysmacros.h presence... yes
checking for sys/sysmacros.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/timers.h usability... no
checking sys/timers.h presence... no
checking for sys/timers.h... no
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking tmpdir.h usability... no
checking tmpdir.h presence... no
checking for tmpdir.h... no
checking ttyent.h usability... no
checking ttyent.h presence... no
checking for ttyent.h... no
checking ucred.h usability... no
checking ucred.h presence... no
checking for ucred.h... no
checking for unistd.h... (cached) yes
checking usersec.h usability... no
checking usersec.h presence... no
checking for usersec.h... no
checking util.h usability... no
checking util.h presence... no
checking for util.h... no
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking utmp.h usability... yes
checking utmp.h presence... yes
checking for utmp.h... yes
checking utmpx.h usability... no
checking utmpx.h presence... no
checking for utmpx.h... no
checking vis.h usability... yes
checking vis.h presence... yes
checking for vis.h... yes
checking for lastlog.h... no
checking for sys/ptms.h... no
checking for login_cap.h... no
checking for sys/mount.h... yes
checking linux/if_tun.h usability... no
checking linux/if_tun.h presence... no
checking for linux/if_tun.h... no
checking compiler and flags for sanity... configure: WARNING: cross compiling: not checking compiler sanity
checking for yp_match... no
checking for yp_match in -lnsl... no
checking for setsockopt... no
checking for setsockopt in -lsocket... yes
checking for dirname... yes
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking for getspnam... yes
checking for library containing basename... none required
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for deflate in -lz... yes
checking for possibly buggy zlib... configure: WARNING: cross compiling: not checking zlib version
checking for strcasecmp... yes
checking for utimes... yes
checking libutil.h usability... no
checking libutil.h presence... no
checking for libutil.h... no
checking for library containing login... none required
checking for fmt_scaled... no
checking for logout... yes
checking for updwtmp... no
checking for logwtmp... yes
checking for strftime... yes
checking for GLOB_ALTDIRFUNC support... yes
checking for gl_matchc field in glob_t... yes
checking for gl_statv and GLOB_KEEPSTAT extensions for glob... no
checking whether GLOB_NOMATCH is declared... yes
checking whether struct dirent allocates space for d_name... configure: WARNING: cross compiling: assuming BROKEN_ONE_BYTE_DIRENT_D_NAME
checking for /proc/pid/fd directory... yes
checking for arc4random... no
checking for arc4random_buf... no
checking for arc4random_uniform... no
checking for asprintf... no
checking for b64_ntop... no
checking for __b64_ntop... yes
checking for b64_pton... no
checking for __b64_pton... yes
checking for bcopy... yes
checking for bindresvport_sa... yes
checking for clock... yes
checking for closefrom... no
checking for dirfd... yes
checking for fchmod... yes
checking for fchown... yes
checking for freeaddrinfo... yes
checking for fstatvfs... yes
checking for futimes... no
checking for getaddrinfo... yes
checking for getcwd... yes
checking for getgrouplist... yes
checking for getnameinfo... yes
checking for getopt... yes
checking for getpeereid... yes
checking for getpeerucred... no
checking for _getpty... no
checking for getrlimit... yes
checking for getttyent... no
checking for glob... yes
checking for group_from_gid... no
checking for inet_aton... yes
checking for inet_ntoa... yes
checking for inet_ntop... yes
checking for innetgr... no
checking for login_getcapbool... no
checking for md5_crypt... no
checking for memmove... yes
checking for mkdtemp... no
checking for mmap... yes
checking for ngetaddrinfo... no
checking for nsleep... no
checking for ogetaddrinfo... no
checking for openlog_r... no
checking for openpty... yes
checking for poll... yes
checking for prctl... no
checking for pstat... no
checking for readpassphrase... no
checking for realpath... yes
checking for recvmsg... yes
checking for rresvport_af... yes
checking for sendmsg... yes
checking for setdtablesize... no
checking for setegid... yes
checking for setenv... yes
checking for seteuid... yes
checking for setgroupent... no
checking for setgroups... yes
checking for setlogin... no
checking for setpassent... no
checking for setpcred... no
checking for setproctitle... no
checking for setregid... yes
checking for setreuid... yes
checking for setrlimit... yes
checking for setsid... yes
checking for setvbuf... yes
checking for sigaction... yes
checking for sigvec... no
checking for snprintf... yes
checking for socketpair... yes
checking for statfs... no
checking for statvfs... yes
checking for strdup... yes
checking for strerror... yes
checking for strlcat... yes
checking for strlcpy... yes
checking for strmode... no
checking for strnvis... no
checking for strptime... yes
checking for strtonum... no
checking for strtoll... yes
checking for strtoul... yes
checking for swap32... no
checking for sysconf... yes
checking for tcgetpgrp... yes
checking for timingsafe_bcmp... no
checking for truncate... yes
checking for unsetenv... yes
checking for updwtmpx... no
checking for user_from_uid... no
checking for vasprintf... no
checking for vhangup... no
checking for vsnprintf... yes
checking for waitpid... yes
checking for library containing dlopen... none required
checking for gai_strerror... yes
checking for library containing nanosleep... none required
checking whether getrusage is declared... no
checking whether strsep is declared... yes
checking for strsep... yes
checking whether tcsendbreak is declared... yes
checking whether h_errno is declared... yes
checking whether SHUT_RD is declared... yes
checking whether O_NONBLOCK is declared... yes
checking whether writev is declared... yes
checking whether MAXSYMLINKS is declared... yes
checking whether offsetof is declared... yes
checking for setresuid... no
checking for setresgid... no
checking for gettimeofday... yes
checking for time... yes
checking for endutent... yes
checking for getutent... yes
checking for getutid... yes
checking for getutline... yes
checking for pututline... yes
checking for setutent... yes
checking for utmpname... yes
checking for endutxent... no
checking for getutxent... no
checking for getutxid... no
checking for getutxline... no
checking for getutxuser... no
checking for pututxline... no
checking for setutxdb... no
checking for setutxent... no
checking for utmpxname... no
checking for getlastlogxbyname... no
checking for daemon... yes
checking for getpagesize... yes
checking whether snprintf correctly terminates long strings... configure: WARNING: cross compiling: Assuming working snprintf()
checking whether vsnprintf returns correct values on overflow... configure: WARNING: cross compiling: Assuming working vsnprintf()
checking whether snprintf can declare const char *fmt... yes
checking if openpty correctly handles controlling tty... cross-compiling
checking whether getpgrp requires zero arguments... yes
checking OpenSSL header version... configure: WARNING: cross compiling: not checking
checking OpenSSL library version... configure: WARNING: cross compiling: not checking
checking whether OpenSSL's headers match the library... configure: WARNING: cross compiling: not checking
checking if programs using OpenSSL functions will link... yes
checking for RSA_generate_key_ex... yes
checking for DSA_generate_parameters_ex... yes
checking for BN_is_prime_ex... yes
checking for RSA_get_default_method... yes
checking whether OpenSSL has crippled AES support... no
checking if EVP_DigestUpdate returns an int... yes
checking for crypt in -lcrypt... no
checking for SHA256_Update... yes
checking for EVP_sha256... yes
checking whether OpenSSL has complete ECC support... yes
checking for ia_openinfo in -liaf... no
checking whether OpenSSL's PRNG is internally seeded... configure: WARNING: cross compiling: assuming yes
checking for ls... /bin/ls
checking for netstat... /bin/netstat
checking for arp... /usr/sbin/arp
checking for ifconfig... /sbin/ifconfig
checking for jstat... no
checking for ps... /bin/ps
checking for sar... no
checking for w... /usr/bin/w
checking for who... /usr/bin/who
checking for last... /usr/bin/last
checking for lastlog... /usr/bin/lastlog
checking for df... /bin/df
checking for vmstat... /usr/bin/vmstat
checking for uptime... /usr/bin/uptime
checking for ipcs... /usr/bin/ipcs
checking for tail... /usr/bin/tail
checking for long long... yes
checking for unsigned long long... yes
checking for long double... yes
checking for char... yes
checking size of char... 1
checking for short int... yes
checking size of short int... 2
checking for int... yes
checking size of int... 4
checking for long int... yes
checking size of long int... 4
checking for long long int... yes
checking size of long long int... 8
checking for u_int type... yes
checking for intXX_t types... no
checking for intXX_t types in stdint.h... yes
checking for int64_t type... yes
checking for u_intXX_t types... no
checking for u_intXX_t types in sys/socket.h... no
checking for u_int64_t types... no
checking for u_int64_t type in sys/bitypes.h... no
checking for uintXX_t types... no
checking for uintXX_t types in stdint.h... yes
checking for u_char... yes
checking for socklen_t... yes
checking for sig_atomic_t... yes
checking for fsblkcnt_t... yes
checking for fsfilcnt_t... yes
checking for in_addr_t... yes
checking for in_port_t... yes
checking for size_t... yes
checking for ssize_t... yes
checking for clock_t... yes
checking for sa_family_t... yes
checking for pid_t... yes
checking for mode_t... yes
checking for struct sockaddr_storage... yes
checking for struct sockaddr_in6... yes
checking for struct in6_addr... yes
checking for struct sockaddr_in6.sin6_scope_id... yes
checking for struct addrinfo... yes
checking for struct timeval... yes
checking for struct timespec... no
configure: WARNING: cross compiling: Assuming working snprintf()
checking for ut_host field in utmp.h... no
checking for ut_host field in utmpx.h... no
checking for syslen field in utmpx.h... no
checking for ut_pid field in utmp.h... yes
checking for ut_type field in utmp.h... yes
checking for ut_type field in utmpx.h... no
checking for ut_tv field in utmp.h... no
checking for ut_id field in utmp.h... yes
checking for ut_id field in utmpx.h... no
checking for ut_addr field in utmp.h... no
checking for ut_addr field in utmpx.h... no
checking for ut_addr_v6 field in utmp.h... no
checking for ut_addr_v6 field in utmpx.h... no
checking for ut_exit field in utmp.h... yes
checking for ut_time field in utmp.h... yes
checking for ut_time field in utmpx.h... no
checking for ut_tv field in utmpx.h... no
checking for struct stat.st_blksize... yes
checking for struct __res_state.retrans... yes
checking for ss_family field in struct sockaddr_storage... yes
checking for __ss_family field in struct sockaddr_storage... no
checking for pw_class field in struct passwd... no
checking for pw_expire field in struct passwd... no
checking for pw_change field in struct passwd... no
checking for msg_accrights field in struct msghdr... no
checking if struct statvfs.f_fsid is integral type... yes
checking for msg_control field in struct msghdr... yes
checking if libc defines __progname... yes
checking whether ntoarmv7-gcc implements __FUNCTION__... yes
checking whether ntoarmv7-gcc implements __func__... yes
checking whether va_copy exists... yes
checking whether __va_copy exists... no
checking whether getopt has optreset support... no
checking if libc defines sys_errlist... yes
checking if libc defines sys_nerr... yes
checking for library containing getrrsetbyname... no
checking for library containing res_query... none required
checking for library containing dn_expand... none required
checking if res_query will link... yes
checking for _getshort... yes
checking for _getlong... yes
checking whether _getshort is declared... no
checking whether _getlong is declared... no
checking for HEADER.ad... yes
checking if struct __res_state _res is an extern... yes
checking for xauth... /usr/bin/xauth
configure: WARNING: cross compiling: Disabling /dev/ptmx test
configure: WARNING: cross compiling: Disabling /dev/ptc test
checking for nroff... (cached) /usr/bin/nroff
checking if the systems has expire shadow information... yes
configure: WARNING: cross compiling: not checking /etc/default/login
Adding /home/builder/openssh/bin to USER_PATH so scp will work
checking if we need to convert IPv4 in IPv6-mapped addresses... yes (default)
checking if your system defines LASTLOG_FILE... yes
checking if your system defines UTMP_FILE... yes
checking if your system defines WTMP_FILE... yes
checking if your system defines WTMPX_FILE... no
checking whether BROKEN_GETADDRINFO is declared... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating buildpkg.sh
config.status: creating opensshd.init
config.status: creating openssh.xml
config.status: creating openbsd-compat/Makefile
config.status: creating openbsd-compat/regress/Makefile
config.status: creating ssh_prng_cmds
config.status: creating survey.sh
config.status: creating config.h

OpenSSH has been configured with the following options:
                     User binaries: /home/builder/openssh/bin
                   System binaries: /home/builder/openssh/sbin
               Configuration files: /home/builder/openssh/etc
                   Askpass program: /home/builder/openssh/libexec/ssh-askpass
                      Manual pages: /home/builder/openssh/share/man/manX
                          PID file: /var/run
  Privilege separation chroot path: /var/empty
            sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/home/builder/openssh/bin
                    Manpage format: doc
                       PAM support: no
                   OSF SIA support: no
                 KerberosV support: no
                   SELinux support: no
                 Smartcard support:
                     S/KEY support: no
              TCP Wrappers support: no
              MD5 password support: no
                   libedit support: no
  Solaris process contract support: no
           Solaris project support: no
       IP address in $DISPLAY hack: no
           Translate v4 in v6 hack: yes
                  BSD Auth support: no
              Random number source: OpenSSL internal ONLY

              Host: i686-pc-linux-gnu
          Compiler: ntoarmv7-gcc
    Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -fno-builtin-memset
Preprocessor flags: -I/home/builder/stage/nto/usr/include
      Linker flags: -L/home/builder/stage/nto/armle-v7/lib -L/home/builder/stage/nto/armle-v7/usr/lib
         Libraries: -lcrypto -lz -lsocket



Here is the compile command for loginrec.c:
ntoarmv7-gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -fno-builtin-memset  -I. -I. -I/home/builder/stage/nto/usr/include -DSSHDIR=\"/home/builder/openssh/etc\" -D_PATH_SSH_PROGRAM=\"/home/builder/openssh/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/home/builder/openssh/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/home/builder/openssh/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/home/builder/openssh/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/home/builder/openssh/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/home/builder/openssh/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c loginrec.c
loginrec.c: In function 'record_failed_login':
loginrec.c:1700: error: 'struct utmp' has no member named 'ut_host'
loginrec.c:1700: error: 'struct utmp' has no member named 'ut_host'
loginrec.c:1708: error: 'struct utmp' has no member named 'ut_addr'
loginrec.c:1709: error: 'struct utmp' has no member named 'ut_addr'
loginrec.c:1709: error: 'struct utmp' has no member named 'ut_addr'
loginrec.c:1667: warning: unused variable 'a6'
At top level:
cc1: warning: unrecognized command line option "-Wno-unused-result"
make: *** [loginrec.o] Error 1



Any help would be greatly appreciated.
Rob

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

From dtucker at zip.com.au  Fri Sep  2 23:32:32 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 2 Sep 2011 23:32:32 +1000
Subject: problems building openssh-5.8p1 on qnx
In-Reply-To: <7C6BDB4BD9974646856544650C016B8209C8E047@XCH117CNC.rim.net>
References: <7C6BDB4BD9974646856544650C016B8209C8E047@XCH117CNC.rim.net>
Message-ID: <CALDDTe1BE-jfKOtjzrHzumSoBiNwRTd+fBR0AohyvXFg919J9g@mail.gmail.com>

On Fri, Sep 2, 2011 at 9:33 PM, Robert Dugal <rdugal at certicom.com> wrote:
[...]
> If I manually edit config.h after configure, adding #define MISSING_HOWMANY then I get these errors when I build:
> ? ? ? ?loginrec.c: In function 'record_failed_login':
> ? ? ? ?loginrec.c:1700: error: 'struct utmp' has no member named 'ut_host'

These are all inside #ifdef USE_BTMP.  Try commenting it out of
config.h (maybe configure is getting it from the host system).

-- 
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 dtucker at zip.com.au  Fri Sep  2 23:22:20 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 2 Sep 2011 23:22:20 +1000
Subject: Call for testing: OpenSSH-5.9
In-Reply-To: <CALDDTe1ughKVJqwZ0zE4AaC-JEL3P84676hL8dUCooN4La_VYQ@mail.gmail.com>
References: <alpine.BSO.2.00.1108141014180.23174@natsu.mindrot.org>
 <20110818060840.GB26471@red-sonja>
 <CALDDTe2L9g_PPjo_2FRGv0dx-1oJPNzv7X+shSE_d76NG8j9fQ@mail.gmail.com>
 <CALDDTe2_phViw2Fvh_e6Umq5vFsncEzboqmBpBpBSJ6MGoHcCg@mail.gmail.com>
 <CALDDTe2XZZis2D3BJwM_pROM+i+G7s6QdV+O_-VMLFWU=iy+xw@mail.gmail.com>
 <CALDDTe1ughKVJqwZ0zE4AaC-JEL3P84676hL8dUCooN4La_VYQ@mail.gmail.com>
Message-ID: <20110902132220.GA8954@gate.dtucker.net>

On Fri, Sep 02, 2011 at 10:33:58PM +1000, Darren Tucker wrote:
> On Mon, Aug 29, 2011 at 6:31 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> > On Mon, Aug 29, 2011 at 2:48 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> > [...]
> >> confirmed: it's poll.
> >
> > Actually now I'm not sure about that. ?Or rather I still think it's
> > poll, but maybe not in the place I originally thought.
> 
> OK, I think I have it figured out.  Here's my theory:
> 
> 1. it's poll()
> 2. some platforms (eg Solaris) implement select() on top of poll().
> Those are the ones where the test fails.
> 3. platforms that implement select() natively (eg Linux) are the ones that work.
> 4. the problem is not in atomicio, because poll is only used to
> prevent busy-waiting on EAGAIN.  if poll() fails it'll busy-wait on
> EAGAIN but otherwise work.  rather, the failure is in the main select
> loop.

Here's a configure test for this.  Tested on Linux and Solaris.

Index: configure.ac
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/configure.ac,v
retrieving revision 1.480
diff -u -p -r1.480 configure.ac
--- configure.ac	18 Aug 2011 04:48:24 -0000	1.480
+++ configure.ac	2 Sep 2011 13:09:06 -0000
@@ -2505,6 +2505,51 @@ elif test "x$sandbox_arg" = "xrlimit" ||
 		AC_MSG_ERROR([rlimit sandbox requires setrlimit function])
 	SANDBOX_STYLE="rlimit"
 	AC_DEFINE([SANDBOX_RLIMIT], [1], [Sandbox using setrlimit(2)])
+
+	AC_MSG_CHECKING([if select works with zero available fds])
+	AC_RUN_IFELSE(
+		[AC_LANG_PROGRAM([[
+#include <sys/time.h>
+#ifdef HAVE_SYS_SELECT_H
+#include <sys/select.h>
+#endif
+#ifdef HAVE_SYS_STAT_H
+#include <sys/stat.h>
+#endif
+#include <sys/resource.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <stdio.h>
+#include <stdlib.h>
+		]], [[
+	struct rlimit rl_zero;
+	int fd, r;
+	fd_set fds;
+
+	fd = open("/dev/null", O_RDWR);
+	rl_zero.rlim_cur = rl_zero.rlim_max = 0;
+	setrlimit(RLIMIT_FSIZE, &rl_zero);
+	setrlimit(RLIMIT_NOFILE, &rl_zero);
+	FD_ZERO(&fds);
+	FD_SET(fd, &fds);
+	r = select(fd+1, &fds, NULL, NULL, NULL);
+	if (r == -1)
+		exit(1);
+	exit(0);
+		]])], [
+			AC_MSG_RESULT(yes)
+			AC_DEFINE([SELECT_REQUIRED_FDS], [0],
+			    [number of available fds required for select])
+		], [
+			AC_MSG_RESULT(no)
+			AC_DEFINE([SELECT_REQUIRED_FDS], [1],
+			    [number of available fds required for select])
+		], [
+			AC_MSG_RESULT([cross-compiling, assuming yes])
+			AC_DEFINE([SELECT_REQUIRED_FDS], [0],
+			    [assuming select works with zero free fds])
+		]
+	)
 elif test -z "$sandbox_arg" || test "x$sandbox_arg" = "xno" || \
      test "x$sandbox_arg" = "xnone" || test "x$sandbox_arg" = "xnull" ; then
 	SANDBOX_STYLE="none"
Index: sandbox-rlimit.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/sandbox-rlimit.c,v
retrieving revision 1.2
diff -u -p -r1.2 sandbox-rlimit.c
--- sandbox-rlimit.c	23 Jun 2011 09:45:51 -0000	1.2
+++ sandbox-rlimit.c	2 Sep 2011 13:20:15 -0000
@@ -60,18 +60,20 @@ ssh_sandbox_init(void)
 void
 ssh_sandbox_child(struct ssh_sandbox *box)
 {
-	struct rlimit rl_zero;
+	struct rlimit rl;
 
-	rl_zero.rlim_cur = rl_zero.rlim_max = 0;
+	rl.rlim_cur = rl.rlim_max = SELECT_REQUIRED_FDS;
+	if (setrlimit(RLIMIT_NOFILE, &rl) == -1)
+		fatal("%s: setrlimit(RLIMIT_NOFILE, { %d, %d }): %s",
+			__func__, (int)rl.rlim_cur, (int)rl.rlim_max, strerror(errno));
 
-	if (setrlimit(RLIMIT_FSIZE, &rl_zero) == -1)
+	rl.rlim_cur = rl.rlim_max = 0;
+	if (setrlimit(RLIMIT_FSIZE, &rl) == -1)
 		fatal("%s: setrlimit(RLIMIT_FSIZE, { 0, 0 }): %s",
 			__func__, strerror(errno));
-	if (setrlimit(RLIMIT_NOFILE, &rl_zero) == -1)
-		fatal("%s: setrlimit(RLIMIT_NOFILE, { 0, 0 }): %s",
-			__func__, strerror(errno));
+
 #ifdef HAVE_RLIMIT_NPROC
-	if (setrlimit(RLIMIT_NPROC, &rl_zero) == -1)
+	if (setrlimit(RLIMIT_NPROC, &rl) == -1)
 		fatal("%s: setrlimit(RLIMIT_NPROC, { 0, 0 }): %s",
 			__func__, strerror(errno));
 #endif

-- 
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 rdugal at certicom.com  Sat Sep  3 02:21:38 2011
From: rdugal at certicom.com (Robert Dugal)
Date: Fri, 2 Sep 2011 12:21:38 -0400
Subject: problems building openssh-5.8p1 on qnx
In-Reply-To: <CALDDTe1BE-jfKOtjzrHzumSoBiNwRTd+fBR0AohyvXFg919J9g@mail.gmail.com>
References: <7C6BDB4BD9974646856544650C016B8209C8E047@XCH117CNC.rim.net>
 <CALDDTe1BE-jfKOtjzrHzumSoBiNwRTd+fBR0AohyvXFg919J9g@mail.gmail.com>
Message-ID: <7C6BDB4BD9974646856544650C016B8209C8E16D@XCH117CNC.rim.net>

Thanks, that fixed it. 
The only other problem I ran into is lock_passwd in ssh-agent.c conflicts with a function of same name in the QNX header file login.h
Renaming lock_passwd to ssh_lock_passwd fixed this.

Rob

-----Original Message-----
From: dtucker at dtucker.net [mailto:dtucker at dtucker.net] On Behalf Of Darren Tucker
Sent: Friday, September 02, 2011 9:33 AM
To: Robert Dugal
Cc: openssh-unix-dev at mindrot.org
Subject: Re: problems building openssh-5.8p1 on qnx

On Fri, Sep 2, 2011 at 9:33 PM, Robert Dugal <rdugal at certicom.com> wrote:
[...]
> If I manually edit config.h after configure, adding #define MISSING_HOWMANY then I get these errors when I build:
> ? ? ? ?loginrec.c: In function 'record_failed_login':
> ? ? ? ?loginrec.c:1700: error: 'struct utmp' has no member named 'ut_host'

These are all inside #ifdef USE_BTMP.  Try commenting it out of
config.h (maybe configure is getting it from the host system).

-- 
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.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

From carson at taltos.org  Sat Sep  3 06:21:17 2011
From: carson at taltos.org (Carson Gaspar)
Date: Fri, 02 Sep 2011 13:21:17 -0700
Subject: Call for testing: OpenSSH-5.9
In-Reply-To: <CALDDTe1ughKVJqwZ0zE4AaC-JEL3P84676hL8dUCooN4La_VYQ@mail.gmail.com>
References: <alpine.BSO.2.00.1108141014180.23174@natsu.mindrot.org>
 <20110818060840.GB26471@red-sonja>
 <CALDDTe2L9g_PPjo_2FRGv0dx-1oJPNzv7X+shSE_d76NG8j9fQ@mail.gmail.com>
 <CALDDTe2_phViw2Fvh_e6Umq5vFsncEzboqmBpBpBSJ6MGoHcCg@mail.gmail.com>
 <CALDDTe2XZZis2D3BJwM_pROM+i+G7s6QdV+O_-VMLFWU=iy+xw@mail.gmail.com>
 <CALDDTe1ughKVJqwZ0zE4AaC-JEL3P84676hL8dUCooN4La_VYQ@mail.gmail.com>
Message-ID: <4E613ABD.9060102@taltos.org>

On 9/2/11 5:33 AM, Darren Tucker wrote:
> On Mon, Aug 29, 2011 at 6:31 PM, Darren Tucker<dtucker at zip.com.au>  wrote:
>> On Mon, Aug 29, 2011 at 2:48 PM, Darren Tucker<dtucker at zip.com.au>  wrote:
>> [...]
>>> confirmed: it's poll.
>>
>> Actually now I'm not sure about that.  Or rather I still think it's
>> poll, but maybe not in the place I originally thought.
>
> OK, I think I have it figured out.  Here's my theory:
>
> 1. it's poll()
> 2. some platforms (eg Solaris) implement select() on top of poll().
> Those are the ones where the test fails.
> 3. platforms that implement select() natively (eg Linux) are the ones that work.
> 4. the problem is not in atomicio, because poll is only used to
> prevent busy-waiting on EAGAIN.  if poll() fails it'll busy-wait on
> EAGAIN but otherwise work.  rather, the failure is in the main select
> loop.

It's pollsys(), called by both poll() and select() in Solaris 10, so the 
failure is in the kernel (looking at the source, it's in poll_common - 
"if (nfds > p->p_fno_ctl)"). One option is to use /dev/poll directly, 
working around the issue. The code is more complex, but not impossibly so.

#include <sys/types.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <sys/select.h>
#include <sys/socket.h>
#include <stdio.h>
#include <poll.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/devpoll.h>
#include <strings.h>
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
         struct rlimit rl_zero;
         struct pollfd pfd;
         int wfd, r, enforce_limit = 0;
         struct pollfd fds[1];
         dvpoll_t dopoll;

         if (argc == 2 && strcmp(argv[1], "limit") == 0)
                 enforce_limit = 1;

         fds[0].fd = open("/dev/null", O_RDONLY);
         fds[0].events = POLLIN;
         fds[0].revents = 0;

         dopoll.dp_timeout = 0;
         dopoll.dp_nfds = 1;
         dopoll.dp_fds = (struct pollfd *)
                 malloc(sizeof(struct pollfd));
         if (!dopoll.dp_fds) {
                 perror("Failed in dopoll.dp_fds" );
                 exit(-1);
         }

         if ((wfd = open("/dev/poll", O_RDWR)) < 0) {
                 perror("Failed to open /dev/poll");
                 exit(-1);
         }

         if (write(wfd, &fds[0], sizeof(struct pollfd)) != sizeof(struct 
pollfd)) {
                 perror("failed to write all pollfds");
                 close(wfd);
                 exit(-1);
         }

         if (enforce_limit) {
                 rl_zero.rlim_cur = rl_zero.rlim_max = 0;
                 setrlimit(RLIMIT_FSIZE, &rl_zero);
                 setrlimit(RLIMIT_NOFILE, &rl_zero);
         }

         r = ioctl(wfd, DP_POLL, &dopoll);
         printf("/dev/poll = %d, error: %s\n", r, strerror(errno));
}


From djm at mindrot.org  Sat Sep  3 11:06:03 2011
From: djm at mindrot.org (Damien Miller)
Date: Sat, 3 Sep 2011 11:06:03 +1000 (EST)
Subject: pkcs and host keys
In-Reply-To: <CAPKO79sZLa+yAzWEXh=Py0ahytpK8-S8N3ASkQEaFB69LzjD0Q@mail.gmail.com>
References: <CAPKO79sZLa+yAzWEXh=Py0ahytpK8-S8N3ASkQEaFB69LzjD0Q@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1109031104380.14401@natsu.mindrot.org>

On Thu, 1 Sep 2011, Benjamin Myers wrote:

> Hi Damien,
> 
> I see in your asia bsdcon presentation you mentioned the possibility
> of storing host keys in PKCS #11.  I'm interested in using a usb rsa
> fob for host keys and am interested in this feature.  What's the
> current status?  As you said:  root compromise != persistent hostkey
> theft.

No, I haven't started working on it yet for lack of smartcard hardware.
I (or someone else) will probably get around to it sooner or later, but
it will go quicker if I can get a supported USB smartcard on OpenBSD.

-d

From phorminx at web.de  Sun Sep  4 01:43:06 2011
From: phorminx at web.de (phorminx at web.de)
Date: Sat, 3 Sep 2011 17:43:06 +0200 (CEST)
Subject: scp fails after sending command: scp -v -t
Message-ID: <365337210.2055575.1315064586761.JavaMail.fmail@mwmweb030>

I encounter a strange problem with scp / sftp:

I travel quite a bit. Normally I never have had any problems using
ssh / scp / sftp to connect from my laptop to my computer at home /
in the office. Currently (for the next 6 months, too long to ignore it)
I'll stay in a place where scp / sftp seem to fail, while as usual I
have no problems to establish an interactive ssh connection to these
remote computers. Recently, I did not change any configuration
neither on my laptop nor on the remote computers I want to connect
to. In particular, I also double-checked that

? http://www.openssh.org/faq.html#2.9

does not apply, i.e.,

? $ssh myhost /bin/true

does not give any spurious output.

More specifically, I also tried scp -v together with sshd -d
on the server side. The client hangs after issuing

? debug1: Sending command: scp -v -t ~/foo

At this stage, the server says

? debug1: server_input_channel_open: confirm session

The complete output of scp -v and sshd -d is attached below.

My problem appears to be similar to

? http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-March/026276.html

The only difference might be that the guy of the previous thread
stayed (and suffered) in his hotel not very long so that apparently
his case was never resolved properly. I cannot ignore this problem
for the next six months. So any help will be appreciated!

___________________________________________________________
Schon geh?rt? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

From phorminx at web.de  Sun Sep  4 04:03:31 2011
From: phorminx at web.de (phorminx at web.de)
Date: Sat, 3 Sep 2011 20:03:31 +0200 (CEST)
Subject: scp fails after sending command: scp -v -t
Message-ID: <733122823.2391194.1315073011966.JavaMail.fmail@mwmweb026>

Does this list not like plain text attachments?
Well, here is my email once more with debug output included directly.

----------------------------------------------------------
I encounter a strange problem with scp / sftp:

I travel quite a bit. Normally I never have had any problems using
ssh / scp / sftp to connect from my laptop to my computer at home /
at work. Currently (for the next 6 months, too long to ignore it)
I'll stay in a place where scp / sftp seem to fail, while as usual I
have no problems to establish an interactive ssh connection to these
remote computers. Recently, I did not change any configuration
neither on my laptop nor on the remote computers I want to connect
to. In particular, I also double-checked that

? http://www.openssh.org/faq.html#2.9

does not apply, i.e.,

? $ssh myhost /bin/true

does not give any spurious output.

More specifically, I also tried scp -v together with sshd -d
on the server side. The client hangs after issuing

? debug1: Sending command: scp -v -t ~/foo

At this stage, the server says

? debug1: server_input_channel_open: confirm session

The complete output of scp -v and sshd -d is attached below.

My problem appears to be similar to

? http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-March/026276.html

The only difference might be that the guy of the previous thread
stayed (and suffered) in his hotel not very long so that apparently
his case was never resolved properly. I cannot ignore this problem
for the next six months. So any help will be appreciated!

$ scp -v scratch phorminx at foo.bar.com:~/foo
Executing: program /usr/bin/ssh host foo.bar.com, user phorminx, command scp -v -t ~/foo
OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to foo.bar.com [123.456.78.901] port 22.
debug1: Connection established.
debug1: identity file /home/phorminx/.ssh/identity type -1
debug1: identity file /home/phorminx/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: identity file /home/phorminx/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'foo.bar.com' is known and matches the RSA host key.
debug1: Found key in /home/phorminx/.ssh/known_hosts:13
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/phorminx/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_COLLATE = C
debug1: Sending env LANG = en_US.ISO-8859-15
debug1: Sending env LC_TIME = en_GB.utf8
debug1: Sending command: scp -v -t ~/foo
^Cdebug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug1: Killed by signal 2.

# /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 98.765.432.10 port 46213
debug1: Client protocol version 2.0; client software version OpenSSH_5.3p1 Debian-3ubuntu7
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: permanently_set_uid: 112/65534
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user phorminx service ssh-connection method none
debug1: attempt 0 failures 0
debug1: userauth-request for user phorminx service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/phorminx/.ssh/authorized_keys
debug1: matching key found: file /home/phorminx/.ssh/authorized_keys, line 3
Found matching RSA key:
debug1: restore_uid: 0/0
Postponed publickey for phorminx from 98.765.432.10 port 46213 ssh2
debug1: userauth-request for user phorminx service ssh-connection method publickey
debug1: attempt 2 failures 1
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/phorminx/.ssh/authorized_keys
debug1: matching key found: file /home/phorminx/.ssh/authorized_keys, line 3
Found matching RSA key: a5:d8:80:5e:f5:83:c5:eb:d0:38:13:d8:d4:87:de:cd
debug1: restore_uid: 0/0
debug1: ssh_rsa_verify: signature correct
Accepted publickey for phorminx from 98.765.432.10 port 46213 ssh2
debug1: monitor_child_preauth: phorminx has been authenticated by privileged process
debug1: permanently_set_uid: 1000/1000
debug1: SELinux support disabled
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session

debug1: do_cleanup


___________________________________________________________
Schon geh?rt? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

From dtucker at zip.com.au  Sun Sep  4 11:04:48 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 4 Sep 2011 11:04:48 +1000
Subject: scp fails after sending command: scp -v -t
In-Reply-To: <365337210.2055575.1315064586761.JavaMail.fmail@mwmweb030>
References: <365337210.2055575.1315064586761.JavaMail.fmail@mwmweb030>
Message-ID: <CALDDTe0u_y1JavE5Saw8LJwce_hJTcv8DoDWbMtYgyC8Nq+toA@mail.gmail.com>

On Sun, Sep 4, 2011 at 1:43 AM,  <phorminx at web.de> wrote:
> I encounter a strange problem with scp / sftp:
>
> I travel quite a bit. Normally I never have had any problems using
> ssh / scp / sftp to connect from my laptop to my computer at home /
> in the office. Currently (for the next 6 months, too long to ignore it)
> I'll stay in a place where scp / sftp seem to fail,

Sounds like a mtu/fragmentation problem. See
http://www.snailbook.com/faq/mtu-mismatch.auto.html for some
suggestions.

-- 
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 phorminx at web.de  Sun Sep  4 17:40:44 2011
From: phorminx at web.de (phorminx at web.de)
Date: Sun, 4 Sep 2011 09:40:44 +0200 (CEST)
Subject: scp fails after sending command: scp -v -t
Message-ID: <982363938.2172536.1315122044850.JavaMail.fmail@mwmweb034>

Thanks for the quick reply. Unfortunately, reducing the MTU on the
client and server side to 576 (default was 1500) did not solve my
problem.

I assume that the MTU suggested there (the value 576) is a
reasonable value that _should_ be small enough to avoid the
fragmentation problem. Well, I could reduce this number further. Yet
I do not want to experiment with yet smaller values till I reach the
point where I cannot reach at all anymore the server.
Then I would be really stuck!

Any thoughts or ideas? Thanks a lot!

I could add another strange observation: I like GNU emacs. This
comes with TRAMP, the `Transparent Remote (file) Access, Multiple
Protocol'. When I establish a TRAMP/ssh connection to the remote
server, I can transfer big files just fine. Unfortunately, I do not
know more details about how TRAMP is doing this internally. All I
can say is that my TRAMP session uses the so-called `scpc' method
which combines ssh with scp by reusing an existing `ssh' channel via
the ssh `ControlMaster' option. So it does something like (taken
from the TRAMP debug output)

? scp -p -q -r -o ControlPath=/home/phorminx/emacs/scratch/tramp.4900PZy.%r@%h:%p -o ControlMaster=auto phorminx at foo.bar.com:/home/phorminx/foo.txt /home/phorminx/emacs/scratch/tramp.49009EH.txt

(I have attached the server debug output from such a session. I
could also provide the complete TRAMP debug output. Yet this might
be more difficult to digest for you as it uses emacs/TRAMP's
internal format.)

The main reason I mention this here is that if the MTU value was the
real problem, I expect it should affect the TRAMP/ssh connection,
too.

# /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from 98.765.432.10 port 51539
debug1: Client protocol version 2.0; client software version OpenSSH_5.3p1 Debian-3ubuntu7
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: permanently_set_uid: 112/65534
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user phorminx service ssh-connection method none
debug1: attempt 0 failures 0
debug1: userauth-request for user phorminx service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/phorminx/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/phorminx/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for phorminx from 98.765.432.10 port 51539 ssh2
debug1: userauth-request for user phorminx service ssh-connection method publickey
debug1: attempt 2 failures 2
debug1: test whether pkalg/pkblob are acceptable
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/phorminx/.ssh/authorized_keys
debug1: matching key found: file /home/phorminx/.ssh/authorized_keys, line 3
Found matching RSA key: a5:d8:80:5e:f5:83:c5:eb:d0:38:13:d8:d4:87:de:cd
debug1: restore_uid: 0/0
Postponed publickey for phorminx from 98.765.432.10 port 51539 ssh2
debug1: userauth-request for user phorminx service ssh-connection method publickey
debug1: attempt 3 failures 2
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/phorminx/.ssh/authorized_keys
debug1: matching key found: file /home/phorminx/.ssh/authorized_keys, line 3
Found matching RSA key: a5:d8:80:5e:f5:83:c5:eb:d0:38:13:d8:d4:87:de:cd
debug1: restore_uid: 0/0
debug1: ssh_rsa_verify: signature correct
Accepted publickey for phorminx from 98.765.432.10 port 51539 ssh2
debug1: monitor_child_preauth: phorminx has been authenticated by privileged process
debug1: permanently_set_uid: 1000/1000
debug1: SELinux support disabled
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_new: init
debug1: session_new: session 0
debug1: SELinux support disabled
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request env reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req env
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
debug1: Setting controlling tty using TIOCSCTTY.
debug1: session_by_tty: session 0 tty /dev/pts/2
debug1: registered uid=1000 on tty='/dev/pts/2' with ConsoleKit
debug1: server_input_channel_open: ctype session rchan 1 win 2097152 max 32768
debug1: input_session_request
debug1: channel 1: new [server-session]
debug1: session_new: session 1
debug1: session_open: channel 1
debug1: session_open: session 1: link with channel 1
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 1 request env reply 0
debug1: session_by_channel: session 1 channel 1
debug1: session_input_channel_req: session 1 req env
debug1: server_input_channel_req: channel 1 request env reply 0
debug1: session_by_channel: session 1 channel 1
debug1: session_input_channel_req: session 1 req env
debug1: server_input_channel_req: channel 1 request env reply 0
debug1: session_by_channel: session 1 channel 1
debug1: session_input_channel_req: session 1 req env
debug1: server_input_channel_req: channel 1 request exec reply 1
debug1: session_by_channel: session 1 channel 1
debug1: session_input_channel_req: session 1 req exec
debug1: Received SIGCHLD.
debug1: session_by_pid: pid 23086
debug1: session_exit_message: session 1 channel 1 pid 23086
debug1: session_exit_message: release channel 1
debug1: session_by_channel: session 1 channel 1
debug1: session_close_by_channel: channel 1 child 0
debug1: session_close: session 1 pid 0
debug1: channel 1: free: server-session, nchannels 2
Received disconnect from 98.765.432.10: 11: disconnected by user
debug1: do_cleanup
debug1: do_cleanup
debug1: session_pty_cleanup: session 0 release /dev/pts/2
debug1: unregistering ConsoleKit session f3021f11585cab6e6e7cce3849403e97-1315120728.670360-1872441218

___________________________________________________________
Schon geh?rt? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

From djm at cvs.openbsd.org  Tue Sep  6 15:29:50 2011
From: djm at cvs.openbsd.org (Damien Miller)
Date: Mon, 5 Sep 2011 23:29:50 -0600 (MDT)
Subject: Announce: OpenSSH 5.9 released
Message-ID: <201109060529.p865ToxH008061@cvs.openbsd.org>

OpenSSH 5.9 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 5.8
=========================

Features:

 * Introduce sandboxing of the pre-auth privsep child using an optional
   sshd_config(5) "UsePrivilegeSeparation=sandbox" mode that enables
   mandatory restrictions on the syscalls the privsep child can perform.
   This intention is to prevent a compromised privsep child from being
   used to attack other hosts (by opening sockets and proxying) or
   probing local kernel attack surface.
    
   Three concrete sandbox implementation are provided (selected at
   configure time): systrace, seatbelt and rlimit.

   The systrace sandbox uses systrace(4) in unsupervised "fast-path"
   mode, where a list of permitted syscalls is supplied. Any syscall not
   on the list results in SIGKILL being sent to the privsep child. Note
   that this requires a kernel with the new SYSTR_POLICY_KILL option
   (only OpenBSD has this mode at present).
 
   The seatbelt sandbox uses OS X/Darwin sandbox(7) facilities with a
   strict (kSBXProfilePureComputation) policy that disables access to
   filesystem and network resources.

   The rlimit sandbox is a fallback choice for platforms that don't
   support a better one; it uses setrlimit() to reset the hard-limit
   of file descriptors and processes to zero, which should prevent
   the privsep child from forking or opening new network connections.

   Sandboxing of the privilege separated child process is currently
   experimental but should become the default in a future release.
   Native sandboxes for other platforms are welcome (e.g. Capsicum,
   Linux pid/net namespaces, etc.)

 * Add new SHA256-based HMAC transport integrity modes from
   http://www.ietf.org/id/draft-dbider-sha2-mac-for-ssh-02.txt
   These modes are hmac-sha2-256, hmac-sha2-256-96, hmac-sha2-512,
   and hmac-sha2-512-96, and are available by default in ssh(1) and
   sshd(8)

 * The pre-authentication sshd(8) privilege separation slave process
   now logs via a socket shared with the master process, avoiding the
   need to maintain /dev/log inside the chroot.

 * ssh(1) now warns when a server refuses X11 forwarding

 * sshd_config(5)'s AuthorizedKeysFile now accepts multiple paths,
   separated by whitespace. The undocumented AuthorizedKeysFile2
   option is deprecated (though the default for AuthorizedKeysFile
   includes .ssh/authorized_keys2)

 * sshd_config(5): similarly deprecate UserKnownHostsFile2 and
   GlobalKnownHostsFile2 by making UserKnownHostsFile and
   GlobalKnownHostsFile accept multiple options and default to
   include known_hosts2

 * Retain key comments when loading v.2 keys. These will be visible
   in "ssh-add -l" and other places. bz#439

 * ssh(1) and sshd(8): set IPv6 traffic class from IPQoS (as well as
   IPv4 ToS/DSCP). bz#1855

 * ssh_config(5)'s ControlPath option now expands %L to the host
   portion of the destination host name.

 * ssh_config(5) "Host" options now support negated Host matching, e.g.
     
     Host *.example.org !c.example.org
        User mekmitasdigoat
     
   Will match "a.example.org", "b.example.org", but not "c.example.org"

 * ssh_config(5): a new RequestTTY option provides control over when a
   TTY is requested for a connection, similar to the existing -t/-tt/-T
   ssh(1) commandline options.

 * sshd(8): allow GSSAPI authentication to detect when a server-side
   failure causes authentication failure and don't count such failures
   against MaxAuthTries; bz#1244

 * ssh-keygen(1): Add -A option. For each of the key types (rsa1, rsa,
   dsa and ecdsa) for which host keys do not exist, generate the host
   keys with the default key file path, an empty passphrase, default
   bits for the key type, and default comment. This is useful for
   system initialisation scripts.

 * ssh(1): Allow graceful shutdown of multiplexing: request that a mux
   server removes its listener socket and refuse future multiplexing
   requests but don't kill existing connections. This may be requested
   using "ssh -O stop ..."

 * ssh-add(1) now accepts keys piped from standard input. E.g.
   "ssh-add - < /path/to/key"
 
 * ssh-keysign(8) now signs hostbased authentication
   challenges correctly using ECDSA keys; bz#1858

 * sftp(1): document that sftp accepts square brackets to delimit
   addresses (useful for IPv6); bz#1847a

 * ssh(1): when using session multiplexing, the master process will
   change its process title to reflect the control path in use and
   when a ControlPersist-ed master is waiting to close; bz#1883 and
   bz#1911

 * Other minor bugs fixed: 1849 1861 1862 1869 1875 1878 1879 1892
   1900 1905 1913

Portable OpenSSH Bugfixes:

 * Fix a compilation error in the SELinux support code. bz#1851

 * This release removes support for ssh-rand-helper. OpenSSH now
   obtains its random numbers directly from OpenSSL or from
   a PRNGd/EGD instance specified at configure time.

 * sshd(8) now resets the SELinux process execution context before
   executing passwd for password changes; bz#1891

 * Since gcc >= 4.x ignores all -Wno-options options, test only the
   corresponding -W-option when trying to determine whether it is
   accepted; bz#1901

 * Add ECDSA key generation to the Cygwin ssh-{host,user}-config
   scripts.

 * Updated .spec and init files for Linux; bz#1920

 * Improved SELinux error messages in context change failures and
   suppress error messages when attempting to change from the
   "unconfined_t" type; bz#1924 bz#1919

 * Fix build errors on platforms without dlopen(); bz#1929

Checksums:
==========

 - SHA1 (openssh-5.9.tar.gz) = bc0cb728bbc394769f9a2ce5b8cd99dc41e12632
 - SHA1 (openssh-5.9p1.tar.gz) = be8878869bb80ce12ca79282768ffa73cc3f05fc

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 djm at mindrot.org  Tue Sep  6 22:16:00 2011
From: djm at mindrot.org (Damien Miller)
Date: Tue, 6 Sep 2011 22:16:00 +1000 (EST)
Subject: error in openssh-5.9p1 release
Message-ID: <alpine.BSO.2.00.1109062213320.10667@natsu.mindrot.org>

Hi,

Some of the more observant of you have noticed that the just-released
OpenSSH-5.9p1 identifies itself as OpenSSH-5.9p2.

Don't be worried - it is not a robot sent back from the future to kill
you, it was just a screwup on my part. I'll decide whether to issue a new
tarball tomorrow morning after some sleep.

Sorry for the hassle.

-d

From rdugal at certicom.com  Wed Sep  7 00:36:51 2011
From: rdugal at certicom.com (Robert Dugal)
Date: Tue, 6 Sep 2011 10:36:51 -0400
Subject: mac_int() does not call HMAC_CTX_init()
Message-ID: <7C6BDB4BD9974646856544650C016B8209DF0B48@XCH117CNC.rim.net>

Last year I sent the email below describing a bug in openssh 5.6p1.
I just noticed this bug still exists in 5.9p1.

Probably my earlier email was treated as spam because it was in HTML format. 


-- 
Robert Dugal	Team Lead SSL & PKI Group
Certicom Corp.	A Subsidiary of Research In Motion
                  4701 Tahoe Blvd., Building A
                  Mississauga, ON
                  L4W 0B5
 
rdugal at certicom.com
direct???????	+1.289.261.4148
mobile??????	+1.416.276.8062
main ??? ????	+1.905.507.4220
fax?? ??????????	+1.905.507.4230
www.certicom.com





From: Robert Dugal 
Sent: Wednesday, September 29, 2010 1:02 PM
To: openssh-unix-dev at mindrot.org
Subject: bug in openssh - mac_int() does not call HMAC_CTX_init()

I have been doing some work with OpenSSH 5.6p1, attempting to use an alternative engine for crypto.
In mac.c, the function mac_init() calls HMAC_Init() without previously having called HMAC_CTX_init().
However, OpenSSL documentation states that HMAC_CTX_init() is mandatory.

http://www.openssl.org/docs/crypto/hmac.html

HMAC_CTX_init() initialises a HMAC_CTX before first use. It must be called. 
HMAC_CTX_init() must have been called before the first use of an HMAC_CTX in this function. N.B. HMAC_Init() had this undocumented behaviour in previous versions of OpenSSL - failure to switch to HMAC_Init_ex() in programs that expect it will cause them to stop working

While this appears to cause no issues with OpenSSH 5.6p1 using OpenSSL 1.0.0a and the default crypto engine,
it may cause problems (such as segfaults in my case) when attempting to use an alternative engine.
-- 
Robert Dugal??????????????????????? Senior Software Developer
Certicom Corp.???????????????????   A Subsidiary of Research In Motion 
rdugal at certicom.com
direct????????905.501.3848
fax?? ??????????905.507.4230
www.certicom.com


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

From imorgan at nas.nasa.gov  Wed Sep  7 07:44:26 2011
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 6 Sep 2011 14:44:26 -0700
Subject: mac_int() does not call HMAC_CTX_init()
In-Reply-To: <7C6BDB4BD9974646856544650C016B8209DF0B48@XCH117CNC.rim.net>
References: <7C6BDB4BD9974646856544650C016B8209DF0B48@XCH117CNC.rim.net>
Message-ID: <20110906214426.GB5680@linux124.nas.nasa.gov>

Did you file a bug with bugzilla.mindrot.org? If not, it could easily
get overlooked regardless of whether or not the email made it to the
mailing list.

-- 
Iain

On Tue, Sep 06, 2011 at 09:36:51 -0500, Robert Dugal wrote:
> Last year I sent the email below describing a bug in openssh 5.6p1.
> I just noticed this bug still exists in 5.9p1.
> 
> Probably my earlier email was treated as spam because it was in HTML format. 
> 
> 
> -- 
> Robert Dugal	Team Lead SSL & PKI Group
> Certicom Corp.	A Subsidiary of Research In Motion
>                   4701 Tahoe Blvd., Building A
>                   Mississauga, ON
>                   L4W 0B5
>  
> rdugal at certicom.com
> direct???????	+1.289.261.4148
> mobile??????	+1.416.276.8062
> main ??? ????	+1.905.507.4220
> fax?? ??????????	+1.905.507.4230
> www.certicom.com
> 
> 
> 
> 
> 
> From: Robert Dugal 
> Sent: Wednesday, September 29, 2010 1:02 PM
> To: openssh-unix-dev at mindrot.org
> Subject: bug in openssh - mac_int() does not call HMAC_CTX_init()
> 
> I have been doing some work with OpenSSH 5.6p1, attempting to use an alternative engine for crypto.
> In mac.c, the function mac_init() calls HMAC_Init() without previously having called HMAC_CTX_init().
> However, OpenSSL documentation states that HMAC_CTX_init() is mandatory.
> 
> http://www.openssl.org/docs/crypto/hmac.html
> 
> HMAC_CTX_init() initialises a HMAC_CTX before first use. It must be called. 
> HMAC_CTX_init() must have been called before the first use of an HMAC_CTX in this function. N.B. HMAC_Init() had this undocumented behaviour in previous versions of OpenSSL - failure to switch to HMAC_Init_ex() in programs that expect it will cause them to stop working
> 
> While this appears to cause no issues with OpenSSH 5.6p1 using OpenSSL 1.0.0a and the default crypto engine,
> it may cause problems (such as segfaults in my case) when attempting to use an alternative engine.
> -- 
> Robert Dugal??????????????????????? Senior Software Developer
> Certicom Corp.???????????????????   A Subsidiary of Research In Motion 
> rdugal at certicom.com
> direct????????905.501.3848
> fax?? ??????????905.507.4230
> www.certicom.com
> 
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Iain Morgan

From djm at cvs.openbsd.org  Wed Sep  7 09:35:38 2011
From: djm at cvs.openbsd.org (Damien Miller)
Date: Tue, 6 Sep 2011 17:35:38 -0600 (MDT)
Subject: Announce: OpenSSH 5.9 released
Message-ID: <201109062335.p86NZceR032426@cvs.openbsd.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Yesterday's portable OpenSSH 5.9p1 release was made with an incorrect
version number in the source (it erroneously identified itself as 5.9p2)

I have respun the openssh-5.9p1 release tarball to correct this and
another typo in contrib/redhat/openssh.spec (bz#1933). The checksum for
the respun tarball is:

 - SHA1 (openssh-5.9p1.tar.gz) = ac4e0055421e9543f0af5da607a72cf5922dcc56

It has also been signed with the release PGP key.

Apologies for any inconvenience,
Damien Miller

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (OpenBSD)

iD8DBQFOZq19zo7LA4b/nEgRAlCAAJ9ptnASRU9FYO8wPm5dVf3EjcuAdACeLRA9
ZxvYQVcd1w1tiMAmedV28jY=
=EEG8
-----END PGP SIGNATURE-----

From djm at cvs.openbsd.org  Wed Sep  7 09:35:32 2011
From: djm at cvs.openbsd.org (Damien Miller)
Date: Tue, 6 Sep 2011 17:35:32 -0600 (MDT)
Subject: Announce: OpenSSH 5.9 released
Message-ID: <201109062335.p86NZWpE000719@cvs.openbsd.org>

OpenSSH 5.9 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 5.8
=========================

Features:

 * Introduce sandboxing of the pre-auth privsep child using an optional
   sshd_config(5) "UsePrivilegeSeparation=sandbox" mode that enables
   mandatory restrictions on the syscalls the privsep child can perform.
   This intention is to prevent a compromised privsep child from being
   used to attack other hosts (by opening sockets and proxying) or
   probing local kernel attack surface.
    
   Three concrete sandbox implementation are provided (selected at
   configure time): systrace, seatbelt and rlimit.

   The systrace sandbox uses systrace(4) in unsupervised "fast-path"
   mode, where a list of permitted syscalls is supplied. Any syscall not
   on the list results in SIGKILL being sent to the privsep child. Note
   that this requires a kernel with the new SYSTR_POLICY_KILL option
   (only OpenBSD has this mode at present).
 
   The seatbelt sandbox uses OS X/Darwin sandbox(7) facilities with a
   strict (kSBXProfilePureComputation) policy that disables access to
   filesystem and network resources.

   The rlimit sandbox is a fallback choice for platforms that don't
   support a better one; it uses setrlimit() to reset the hard-limit
   of file descriptors and processes to zero, which should prevent
   the privsep child from forking or opening new network connections.

   Sandboxing of the privilege separated child process is currently
   experimental but should become the default in a future release.
   Native sandboxes for other platforms are welcome (e.g. Capsicum,
   Linux pid/net namespaces, etc.)

 * Add new SHA256-based HMAC transport integrity modes from
   http://www.ietf.org/id/draft-dbider-sha2-mac-for-ssh-02.txt
   These modes are hmac-sha2-256, hmac-sha2-256-96, hmac-sha2-512,
   and hmac-sha2-512-96, and are available by default in ssh(1) and
   sshd(8)

 * The pre-authentication sshd(8) privilege separation slave process
   now logs via a socket shared with the master process, avoiding the
   need to maintain /dev/log inside the chroot.

 * ssh(1) now warns when a server refuses X11 forwarding

 * sshd_config(5)'s AuthorizedKeysFile now accepts multiple paths,
   separated by whitespace. The undocumented AuthorizedKeysFile2
   option is deprecated (though the default for AuthorizedKeysFile
   includes .ssh/authorized_keys2)

 * sshd_config(5): similarly deprecate UserKnownHostsFile2 and
   GlobalKnownHostsFile2 by making UserKnownHostsFile and
   GlobalKnownHostsFile accept multiple options and default to
   include known_hosts2

 * Retain key comments when loading v.2 keys. These will be visible
   in "ssh-add -l" and other places. bz#439

 * ssh(1) and sshd(8): set IPv6 traffic class from IPQoS (as well as
   IPv4 ToS/DSCP). bz#1855

 * ssh_config(5)'s ControlPath option now expands %L to the host
   portion of the destination host name.

 * ssh_config(5) "Host" options now support negated Host matching, e.g.
     
     Host *.example.org !c.example.org
        User mekmitasdigoat
     
   Will match "a.example.org", "b.example.org", but not "c.example.org"

 * ssh_config(5): a new RequestTTY option provides control over when a
   TTY is requested for a connection, similar to the existing -t/-tt/-T
   ssh(1) commandline options.

 * sshd(8): allow GSSAPI authentication to detect when a server-side
   failure causes authentication failure and don't count such failures
   against MaxAuthTries; bz#1244

 * ssh-keygen(1): Add -A option. For each of the key types (rsa1, rsa,
   dsa and ecdsa) for which host keys do not exist, generate the host
   keys with the default key file path, an empty passphrase, default
   bits for the key type, and default comment. This is useful for
   system initialisation scripts.

 * ssh(1): Allow graceful shutdown of multiplexing: request that a mux
   server removes its listener socket and refuse future multiplexing
   requests but don't kill existing connections. This may be requested
   using "ssh -O stop ..."

 * ssh-add(1) now accepts keys piped from standard input. E.g.
   "ssh-add - < /path/to/key"
 
 * ssh-keysign(8) now signs hostbased authentication
   challenges correctly using ECDSA keys; bz#1858

 * sftp(1): document that sftp accepts square brackets to delimit
   addresses (useful for IPv6); bz#1847a

 * ssh(1): when using session multiplexing, the master process will
   change its process title to reflect the control path in use and
   when a ControlPersist-ed master is waiting to close; bz#1883 and
   bz#1911

 * Other minor bugs fixed: 1849 1861 1862 1869 1875 1878 1879 1892
   1900 1905 1913

Portable OpenSSH Bugfixes:

 * Fix a compilation error in the SELinux support code. bz#1851

 * This release removes support for ssh-rand-helper. OpenSSH now
   obtains its random numbers directly from OpenSSL or from
   a PRNGd/EGD instance specified at configure time.

 * sshd(8) now resets the SELinux process execution context before
   executing passwd for password changes; bz#1891

 * Since gcc >= 4.x ignores all -Wno-options options, test only the
   corresponding -W-option when trying to determine whether it is
   accepted; bz#1901

 * Add ECDSA key generation to the Cygwin ssh-{host,user}-config
   scripts.

 * Updated .spec and init files for Linux; bz#1920

 * Improved SELinux error messages in context change failures and
   suppress error messages when attempting to change from the
   "unconfined_t" type; bz#1924 bz#1919

 * Fix build errors on platforms without dlopen(); bz#1929

Checksums:
==========

 - SHA1 (openssh-5.9.tar.gz) = bc0cb728bbc394769f9a2ce5b8cd99dc41e12632
 - SHA1 (openssh-5.9p1.tar.gz) = be8878869bb80ce12ca79282768ffa73cc3f05fc

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 rdugal at certicom.com  Thu Sep  8 00:01:48 2011
From: rdugal at certicom.com (Robert Dugal)
Date: Wed, 7 Sep 2011 10:01:48 -0400
Subject: mac_int() does not call HMAC_CTX_init()
In-Reply-To: <20110906214426.GB5680@linux124.nas.nasa.gov>
References: <7C6BDB4BD9974646856544650C016B8209DF0B48@XCH117CNC.rim.net>
 <20110906214426.GB5680@linux124.nas.nasa.gov>
Message-ID: <7C6BDB4BD9974646856544650C016B8209DF0E60@XCH117CNC.rim.net>

No, I did not file a bug last year. I have just filed bug 1934.

-- 
Robert Dugal	Team Lead SSL & PKI Group
Certicom Corp.	A Subsidiary of Research In Motion
		4701 Tahoe Blvd., Building A
		Mississauga, ON
		L4W 0B5
 
rdugal at certicom.com
direct???????	+1.289.261.4148
mobile??????	+1.416.276.8062
main ??? ????	+1.905.507.4220
fax?? ??????????	+1.905.507.4230
www.certicom.com


-----Original Message-----
From: Iain Morgan [mailto:imorgan at nas.nasa.gov] 
Sent: Tuesday, September 06, 2011 5:44 PM
To: Robert Dugal
Cc: openssh-unix-dev at mindrot.org
Subject: Re: mac_int() does not call HMAC_CTX_init()

Did you file a bug with bugzilla.mindrot.org? If not, it could easily
get overlooked regardless of whether or not the email made it to the
mailing list.

-- 
Iain

On Tue, Sep 06, 2011 at 09:36:51 -0500, Robert Dugal wrote:
> Last year I sent the email below describing a bug in openssh 5.6p1.
> I just noticed this bug still exists in 5.9p1.
> 
> Probably my earlier email was treated as spam because it was in HTML format. 
> 
> 
> -- 
> Robert Dugal	Team Lead SSL & PKI Group
> Certicom Corp.	A Subsidiary of Research In Motion
>                   4701 Tahoe Blvd., Building A
>                   Mississauga, ON
>                   L4W 0B5
>  
> rdugal at certicom.com
> direct???????	+1.289.261.4148
> mobile??????	+1.416.276.8062
> main ??? ????	+1.905.507.4220
> fax?? ??????????	+1.905.507.4230
> www.certicom.com
> 
> 
> 
> 
> 
> From: Robert Dugal 
> Sent: Wednesday, September 29, 2010 1:02 PM
> To: openssh-unix-dev at mindrot.org
> Subject: bug in openssh - mac_int() does not call HMAC_CTX_init()
> 
> I have been doing some work with OpenSSH 5.6p1, attempting to use an alternative engine for crypto.
> In mac.c, the function mac_init() calls HMAC_Init() without previously having called HMAC_CTX_init().
> However, OpenSSL documentation states that HMAC_CTX_init() is mandatory.
> 
> http://www.openssl.org/docs/crypto/hmac.html
> 
> HMAC_CTX_init() initialises a HMAC_CTX before first use. It must be called. 
> HMAC_CTX_init() must have been called before the first use of an HMAC_CTX in this function. N.B. HMAC_Init() had this undocumented behaviour in previous versions of OpenSSL - failure to switch to HMAC_Init_ex() in programs that expect it will cause them to stop working
> 
> While this appears to cause no issues with OpenSSH 5.6p1 using OpenSSL 1.0.0a and the default crypto engine,
> it may cause problems (such as segfaults in my case) when attempting to use an alternative engine.
> -- 
> Robert Dugal??????????????????????? Senior Software Developer
> Certicom Corp.???????????????????   A Subsidiary of Research In Motion 
> rdugal at certicom.com
> direct????????905.501.3848
> fax?? ??????????905.507.4230
> www.certicom.com
> 
> 
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Iain Morgan

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

From rdugal at certicom.com  Thu Sep  8 00:34:46 2011
From: rdugal at certicom.com (Robert Dugal)
Date: Wed, 7 Sep 2011 10:34:46 -0400
Subject: cipher_get_keycontext() and cipher_set_keycontext() copying OpenSSL
 RC4 cryptographic state
Message-ID: <7C6BDB4BD9974646856544650C016B8209DF0E93@XCH117CNC.rim.net>

These two functions in cipher.c (I have looked at openssh5.8p1 & openssh5.9p1) copy the internal cryptographic state of an OpenSSL RC4 encryption/decryption context using simple memcpy().  
This code also copies the state when evptype is EVP_acss, which I am unfamiliar with.
This code appears to works fine when using the builtin crypto of OpenSSL 1.0.0d.  
However, I have been doing some work to make OpenSSH use alternative crypto engines and it appears to me that this code may not work correctly when using an OpenSSL engine.
The cipher_data could contain pointers to other data objects so just copying the cipher_data is not going to work correctly.  

OpenSSL provides EVP_CIPHER_CTX_copy() which can be used to safely copy the cryptographic state of an EVP_CIPHER_CTX. 
This API will call an engine specific interface to perform the copy, if required by the engine, ensuring that the cipher_data is copied correctly.
It's unclear exactly how EVP_CIPHER_CTX_copy() can be used in the OpenSSH code. 

It's unclear to me exactly under which situations cipher_get_keycontext() and cipher_set_keycontext() will be called.
Can someone provide me with some instructions on how I could configure an OpenSSH linux installation to verify this will be an issue when using an engine?
Once I have verified this is an issue I will file a bug.

Thanks
Rob

-- 
Robert Dugal	Team Lead SSL & PKI Group
Certicom Corp.	A Subsidiary of Research In Motion
                  4701 Tahoe Blvd., Building A
                  Mississauga, ON
                  L4W 0B5

rdugal at certicom.com
direct       	+1.289.261.4148
mobile      	+1.416.276.8062
main         	+1.905.507.4220
fax             	+1.905.507.4230
www.certicom.com

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

From rdugal at certicom.com  Thu Sep  8 23:33:24 2011
From: rdugal at certicom.com (Robert Dugal)
Date: Thu, 8 Sep 2011 09:33:24 -0400
Subject: ssh_SSLeay_add_all_algorithms() 
Message-ID: <7C6BDB4BD9974646856544650C016B8209DF11E0@XCH117CNC.rim.net>

I am confused on how ssh_SSLeay_add_all_algorithms() get used in the ssh applications for openssh-5.7p1 and later releases.
I don't see any of the applications making calls to ssh_SSLeay_add_all_algorithms().
There is a macro that redefines SSLeay_add_all_algorithms() to ssh_SSLeay_add_all_algorithms() but I don't see any code calling SSLeay_add_all_algorithms().


In openssh-5.6p1 and earlier releases (I looked as far back as openssh-4.7p1) all these sources below have calls to SSLeay_add_all_algorithms(), 
which means that when configured --with-ssl-engine would get replaced as ssh_SSLeay_add_all_algorithms():
ssh-add.c 
ssh-agent.c
ssh-keygen.c
ssh-keysign.c
ssh.c
sshd.c

But starting with openssh-5.7p1 these calls are all gone.
Is this a bug or can anyone explain how this should work in 5.6p1 and later?   

SSLeay_add_all_algorithms() is replaced with OpenSSL_add_all_algorithms().

-- 
Robert Dugal	Team Lead SSL & PKI Group
Certicom Corp.	A Subsidiary of Research In Motion
                  4701 Tahoe Blvd., Building A
                  Mississauga, ON
                  L4W 0B5
 
rdugal at certicom.com
direct???????	+1.289.261.4148
mobile??????	+1.416.276.8062
main ??? ????	+1.905.507.4220
fax?? ??????????	+1.905.507.4230
www.certicom.com



---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

From rdugal at certicom.com  Thu Sep  8 23:49:02 2011
From: rdugal at certicom.com (Robert Dugal)
Date: Thu, 8 Sep 2011 09:49:02 -0400
Subject: ssh_SSLeay_add_all_algorithms() 
Message-ID: <7C6BDB4BD9974646856544650C016B8209DF11F8@XCH117CNC.rim.net>

Please disregard my earlier post. I believe I have figured out the answer myself.

It looks like beginning with 5.7p1 calls to SSLeay_add_all_algorithms() were replaced with OpenSSL_add_all_algorithms().
In OpenSSL 1.0.0d the include file evp.h then redefines OpenSSL_add_all_algorithms() to either OPENSSL_add_all_algorithms_conf() or OPENSSL_add_all_algorithms_noconf() depending on whether OPENSSL_LOAD_CONF is defined. It also defines SSLeay_add_all_algorithms() as OpenSSL_add_all_algorithms().
OPENSSL_add_all_algorithms_conf() is basically equivalent to ssh_SSLeay_add_all_algorithms().

So ssh_SSLeay_add_all_algorithms() isn't needed with OpenSSL 1.0.0d and probably for several other versions of openssl. 



-- 
Robert Dugal	Team Lead SSL & PKI Group
Certicom Corp.	A Subsidiary of Research In Motion
		4701 Tahoe Blvd., Building A
		Mississauga, ON
		L4W 0B5
 
rdugal at certicom.com
direct???????	+1.289.261.4148
mobile??????	+1.416.276.8062
main ??? ????	+1.905.507.4220
fax?? ??????????	+1.905.507.4230
www.certicom.com


-----Original Message-----
From: Robert Dugal 
Sent: Thursday, September 08, 2011 9:33 AM
To: openssh-unix-dev at mindrot.org
Subject: ssh_SSLeay_add_all_algorithms() 

I am confused on how ssh_SSLeay_add_all_algorithms() get used in the ssh applications for openssh-5.7p1 and later releases.
I don't see any of the applications making calls to ssh_SSLeay_add_all_algorithms().
There is a macro that redefines SSLeay_add_all_algorithms() to ssh_SSLeay_add_all_algorithms() but I don't see any code calling SSLeay_add_all_algorithms().


In openssh-5.6p1 and earlier releases (I looked as far back as openssh-4.7p1) all these sources below have calls to SSLeay_add_all_algorithms(), 
which means that when configured --with-ssl-engine would get replaced as ssh_SSLeay_add_all_algorithms():
ssh-add.c 
ssh-agent.c
ssh-keygen.c
ssh-keysign.c
ssh.c
sshd.c

But starting with openssh-5.7p1 these calls are all gone.
Is this a bug or can anyone explain how this should work in 5.6p1 and later?   

SSLeay_add_all_algorithms() is replaced with OpenSSL_add_all_algorithms().

-- 
Robert Dugal	Team Lead SSL & PKI Group
Certicom Corp.	A Subsidiary of Research In Motion
                  4701 Tahoe Blvd., Building A
                  Mississauga, ON
                  L4W 0B5
 
rdugal at certicom.com
direct???????	+1.289.261.4148
mobile??????	+1.416.276.8062
main ??? ????	+1.905.507.4220
fax?? ??????????	+1.905.507.4230
www.certicom.com



---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

From openssh at roumenpetrov.info  Fri Sep  9 04:47:29 2011
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Thu, 08 Sep 2011 21:47:29 +0300
Subject: ssh_SSLeay_add_all_algorithms()
In-Reply-To: <7C6BDB4BD9974646856544650C016B8209DF11F8@XCH117CNC.rim.net>
References: <7C6BDB4BD9974646856544650C016B8209DF11F8@XCH117CNC.rim.net>
Message-ID: <4E690DC1.10708@roumenpetrov.info>

Robert Dugal wrote:
> Please disregard my earlier post. I believe I have figured out the answer myself.
>
> It looks like beginning with 5.7p1 calls to SSLeay_add_all_algorithms() were replaced with OpenSSL_add_all_algorithms().
> In OpenSSL 1.0.0d the include file evp.h then redefines OpenSSL_add_all_algorithms() to either OPENSSL_add_all_algorithms_conf() or OPENSSL_add_all_algorithms_noconf() depending on whether OPENSSL_LOAD_CONF is defined. It also defines SSLeay_add_all_algorithms() as OpenSSL_add_all_algorithms().
> OPENSSL_add_all_algorithms_conf() is basically equivalent to ssh_SSLeay_add_all_algorithms().
>
> So ssh_SSLeay_add_all_algorithms() isn't needed with OpenSSL 1.0.0d and probably for several other versions of openssl.
>    

The difference is if you configure with --enable-engine (see 
openssl-compat.h).

Roumen


-- 
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/


From openssh at roumenpetrov.info  Fri Sep  9 04:52:19 2011
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Thu, 08 Sep 2011 21:52:19 +0300
Subject: ssh_SSLeay_add_all_algorithms()
In-Reply-To: <4E690DC1.10708@roumenpetrov.info>
References: <7C6BDB4BD9974646856544650C016B8209DF11F8@XCH117CNC.rim.net>
 <4E690DC1.10708@roumenpetrov.info>
Message-ID: <4E690EE3.8090305@roumenpetrov.info>

P.S. correction flag is  --with-ssl-engine

Roumen Petrov wrote:
> Robert Dugal wrote:
>> Please disregard my earlier post. I believe I have figured out the 
>> answer myself.
>>
>> It looks like beginning with 5.7p1 calls to 
>> SSLeay_add_all_algorithms() were replaced with 
>> OpenSSL_add_all_algorithms().
>> In OpenSSL 1.0.0d the include file evp.h then redefines 
>> OpenSSL_add_all_algorithms() to either 
>> OPENSSL_add_all_algorithms_conf() or 
>> OPENSSL_add_all_algorithms_noconf() depending on whether 
>> OPENSSL_LOAD_CONF is defined. It also defines 
>> SSLeay_add_all_algorithms() as OpenSSL_add_all_algorithms().
>> OPENSSL_add_all_algorithms_conf() is basically equivalent to 
>> ssh_SSLeay_add_all_algorithms().
>>
>> So ssh_SSLeay_add_all_algorithms() isn't needed with OpenSSL 1.0.0d 
>> and probably for several other versions of openssl.
>
> The difference is if you configure with --enable-engine (see 
> openssl-compat.h).
>
> Roumen


-- 
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/


From openssh at roumenpetrov.info  Fri Sep  9 02:39:03 2011
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Thu, 08 Sep 2011 19:39:03 +0300
Subject: Announce: X.509 certificates support v7.0 for OpenSSH version 5.9p1
Message-ID: <4E68EFA7.20601@roumenpetrov.info>

Hi All,

Version 7.0 of "X.509 certificates support in OpenSSH" is ready for 
immediate download.

This version allow client to use certificates and keys stored into 
external devices. The implementation is based on openssl dynamic engines.

For instance E_NSS engine ( http://developer.berlios.de/projects/enss ) 
will allow you to
use certificates and keys from Firefox, SeaMonkey, Thunderbird security 
database to authenticate to remote hosts.


Regards,
Roumen Petrov


-- 
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/




From qus123 at gmail.com  Fri Sep  9 01:24:10 2011
From: qus123 at gmail.com (=?ISO-8859-2?Q?Przemys=B3aw_Szczygielski?=)
Date: Thu, 8 Sep 2011 17:24:10 +0200
Subject: Dynamic port remote listener - a BUG?
Message-ID: <CAD+sJOP8Turg+MxE0RYXj=m5WU1Yy1Ve=ncxRUKOwpeVKjAGQw@mail.gmail.com>

Hello,

Today I tried using "dynamically assigned" port for remote listener, by
requesting listener on port 0. This is supposed to create a listener on a
port choosen by server. Everything seemed OK (the choosen port was sent back
to client), but forwarding was refused. So I checked the source.

in channels.c, function: channel_setup_fwd_listener

                /*
                 * listen_port == 0 requests a dynamically allocated port -
                 * record what we got.
                 */
                if (type == SSH_CHANNEL_RPORT_LISTENER && listen_port == 0
&&
                    allocated_listen_port != NULL &&
                    *allocated_listen_port == 0) {
                        *allocated_listen_port = get_sock_port(sock, 1);
                        debug("Allocated listen port %d",
                            *allocated_listen_port);
                }

                /* Allocate a channel number for the socket. */
                c = channel_new("port listener", type, sock, sock, -1,
                    CHAN_TCP_WINDOW_DEFAULT, CHAN_TCP_PACKET_DEFAULT,
                    0, "port listener", 1);
                c->path = xstrdup(host);
                c->host_port = port_to_connect;
                c->listening_port = listen_port;
                success = 1;
        }
        if (success == 0)
                error("channel_setup_fwd_listener: cannot listen to port:
%d",
                    listen_port);
        freeaddrinfo(aitop);
        return success;
}

As you see allocated_listen_port gets assigned to some free port, but
then... nothing more happens with allocated_listen_port, because
c->listening_port is set to listen_port, which in this case equals 0. (note
that listen_port IS NOT set to allocated_listen_port!)

But then again - I am not a programmer. So I might be wrong.

From djm at mindrot.org  Fri Sep  9 20:18:15 2011
From: djm at mindrot.org (Damien Miller)
Date: Fri, 9 Sep 2011 20:18:15 +1000 (EST)
Subject: Dynamic port remote listener - a BUG?
In-Reply-To: <CAD+sJOP8Turg+MxE0RYXj=m5WU1Yy1Ve=ncxRUKOwpeVKjAGQw@mail.gmail.com>
References: <CAD+sJOP8Turg+MxE0RYXj=m5WU1Yy1Ve=ncxRUKOwpeVKjAGQw@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1109092017040.32133@natsu.mindrot.org>


> Hello,
> 
> Today I tried using "dynamically assigned" port for remote listener, by
> requesting listener on port 0. This is supposed to create a listener on a
> port choosen by server. Everything seemed OK (the choosen port was sent back
> to client), but forwarding was refused. So I checked the source.

it works for me on both portable and OpenBSD, with -R forwardings on
the initial ssh commandline or set up using -O forward.

> in channels.c, function: channel_setup_fwd_listener
> 
>                 /*
>                  * listen_port == 0 requests a dynamically allocated port -
>                  * record what we got.
>                  */
>                 if (type == SSH_CHANNEL_RPORT_LISTENER && listen_port == 0
> &&
>                     allocated_listen_port != NULL &&
>                     *allocated_listen_port == 0) {
>                         *allocated_listen_port = get_sock_port(sock, 1);
>                         debug("Allocated listen port %d",
>                             *allocated_listen_port);
>                 }
> 
>                 /* Allocate a channel number for the socket. */
>                 c = channel_new("port listener", type, sock, sock, -1,
>                     CHAN_TCP_WINDOW_DEFAULT, CHAN_TCP_PACKET_DEFAULT,
>                     0, "port listener", 1);
>                 c->path = xstrdup(host);
>                 c->host_port = port_to_connect;
>                 c->listening_port = listen_port;
>                 success = 1;
>         }
>         if (success == 0)
>                 error("channel_setup_fwd_listener: cannot listen to port:
> %d",
>                     listen_port);
>         freeaddrinfo(aitop);
>         return success;
> }
> 
> As you see allocated_listen_port gets assigned to some free port, but
> then... nothing more happens with allocated_listen_port, because
> c->listening_port is set to listen_port, which in this case equals 0. (note
> that listen_port IS NOT set to allocated_listen_port!)
> 
> But then again - I am not a programmer. So I might be wrong.

listen_port isn't used for all that much, the important thing is the
sock that is bound to the listening port.

-d

From djm at mindrot.org  Fri Sep  9 20:24:20 2011
From: djm at mindrot.org (Damien Miller)
Date: Fri, 9 Sep 2011 20:24:20 +1000 (EST)
Subject: Dynamic port remote listener - a BUG?
In-Reply-To: <alpine.BSO.2.00.1109092017040.32133@natsu.mindrot.org>
References: <CAD+sJOP8Turg+MxE0RYXj=m5WU1Yy1Ve=ncxRUKOwpeVKjAGQw@mail.gmail.com>
 <alpine.BSO.2.00.1109092017040.32133@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.00.1109092022410.32133@natsu.mindrot.org>

On Fri, 9 Sep 2011, Damien Miller wrote:

> 
> > Hello,
> > 
> > Today I tried using "dynamically assigned" port for remote listener, by
> > requesting listener on port 0. This is supposed to create a listener on a
> > port choosen by server. Everything seemed OK (the choosen port was sent back
> > to client), but forwarding was refused. So I checked the source.
> 
> it works for me on both portable and OpenBSD, with -R forwardings on
> the initial ssh commandline or set up using -O forward.

there is a bug in there though - is more than one -R 0:... foward is
created, the later ones will all direct their connections to the
destination specified for the first -R0 forward.

i'll look at it when i have slept...

-d

From djm at mindrot.org  Fri Sep  9 20:44:04 2011
From: djm at mindrot.org (Damien Miller)
Date: Fri, 9 Sep 2011 20:44:04 +1000 (EST)
Subject: Dynamic port remote listener - a BUG?
In-Reply-To: <alpine.BSO.2.00.1109092022410.32133@natsu.mindrot.org>
References: <CAD+sJOP8Turg+MxE0RYXj=m5WU1Yy1Ve=ncxRUKOwpeVKjAGQw@mail.gmail.com>
 <alpine.BSO.2.00.1109092017040.32133@natsu.mindrot.org>
 <alpine.BSO.2.00.1109092022410.32133@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.00.1109092041150.32133@natsu.mindrot.org>

On Fri, 9 Sep 2011, Damien Miller wrote:

> On Fri, 9 Sep 2011, Damien Miller wrote:
> 
> > 
> > > Hello,
> > > 
> > > Today I tried using "dynamically assigned" port for remote listener, by
> > > requesting listener on port 0. This is supposed to create a listener on a
> > > port choosen by server. Everything seemed OK (the choosen port was sent back
> > > to client), but forwarding was refused. So I checked the source.
> > 
> > it works for me on both portable and OpenBSD, with -R forwardings on
> > the initial ssh commandline or set up using -O forward.
> 
> there is a bug in there though - is more than one -R 0:... foward is
> created, the later ones will all direct their connections to the
> destination specified for the first -R0 forward.
> 
> i'll look at it when i have slept...

Couldn't get to sleep. 

The problem is our s->c forwarded-tcpip channel opens use a listen_port
of 0, which causes client_request_forwarded_tcpip()->
channel_connect_by_listen_address() to always return the same destination.

So we should set c->listening_port, but we need to fix up permitted_opens
when we receive the open confirmation message otherwise the client will
refuse the requests. I think this will break backwards compat for -R 0...
forwardings from a new server (>=openssh-6.0) to an older client, since
the older clients expect a listen_port of 0 in the channel open messages.
We could do a compat.[ch] hack or live with the breakage...

-d

From rdugal at certicom.com  Fri Sep  9 20:46:59 2011
From: rdugal at certicom.com (Robert Dugal)
Date: Fri, 9 Sep 2011 06:46:59 -0400
Subject: ssh_SSLeay_add_all_algorithms()
In-Reply-To: <4E690EE3.8090305@roumenpetrov.info>
References: <7C6BDB4BD9974646856544650C016B8209DF11F8@XCH117CNC.rim.net>
 <4E690DC1.10708@roumenpetrov.info> <4E690EE3.8090305@roumenpetrov.info>
Message-ID: <7C6BDB4BD9974646856544650C016B8209DF1507@XCH117CNC.rim.net>

I am using the --with-ssl-engine option when I configure.
However, because the ssh apps no longer call SSLeay_add_all_algorithms() this option basically does nothing. The option will result in ssh_SSLeay_add_all_algorithms() code being compiled but because there are no references to that function in the ssh apps, in most cases it will get stripped from the ssh apps.

The ssh apps call OpenSSL_add_all_algorithms() which is not affected by the preprocessor definitions added by the --with-ssl-engine option.
I looked at openssl 1.0.0d and openssl 0.9.7a. 
They both define OpenSSL_add_all_algorithms() as OPENSSL_add_all_algorithms_conf() or OPENSSL_add_all_algorithms_noconf() depending on whether OPENSSL_LOAD_CONF is defined.

-- 
Robert Dugal	Team Lead SSL & PKI Group
Certicom Corp.	A Subsidiary of Research In Motion
		4701 Tahoe Blvd., Building A
		Mississauga, ON
		L4W 0B5
 
rdugal at certicom.com
direct???????	+1.289.261.4148
mobile??????	+1.416.276.8062
main ??? ????	+1.905.507.4220
fax?? ??????????	+1.905.507.4230
www.certicom.com


-----Original Message-----
From: Roumen Petrov [mailto:openssh at roumenpetrov.info] 
Sent: Thursday, September 08, 2011 2:52 PM
To: Robert Dugal
Cc: OpenSSH Devel List
Subject: Re: ssh_SSLeay_add_all_algorithms()

P.S. correction flag is  --with-ssl-engine

Roumen Petrov wrote:
> Robert Dugal wrote:
>> Please disregard my earlier post. I believe I have figured out the 
>> answer myself.
>>
>> It looks like beginning with 5.7p1 calls to 
>> SSLeay_add_all_algorithms() were replaced with 
>> OpenSSL_add_all_algorithms().
>> In OpenSSL 1.0.0d the include file evp.h then redefines 
>> OpenSSL_add_all_algorithms() to either 
>> OPENSSL_add_all_algorithms_conf() or 
>> OPENSSL_add_all_algorithms_noconf() depending on whether 
>> OPENSSL_LOAD_CONF is defined. It also defines 
>> SSLeay_add_all_algorithms() as OpenSSL_add_all_algorithms().
>> OPENSSL_add_all_algorithms_conf() is basically equivalent to 
>> ssh_SSLeay_add_all_algorithms().
>>
>> So ssh_SSLeay_add_all_algorithms() isn't needed with OpenSSL 1.0.0d 
>> and probably for several other versions of openssl.
>
> The difference is if you configure with --enable-engine (see 
> openssl-compat.h).
>
> Roumen


-- 
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

From molson at atlantis.oceanconsulting.com  Sat Sep 10 03:03:23 2011
From: molson at atlantis.oceanconsulting.com (Matt Olson)
Date: Fri, 9 Sep 2011 10:03:23 -0700 (PDT)
Subject: SSH Compression - Block Deduplication
Message-ID: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>

Hello,

I did a search against the list archive and didn't see any comments on the 
topic of using deduplication as a compression algorithm.  This is just a 
suggestion for the developers to think about.  Block de-duplication is 
found in higher end WAN gear.  The idea is to mantain an indexed 
dictionary of data blocks.  If a matching block is found prior to 
transmission, a token (hash id) is sent in it's place to reduce the amount 
of data transmitted.  Each side of the connection builds and maintains 
this dictionary.  This would be done to data blocks before they are 
encrypted.

Optimal systems go beyond using fixed block sizes and look for variable 
length data block that occur frequently.  For an initial implementation, 
fix block sizes are probably fine.

In the WAN scenario, the dictionaries are retained and built up over time 
to optimize performance.

This may run somewhat contrary to the goals of OpenSSH, namely privacy. 
Retention of data in a memory or disk cache may not be desirable. 
However, certain work loads would stand to benefit from this type of 
compression.

I would suggest a default of per-session only cache/dictionary with a 
switch to enable a persistent disk based cache/dictionary.  Dictionaries 
would probably be maintained seperately on a per host basis.

My hope is that this sort of compression would greatly help remote X11 
display.  Latency and the chatty nature of X11 is still an issue.  But 
this would help with painting of bitmap patterns.

Matt




From dan at doxpara.com  Sat Sep 10 08:56:58 2011
From: dan at doxpara.com (Dan Kaminsky)
Date: Fri, 9 Sep 2011 15:56:58 -0700
Subject: SSH Compression - Block Deduplication
In-Reply-To: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
Message-ID: <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>

Deduplication is a fairly domain specific technology -- it works well for
files that are shared across multiple users (a context that's about as
distant from SSH as you can imagine) and for a few protocols that move large
blocks of data repeatedly (X11).  But even in the latter case, efficient
protocols like NoMachine's do much better, as they're deeply protocol aware.
 SSH is most likely the wrong layer for this work -- in general, gzip
captures most of the compression gain, and in the specific cases where it
doesn't, the work is too specific to be done generically (thus special
accelerators for each protocol in WAN gear).

On Fri, Sep 9, 2011 at 10:03 AM, Matt Olson <
molson at atlantis.oceanconsulting.com> wrote:

> Hello,
>
> I did a search against the list archive and didn't see any comments on the
> topic of using deduplication as a compression algorithm.  This is just a
> suggestion for the developers to think about.  Block de-duplication is found
> in higher end WAN gear.  The idea is to mantain an indexed dictionary of
> data blocks.  If a matching block is found prior to transmission, a token
> (hash id) is sent in it's place to reduce the amount of data transmitted.
>  Each side of the connection builds and maintains this dictionary.  This
> would be done to data blocks before they are encrypted.
>
> Optimal systems go beyond using fixed block sizes and look for variable
> length data block that occur frequently.  For an initial implementation, fix
> block sizes are probably fine.
>
> In the WAN scenario, the dictionaries are retained and built up over time
> to optimize performance.
>
> This may run somewhat contrary to the goals of OpenSSH, namely privacy.
> Retention of data in a memory or disk cache may not be desirable. However,
> certain work loads would stand to benefit from this type of compression.
>
> I would suggest a default of per-session only cache/dictionary with a
> switch to enable a persistent disk based cache/dictionary.  Dictionaries
> would probably be maintained seperately on a per host basis.
>
> My hope is that this sort of compression would greatly help remote X11
> display.  Latency and the chatty nature of X11 is still an issue.  But this
> would help with painting of bitmap patterns.
>
> Matt
>
>
>
> ______________________________**_________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/**mailman/listinfo/openssh-unix-**dev<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
>

From dtucker at zip.com.au  Sat Sep 10 13:58:35 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 10 Sep 2011 13:58:35 +1000
Subject: ssh_SSLeay_add_all_algorithms()
In-Reply-To: <7C6BDB4BD9974646856544650C016B8209DF1507@XCH117CNC.rim.net>
References: <7C6BDB4BD9974646856544650C016B8209DF11F8@XCH117CNC.rim.net>
 <4E690DC1.10708@roumenpetrov.info> <4E690EE3.8090305@roumenpetrov.info>
 <7C6BDB4BD9974646856544650C016B8209DF1507@XCH117CNC.rim.net>
Message-ID: <CALDDTe0YKUAO8gdxa3LqPYvEQDvQA_2-E=7fVt0+Ho3h5ifCyA@mail.gmail.com>

On Fri, Sep 9, 2011 at 8:46 PM, Robert Dugal <rdugal at certicom.com> wrote:
> I am using the --with-ssl-engine option when I configure.
> However, because the ssh apps no longer call SSLeay_add_all_algorithms()
> this option basically does nothing.

FYI that was fixed for the 5.9p1 release:
http://anoncvs.mindrot.org/index.cgi/openssh/openbsd-compat/openssl-compat.c?r1=1.13&r2=1.14

-- 
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 loganaden at gmail.com  Sun Sep 11 19:04:15 2011
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Sun, 11 Sep 2011 13:04:15 +0400
Subject: sftp memory leak patch
Message-ID: <CAOp4FwTZ=1Upkr72UKtLJ3y1hV-AeG-PmoraekyS9aNG46JbFw@mail.gmail.com>

Hi,

I was wondering if there were issues with this
diff:

https://bugzilla.mindrot.org/show_bug.cgi?id=1921

-- 
`` Real men run current !''

From phorminx at web.de  Sun Sep 11 22:55:14 2011
From: phorminx at web.de (phorminx at web.de)
Date: Sun, 11 Sep 2011 14:55:14 +0200 (CEST)
Subject: scp fails after sending command: scp -v -t
Message-ID: <515322457.597173.1315745714424.JavaMail.fmail@mwmweb031>

> Thanks for the quick reply. Unfortunately, reducing the MTU on the
> client and server side to 576 (default was 1500) did not solve my
> problem.

Is there possibly anything else I can do to address this problem?

I can add that by now I have checked that the problem exists only
at the place where I'll spent most of my time the next couple of
months. When I take my laptop elsewhere, scp works fine. So I am yet
more confident that the problem is not caused by a change of
configuration of one or both computers between which I want to
establish an scp connection. But it appears to be caused by the
interplay between scp and the internet access provided by the place
where I stay. (And the ssh connection established by rsync also
fails -- which is too bad for my normal work!)

Any help is greatly appreciated!
___________________________________________________________
Schon geh?rt? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

From jchadima at redhat.com  Mon Sep 12 16:48:41 2011
From: jchadima at redhat.com (Jan F. Chadima)
Date: Mon, 12 Sep 2011 08:48:41 +0200
Subject: scp fails after sending command: scp -v -t
In-Reply-To: <515322457.597173.1315745714424.JavaMail.fmail@mwmweb031>
References: <515322457.597173.1315745714424.JavaMail.fmail@mwmweb031>
Message-ID: <E8DD0621-4577-46D8-9AFB-FE9BCD2B55B9@redhat.com>


On Sep 11, 2011, at 2:55 PM, phorminx at web.de wrote:

>> Thanks for the quick reply. Unfortunately, reducing the MTU on the
>> client and server side to 576 (default was 1500) did not solve my
>> problem.
> 
> Is there possibly anything else I can do to address this problem?
> 
> I can add that by now I have checked that the problem exists only
> at the place where I'll spent most of my time the next couple of
> months. When I take my laptop elsewhere, scp works fine. So I am yet
> more confident that the problem is not caused by a change of
> configuration of one or both computers between which I want to
> establish an scp connection. But it appears to be caused by the
> interplay between scp and the internet access provided by the place
> where I stay. (And the ssh connection established by rsync also
> fails -- which is too bad for my normal work!)
> 
> Any help is greatly appreciated!

We had a similar case caused by a firewall which worked poorly with the change of the TCP window.



> ___________________________________________________________
> Schon geh?rt? WEB.DE hat einen genialen Phishing-Filter in die
> Toolbar eingebaut! http://produkte.web.de/go/toolbar
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Jan F. Chadima
jchadima at redhat.com




From phorminx at web.de  Mon Sep 12 17:53:23 2011
From: phorminx at web.de (phorminx at web.de)
Date: Mon, 12 Sep 2011 09:53:23 +0200 (CEST)
Subject: scp fails after sending command: scp -v -t
Message-ID: <320052112.910602.1315814003046.JavaMail.fmail@mwmweb032>

> We had a similar case caused by a firewall which worked poorly
> with the change of the TCP window.

Were you ever able to solve this problem while this firewall was
in place? Your email sounds as if the problem went away only when
you got a new firewall.

Oh well...
___________________________________________________________
Schon geh?rt? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

From dtucker at zip.com.au  Mon Sep 12 18:27:44 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 12 Sep 2011 18:27:44 +1000
Subject: scp fails after sending command: scp -v -t
In-Reply-To: <E8DD0621-4577-46D8-9AFB-FE9BCD2B55B9@redhat.com>
References: <515322457.597173.1315745714424.JavaMail.fmail@mwmweb031>
 <E8DD0621-4577-46D8-9AFB-FE9BCD2B55B9@redhat.com>
Message-ID: <CALDDTe1GKVy9UMX9hnT-Hg+dAJ5Jd13W7tM+LR5QocwjnUV9KQ@mail.gmail.com>

On Mon, Sep 12, 2011 at 4:48 PM, Jan F. Chadima <jchadima at redhat.com> wrote:
[...]
> We had a similar case caused by a firewall which worked poorly with the change of the TCP window.

oh, great idea!  a misconfigured stateful firewall can screw up TCP
window scaling.  You can test this by disabling window scaling on
either end (exactly how is platform dependent, on Linux it's usually
"sysctl net.ipv4.tcp_adv_win_scale=0"

I should add an FAQ entry with these suggestions.

-- 
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 molson at atlantis.oceanconsulting.com  Tue Sep 13 01:26:41 2011
From: molson at atlantis.oceanconsulting.com (Matt Olson)
Date: Mon, 12 Sep 2011 08:26:41 -0700 (PDT)
Subject: SSH Compression - Block Deduplication
In-Reply-To: <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
Message-ID: <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>

Dan,

All perfectly valid points.

Nomachine, being a commercial product, is not likely to achieve ubiquity.

I agree that SSH may not be the ideal layer.  SSH support for X11 
forwarding implies some level of interest by the community in X11 
tunneling.  The thought behind implementing deduplication is that it is 
likely a significant aid to X11 traffic and may provide some benefit to 
other workloads as well.

I may look around and see if I can find a library that does another layer 
of tunneling or a Xorg addon to provide deduplication.

Thanks for your comments.

Matt


On Fri, 9 Sep 2011, Dan Kaminsky wrote:

> 
> Deduplication is a fairly domain specific technology -- it works well for files that are shared across multiple users (a context that's about as
> distant from SSH as you can imagine) and for a few protocols that move large blocks of data repeatedly (X11). ?But even in the latter case,
> efficient protocols like NoMachine's do much better, as they're deeply protocol aware. ?SSH is most likely the wrong layer for this work -- in
> general, gzip captures most of the compression gain, and in the specific cases where it doesn't, the work is too specific to be done generically
> (thus special accelerators for each protocol in WAN gear).
>

From gert at greenie.muc.de  Tue Sep 13 01:58:29 2011
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 12 Sep 2011 17:58:29 +0200
Subject: SSH Compression - Block Deduplication
In-Reply-To: <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
Message-ID: <20110912155829.GP8496@greenie.muc.de>

Hi,

On Mon, Sep 12, 2011 at 08:26:41AM -0700, Matt Olson wrote:
> I may look around and see if I can find a library that does another layer 
> of tunneling or a Xorg addon to provide deduplication.

Doesn't gzip compression suit your needs?  This already does fairly
thorough deduplication - not on a "per block level" but on a "per byte
sequence" level, so much more flexible...

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From molson at atlantis.oceanconsulting.com  Tue Sep 13 05:55:30 2011
From: molson at atlantis.oceanconsulting.com (Matt Olson)
Date: Mon, 12 Sep 2011 12:55:30 -0700 (PDT)
Subject: SSH Compression - Block Deduplication
In-Reply-To: <20110912155829.GP8496@greenie.muc.de>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912155829.GP8496@greenie.muc.de>
Message-ID: <alpine.LFD.2.02.1109121211560.30047@atlantis.oceanconsulting.com>

Hi Gert,

Let me start by saying I'm not an expert in gzip compression internals.

For others to read along:

http://www.gzip.org/algorithm.txt

(RE: LZ77) Distance of 32k and lengths (essentially variable block) of 258 
bytes are both quite small when talking about graphics data.  With moderm 
processors and memory, it would be interesting to see how this performs 
with distance of 4MB and length of 32k.  Those fit well within modern L2 
and L1 caches respectively.

Of course the actualy distance and length values balance a race between 
CPU time and network latency.  Example: if it takes 500ms to 
search the last 4MB for duplicates when your network is 100ms latency, 
then you really haven't gained anything in apparent speed; you have 
only conserved bandwidth.

WAN accelerator deduplication data dictionaries are much larger and can 
cache patterns found within the entire (or multiple) session(s).

However, LZ77 with larger distance and length values do have the speed 
advantage of not having to go to main memory or disk.  I think 4MB/32KB 
would be useful with X11 and be an interesting test.

Matt


On Mon, 12 Sep 2011, Gert Doering wrote:

> Hi,
>
> On Mon, Sep 12, 2011 at 08:26:41AM -0700, Matt Olson wrote:
>> I may look around and see if I can find a library that does another layer
>> of tunneling or a Xorg addon to provide deduplication.
>
> Doesn't gzip compression suit your needs?  This already does fairly
> thorough deduplication - not on a "per block level" but on a "per byte
> sequence" level, so much more flexible...
>
> gert
> -- 
> USENET is *not* the non-clickable part of WWW!
>                                                           //www.muc.de/~gert/
> Gert Doering - Munich, Germany                             gert at greenie.muc.de
> fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
>

From dan at doxpara.com  Tue Sep 13 07:09:04 2011
From: dan at doxpara.com (Dan Kaminsky)
Date: Mon, 12 Sep 2011 14:09:04 -0700
Subject: SSH Compression - Block Deduplication
In-Reply-To: <alpine.LFD.2.02.1109121211560.30047@atlantis.oceanconsulting.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912155829.GP8496@greenie.muc.de>
 <alpine.LFD.2.02.1109121211560.30047@atlantis.oceanconsulting.com>
Message-ID: <B0433F0F-6908-442D-87D7-F8F67B003916@doxpara.com>

I can't speak for everyone, but a new compression mode with 75% of the efficiency of NoMachine but 10% of the complexity wouldn't scare me, especially since it'd be a post-auth codebase. The thing to do would be to look at, say, 100MB of X traffic and see if there are indeed massive duplicated blocks in the stream.  

Sent from my iPhone

On Sep 12, 2011, at 12:55 PM, Matt Olson <molson at atlantis.oceanconsulting.com> wrote:

> Hi Gert,
> 
> Let me start by saying I'm not an expert in gzip compression internals.
> 
> For others to read along:
> 
> http://www.gzip.org/algorithm.txt
> 
> (RE: LZ77) Distance of 32k and lengths (essentially variable block) of 258 bytes are both quite small when talking about graphics data.  With moderm processors and memory, it would be interesting to see how this performs with distance of 4MB and length of 32k.  Those fit well within modern L2 and L1 caches respectively.
> 
> Of course the actualy distance and length values balance a race between CPU time and network latency.  Example: if it takes 500ms to search the last 4MB for duplicates when your network is 100ms latency, then you really haven't gained anything in apparent speed; you have only conserved bandwidth.
> 
> WAN accelerator deduplication data dictionaries are much larger and can cache patterns found within the entire (or multiple) session(s).
> 
> However, LZ77 with larger distance and length values do have the speed advantage of not having to go to main memory or disk.  I think 4MB/32KB would be useful with X11 and be an interesting test.
> 
> Matt
> 
> 
> On Mon, 12 Sep 2011, Gert Doering wrote:
> 
>> Hi,
>> 
>> On Mon, Sep 12, 2011 at 08:26:41AM -0700, Matt Olson wrote:
>>> I may look around and see if I can find a library that does another layer
>>> of tunneling or a Xorg addon to provide deduplication.
>> 
>> Doesn't gzip compression suit your needs?  This already does fairly
>> thorough deduplication - not on a "per block level" but on a "per byte
>> sequence" level, so much more flexible...
>> 
>> gert
>> -- 
>> USENET is *not* the non-clickable part of WWW!
>>                                                          //www.muc.de/~gert/
>> Gert Doering - Munich, Germany                             gert at greenie.muc.de
>> fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
>> 

From phorminx at web.de  Tue Sep 13 07:57:10 2011
From: phorminx at web.de (phorminx at web.de)
Date: Mon, 12 Sep 2011 23:57:10 +0200 (CEST)
Subject: scp fails after sending command: scp -v -t
Message-ID: <435236756.702981.1315864630823.JavaMail.fmail@mwmweb024>

> oh, great idea! a misconfigured stateful firewall can screw up TCP
> window scaling. You can test this by disabling window scaling on
> either end (exactly how is platform dependent, on Linux it's usually
> "sysctl net.ipv4.tcp_adv_win_scale=0"

Thanks! Actually, if I understand the tcp man page correctly, it
should be net.ipv4.tcp_window_scaling, and sysctl requires `-w'.
Anyway, unfortunately this does not work for me? :-(

I am certainly not an expert for such things. Nonetheless,
what really irritates me about this is that I can use ssh in certain
ways to transfer arbitrary amounts of data without any problems.
Only some other ways that I'd prefer to use are failing.

___________________________________________________________
Schon geh?rt? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

From jchadima at redhat.com  Tue Sep 13 08:35:04 2011
From: jchadima at redhat.com (Jan F. Chadima)
Date: Tue, 13 Sep 2011 00:35:04 +0200
Subject: scp fails after sending command: scp -v -t
In-Reply-To: <435236756.702981.1315864630823.JavaMail.fmail@mwmweb024>
References: <435236756.702981.1315864630823.JavaMail.fmail@mwmweb024>
Message-ID: <D497C96A-A177-42F7-B745-C3A1B312EBCF@redhat.com>


On Sep 12, 2011, at 11:57 PM, phorminx at web.de wrote:

>> oh, great idea! a misconfigured stateful firewall can screw up TCP
>> window scaling. You can test this by disabling window scaling on
>> either end (exactly how is platform dependent, on Linux it's usually
>> "sysctl net.ipv4.tcp_adv_win_scale=0"
> 
> Thanks! Actually, if I understand the tcp man page correctly, it
> should be net.ipv4.tcp_window_scaling, and sysctl requires `-w'.
> Anyway, unfortunately this does not work for me  :-(
> 

for modern linux is relevant pseudo file
/proc/sys/net/ipv4/tcp_window_scaling
if you see there something other than 0
you have tcp window scaling enabled.
echo "0" > $this_file switch it off.


> I am certainly not an expert for such things. Nonetheless,
> what really irritates me about this is that I can use ssh in certain
> ways to transfer arbitrary amounts of data without any problems.
> Only some other ways that I'd prefer to use are failing.
> 
> ___________________________________________________________
> Schon geh?rt? WEB.DE hat einen genialen Phishing-Filter in die
> Toolbar eingebaut! http://produkte.web.de/go/toolbar
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Jan F. Chadima
jchadima at redhat.com




From morty at frakir.org  Tue Sep 13 08:53:25 2011
From: morty at frakir.org (Morty Abzug)
Date: Mon, 12 Sep 2011 18:53:25 -0400
Subject: SSH Compression - Block Deduplication
In-Reply-To: <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
Message-ID: <20110912225325.GA3742@red-sonja>

On Mon, Sep 12, 2011 at 08:26:41AM -0700, Matt Olson wrote:

> Nomachine, being a commercial product, is not likely to achieve ubiquity.
[snip]
> I may look around and see if I can find a library that does another
> layer of tunneling or a Xorg addon to provide deduplication.

Have you looked at VNC?  Especially the x11vnc implementation, in
service mode, with "Tight" encoding.  IME, one gets amazingly good
performance via that specific combination.  Use it in service mode and
you can do one master port redirection instead of per-user port
redirection.  This makes X11 useful even over slow WAN links.

If you have a COTS WAN dedupe, I would be curious to see how raw x11 +
block dedupe does against VNC in Tight encoding mode with a poorly
behaved app, such as wireshark with gtk2+.  X11 has at least three
subtleties that create unnecessary traffic: (1) X11 applications can
redraw themselves even when there has been no change within the app;
(2) applications can communicate all kinds of data to the X server
that isn't actually user-visible; (3) pointer movements result in a
lot of data traffic across the network.  Block-level dedupe can, at
best, only reduce that traffic.  Tight VNC can completely eliminate
the first two, and enormously reduce most of the need for the latter.
So I would expect Tight VNC to perform better than block dedupe.  But
a test would be a lot better. . .

That said, setting up VNC currently requires additional effort.  Doing
something like this transparently in openssh would save a lot of
trouble.

- Morty

From molson at atlantis.oceanconsulting.com  Wed Sep 14 02:28:24 2011
From: molson at atlantis.oceanconsulting.com (Matt Olson)
Date: Tue, 13 Sep 2011 09:28:24 -0700 (PDT)
Subject: SSH Compression - Block Deduplication
In-Reply-To: <20110912225325.GA3742@red-sonja>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
Message-ID: <alpine.LFD.2.02.1109130808490.25634@atlantis.oceanconsulting.com>

Morty,

There are good alternatives like VNC with better performance.  When 
working with a lot of hosts, VNC requires setup on each (as you 
indicated).  X is ready to fire up as soon as you login.

x11vnc: at your suggestion I tried it.  Performance is very good, if you 
want to display the entire desktop.

I think the X11 client/server model is cleaner from the user point of 
view.  It's the only GUI implementation I know of that actually splits 
display from the application in a client/server model; which allows you to 
work with applications from multiple hosts seemlessly in a single 
window manager.  I do think this model is cleaner from the user 
perspective and deserves continued support.

X11 is dated, has security and performance issues, all the normal 
criticisms.

The approach of possibly improving gzip/LZ77 performance still semms like 
it might be worth while and have value beyond X11 tunneling.

Matt

On Mon, 12 Sep 2011, Morty Abzug wrote:

> On Mon, Sep 12, 2011 at 08:26:41AM -0700, Matt Olson wrote:
>
>> Nomachine, being a commercial product, is not likely to achieve ubiquity.
> [snip]
>> I may look around and see if I can find a library that does another
>> layer of tunneling or a Xorg addon to provide deduplication.
>
> Have you looked at VNC?  Especially the x11vnc implementation, in
> service mode, with "Tight" encoding.  IME, one gets amazingly good
> performance via that specific combination.  Use it in service mode and
> you can do one master port redirection instead of per-user port
> redirection.  This makes X11 useful even over slow WAN links.
>
> If you have a COTS WAN dedupe, I would be curious to see how raw x11 +
> block dedupe does against VNC in Tight encoding mode with a poorly
> behaved app, such as wireshark with gtk2+.  X11 has at least three
> subtleties that create unnecessary traffic: (1) X11 applications can
> redraw themselves even when there has been no change within the app;
> (2) applications can communicate all kinds of data to the X server
> that isn't actually user-visible; (3) pointer movements result in a
> lot of data traffic across the network.  Block-level dedupe can, at
> best, only reduce that traffic.  Tight VNC can completely eliminate
> the first two, and enormously reduce most of the need for the latter.
> So I would expect Tight VNC to perform better than block dedupe.  But
> a test would be a lot better. . .
>
> That said, setting up VNC currently requires additional effort.  Doing
> something like this transparently in openssh would save a lot of
> trouble.
>
> - Morty
>

From dan at doxpara.com  Wed Sep 14 12:27:01 2011
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 13 Sep 2011 19:27:01 -0700
Subject: SSH Compression - Block Deduplication
In-Reply-To: <CAOCN9rxYsYr-dZ_Wg4rVm0cAYaNWp0VMQOvq5Rf00sFsNQD8vQ@mail.gmail.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
 <CAOCN9rxYsYr-dZ_Wg4rVm0cAYaNWp0VMQOvq5Rf00sFsNQD8vQ@mail.gmail.com>
Message-ID: <CAEW7AC=dUOZ66vNv1NxRA-T98_PYY=M7bwu5BFfE+FhxtQ-_tA@mail.gmail.com>

>
> NX's security model is much better, and you can review it. But all the
> freeware versions of NX are abandonware, and many of them do rude
> things to dead farm animals in the process. Do not get me *started* on
> the Google code published "neatx" toolkit. And *all* of them rely on
> the older GPL published NX from NoMachine.
>
> I did have some concerns about their default NX private/public key
> management for the original SSH connection as the "nx" user, to open
> the session, but that can actually be replaced pretty easily if you're
> concerned.
>

SSH provides an excellent security model for X; I wouldn't object at all to
tearing the security out of NX *or* VNC and making either of them dependent
on what SSH provides.

From nkadel at gmail.com  Wed Sep 14 12:20:37 2011
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Tue, 13 Sep 2011 22:20:37 -0400
Subject: SSH Compression - Block Deduplication
In-Reply-To: <20110912225325.GA3742@red-sonja>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
Message-ID: <CAOCN9rxYsYr-dZ_Wg4rVm0cAYaNWp0VMQOvq5Rf00sFsNQD8vQ@mail.gmail.com>

On Mon, Sep 12, 2011 at 6:53 PM, Morty Abzug <morty at frakir.org> wrote:
> On Mon, Sep 12, 2011 at 08:26:41AM -0700, Matt Olson wrote:
>
>> Nomachine, being a commercial product, is not likely to achieve ubiquity.
> [snip]
>> I may look around and see if I can find a library that does another
>> layer of tunneling or a Xorg addon to provide deduplication.
>
> Have you looked at VNC? ?Especially the x11vnc implementation, in
> service mode, with "Tight" encoding. ?IME, one gets amazingly good
> performance via that specific combination. ?Use it in service mode and
> you can do one master port redirection instead of per-user port
> redirection. ?This makes X11 useful even over slow WAN links.

I wrote the first published SunOS port of VNC, and more recently took
apart NX for RHEL usas, along with a number of the freeware
implementations. All the freeware uses are abandonware, and NX does
provide a *very* effective wrapper and integration of optimized and
stable X services for multiple platforms, much improved over raw X11
tunneling and with ligher and more stable behavior, without the
amazing expense of commercial products, especially the very expensive
and bloated 'eXodus' software for Windows users, which charges extra
for SSH integration.

Unfortunately, the default implementation of VNC has a truly horrible
security model with manually generated passwords stored in
$HOME/.vnc/, which share all the flaws of a publicly readable
.htpasswd file. There's no way to ensure password quality nor
expiration, and they're typically encrypted only with DES. Since far
too many people use their personal user password as their VNC
password, it creates a vulnerability for anyone who can access
$HOME/.vnc to crack the password.

NX's security model is much better, and you can review it. But all the
freeware versions of NX are abandonware, and many of them do rude
things to dead farm animals in the process. Do not get me *started* on
the Google code published "neatx" toolkit. And *all* of them rely on
the older GPL published NX from NoMachine.

I did have some concerns about their default NX private/public key
management for the original SSH connection as the "nx" user, to open
the session, but that can actually be replaced pretty easily if you're
concerned.

From djm at mindrot.org  Wed Sep 14 12:35:53 2011
From: djm at mindrot.org (Damien Miller)
Date: Wed, 14 Sep 2011 12:35:53 +1000 (EST)
Subject: SSH Compression - Block Deduplication
In-Reply-To: <CAOCN9rxYsYr-dZ_Wg4rVm0cAYaNWp0VMQOvq5Rf00sFsNQD8vQ@mail.gmail.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
 <CAOCN9rxYsYr-dZ_Wg4rVm0cAYaNWp0VMQOvq5Rf00sFsNQD8vQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1109141231340.8313@natsu.mindrot.org>

On Tue, 13 Sep 2011, Nico Kadel-Garcia wrote:

> Unfortunately, the default implementation of VNC has a truly horrible
> security model with manually generated passwords stored in
> $HOME/.vnc/, which share all the flaws of a publicly readable
> .htpasswd file. There's no way to ensure password quality nor
> expiration, and they're typically encrypted only with DES. Since far
> too many people use their personal user password as their VNC
> password, it creates a vulnerability for anyone who can access
> $HOME/.vnc to crack the password.

Since we are talking SSH here, it should be easy to hack a VNC client
to execute a server and talk to it on stdin/out*. At this point it is
easy to stuck a ssh invocation in the pipeline to eliminate the need
for listening ports or random passwords laying around on the server.

As for more compression methods. I suppose we could consider them
if they were a) post-auth only (like zlib at openssh.com); b) totally
compelling from the persepectives of compression ratio and speed; and
c) BSD/MIT licensed.

-d

From nkadel at gmail.com  Wed Sep 14 14:07:09 2011
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Wed, 14 Sep 2011 00:07:09 -0400
Subject: SSH Compression - Block Deduplication
In-Reply-To: <CAEW7AC=dUOZ66vNv1NxRA-T98_PYY=M7bwu5BFfE+FhxtQ-_tA@mail.gmail.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
 <CAOCN9rxYsYr-dZ_Wg4rVm0cAYaNWp0VMQOvq5Rf00sFsNQD8vQ@mail.gmail.com>
 <CAEW7AC=dUOZ66vNv1NxRA-T98_PYY=M7bwu5BFfE+FhxtQ-_tA@mail.gmail.com>
Message-ID: <CAOCN9ryTqT6zRbbUWKL+vQ20-rXjargdegEHd=z5uUmL_XQ8mA@mail.gmail.com>

On Tue, Sep 13, 2011 at 10:27 PM, Dan Kaminsky <dan at doxpara.com> wrote:
>> NX's security model is much better, and you can review it. But all the
>> freeware versions of NX are abandonware, and many of them do rude
>> things to dead farm animals in the process. Do not get me *started* on
>> the Google code published "neatx" toolkit. And *all* of them rely on
>> the older GPL published NX from NoMachine.
>>
>> I did have some concerns about their default NX private/public key
>> management for the original SSH connection as the "nx" user, to open
>> the session, but that can actually be replaced pretty easily if you're
>> concerned.
>
> SSH provides an excellent security model for X; I wouldn't object at all to
> tearing the security out of NX *or* VNC and making either of them dependent
> on what SSH provides.

Dan, NX *uses* SSH. It has a dedicated "nx" user with an sshd on an
alternative port, with a public/private user key pair and host key
management, dedicated back end that manages passing along
authentication via normal sytem enabled means, such as anything
supported by PAM, to the individual user authentication.

Basically, the X-Windows compression and user management is already
done. If someone wants to write it from scratch, they can try, but I
don't recommend it. And X is one of the few SSH access techniques
where bandwidth squeezing is most helpful.

From dan at doxpara.com  Wed Sep 14 14:20:47 2011
From: dan at doxpara.com (Dan Kaminsky)
Date: Tue, 13 Sep 2011 21:20:47 -0700
Subject: SSH Compression - Block Deduplication
In-Reply-To: <CAOCN9ryTqT6zRbbUWKL+vQ20-rXjargdegEHd=z5uUmL_XQ8mA@mail.gmail.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
 <CAOCN9rxYsYr-dZ_Wg4rVm0cAYaNWp0VMQOvq5Rf00sFsNQD8vQ@mail.gmail.com>
 <CAEW7AC=dUOZ66vNv1NxRA-T98_PYY=M7bwu5BFfE+FhxtQ-_tA@mail.gmail.com>
 <CAOCN9ryTqT6zRbbUWKL+vQ20-rXjargdegEHd=z5uUmL_XQ8mA@mail.gmail.com>
Message-ID: <3A63CB47-795A-4162-970D-0A173D12C042@doxpara.com>



Sent from my iPhone

On Sep 13, 2011, at 9:07 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Tue, Sep 13, 2011 at 10:27 PM, Dan Kaminsky <dan at doxpara.com> wrote:
>>> NX's security model is much better, and you can review it. But all the
>>> freeware versions of NX are abandonware, and many of them do rude
>>> things to dead farm animals in the process. Do not get me *started* on
>>> the Google code published "neatx" toolkit. And *all* of them rely on
>>> the older GPL published NX from NoMachine.
>>> 
>>> I did have some concerns about their default NX private/public key
>>> management for the original SSH connection as the "nx" user, to open
>>> the session, but that can actually be replaced pretty easily if you're
>>> concerned.
>> 
>> SSH provides an excellent security model for X; I wouldn't object at all to
>> tearing the security out of NX *or* VNC and making either of them dependent
>> on what SSH provides.
> 
> Dan, NX *uses* SSH. It has a dedicated "nx" user with an sshd on an
> alternative port, with a public/private user key pair and host key
> management, dedicated back end that manages passing along
> authentication via normal sytem enabled means, such as anything
> supported by PAM, to the individual user authentication.
> 
> Basically, the X-Windows compression and user management is already
> done. If someone wants to write it from scratch, they can try, but I
> don't recommend it. And X is one of the few SSH access techniques
> where bandwidth squeezing is most helpful.

I'm sure NX isn't impossible to deploy, but its dependencies (including the nx user) do form a barrier to entry.

Meanwhile, ssh -X just works.

What's basically being talked about, is leveraging ssh user auth instead of leaving users to NX to multiplex. It's not necessarily a better approach, but it might potentially be simpler, and thus distributable by default (which NX has not been).

Of course it's possible that licensing prevents direct integration, in which case I'd imagine the client using a XCompressConmand provider and the server opening a channel to a serverside binary. Less elegant, though. 

What I think everyone can agree on, is that it's technically feasible to compress X better. Whether it's interesting to do so, is another story.

From ehimawan at gmail.com  Wed Sep 14 23:44:26 2011
From: ehimawan at gmail.com (Erwin Himawan)
Date: Wed, 14 Sep 2011 08:44:26 -0500
Subject: Announce: X.509 certificates support v7.0 for OpenSSH version
 5.9p1
In-Reply-To: <4E68EFA7.20601@roumenpetrov.info>
References: <4E68EFA7.20601@roumenpetrov.info>
Message-ID: <CAFY=A47w_82eBKv13eAHc51N3LPWvxmbg967oq5wmQtzMbrZQw@mail.gmail.com>

Hi Roumen,

Does Ver 7.0 support X509 with ECC key (prime256v1)?

Supposing, that ver 7.0 supports ECC key, is the procedure for configuring
x509-based openssh with ECC key is similar when configuring it wirh RSA
keypair?
Should I use openssl ver 1.0.0.d to build the openssh?

Thanks in advanced.

Regards,
Erwin

On Thu, Sep 8, 2011 at 11:39 AM, Roumen Petrov <openssh at roumenpetrov.info>wrote:

> Hi All,
>
> Version 7.0 of "X.509 certificates support in OpenSSH" is ready for
> immediate download.
>
> This version allow client to use certificates and keys stored into external
> devices. The implementation is based on openssl dynamic engines.
>
> For instance E_NSS engine ( http://developer.berlios.de/**projects/enss<http://developer.berlios.de/projects/enss>) will allow you to
> use certificates and keys from Firefox, SeaMonkey, Thunderbird security
> database to authenticate to remote hosts.
>
>
> Regards,
> Roumen Petrov
>
>
> --
> Get X.509 certificates support in OpenSSH:
> http://roumenpetrov.info/**openssh/ <http://roumenpetrov.info/openssh/>
>
>
>
> ______________________________**_________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/**mailman/listinfo/openssh-unix-**dev<https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev>
>

From dan at doxpara.com  Thu Sep 15 10:05:46 2011
From: dan at doxpara.com (Dan Kaminsky)
Date: Wed, 14 Sep 2011 17:05:46 -0700
Subject: SSH Compression - Block Deduplication
In-Reply-To: <CAOCN9ryTqT6zRbbUWKL+vQ20-rXjargdegEHd=z5uUmL_XQ8mA@mail.gmail.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
 <CAOCN9rxYsYr-dZ_Wg4rVm0cAYaNWp0VMQOvq5Rf00sFsNQD8vQ@mail.gmail.com>
 <CAEW7AC=dUOZ66vNv1NxRA-T98_PYY=M7bwu5BFfE+FhxtQ-_tA@mail.gmail.com>
 <CAOCN9ryTqT6zRbbUWKL+vQ20-rXjargdegEHd=z5uUmL_XQ8mA@mail.gmail.com>
Message-ID: <CEFE053B-A80F-4EEC-ABBC-D16BAC15433E@doxpara.com>

As a note, I asked around. X over ssh has a significant userbase.  A better compressor for it would absolutely be useful. 

Sent from my iPhone

On Sep 13, 2011, at 9:07 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Tue, Sep 13, 2011 at 10:27 PM, Dan Kaminsky <dan at doxpara.com> wrote:
>>> NX's security model is much better, and you can review it. But all the
>>> freeware versions of NX are abandonware, and many of them do rude
>>> things to dead farm animals in the process. Do not get me *started* on
>>> the Google code published "neatx" toolkit. And *all* of them rely on
>>> the older GPL published NX from NoMachine.
>>> 
>>> I did have some concerns about their default NX private/public key
>>> management for the original SSH connection as the "nx" user, to open
>>> the session, but that can actually be replaced pretty easily if you're
>>> concerned.
>> 
>> SSH provides an excellent security model for X; I wouldn't object at all to
>> tearing the security out of NX *or* VNC and making either of them dependent
>> on what SSH provides.
> 
> Dan, NX *uses* SSH. It has a dedicated "nx" user with an sshd on an
> alternative port, with a public/private user key pair and host key
> management, dedicated back end that manages passing along
> authentication via normal sytem enabled means, such as anything
> supported by PAM, to the individual user authentication.
> 
> Basically, the X-Windows compression and user management is already
> done. If someone wants to write it from scratch, they can try, but I
> don't recommend it. And X is one of the few SSH access techniques
> where bandwidth squeezing is most helpful.

From nkadel at gmail.com  Thu Sep 15 10:44:05 2011
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Wed, 14 Sep 2011 20:44:05 -0400
Subject: SSH Compression - Block Deduplication
In-Reply-To: <3A63CB47-795A-4162-970D-0A173D12C042@doxpara.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
 <CAOCN9rxYsYr-dZ_Wg4rVm0cAYaNWp0VMQOvq5Rf00sFsNQD8vQ@mail.gmail.com>
 <CAEW7AC=dUOZ66vNv1NxRA-T98_PYY=M7bwu5BFfE+FhxtQ-_tA@mail.gmail.com>
 <CAOCN9ryTqT6zRbbUWKL+vQ20-rXjargdegEHd=z5uUmL_XQ8mA@mail.gmail.com>
 <3A63CB47-795A-4162-970D-0A173D12C042@doxpara.com>
Message-ID: <CAOCN9rwSe8iC0hi+rgpvN73VVhM+==TfLzSDUNDzMVxOk_SLNg@mail.gmail.com>

On Wed, Sep 14, 2011 at 12:20 AM, Dan Kaminsky <dan at doxpara.com> wrote:

>> Dan, NX *uses* SSH. It has a dedicated "nx" user with an sshd on an
>> alternative port, with a public/private user key pair and host key
>> management, dedicated back end that manages passing along
>> authentication via normal sytem enabled means, such as anything
>> supported by PAM, to the individual user authentication.
>>
>> Basically, the X-Windows compression and user management is already
>> done. If someone wants to write it from scratch, they can try, but I
>> don't recommend it. And X is one of the few SSH access techniques
>> where bandwidth squeezing is most helpful.
>
> I'm sure NX isn't impossible to deploy, but its dependencies (including the nx user) do form a barrier to entry.
>
> Meanwhile, ssh -X just works.

Mostly. Many X servers for non-UNIX and Linux systems are norrrible
and expensive, and the NX "client" with the embedded X server is very
good by comparison (and free).  And the variety of extremely poorly
managed X configurations creates tremendous security issues. The
common use of "xhost +", for example, to allow multiple user access
has been a popular security bad habit for many years. And the NX
server provides access control over the number of X sessions and
authorized users, separate from the list of users who have normal
shell access, even restricting the number of sessions per user and
allowing graceful reconnection to the *same* X sessions if a temporary
interruption occurs. VNC permits that, but quite badly, and individual
users can conflict with each other for the same port.

This level of control is very is very useful for shared servers, where
users have a bad tendency to leave their X sessions behind,
unattended, from multiple clients.

> What's basically being talked about, is leveraging ssh user auth instead of leaving users to NX to multiplex. It's not necessarily a better approach, but it might potentially be simpler, and thus distributable by default (which NX has not been).

True. Only the older GPL versions have been available to even try to
port to OpenBSD, which I might take a shot at if I can find the time.
Unfortunately, I don't see any bundles for the new version 4.x for any
of the BSD (unless you count MacOs as a FreeBSD variant).

Too bad it's not under GPL anymore. The ability to port across
platforms has been a very useful aspect of such licenses.

> Of course it's possible that licensing prevents direct integration, in which case I'd imagine the client using a XCompressConmand provider and the server opening a channel to a serverside binary. Less elegant, though.
>
> What I think everyone can agree on, is that it's technically feasible to compress X better. Whether it's interesting to do so, is another story.

*Interesting* is perhaps not the point.  *Useful*, and *feasible*, are
stronger points. A customized client with a built-in X server, such as
VNC or NX use, has historically been effective and has avoided the
protocol mangling necessary for optimizing SSH or SSL further. I just
think that NX has done a better job, already, than any reasonably
competent single developer can achieve, even if they're as smart as,
for example, me.

From morty at frakir.org  Thu Sep 15 13:50:36 2011
From: morty at frakir.org (Morty Abzug)
Date: Wed, 14 Sep 2011 23:50:36 -0400
Subject: SSH Compression - Block Deduplication
In-Reply-To: <alpine.LFD.2.02.1109130808490.25634@atlantis.oceanconsulting.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
 <alpine.LFD.2.02.1109130808490.25634@atlantis.oceanconsulting.com>
Message-ID: <20110915035035.GA20030@red-sonja>

On Tue, Sep 13, 2011 at 09:28:24AM -0700, Matt Olson wrote:

> It's the only GUI implementation I know of that actually splits
> display from the application in a client/server model; which allows
> you to work with applications from multiple hosts seemlessly in a
> single window manager.

I've read that recent application sharing implementations from both
Citrix and Microsoft have incorporated this feature.

> The approach of possibly improving gzip/LZ77 performance still semms
> like it might be worth while and have value beyond X11 tunneling.

FWIW, I would also love to see performance improvements for ssh
tunneling of raw X11.  I'm recommending x11vnc (and note
tightvncviewer's -via option) as a workaround, not as a solution.

While a compression approach would certain help, please note that
there are a lot of X11 performance problems that cannot be solved with
compression.  For example, some applications display a whole bunch of
status updates at startup.  Those updates display in seconds to a
local display, but can take hours when played over a slow WAN link.
Compression might help, but realistically, not by more than a factor
of 10 or so.  The tight VNC approach of implementing a virtual
framebuffer and sending compressed updates only as needed effectively
eliminates the status updates altogether.  If that can somehow be
implemented transparently via openssh, it would be a big win.
[Although maybe this is more easily done in X11 itself.]

- Morty

From alex at alex.org.uk  Thu Sep 15 16:24:03 2011
From: alex at alex.org.uk (Alex Bligh)
Date: Thu, 15 Sep 2011 07:24:03 +0100
Subject: SSH Compression - Block Deduplication
In-Reply-To: <CEFE053B-A80F-4EEC-ABBC-D16BAC15433E@doxpara.com>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
 <CAOCN9rxYsYr-dZ_Wg4rVm0cAYaNWp0VMQOvq5Rf00sFsNQD8vQ@mail.gmail.com>
 <CAEW7AC=dUOZ66vNv1NxRA-T98_PYY=M7bwu5BFfE+FhxtQ-_tA@mail.gmail.com>
 <CAOCN9ryTqT6zRbbUWKL+vQ20-rXjargdegEHd=z5uUmL_XQ8mA@mail.gmail.com>
 <CEFE053B-A80F-4EEC-ABBC-D16BAC15433E@doxpara.com>
Message-ID: <2C4AAFEACD3E222EFA63DB9E@nimrod.local>



--On 14 September 2011 17:05:46 -0700 Dan Kaminsky <dan at doxpara.com> wrote:

> As a note, I asked around. X over ssh has a significant userbase.  A
> better compressor for it would absolutely be useful.

My understanding is that most of the "compression" (in the sense of
bandwidth reduction) in NX came from nxproxy (i.e. running a proxy
server on the client, and sending less stuff i.e. only differences)
rather than data stream compression in the conventional sense.

I'm taking it the reason not to try bzip2 compression its ability to
eat CPU.

-- 
Alex Bligh

From molson at atlantis.oceanconsulting.com  Fri Sep 16 02:40:45 2011
From: molson at atlantis.oceanconsulting.com (Matt Olson)
Date: Thu, 15 Sep 2011 09:40:45 -0700 (PDT)
Subject: SSH Compression - Block Deduplication
In-Reply-To: <20110915035035.GA20030@red-sonja>
References: <alpine.LFD.2.02.1109090935310.7014@atlantis.oceanconsulting.com>
 <CAEW7ACnyOKcdLK6Ecm4VfgCQEhweVQc9UizYk7mYzNhMW6PBzg@mail.gmail.com>
 <alpine.LFD.2.02.1109120809390.30047@atlantis.oceanconsulting.com>
 <20110912225325.GA3742@red-sonja>
 <alpine.LFD.2.02.1109130808490.25634@atlantis.oceanconsulting.com>
 <20110915035035.GA20030@red-sonja>
Message-ID: <alpine.LFD.2.02.1109150901190.23166@atlantis.oceanconsulting.com>


On Wed, 14 Sep 2011, Morty Abzug wrote:

> On Tue, Sep 13, 2011 at 09:28:24AM -0700, Matt Olson wrote:
>
>> The approach of possibly improving gzip/LZ77 performance still semms
>> like it might be worth while and have value beyond X11 tunneling.
>
> While a compression approach would certain help, please note that
> there are a lot of X11 performance problems that cannot be solved with
> compression.

My thing is not so much compression for the sake of bandwidth, rather, to 
eliminate latency which is at the core of X11 remote performance problems.

Example: transmission from host A (any number of bytes) which takes 100ms 
to fully transmit to host B; if host A can hash transmission data block, 
find that block in the cache, transmit a token all in 25ms total time from 
host A to host B, then you're effective reduced the amount of latency, as 
well as reduce the amount of data to transmit.

It's a tall order for the hosts on each end to process data fast enough to 
do this.  But modern hardware has also come a long way.

Personally I'm not in favor of adding compression or RFB specifically for 
X11.  I'd rather see a generalized solution, like block deduplication, 
that has potential benefits for other use cases.

X11 has problems.  A highly interactive protocol with serially dependent 
operations will suffer from any significant increase in network latency; 
I.e. under 1-2ms for local networks vs 25-250ms for wide area networks. 
There's no getting around that without fixing X11.

Matt

From openssh at roumenpetrov.info  Fri Sep 16 05:54:57 2011
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Thu, 15 Sep 2011 22:54:57 +0300
Subject: Announce: X.509 certificates support v7.0 for OpenSSH version
 5.9p1
In-Reply-To: <CAFY=A47w_82eBKv13eAHc51N3LPWvxmbg967oq5wmQtzMbrZQw@mail.gmail.com>
References: <4E68EFA7.20601@roumenpetrov.info>
 <CAFY=A47w_82eBKv13eAHc51N3LPWvxmbg967oq5wmQtzMbrZQw@mail.gmail.com>
Message-ID: <4E725811.202@roumenpetrov.info>

Erwin Himawan wrote:
> Hi Roumen,
>
> Does Ver 7.0 support X509 with ECC key (prime256v1)?
>
> Supposing, that ver 7.0 supports ECC key, is the procedure for configuring
> x509-based openssh with ECC key is similar when configuring it wirh RSA
> keypair?
> Should I use openssl ver 1.0.0.d to build the openssh?
>
> Thanks in advanced.
>
> Regards,
> Erwin

RFC 6187 (March 2011, X.509v3 Certificates for Secure Shell 
Authentication) is not implemented yet.

Roumen


From loganaden at gmail.com  Sat Sep 17 02:42:13 2011
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Fri, 16 Sep 2011 20:42:13 +0400
Subject: weird make errors on portable snapshots
Message-ID: <CAOp4FwS6JaWNj_L=5zJfyaC=wBA4k374r8AM4=c=U6qFuq-Nhw@mail.gmail.com>

When doing a make with the portable developer version,
I came across this error:


ssh/ssh_host_ecdsa_key|/opt/etc/ssh_host_ecdsa_key|g'  -e
's|/etc/ssh/ssh_host_dsa_key|/opt/etc/ssh_host_dsa_key|g'  -e
's|/etc/ssh/ssh_host_rsa_key|/opt/etc/ssh_host_rsa_key|g'  -e
's|/var/run/sshd.pid|/var/run/sshd.pid|g'  -e
's|/etc/moduli|/opt/etc/moduli|g'  -e
's|/etc/ssh/moduli|/opt/etc/moduli|g'  -e
's|/etc/ssh/sshrc|/opt/etc/sshrc|g'  -e
's|/usr/X11R6/bin/xauth|/usr/X11R6/bin/xauth|g'  -e
's|/var/empty|/var/empty|g'  -e 's|/usr/bin:/bin:/usr/sbin:/sbin||g'
${manpage} > moduli.5.out;  fi
sed: ./moduli.0: No such file or directory
*** Error code 1

Stop in /diff/openssh (line 187 of Makefile).

If I run make again, it compiles but fails for scp
-e 's|/usr/libexec|/opt/libexec|g'  -e
's|/etc/shosts.equiv|/opt/etc/shosts.equiv|g'  -e
's|/etc/ssh/ssh_host_key|/opt/etc/ssh_host_key|g'  -e
's|/etc/ssh/ssh_host_ecdsa_key|/opt/etc/ssh_host_ecdsa_key|g'  -e
's|/etc/ssh/ssh_host_dsa_key|/opt/etc/ssh_host_dsa_key|g'  -e
's|/etc/ssh/ssh_host_rsa_key|/opt/etc/ssh_host_rsa_key|g'  -e
's|/var/run/sshd.pid|/var/run/sshd.pid|g'  -e
's|/etc/moduli|/opt/etc/moduli|g'  -e
's|/etc/ssh/moduli|/opt/etc/moduli|g'  -e
's|/etc/ssh/sshrc|/opt/etc/sshrc|g'  -e
's|/usr/X11R6/bin/xauth|/usr/X11R6/bin/xauth|g'  -e
's|/var/empty|/var/empty|g'  -e 's|/usr/bin:/bin:/usr/sbin:/sbin||g'
${manpage} > scp.1.out;  fi
sed: ./scp.0: No such file or directory

This goes on until it compiles completely.


-- 
`` Real men run current !''

From g.esp at free.fr  Sat Sep 17 03:34:02 2011
From: g.esp at free.fr (Gilles Espinasse)
Date: Fri, 16 Sep 2011 19:34:02 +0200
Subject: weird make errors on portable snapshots
References: <CAOp4FwS6JaWNj_L=5zJfyaC=wBA4k374r8AM4=c=U6qFuq-Nhw@mail.gmail.com>
Message-ID: <0cbb01cc7496$d478ba60$f9b5a8c0@pii350>


----- Original Message ----- 
From: "Loganaden Velvindron" <loganaden at gmail.com>
To: <openssh-unix-dev at mindrot.org>
Sent: Friday, September 16, 2011 6:42 PM
Subject: weird make errors on portable snapshots


> When doing a make with the portable developer version,
> I came across this error:
> 
> 
> ssh/ssh_host_ecdsa_key|/opt/etc/ssh_host_ecdsa_key|g'  -e
> 's|/etc/ssh/ssh_host_dsa_key|/opt/etc/ssh_host_dsa_key|g'  -e
> 's|/etc/ssh/ssh_host_rsa_key|/opt/etc/ssh_host_rsa_key|g'  -e
> 's|/var/run/sshd.pid|/var/run/sshd.pid|g'  -e
> 's|/etc/moduli|/opt/etc/moduli|g'  -e
> 's|/etc/ssh/moduli|/opt/etc/moduli|g'  -e
> 's|/etc/ssh/sshrc|/opt/etc/sshrc|g'  -e
> 's|/usr/X11R6/bin/xauth|/usr/X11R6/bin/xauth|g'  -e
> 's|/var/empty|/var/empty|g'  -e 's|/usr/bin:/bin:/usr/sbin:/sbin||g'
> ${manpage} > moduli.5.out;  fi
> sed: ./moduli.0: No such file or directory
> *** Error code 1
> 
> Stop in /diff/openssh (line 187 of Makefile).
> 
> If I run make again, it compiles but fails for scp
> -e 's|/usr/libexec|/opt/libexec|g'  -e
> 's|/etc/shosts.equiv|/opt/etc/shosts.equiv|g'  -e
> 's|/etc/ssh/ssh_host_key|/opt/etc/ssh_host_key|g'  -e
> 's|/etc/ssh/ssh_host_ecdsa_key|/opt/etc/ssh_host_ecdsa_key|g'  -e
> 's|/etc/ssh/ssh_host_dsa_key|/opt/etc/ssh_host_dsa_key|g'  -e
> 's|/etc/ssh/ssh_host_rsa_key|/opt/etc/ssh_host_rsa_key|g'  -e
> 's|/var/run/sshd.pid|/var/run/sshd.pid|g'  -e
> 's|/etc/moduli|/opt/etc/moduli|g'  -e
> 's|/etc/ssh/moduli|/opt/etc/moduli|g'  -e
> 's|/etc/ssh/sshrc|/opt/etc/sshrc|g'  -e
> 's|/usr/X11R6/bin/xauth|/usr/X11R6/bin/xauth|g'  -e
> 's|/var/empty|/var/empty|g'  -e 's|/usr/bin:/bin:/usr/sbin:/sbin||g'
> ${manpage} > scp.1.out;  fi
> sed: ./scp.0: No such file or directory
> 
> This goes on until it compiles completely.
> 
> 
Which sed version, on which plateform?

Gilles

From loganaden at gmail.com  Sat Sep 17 14:53:11 2011
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Sat, 17 Sep 2011 08:53:11 +0400
Subject: weird make errors on portable snapshots
In-Reply-To: <0cbb01cc7496$d478ba60$f9b5a8c0@pii350>
References: <CAOp4FwS6JaWNj_L=5zJfyaC=wBA4k374r8AM4=c=U6qFuq-Nhw@mail.gmail.com>
 <0cbb01cc7496$d478ba60$f9b5a8c0@pii350>
Message-ID: <CAOp4FwTPv-dy4Oaw-dhJ_65yCeuZmqExmsWB0HekpcqAPGwEfA@mail.gmail.com>

OpenBSD 4.9

Sed is the one shipped with OpenBSD 4.9-release. No
patches whatsoever applied.

On Fri, Sep 16, 2011 at 9:34 PM, Gilles Espinasse <g.esp at free.fr> wrote:
>
> ----- Original Message -----
> From: "Loganaden Velvindron" <loganaden at gmail.com>
> To: <openssh-unix-dev at mindrot.org>
> Sent: Friday, September 16, 2011 6:42 PM
> Subject: weird make errors on portable snapshots
>
>
>> When doing a make with the portable developer version,
>> I came across this error:
>>
>>
>> ssh/ssh_host_ecdsa_key|/opt/etc/ssh_host_ecdsa_key|g' ?-e
>> 's|/etc/ssh/ssh_host_dsa_key|/opt/etc/ssh_host_dsa_key|g' ?-e
>> 's|/etc/ssh/ssh_host_rsa_key|/opt/etc/ssh_host_rsa_key|g' ?-e
>> 's|/var/run/sshd.pid|/var/run/sshd.pid|g' ?-e
>> 's|/etc/moduli|/opt/etc/moduli|g' ?-e
>> 's|/etc/ssh/moduli|/opt/etc/moduli|g' ?-e
>> 's|/etc/ssh/sshrc|/opt/etc/sshrc|g' ?-e
>> 's|/usr/X11R6/bin/xauth|/usr/X11R6/bin/xauth|g' ?-e
>> 's|/var/empty|/var/empty|g' ?-e 's|/usr/bin:/bin:/usr/sbin:/sbin||g'
>> ${manpage} > moduli.5.out; ?fi
>> sed: ./moduli.0: No such file or directory
>> *** Error code 1
>>
>> Stop in /diff/openssh (line 187 of Makefile).
>>
>> If I run make again, it compiles but fails for scp
>> -e 's|/usr/libexec|/opt/libexec|g' ?-e
>> 's|/etc/shosts.equiv|/opt/etc/shosts.equiv|g' ?-e
>> 's|/etc/ssh/ssh_host_key|/opt/etc/ssh_host_key|g' ?-e
>> 's|/etc/ssh/ssh_host_ecdsa_key|/opt/etc/ssh_host_ecdsa_key|g' ?-e
>> 's|/etc/ssh/ssh_host_dsa_key|/opt/etc/ssh_host_dsa_key|g' ?-e
>> 's|/etc/ssh/ssh_host_rsa_key|/opt/etc/ssh_host_rsa_key|g' ?-e
>> 's|/var/run/sshd.pid|/var/run/sshd.pid|g' ?-e
>> 's|/etc/moduli|/opt/etc/moduli|g' ?-e
>> 's|/etc/ssh/moduli|/opt/etc/moduli|g' ?-e
>> 's|/etc/ssh/sshrc|/opt/etc/sshrc|g' ?-e
>> 's|/usr/X11R6/bin/xauth|/usr/X11R6/bin/xauth|g' ?-e
>> 's|/var/empty|/var/empty|g' ?-e 's|/usr/bin:/bin:/usr/sbin:/sbin||g'
>> ${manpage} > scp.1.out; ?fi
>> sed: ./scp.0: No such file or directory
>>
>> This goes on until it compiles completely.
>>
>>
> Which sed version, on which plateform?
>
> Gilles
>



-- 
`` Real men run current !''

From tim at multitalents.net  Sun Sep 18 04:03:17 2011
From: tim at multitalents.net (Tim Rice)
Date: Sat, 17 Sep 2011 11:03:17 -0700 (PDT)
Subject: weird make errors on portable snapshots
In-Reply-To: <CAOp4FwS6JaWNj_L=5zJfyaC=wBA4k374r8AM4=c=U6qFuq-Nhw@mail.gmail.com>
References: <CAOp4FwS6JaWNj_L=5zJfyaC=wBA4k374r8AM4=c=U6qFuq-Nhw@mail.gmail.com>
Message-ID: <Pine.UW2.4.64.1109171100020.741@server01.int.multitalents.net>

On Fri, 16 Sep 2011, Loganaden Velvindron wrote:

> When doing a make with the portable developer version,
> I came across this error:
> 
[snip]
> sed: ./moduli.0: No such file or directory
[snip]
> sed: ./scp.0: No such file or directory

If the .0 files are missing run "make catman-do"

> This goes on until it compiles completely.
 

-- 
Tim Rice				Multitalents
tim at multitalents.net



From mi+thun at aldan.algebra.com  Wed Sep 21 06:12:08 2011
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue, 20 Sep 2011 16:12:08 -0400
Subject: Different HostKeys for different hostnames or IPs in the same sshd?..
Message-ID: <4E78F398.7070502@aldan.algebra.com>

Hello!

Like many organizations, we have "disaster-recovery" location, where separate 
servers are running ready to take up important services should the primary 
location fail.

Some of the services provided involve accepting files over scp (and sftp), and 
here is the problem... The primary and the secondary hosts use different 
host-keys... If the hosts were accessed as "service-primary.example.net" and 
"host-dr.example.net", this would be fine, but the users (and the automated 
tools) would have to be told, which name to use.

So, we want to use an "umbrella" DNS name "service.example.net" to control the 
destination. Under normal circumstances, it is a CNAME for the 
"service-primary.example.net", but in case of a disaster, it will be changed to 
"service-dr.example.net".

How do we configure things so that the users and the automated scripts aren't 
"freaked-out" by the key of "service.example.net" suddenly changing, when the 
DNS is changed? Other than both machines using the same  hostkey, of course...

Can sshd use a different key depending on which name it is contacted under -- 
that is, does the ssh-protocol have anything like HTTP's Host:-header? If not, 
can sshd offer a different key depending on the IP-address, that the incoming 
connection uses?

Thanks for any ideas. Yours,

    -mi



From peter at stuge.se  Wed Sep 21 10:21:16 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 21 Sep 2011 02:21:16 +0200
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <4E78F398.7070502@aldan.algebra.com>
References: <4E78F398.7070502@aldan.algebra.com>
Message-ID: <20110921002116.28366.qmail@stuge.se>

Mikhail T. wrote:
> How do we configure things so that the users and the automated
> scripts aren't "freaked-out" by the key of "service.example.net"
> suddenly changing, when the DNS is changed?

Counter-question: How do you want to still have protection against
malicious DNS data, or simply TCP MITM attacks?


> Other than both machines using the same  hostkey, of course...

Why not do this?


> does the ssh-protocol have anything like HTTP's Host:-header?

Thankfully no.


> If not, can sshd offer a different key depending on the IP-address,
> that the incoming connection uses?

In theory sure, in practise OpenSSH can't. You could always patch it.


//Peter

From djm at mindrot.org  Wed Sep 21 11:44:53 2011
From: djm at mindrot.org (Damien Miller)
Date: Wed, 21 Sep 2011 11:44:53 +1000 (EST)
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <4E78F398.7070502@aldan.algebra.com>
References: <4E78F398.7070502@aldan.algebra.com>
Message-ID: <alpine.BSO.2.00.1109211143220.16677@natsu.mindrot.org>

On Tue, 20 Sep 2011, Mikhail T. wrote:

> Hello!
> 
> Like many organizations, we have "disaster-recovery" location, where separate
> servers are running ready to take up important services should the primary
> location fail.
> 
> Some of the services provided involve accepting files over scp (and sftp), and
> here is the problem... The primary and the secondary hosts use different
> host-keys... If the hosts were accessed as "service-primary.example.net" and
> "host-dr.example.net", this would be fine, but the users (and the automated
> tools) would have to be told, which name to use.

If these machines are replicas of each other and are subject to similar
security controls then there is no reason they cannot have the same key.

Unless you store keys in DNSSEC, OpenSSH doesn't have a mechanism to allow
two hosts with the sane name to use different keys.

-d

From dtucker at zip.com.au  Wed Sep 21 12:20:31 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 21 Sep 2011 12:20:31 +1000
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <20110921002116.28366.qmail@stuge.se>
References: <4E78F398.7070502@aldan.algebra.com>
 <20110921002116.28366.qmail@stuge.se>
Message-ID: <CALDDTe1=E8v3kU8z+K4W1_tuBxCUU=-c_nFU07pDXeb5PFzajQ@mail.gmail.com>

On Wed, Sep 21, 2011 at 10:21 AM, Peter Stuge <peter at stuge.se> wrote:
> Mikhail T. wrote:
>> If not, can sshd offer a different key depending on the IP-address,
>> that the incoming connection uses?
>
> In theory sure, in practise OpenSSH can't. You could always patch it.

If by "IP-address that the incoming connection uses" you mean "address
that you connect *to*" then you can run two separate sshds with
distinct configs (setting at least ListenAddress and HostKey to
different values).

If you mean "address that you connect *from*" then no it currently
can't.  It could probably be added to Match (but I'm struggling to see
a sensible use case for it).

-- 
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 carson at taltos.org  Wed Sep 21 10:26:53 2011
From: carson at taltos.org (Carson Gaspar)
Date: Tue, 20 Sep 2011 17:26:53 -0700
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <4E78F398.7070502@aldan.algebra.com>
References: <4E78F398.7070502@aldan.algebra.com>
Message-ID: <4E792F4D.3010907@taltos.org>

On 9/20/11 1:12 PM, Mikhail T. wrote:
> How do we configure things so that the users and the automated scripts
> aren't "freaked-out" by the key of "service.example.net" suddenly
> changing, when the DNS is changed? Other than both machines using the
> same hostkey, of course...

That's the easiest way - if you want the machines to appear identical, 
make the host keys identical.

> Can sshd use a different key depending on which name it is contacted
> under -- that is, does the ssh-protocol have anything like HTTP's
> Host:-header? If not, can sshd offer a different key depending on the
> IP-address, that the incoming connection uses?

Run 2 sshd masters with 2 different config files, one listening on the 
VIP with shared keys and one listening on non-VIP with host specific keys.

-- 
Carson


From coy.hile at coyhile.com  Wed Sep 21 10:54:21 2011
From: coy.hile at coyhile.com (Coy Hile)
Date: Wed, 21 Sep 2011 00:54:21 +0000
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <4E78F398.7070502@aldan.algebra.com>
References: <4E78F398.7070502@aldan.algebra.com>
Message-ID: <CAJS2yDvYMZfZVzn4RtVzPD9b1211oBHFB9G3JeYf=VC_X=VY+Q@mail.gmail.com>

On Tue, Sep 20, 2011 at 8:12 PM, Mikhail T. <mi+thun at aldan.algebra.com> wrote:

> So, we want to use an "umbrella" DNS name "service.example.net" to control
> the destination. Under normal circumstances, it is a CNAME for the
> "service-primary.example.net", but in case of a disaster, it will be changed
> to "service-dr.example.net".
>
> How do we configure things so that the users and the automated scripts
> aren't "freaked-out" by the key of "service.example.net" suddenly changing,
> when the DNS is changed? Other than both machines using the same ?hostkey,
> of course...

In the cases where I've had a handful of boxes behind a single DNS RR,
I took the poor man's way out and ensured that all six boxes in that
farm had the same hostkeys via an administrative process.

--
Coy

From mi+thun at aldan.algebra.com  Wed Sep 21 13:53:04 2011
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Tue, 20 Sep 2011 23:53:04 -0400
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <CALDDTe1=E8v3kU8z+K4W1_tuBxCUU=-c_nFU07pDXeb5PFzajQ@mail.gmail.com>
References: <4E78F398.7070502@aldan.algebra.com>
 <20110921002116.28366.qmail@stuge.se>
 <CALDDTe1=E8v3kU8z+K4W1_tuBxCUU=-c_nFU07pDXeb5PFzajQ@mail.gmail.com>
Message-ID: <4E795FA0.2060304@aldan.algebra.com>

On 20.09.2011 22:20, Darren Tucker wrote:
> If by "IP-address that the incoming connection uses" you mean "address
> that you connect*to*" then you can run two separate sshds with
> distinct configs (setting at least ListenAddress and HostKey to
> different values).
Yes, running a completely separate sshd-instance is possible. But it 
means replicating the rest of the sshd_config (and ensuring, those 
remain in sync). It also means running an extra process for each of the 
possible roles the server might have (if the same host is used as the 
fallback for different primary servers, for example).

But the real problem is (or could be for some) the IP-address. Years ago 
a separate IP was required for each virtual host on the same web-server 
-- until the Host-header became part of the HTTP-spec. Nobody liked such 
usage of IP-addresses, obviously...

Is not there something similar in ssh protocol? Can it, perhaps, be added?

Alternatively, is there a way to make the client check the remote host 
key against not one, but *several* of the known keys for the same name?

Thanks! Yours,

    -mi


From dtucker at zip.com.au  Wed Sep 21 15:49:00 2011
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 21 Sep 2011 15:49:00 +1000
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <4E795FA0.2060304@aldan.algebra.com>
References: <4E78F398.7070502@aldan.algebra.com>
 <20110921002116.28366.qmail@stuge.se>
 <CALDDTe1=E8v3kU8z+K4W1_tuBxCUU=-c_nFU07pDXeb5PFzajQ@mail.gmail.com>
 <4E795FA0.2060304@aldan.algebra.com>
Message-ID: <CALDDTe0L5C8Dny-pmCPkbjd64TFOcV4XXCkEBTCBReD=86MHcg@mail.gmail.com>

On Wed, Sep 21, 2011 at 1:53 PM, Mikhail T. <mi+thun at aldan.algebra.com> wrote:
[...]
> Yes, running a completely separate sshd-instance is possible. But it means
> replicating the rest of the sshd_config (and ensuring, those remain in
> sync).

You could specify them on the command line using -o to remove the need
to multiple files:

/usr/sbin/sshd -o ListenAddress=1.2.3.4 -o HostKey=/etc/ssh/some_key

> It also means running an extra process for each of the possible roles
> the server might have (if the same host is used as the fallback for
> different primary servers, for example).

That remains true.

> But the real problem is (or could be for some) the IP-address. Years ago a
> separate IP was required for each virtual host on the same web-server --
> until the Host-header became part of the HTTP-spec. Nobody liked such usage
> of IP-addresses, obviously...

Many webservers still have the problem today with SSL.  There are some
SSL protocol workarounds (SAN and SNI, the latter being closer to HTTP
Host in spirit).

> Is not there something similar in ssh protocol? Can it, perhaps, be added?

There's not.  I guess it might be theoretically possible to shoehorn
it in but I don't see much value in it.

> Alternatively, is there a way to make the client check the remote host key
> against not one, but *several* of the known keys for the same name?

Not the openssh client.  I dunno if any other implementations can.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4? 37C9 C982 80C7 8FF4 FA69
? ? Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From nkadel at gmail.com  Wed Sep 21 15:58:22 2011
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Wed, 21 Sep 2011 01:58:22 -0400
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <4E78F398.7070502@aldan.algebra.com>
References: <4E78F398.7070502@aldan.algebra.com>
Message-ID: <CAOCN9rwgW+CmP0Gpm5jbrjYrPJWiEqMOZ0Rq2KEioF0FyCfqRA@mail.gmail.com>

On Tue, Sep 20, 2011 at 4:12 PM, Mikhail T. <mi+thun at aldan.algebra.com> wrote:
> Hello!
>
> Like many organizations, we have "disaster-recovery" location, where
> separate servers are running ready to take up important services should the
> primary location fail.
>
> Some of the services provided involve accepting files over scp (and sftp),
> and here is the problem... The primary and the secondary hosts use different
> host-keys... If the hosts were accessed as "service-primary.example.net" and
> "host-dr.example.net", this would be fine, but the users (and the automated
> tools) would have to be told, which name to use.
>
> So, we want to use an "umbrella" DNS name "service.example.net" to control
> the destination. Under normal circumstances, it is a CNAME for the
> "service-primary.example.net", but in case of a disaster, it will be changed
> to "service-dr.example.net".
>
> How do we configure things so that the users and the automated scripts
> aren't "freaked-out" by the key of "service.example.net" suddenly changing,
> when the DNS is changed? Other than both machines using the same ?hostkey,
> of course...
>
> Can sshd use a different key depending on which name it is contacted under
> -- that is, does the ssh-protocol have anything like HTTP's Host:-header? If
> not, can sshd offer a different key depending on the IP-address, that the
> incoming connection uses?
>
> Thanks for any ideas. Yours,
>
> ? -mi

The *system* keys should, ideally, be unique. The *service* related
keys can then be matched, and stored and shared separately, without
changing basic system authentication. This is commonly used,
especially with virtual ports in failover configurations, to swap the
IP address from one host to the other and to keep the SSH keys tied to
that expected hostname, and even that non-standard port in some
configurations.

I've used this in multiple configurations for SSH based backup systems
and svn+ssh access to Subversion repositories, quite successfully. The
same issues also apply to HTTPS access.

From mi+thun at aldan.algebra.com  Wed Sep 21 16:09:20 2011
From: mi+thun at aldan.algebra.com (Mikhail T.)
Date: Wed, 21 Sep 2011 02:09:20 -0400
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <CALDDTe0L5C8Dny-pmCPkbjd64TFOcV4XXCkEBTCBReD=86MHcg@mail.gmail.com>
References: <4E78F398.7070502@aldan.algebra.com>
 <20110921002116.28366.qmail@stuge.se>
 <CALDDTe1=E8v3kU8z+K4W1_tuBxCUU=-c_nFU07pDXeb5PFzajQ@mail.gmail.com>
 <4E795FA0.2060304@aldan.algebra.com>
 <CALDDTe0L5C8Dny-pmCPkbjd64TFOcV4XXCkEBTCBReD=86MHcg@mail.gmail.com>
Message-ID: <4E797F90.5030909@aldan.algebra.com>

On 21.09.2011 01:49, Darren Tucker wrote:
>> >  Is not there something similar in ssh protocol? Can it, perhaps, be added?
> There's not.  I guess it might be theoretically possible to shoehorn
> it in but I don't see much value in it.

I thought, I began this thread with a use-case for this feature... It is 
hardly an exotic situation and allowing to solve the problem "properly" 
would be most valuable.

> >  Alternatively, is there a way to make the client check the remote host key
> >  against not one, but*several*  of the known keys for the same name?
> Not the openssh client.  I dunno if any other implementations can.

Can't the client be altered to do this? Yours,

    -mi


From mouring at offwriting.org  Wed Sep 21 23:41:33 2011
From: mouring at offwriting.org (Ben Lindstrom)
Date: Wed, 21 Sep 2011 08:41:33 -0500
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <4E797F90.5030909@aldan.algebra.com>
References: <4E78F398.7070502@aldan.algebra.com>
 <20110921002116.28366.qmail@stuge.se>
 <CALDDTe1=E8v3kU8z+K4W1_tuBxCUU=-c_nFU07pDXeb5PFzajQ@mail.gmail.com>
 <4E795FA0.2060304@aldan.algebra.com>
 <CALDDTe0L5C8Dny-pmCPkbjd64TFOcV4XXCkEBTCBReD=86MHcg@mail.gmail.com>
 <4E797F90.5030909@aldan.algebra.com>
Message-ID: <E3B043A7-669E-4262-A320-E400023C4BB8@offwriting.org>


Wouldn't this be a case for using the CAs functionality and signing the host keys?  They may be different but at least they are signed as trusted so there should be less grief that they have been tampered with.

And we have basic CA functionality in OpenSSH right now.

- Ben

On Sep 21, 2011, at 1:09 AM, Mikhail T. wrote:

> On 21.09.2011 01:49, Darren Tucker wrote:
>>> >  Is not there something similar in ssh protocol? Can it, perhaps, be added?
>> There's not.  I guess it might be theoretically possible to shoehorn
>> it in but I don't see much value in it.
> 
> I thought, I began this thread with a use-case for this feature... It is hardly an exotic situation and allowing to solve the problem "properly" would be most valuable.
> 
>> >  Alternatively, is there a way to make the client check the remote host key
>> >  against not one, but*several*  of the known keys for the same name?
>> Not the openssh client.  I dunno if any other implementations can.
> 
> Can't the client be altered to do this? Yours,
> 
>   -mi
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From eth2net at gmail.com  Thu Sep 22 11:34:40 2011
From: eth2net at gmail.com (York Wong)
Date: Thu, 22 Sep 2011 09:34:40 +0800
Subject: which sftp protocol is openssh or sftp-server using or support?
Message-ID: <CABCg0pCZifenxp96S0CKyyXmOcUZiAYXwZzKxhGMxN5OOtOB1w@mail.gmail.com>

Hi,

After reading the source code of openssh and man page of sftp.

In sftp.h it define

27 /*
28  * draft-ietf-secsh-filexfer-01.txt
29  */
30
31 /* version */
32 #define SSH2_FILEXFER_VERSION       3

and In the end of the man page,

T. Ylonen and S. Lehtinen, SSH File Transfer Protocol,
draft-ietf-secsh-filexfer-00.txt, January 2001, work in progress
material.

In wikipedia of "SSH File Transfer Protocal", I notice
draft-ietf-secsh-filexfer-00.txt and draft-ietf-secsh-filexfer-01.txt
are related to the sftp protocal version 3.

So do the openssh is using sftp protocol version 3  or is it only
support up to the sftp protocol version 3 ?

Best Regards,

From ondrej.caletka at gmail.com  Sun Sep 25 17:50:51 2011
From: ondrej.caletka at gmail.com (=?windows-1250?Q?Ond=F8ej_Caletka?=)
Date: Sun, 25 Sep 2011 09:50:51 +0200
Subject: Different HostKeys for different hostnames or IPs in the same
 sshd?..
In-Reply-To: <alpine.BSO.2.00.1109211143220.16677@natsu.mindrot.org>
References: <4E78F398.7070502@aldan.algebra.com>
 <alpine.BSO.2.00.1109211143220.16677@natsu.mindrot.org>
Message-ID: <4E7EDD5B.7090901@gmail.com>

Dne 21.9.2011 03:44, Damien Miller napsal(a):
> Unless you store keys in DNSSEC, OpenSSH doesn't have a mechanism to allow
> two hosts with the sane name to use different keys.
> 
Not true. You can store two different fingerprints under same name in
known_hosts file and SSH client will be satifsied if one of the stored
fingerprints matches the key server offered. The only problem is that
you have to fill in correct fingerprints manually, as SSH client refuses
connecting when there is a record for host you are connecting and no
fingerprint match offered host key.

>From the sshd man page:
> When performing host authentication, authentication is accepted if
> anymatching line has the proper key; either one that matches exactly
> or, if the server has presented a certificate for authentication,
> the key of the certification authority that signed the certificate.

--
Ondrej Caletka

From phorminx at web.de  Mon Sep 26 03:26:45 2011
From: phorminx at web.de (phorminx at web.de)
Date: Sun, 25 Sep 2011 19:26:45 +0200 (CEST)
Subject: scp fails after sending command: scp -v -t
Message-ID: <1883742133.1923716.1316971605546.JavaMail.fmail@mwmweb032>

> I travel quite a bit. Normally I never have had any problems using
> ssh / scp / sftp to connect from my laptop to my computer at home
> / in the office. Currently (for the next 6 months, too long to
> ignore it) I'll stay in a place where scp / sftp seem to fail,
> while as usual I have no problems to establish an interactive ssh
> connection to these remote computers.

Hello

I thought I'd suffer for 6 month from this failing scp connection
(probably due to a misconfigured firewall or something similar
beyond my control). Yet somehow the internet connection of the place
where I stay got reconfigured from scratch. Among other things that
changed, this also made my scp problems go away -- whatever they were.

___________________________________________________________
Schon geh?rt? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

From mats at tande.net  Mon Sep 26 08:10:26 2011
From: mats at tande.net (Mats Tande)
Date: Mon, 26 Sep 2011 00:10:26 +0200
Subject: sshd 5.6p1 does not accept connections in fips mode
Message-ID: <4E7FA6D2.5040209@tande.net>

Hi,

I was trying to run sshd after applying the fips patches mentioned in

 
http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=1835;list=openssh

but for some reason sshd refuses to accept the connection. I guess I do 
something terribly wrong. Is there a reason that this is bound to fail?

These 5.6 patches were the most recent I could find. Are there any fips 
patches for openssh 5.7, 5.8 or 5.9?

Thanks
Mats Tande


Here's what sshd says:

root at nougat /local/fips $ /local/fips/sbin/sshd -Dedddp2222
debug2: load_server_config: filename /local/fips/etc/sshd_config
debug2: load_server_config: done config len = 164
debug2: parse_server_config: config /local/fips/etc/sshd_config len 164
debug3: /local/fips/etc/sshd_config:111 setting Subsystem sftp 
/local/fips/libexec/sftp-server
***IN FIPS MODE***
debug1: sshd version OpenSSH_5.6p1
debug3: Not a RSA1 key file /local/fips/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /local/fips/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/local/fips/sbin/sshd'
debug1: rexec_argv[1]='-Dedddp2222'
debug3: oom_adjust_setup
Set /proc/self/oom_adj from 0 to -17
debug2: fd 3 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 3 IPV6_V6ONLY
debug1: Bind to port 2222 on ::.
Server listening on :: port 2222.
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 2222 on 0.0.0.0.
Server listening on 0.0.0.0 port 2222.
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 164
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug3: recv_rexec_state: entering fd = 5
debug3: ssh_msg_recv entering
debug3: recv_rexec_state: done
debug2: parse_server_config: config rexec len 164
debug3: rexec:111 setting Subsystem sftp 
/local/fips/libexec/sftp-server
***IN FIPS MODE***
debug1: sshd version OpenSSH_5.6p1
debug3: Not a RSA1 key file /local/fips/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /local/fips/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: inetd sockets after dupping: 3, 3
Connection from 10.78.0.8 port 39056
debug1: Client protocol version 2.0; client software version OpenSSH_5.6
debug1: match: OpenSSH_5.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug2: fd 3 setting O_NONBLOCK
debug2: FIPS rand reseeded
debug2: FIPS rand reseeded
debug3: privsep user:group 74:74
debug1: permanently_set_uid: 74/74
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug2: Network child is on pid 27955
debug3: preauth child monitor started
debug3: mm_request_receive entering
debug1: do_cleanup


I test this using ssh, like this:

mats at nougat ~ $ /local/fips/bin/ssh -vvvp2222 nougat
OpenSSH_5.6p1, OpenSSL FIPS Object Module v1.2
debug1: Reading configuration data /local/fips/etc/ssh_config
debug1: *** IN FIPS MODE ***
debug2: ssh_connect: needpriv 0
debug1: Connecting to nougat [10.78.0.8] port 2222.
debug1: Connection established.
debug3: Not a RSA1 key file /home/mats/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/mats/.ssh/id_rsa type 1
debug1: identity file /home/mats/.ssh/id_rsa-cert type -1
debug1: identity file /home/mats/.ssh/id_dsa type -1
debug1: identity file /home/mats/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.6
debug1: match: OpenSSH_5.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

From ehimawan at gmail.com  Mon Sep 26 15:23:47 2011
From: ehimawan at gmail.com (Erwin Himawan)
Date: Mon, 26 Sep 2011 00:23:47 -0500
Subject: Support for ecc
Message-ID: <CAFY=A46XqGoEduhQM4fePMEvtrE1zADmf=1MuXhX-5K_xyt4ew@mail.gmail.com>

Hi All,

I think I know the answer. However, I would like to confirm my
understanding.

Does openssh support the usage of ecc keys?
Any plan for supporting ecc keys?

Thanks,
Erwin

From djm at mindrot.org  Tue Sep 27 11:28:39 2011
From: djm at mindrot.org (Damien Miller)
Date: Tue, 27 Sep 2011 11:28:39 +1000 (EST)
Subject: Support for ecc
In-Reply-To: <CAFY=A46XqGoEduhQM4fePMEvtrE1zADmf=1MuXhX-5K_xyt4ew@mail.gmail.com>
References: <CAFY=A46XqGoEduhQM4fePMEvtrE1zADmf=1MuXhX-5K_xyt4ew@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1109271128130.25772@natsu.mindrot.org>

On Mon, 26 Sep 2011, Erwin Himawan wrote:

> Hi All,
> 
> I think I know the answer. However, I would like to confirm my
> understanding.
> 
> Does openssh support the usage of ecc keys?

yes, for a couple of releases now.

ssh-keygen -t ecdsa ...

From ehimawan at gmail.com  Tue Sep 27 12:25:12 2011
From: ehimawan at gmail.com (Erwin Himawan)
Date: Mon, 26 Sep 2011 21:25:12 -0500
Subject: Support for ecc
In-Reply-To: <alpine.BSO.2.00.1109271128130.25772@natsu.mindrot.org>
References: <CAFY=A46XqGoEduhQM4fePMEvtrE1zADmf=1MuXhX-5K_xyt4ew@mail.gmail.com>
 <alpine.BSO.2.00.1109271128130.25772@natsu.mindrot.org>
Message-ID: <B01E19B449294FBD8FB5E4ECEB338698@d8400>

Thanks for the info.

Erwin

--------------------------------------------------
From: "Damien Miller" <djm at mindrot.org>
Sent: Monday, September 26, 2011 8:28 PM
To: "Erwin Himawan" <ehimawan at gmail.com>
Cc: <openssh-unix-dev at mindrot.org>
Subject: Re: Support for ecc

> On Mon, 26 Sep 2011, Erwin Himawan wrote:
> 
>> Hi All,
>> 
>> I think I know the answer. However, I would like to confirm my
>> understanding.
>> 
>> Does openssh support the usage of ecc keys?
> 
> yes, for a couple of releases now.
> 
> ssh-keygen -t ecdsa ... 

From sdaoden at googlemail.com  Wed Sep 28 21:29:31 2011
From: sdaoden at googlemail.com (Steffen Daode Nurpmeso)
Date: Wed, 28 Sep 2011 13:29:31 +0200
Subject: Fingerprint mismatch upon cvs update
Message-ID: <20110928112931.GA47799@sherwood.local>

Hello,

a moment ago i got this:

: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
: @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
: Someone could be eavesdropping on you right now (man-in-the-middle attack)!
: It is also possible that the RSA host key has just been changed.
: The fingerprint for the RSA key sent by the remote host is
: 37:ff:ba:69:2c:a5:ec:a0:16:34:9c:2b:0f:c7:2b:6d.
: Please contact your system administrator.
: Add correct host key in /Users/steffen/.ssh/known_hosts to get rid of this message.
: Offending key in /Users/steffen/.ssh/known_hosts:6
: RSA host key for anoncvs.mindrot.org has changed and you have requested strict checking.
: Host key verification failed.
: cvs [update aborted]: end of file from server (consult above messages if any)

And i wanted to ask wether the fingerprint from
http://openssh.org/portable.html is still valid.
Can someone confirm the above is not, please?
Thanks a lot!

--steffen

From des at des.no  Thu Sep 29 10:32:10 2011
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Thu, 29 Sep 2011 02:32:10 +0200
Subject: sizeof(char)
Message-ID: <86mxdo89yt.fsf@ds4.des.no>

I was scanning through my config.h and noticed something that startled
me a bit.  The configure script actually checks what sizeof(char) is,
and defines.h relies on this information.

This is completely unnecessary.  By definition, sizeof(char) is always
1.  This is not a matter of opinion; the C standard explicitly states,
in ?6.5.3.4 alinea 3,

  When applied to an operand that has type char, unsigned char, or
  signed char, (or a qualified version thereof) the result is 1.

On the other hand, unlike other basic integer types, the signedness of
char is implementation-defined; see ?6.2.5 alinea 15 and footnote 35.
Since int8_t is supposed to be a *signed* 8-bit integer, it must be
explicitly defined as such.  Code that relies on char being signed will
break on IRIX, and probably a number of other implementations.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-sizeof-char.diff
Type: text/x-patch
Size: 789 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20110929/fa4c089e/attachment.bin>

From djm at mindrot.org  Thu Sep 29 11:09:04 2011
From: djm at mindrot.org (Damien Miller)
Date: Thu, 29 Sep 2011 11:09:04 +1000 (EST)
Subject: Fingerprint mismatch upon cvs update
In-Reply-To: <20110928112931.GA47799@sherwood.local>
References: <20110928112931.GA47799@sherwood.local>
Message-ID: <alpine.BSO.2.00.1109291108311.19071@natsu.mindrot.org>

should be fixed - thanks for letting me know

On Wed, 28 Sep 2011, Steffen Daode Nurpmeso wrote:

> Hello,
> 
> a moment ago i got this:
> 
> : @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> : @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
> : @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> : IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> : Someone could be eavesdropping on you right now (man-in-the-middle attack)!
> : It is also possible that the RSA host key has just been changed.
> : The fingerprint for the RSA key sent by the remote host is
> : 37:ff:ba:69:2c:a5:ec:a0:16:34:9c:2b:0f:c7:2b:6d.
> : Please contact your system administrator.
> : Add correct host key in /Users/steffen/.ssh/known_hosts to get rid of this message.
> : Offending key in /Users/steffen/.ssh/known_hosts:6
> : RSA host key for anoncvs.mindrot.org has changed and you have requested strict checking.
> : Host key verification failed.
> : cvs [update aborted]: end of file from server (consult above messages if any)
> 
> And i wanted to ask wether the fingerprint from
> http://openssh.org/portable.html is still valid.
> Can someone confirm the above is not, please?
> Thanks a lot!
> 
> --steffen
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From djm at mindrot.org  Thu Sep 29 11:12:13 2011
From: djm at mindrot.org (Damien Miller)
Date: Thu, 29 Sep 2011 11:12:13 +1000 (EST)
Subject: sizeof(char)
In-Reply-To: <86mxdo89yt.fsf@ds4.des.no>
References: <86mxdo89yt.fsf@ds4.des.no>
Message-ID: <alpine.BSO.2.00.1109291111540.19071@natsu.mindrot.org>

On Thu, 29 Sep 2011, Dag-Erling Sm?rgrav wrote:

> I was scanning through my config.h and noticed something that startled
> me a bit.  The configure script actually checks what sizeof(char) is,
> and defines.h relies on this information.
> 
> This is completely unnecessary.  By definition, sizeof(char) is always
> 1.  This is not a matter of opinion; the C standard explicitly states,
> in ?6.5.3.4 alinea 3,
> 
>   When applied to an operand that has type char, unsigned char, or
>   signed char, (or a qualified version thereof) the result is 1.
> 
> On the other hand, unlike other basic integer types, the signedness of
> char is implementation-defined; see ?6.2.5 alinea 15 and footnote 35.
> Since int8_t is supposed to be a *signed* 8-bit integer, it must be
> explicitly defined as such.  Code that relies on char being signed will
> break on IRIX, and probably a number of other implementations.

applied - thanks

From des at des.no  Fri Sep 30 06:37:59 2011
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Thu, 29 Sep 2011 22:37:59 +0200
Subject: sizeof(char)
In-Reply-To: <4E84CA45.9050606@roumenpetrov.info> (Roumen Petrov's message of
 "Thu, 29 Sep 2011 22:43:01 +0300")
References: <86mxdo89yt.fsf@ds4.des.no>
 <alpine.BSO.2.00.1109291111540.19071@natsu.mindrot.org>
 <4E84CA45.9050606@roumenpetrov.info>
Message-ID: <86fwjf84pk.fsf@ds4.des.no>

Roumen Petrov <openssh at roumenpetrov.info> writes:
> I don't know what you apply but  patch as is just say good bay on old
> systems where char is with sizeof integer.

I suggest you read what I wrote, and the passage I quoted from the C
standard.

To summarize: sizeof(char) == 1.  Always.  No exceptions.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From des at des.no  Fri Sep 30 08:25:57 2011
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Fri, 30 Sep 2011 00:25:57 +0200
Subject: sizeof(char)
In-Reply-To: <4E84DD58.703@roumenpetrov.info> (Roumen Petrov's message of
 "Fri, 30 Sep 2011 00:04:24 +0300")
References: <86mxdo89yt.fsf@ds4.des.no>
 <alpine.BSO.2.00.1109291111540.19071@natsu.mindrot.org>
 <4E84CA45.9050606@roumenpetrov.info> <86fwjf84pk.fsf@ds4.des.no>
 <4E84DD58.703@roumenpetrov.info>
Message-ID: <867h4r7zpm.fsf@ds4.des.no>

Roumen Petrov <openssh at roumenpetrov.info> writes:
> Dag-Erling Sm?rgrav <des at des.no> writes:
> > To summarize: sizeof(char) == 1.  Always.  No exceptions.
> Sure.  I cannot run my time machine and to return 20 years ago .

Even if you could, sizeof(char) would still be 1.  The C standard
requires it.

> sizeof(char) == 1 does not mean that size if 8 bit . Did you read
> documentation for*AC_TYPE_INT8_T*  ?

The code in defines.h assumes 8 bits per byte.  That's not my doing, nor
does my patch change that fact, and it is completely orthogonal to the
issue I brought up, which was that sizeof(char) is always 1.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From openssh at roumenpetrov.info  Fri Sep 30 07:04:24 2011
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Fri, 30 Sep 2011 00:04:24 +0300
Subject: sizeof(char)
In-Reply-To: <86fwjf84pk.fsf@ds4.des.no>
References: <86mxdo89yt.fsf@ds4.des.no>	<alpine.BSO.2.00.1109291111540.19071@natsu.mindrot.org>	<4E84CA45.9050606@roumenpetrov.info>
 <86fwjf84pk.fsf@ds4.des.no>
Message-ID: <4E84DD58.703@roumenpetrov.info>

Dag-Erling Sm?rgrav wrote:
> Roumen Petrov<openssh at roumenpetrov.info>  writes:
>    
>> I don't know what you apply but  patch as is just say good bay on old
>> systems where char is with sizeof integer.
>>      
> I suggest you read what I wrote, and the passage I quoted from the C
> standard.
>    
:)

> To summarize: sizeof(char) == 1.  Always.  No exceptions.
>    
Sure.  I cannot run my time machine and to return 20 years ago .

sizeof(char) == 1 does not mean that size if 8 bit . Did you read documentation for*AC_TYPE_INT8_T*  ?


> DES
>    
Roumen

From openssh at roumenpetrov.info  Fri Sep 30 05:54:38 2011
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Thu, 29 Sep 2011 22:54:38 +0300
Subject: sizeof(char)
In-Reply-To: <4E84CA45.9050606@roumenpetrov.info>
References: <86mxdo89yt.fsf@ds4.des.no>
 <alpine.BSO.2.00.1109291111540.19071@natsu.mindrot.org>
 <4E84CA45.9050606@roumenpetrov.info>
Message-ID: <4E84CCFE.8030700@roumenpetrov.info>

Roumen Petrov wrote:
> Damien Miller wrote:
>> On Thu, 29 Sep 2011, Dag-Erling Sm?rgrav wrote:
>>
>>> I was scanning through my config.h and noticed something that startled
>>> me a bit.  The configure script actually checks what sizeof(char) is,
>>> and defines.h relies on this information.
>>>
>>> This is completely unnecessary.  By definition, sizeof(char) is always
>>> 1.  This is not a matter of opinion; the C standard explicitly states,
>>> in ?6.5.3.4 alinea 3,
>>>
>>>    When applied to an operand that has type char, unsigned char, or
>>>    signed char, (or a qualified version thereof) the result is 1.
>>>
>>> On the other hand, unlike other basic integer types, the signedness of
>>> char is implementation-defined; see ?6.2.5 alinea 15 and footnote 35.
>>> Since int8_t is supposed to be a *signed* 8-bit integer, it must be
>>> explicitly defined as such.  Code that relies on char being signed will
>>> break on IRIX, and probably a number of other implementations.
>> applied - thanks
> I don't know what you apply but  patch as is just say good bay on old 
> systems where char is with sizeof integer.  I don't think that check 
> for size of char has to be removed .
> Only part "typedef signed char int8_t;" make sense .
>
> Regards,
> Roumen
May be *AC_TYPE_INT8_T* macro could help - cf 
http://www.gnu.org/s/hello/manual/autoconf/Particular-Types.html

Roumen


From openssh at roumenpetrov.info  Fri Sep 30 05:43:01 2011
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Thu, 29 Sep 2011 22:43:01 +0300
Subject: sizeof(char)
In-Reply-To: <alpine.BSO.2.00.1109291111540.19071@natsu.mindrot.org>
References: <86mxdo89yt.fsf@ds4.des.no>
 <alpine.BSO.2.00.1109291111540.19071@natsu.mindrot.org>
Message-ID: <4E84CA45.9050606@roumenpetrov.info>

Damien Miller wrote:
> On Thu, 29 Sep 2011, Dag-Erling Sm?rgrav wrote:
>
>    
>> I was scanning through my config.h and noticed something that startled
>> me a bit.  The configure script actually checks what sizeof(char) is,
>> and defines.h relies on this information.
>>
>> This is completely unnecessary.  By definition, sizeof(char) is always
>> 1.  This is not a matter of opinion; the C standard explicitly states,
>> in ?6.5.3.4 alinea 3,
>>
>>    When applied to an operand that has type char, unsigned char, or
>>    signed char, (or a qualified version thereof) the result is 1.
>>
>> On the other hand, unlike other basic integer types, the signedness of
>> char is implementation-defined; see ?6.2.5 alinea 15 and footnote 35.
>> Since int8_t is supposed to be a *signed* 8-bit integer, it must be
>> explicitly defined as such.  Code that relies on char being signed will
>> break on IRIX, and probably a number of other implementations.
>>      
> applied - thanks
>    
I don't know what you apply but  patch as is just say good bay on old 
systems where char is with sizeof integer.  I don't think that check for 
size of char has to be removed .
Only part "typedef signed char int8_t;" make sense .

Regards,
Roumen


-- 
Get X.509 certificates support in OpenSSH:
http://roumenpetrov.info/openssh/