From ribas at c3sl.ufpr.br Sun Sep 2 06:22:11 2007 From: ribas at c3sl.ufpr.br (Bruno Cesar Ribas) Date: Sat, 1 Sep 2007 17:22:11 -0300 Subject: [patch] sftp-server basepath [yet another] Message-ID: <20070901202211.GA22122@c3sl.ufpr.br> Hi, I made this simple path to make sftp-server restricted to a basepath! This was done because use sshfs [wich base is sftp-server] to allow people access medias [ cdrom,dvdrom, floppy, usb] from x-terms. Those x-terms [ diskless] does not have all users, so we share a single user and a DSA empty passphrase, with some acl scipts at .ssh/authorized keys. Main usage of this patch is to NOT allow a user who mounted a floppy access other mounted media from another user. Usage: sftp-server -b My page includes this path: http://www.inf.ufpr.br/ribas/sshfs_help/ And it is attached too. Thanks for atention Bruno Ribas -- Bruno Ribas - ribas at c3sl.ufpr.br http://web.inf.ufpr.br/ribas C3SL: http://www.c3sl.ufpr.br -------------- next part -------------- A non-text attachment was scrubbed... Name: sftp-server.c.patch Type: text/x-diff Size: 1369 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070901/52e85af4/attachment.bin From dtucker at zip.com.au Sun Sep 2 23:06:52 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 2 Sep 2007 23:06:52 +1000 Subject: [patch] sftp-server basepath [yet another] In-Reply-To: <20070901202211.GA22122@c3sl.ufpr.br> References: <20070901202211.GA22122@c3sl.ufpr.br> Message-ID: <20070902130652.GA24269@gate.dtucker.net> On Sat, Sep 01, 2007 at 05:22:11PM -0300, Bruno Cesar Ribas wrote: > I made this simple path to make sftp-server restricted to a basepath! [...] > + if(strncmp(basepath,realpath(path,NULL),strlen(basepath))==0) { Passing a NULL as the second argument to realpath is a) nonstandard and b) makes it malloc the returned string, so this leaks memory. Also, realpath can fail and return NULL, in which case this would segfault. -- 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 postmaster at mx.aduana.argo.com.br Wed Sep 5 07:09:08 2007 From: postmaster at mx.aduana.argo.com.br (MailScanner) Date: Tue, 4 Sep 2007 17:09:08 -0400 Subject: {Spam?} Aviso: Detectado vírus no e-mail Message-ID: <200709042109.l84L985Y009351@mx.aduana.argo.com.br> Nosso sistema de detec??o de v?rus foi ativado por uma mensagem que voc? enviou para:- To: aduteca at aduana-dsp.com.br Subject: Re: BRAS Vaga Date: Tue Sep 4 17:09:07 2007 Um ou mais dos anexos encontra-se na lista de tipos de arquivo pro?bidos pelo sistema e n?o poder? ser entregue. Considere renomear o(s) arquivo(s) anexos ou coloque-os em formato comprimido ("ZIP") para evitar este tipo de problema. Nosso sistema de anti-virus relatou o seguinte a respeito da sua mensagem: Relat?rio: Reporte: MailScanner: Shortcuts to MS-Dos programs are very dangerous in email (Vaga.pif) Reporte: Blocked Filetype Detected (Vaga.pif) -- Postmaster Aduana Despachos e Assessoria de Com. Exterior www.aduana-dsp.com.br From djm at cvs.openbsd.org Wed Sep 5 10:14:09 2007 From: djm at cvs.openbsd.org (Damien Miller) Date: Tue, 4 Sep 2007 18:14:09 -0600 (MDT) Subject: Announce: OpenSSH 4.7 released Message-ID: <200709050014.l850E9E2015950@cvs.openbsd.org> OpenSSH 4.7 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots and purchased T-shirts or posters. T-shirt, poster and CD sales directly support the project. Pictures and more information can be found at: http://www.openbsd.org/tshirts.html and http://www.openbsd.org/orders.html For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since OpenSSH 4.6: ============================ Security bugs resolved in this release: * Prevent ssh(1) from using a trusted X11 cookie if creation of an untrusted cookie fails; found and fixed by Jan Pechanec. Other changes, new functionality and fixes in this release: * sshd(8) in new installations defaults to SSH Protocol 2 only. Existing installations are unchanged. * The SSH channel window size has been increased, and both ssh(1) sshd(8) now send window updates more aggressively. These improves performance on high-BDP (Bandwidth Delay Product) networks. * ssh(1) and sshd(8) now preserve MAC contexts between packets, which saves 2 hash calls per packet and results in 12-16% speedup for arcfour256/hmac-md5. * A new MAC algorithm has been added, UMAC-64 (RFC4418) as "umac-64 at openssh.com". UMAC-64 has been measured to be approximately 20% faster than HMAC-MD5. * A -K flag was added to ssh(1) to set GSSAPIAuthentication=Yes * Failure to establish a ssh(1) TunnelForward is now treated as a fatal error when the ExitOnForwardFailure option is set. * ssh(1) returns a sensible exit status if the control master goes away without passing the full exit status. (bz #1261) * The following bugs have been fixed in this release: - When using a ProxyCommand in ssh(1), set the outgoing hostname with gethostname(2), allowing hostbased authentication to work (bz #616) - Make scp(1) skip FIFOs rather than hanging (bz #856) - Encode non-printing characters in scp(1) filenames. these could cause copies to be aborted with a "protocol error" (bz #891) - Handle SIGINT in sshd(8) privilege separation child process to ensure that wtmp and lastlog records are correctly updated (bz #1196) - Report GSSAPI mechanism in errors, for libraries that support multiple mechanisms (bz #1220) - Improve documentation for ssh-add(1)'s -d option (bz #1224) - Rearrange and tidy GSSAPI code, removing server-only code being linked into the client. (bz #1225) - Delay execution of ssh(1)'s LocalCommand until after all forwadings have been established. (bz #1232) - In scp(1), do not truncate non-regular files (bz #1236) - Improve exit message from ControlMaster clients. (bz #1262) - Prevent sftp-server(8) from reading until it runs out of buffer space, whereupon it would exit with a fatal error. (bz #1286) * Portable OpenSSH bugs fixed: - Fix multiple inclusion of paths.h on AIX 5.1 systems. (bz #1243) - Implement getpeereid for Solaris using getpeerucred. Solaris systems will now refuse ssh-agent(1) and ssh(1) ControlMaster clients from different, non-root users (bz #1287) - Fix compilation warnings by including string.h if found. (bz #1294) - Remove redefinition of _res in getrrsetbyname.c for platforms that already define it. (bz #1299) - Fix spurious "chan_read_failed for istate 3" errors from sshd(8), a side-effect of the "hang on exit" fix introduced in 4.6p1. (bz #1306) - pam_end() was not being called if authentication failed (bz #1322) - Fix SELinux support when SELinux is in permissive mode. Previously sshd(8) was treating SELinux errors as always fatal. (bz #1325) - Ensure that pam_setcred(..., PAM_ESTABLISH_CRED) is called before pam_setcred(..., PAM_REINITIALIZE_CRED), fixing pam_dhkeys. (bz #1339) - Fix privilege separation on QNX - pre-auth only, this platform does not support file descriptior passing needed for post-auth privilege separation. (bz #1343) Thanks to everyone who has contributed patches, reported bugs and tested releases. Checksums: ========== - SHA1 (openssh-4.7.tar.gz) = 9ebaab9b31e01bd0d04425dc23536bcc78f8d990 - SHA1 (openssh-4.7p1.tar.gz) = 58357db9e64ba6382bef3d73d1d386fcdc0508f4 Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ 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 rsecor at seqlogic.com Thu Sep 6 02:38:51 2007 From: rsecor at seqlogic.com (Richard Secor) Date: Wed, 5 Sep 2007 12:38:51 -0400 Subject: sshd_config -> ChallengeResponseAuthentication Message-ID: <0B1AE1CD-2A0D-40C1-A262-CDDD41DB1FAC@seqlogic.com> I was under the impression from the provided distribution version of the sshd_config file that "ChallengeResponseAuthentication" is supposed to default to "yes". Does anyone know if there are any circumstances, such as configure options, that might cause it to default to "no"? Thanks, Richard A. Secor rsecor at seqlogic.com Sequential Logic http://www.seqlogic.com/ +1.954.931.7374 From rapier at psc.edu Thu Sep 6 07:27:38 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 05 Sep 2007 17:27:38 -0400 Subject: HPN Patch for OpenSSH 4.7 Available Message-ID: <46DF1F4A.6030603@psc.edu> The HPN-SSH patch set for OpenSSH 4.7 is now available from http://www.psc.edu/networking/projects/hpn-ssh/openssh-4.7p1-hpn12v18.diff.gz Its passes all regression tests and my personal sets of tests. We do not introduce any new functionality. However, I expect this is an interim release. I hope to have some relatively minor modification available in the next month. These will mostly deal with buffering issues for *small* BDP connections, a small performance enhancement for bulk data transfers, and a couple user configuration/usage changes. From dtucker at zip.com.au Thu Sep 6 07:49:01 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 06 Sep 2007 07:49:01 +1000 Subject: sshd_config -> ChallengeResponseAuthentication In-Reply-To: <0B1AE1CD-2A0D-40C1-A262-CDDD41DB1FAC@seqlogic.com> References: <0B1AE1CD-2A0D-40C1-A262-CDDD41DB1FAC@seqlogic.com> Message-ID: <46DF244D.4070801@zip.com.au> Richard Secor wrote: > I was under the impression from the provided distribution version of > the sshd_config file that "ChallengeResponseAuthentication" is > supposed to default to "yes". > > Does anyone know if there are any circumstances, such as configure > options, that might cause it to default to "no"? The Match code changes had a side effect (ie "bug") that changed the default of ChallengeResponseAuthentication. It affected version 4.6 only, it's fixed ni 4.7. I can dig up a patch for 4.6 if it helps. -- 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 jwwong at nortel.com Thu Sep 6 06:42:30 2007 From: jwwong at nortel.com (John Wong) Date: Wed, 5 Sep 2007 16:42:30 -0400 Subject: Openssh4.6p1 Make tests failed in sftp Message-ID: <549FD0754C7E1D468D93A34B42AC5F92099D0D13@zcarhxm1.corp.nortel.com> Hi All, After configuring and compiling OpenSSH version 4.6p1 in my SUN Solaris8 ultrasparc machine, I run "make tests" and got the following errors. The compiler used is GCC3.3. run test sftp.sh ... test basic sftp put/get: buffer_size 5 num_requests 1 sftp failed with 1 test basic sftp put/get: buffer_size 5 num_requests 2 sftp failed with 1 test basic sftp put/get: buffer_size 5 num_requests 10 sftp failed with 1 test basic sftp put/get: buffer_size 1000 num_requests 1 sftp failed with 1 test basic sftp put/get: buffer_size 1000 num_requests 2 sftp failed with 1 I do not get these errors when running "make tests" with OpenSSH version 4.3p2 in the same machine. When I installed the 4.6p1 package to my machine and test sftp from a client, I got the following log messages in the authlog: Sep 5 17:09:51 wcarsx0h sshd[23483]: subsystem request for sftp Sep 5 17:09:56 wcarsx0h sftp-server[23840]: error: process_write: write failed Sep 5 17:09:56 wcarsx0h sshd[23483]: error: channel 0: chan_read_failed for ist Further debugging on process_write of sftp-server.c, I found that the errno returned from the "write" function is always "File too large" no matter what is the size of the file. I appreciate your help to further investigate the possible casue of the problem. Thanks in advance, John From dtucker at zip.com.au Thu Sep 6 09:28:56 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 06 Sep 2007 09:28:56 +1000 Subject: Openssh4.6p1 Make tests failed in sftp In-Reply-To: <549FD0754C7E1D468D93A34B42AC5F92099D0D13@zcarhxm1.corp.nortel.com> References: <549FD0754C7E1D468D93A34B42AC5F92099D0D13@zcarhxm1.corp.nortel.com> Message-ID: <46DF3BB8.1000008@zip.com.au> John Wong wrote: > After configuring and compiling OpenSSH version 4.6p1 in my SUN Solaris8 > ultrasparc machine, I run "make tests" and got the following errors. The > compiler used is GCC3.3. 4.7p1 was just released in the last day or so. Could you please repeat the tests with that version? I test on Solaris 8/sparc regularly so there's no fundamental reason why it shouldn't work. > I do not get these errors when running "make tests" with OpenSSH version > 4.3p2 in the same machine. > > When I installed the 4.6p1 package to my machine and test sftp from a > client, I got the following log messages in the authlog: > > Sep 5 17:09:51 wcarsx0h sshd[23483]: subsystem request for sftp > Sep 5 17:09:56 wcarsx0h sftp-server[23840]: error: process_write: write > failed > Sep 5 17:09:56 wcarsx0h sshd[23483]: error: channel 0: chan_read_failed > for ist These are spurious and can be ignored. They are fixed in 4.7p1. > Further debugging on process_write of sftp-server.c, I found that the > errno returned from the "write" function is always "File too large" no > matter what is the size of the file. I appreciate your help to further > investigate the possible casue of the problem. I'm wondering if configure some how got something like large file support wrong... Could you please post the content of config.h (eg "grep '#define' config.h" to strip out the comments and blanks). Also, what CFLAGS are set in the Makefile? Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jwwong at nortel.com Thu Sep 6 22:05:26 2007 From: jwwong at nortel.com (John Wong) Date: Thu, 6 Sep 2007 08:05:26 -0400 Subject: Openssh4.6p1 Make tests failed in sftp In-Reply-To: <46DF3BB8.1000008@zip.com.au> Message-ID: <549FD0754C7E1D468D93A34B42AC5F92099D0D15@zcarhxm1.corp.nortel.com> Thanks Darren. The CFLAGS used in the Makefile is: CFLAGS=-g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -O -mcpu=ultrasparc The contents of '#define' in config.h is: [ /soamp/SSSecurity/OpenSSH/openssh-4.6p1/src 59 ] grep '#define' config.h #define BROKEN_ONE_BYTE_DIRENT_D_NAME 1 #define CONF_LASTLOG_FILE "/var/adm/lastlog" #define DISABLE_UTMP 1 #define DISABLE_WTMP 1 #define ENTROPY_TIMEOUT_MSEC 200 #define GETPGRP_VOID 1 #define HAS_SHADOW_EXPIRE 1 #define HAVE_ACCRIGHTS_IN_MSGHDR 1 #define HAVE_BASENAME 1 #define HAVE_BCOPY 1 #define HAVE_CLOCK 1 #define HAVE_CLOCK_T 1 #define HAVE_CRYPT_H 1 #define HAVE_DECL_GLOB_NOMATCH 1 #define HAVE_DECL_H_ERRNO 1 #define HAVE_DECL_O_NONBLOCK 1 #define HAVE_DECL_SHUT_RD 1 #define HAVE_DECL_WRITEV 1 #define HAVE_DECL__GETLONG 0 #define HAVE_DECL__GETSHORT 0 #define HAVE_DEV_PTMX 1 #define HAVE_DIRENT_H 1 #define HAVE_DIRNAME 1 #define HAVE_ENDUTENT 1 #define HAVE_ENDUTXENT 1 #define HAVE_ETC_DEFAULT_LOGIN 1 #define HAVE_EVP_SHA256 1 #define HAVE_EXIT_IN_UTMP 1 #define HAVE_FCHMOD 1 #define HAVE_FCHOWN 1 #define HAVE_FCNTL_H 1 #define HAVE_FLOATINGPOINT_H 1 #define HAVE_FREEADDRINFO 1 #define HAVE_GAI_STRERROR 1 #define HAVE_GETADDRINFO 1 #define HAVE_GETCWD 1 #define HAVE_GETNAMEINFO 1 #define HAVE_GETOPT 1 #define HAVE_GETPAGESIZE 1 #define HAVE_GETRLIMIT 1 #define HAVE_GETTIMEOFDAY 1 #define HAVE_GETUTENT 1 #define HAVE_GETUTID 1 #define HAVE_GETUTLINE 1 #define HAVE_GETUTXENT 1 #define HAVE_GETUTXID 1 #define HAVE_GETUTXLINE 1 #define HAVE_GLOB 1 #define HAVE_GLOB_H 1 #define HAVE_HOST_IN_UTMPX 1 #define HAVE_ID_IN_UTMP 1 #define HAVE_ID_IN_UTMPX 1 #define HAVE_INET_NTOA 1 #define HAVE_INET_NTOP 1 #define HAVE_INNETGR 1 #define HAVE_INT64_T 1 #define HAVE_INTTYPES_H 1 #define HAVE_INTXX_T 1 #define HAVE_IN_ADDR_T 1 #define HAVE_LASTLOG_H 1 #define HAVE_LIBDL 1 #define HAVE_LIBGEN_H 1 #define HAVE_LIBNSL 1 #define HAVE_LIBPAM 1 #define HAVE_LIBSOCKET 1 #define HAVE_LIBZ 1 #define HAVE_LIMITS_H 1 #define HAVE_LONG_DOUBLE 1 #define HAVE_LONG_LONG 1 #define HAVE_MAILLOCK_H 1 #define HAVE_MEMMOVE 1 #define HAVE_MEMORY_H 1 #define HAVE_MMAP 1 #define HAVE_MODE_T 1 #define HAVE_NANOSLEEP 1 #define HAVE_NETDB_H 1 #define HAVE_OPENSSL 1 #define HAVE_PAM_GETENVLIST 1 #define HAVE_PAM_PUTENV 1 #define HAVE_PID_IN_UTMP 1 #define HAVE_PID_T 1 #define HAVE_PROC_PID 1 #define HAVE_PUTUTLINE 1 #define HAVE_PUTUTXLINE 1 #define HAVE_REALPATH 1 #define HAVE_RECVMSG 1 #define HAVE_RPC_TYPES_H 1 #define HAVE_RRESVPORT_AF 1 #define HAVE_SA_FAMILY_T 1 #define HAVE_SECURITY_PAM_APPL_H 1 #define HAVE_SENDMSG 1 #define HAVE_SETEGID 1 #define HAVE_SETEUID 1 #define HAVE_SETGROUPS 1 #define HAVE_SETREGID 1 #define HAVE_SETREUID 1 #define HAVE_SETRLIMIT 1 #define HAVE_SETSID 1 #define HAVE_SETUTENT 1 #define HAVE_SETUTXENT 1 #define HAVE_SETVBUF 1 #define HAVE_SHA256_UPDATE 1 #define HAVE_SHADOW_H 1 #define HAVE_SIGACTION 1 #define HAVE_SIG_ATOMIC_T 1 #define HAVE_SIZE_T 1 #define HAVE_SNPRINTF 1 #define HAVE_SOCKETPAIR 1 #define HAVE_SSIZE_T 1 #define HAVE_SS_FAMILY_IN_SS 1 #define HAVE_STDDEF_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRDUP 1 #define HAVE_STRERROR 1 #define HAVE_STRFTIME 1 #define HAVE_STRINGS_H 1 #define HAVE_STRING_H 1 #define HAVE_STRLCAT 1 #define HAVE_STRLCPY 1 #define HAVE_STRTOLL 1 #define HAVE_STRTOUL 1 #define HAVE_STRUCT_ADDRINFO 1 #define HAVE_STRUCT_IN6_ADDR 1 #define HAVE_STRUCT_SOCKADDR_IN6 1 #define HAVE_STRUCT_SOCKADDR_STORAGE 1 #define HAVE_STRUCT_STAT_ST_BLKSIZE 1 #define HAVE_STRUCT_TIMESPEC 1 #define HAVE_STRUCT_TIMEVAL 1 #define HAVE_SYSCONF 1 #define HAVE_SYSLEN_IN_UTMPX 1 #define HAVE_SYS_ERRLIST 1 #define HAVE_SYS_MMAN_H 1 #define HAVE_SYS_NERR 1 #define HAVE_SYS_PTMS_H 1 #define HAVE_SYS_SELECT_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_SYS_STREAM_H 1 #define HAVE_SYS_STROPTS_H 1 #define HAVE_SYS_SYSMACROS_H 1 #define HAVE_SYS_TIME_H 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_UN_H 1 #define HAVE_TCGETPGRP 1 #define HAVE_TCSENDBREAK 1 #define HAVE_TIME 1 #define HAVE_TIME_H 1 #define HAVE_TIME_IN_UTMP 1 #define HAVE_TIME_IN_UTMPX 1 #define HAVE_TRUNCATE 1 #define HAVE_TV_IN_UTMPX 1 #define HAVE_TYPE_IN_UTMP 1 #define HAVE_TYPE_IN_UTMPX 1 #define HAVE_UINTXX_T 1 #define HAVE_UNISTD_H 1 #define HAVE_UNSIGNED_LONG_LONG 1 #define HAVE_UPDWTMP 1 #define HAVE_UPDWTMPX 1 #define HAVE_UTIMES 1 #define HAVE_UTIME_H 1 #define HAVE_UTMPNAME 1 #define HAVE_UTMPXNAME 1 #define HAVE_UTMPX_H 1 #define HAVE_UTMP_H 1 #define HAVE_U_CHAR 1 #define HAVE_U_INT 1 #define HAVE_VA_COPY 1 #define HAVE_VHANGUP 1 #define HAVE_VSNPRINTF 1 #define HAVE_WAITPID 1 #define HAVE__GETLONG 1 #define HAVE__GETSHORT 1 #define HAVE___FUNCTION__ 1 #define HAVE___VA_COPY 1 #define HAVE___func__ 1 #define LOCKED_PASSWD_STRING "*LK*" #define LOGIN_NEEDS_TERM 1 #define LOGIN_NEEDS_UTMPX 1 #define LOGIN_PROGRAM_FALLBACK "/usr/bin/login" #define OPENSSL_PRNG_ONLY 1 #define PACKAGE_BUGREPORT "openssh-unix-dev at mindrot.org" #define PACKAGE_NAME "OpenSSH" #define PACKAGE_STRING "OpenSSH Portable" #define PACKAGE_TARNAME "openssh" #define PACKAGE_VERSION "Portable" #define PAM_SUN_CODEBASE 1 #define PAM_TTY_KLUDGE 1 #define PASSWD_NEEDS_USERNAME 1 #define SIZEOF_CHAR 1 #define SIZEOF_INT 4 #define SIZEOF_LONG_INT 4 #define SIZEOF_LONG_LONG_INT 8 #define SIZEOF_SHORT_INT 2 #define SNPRINTF_CONST const #define SSHD_ACQUIRES_CTTY 1 #define SSHPAM_CHAUTHTOK_NEEDS_RUID 1 #define SSH_PRIVSEP_USER "sshd" #define STDC_HEADERS 1 #define USER_PATH "/usr/bin:/bin:/usr/sbin:/sbin:/opt/openssh/bin" #define USE_PAM 1 #define WORDS_BIGENDIAN 1 #define XAUTH_PATH "/usr/openwin/bin/xauth" #define _FILE_OFFSET_BITS 64 #define _PATH_PASSWD_PROG "/usr/bin/passwd" #define _PATH_SSH_PIDDIR "/var/run" [ /soamp/SSSecurity/OpenSSH/openssh-4.6p1/src 60 ] For the sftp-server error "process_write: write failed", I think it's not spurious error because the sftp command "put file" failed. The file is created in the server, but could not be written to because of the "file too large" error returned from the write function. I'll try to run "make tests" of version 4.7p1 today. Thanks again, John -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Wednesday, September 05, 2007 7:29 PM To: Wong, John (CAR:CP04) Cc: openssh-unix-dev at mindrot.org Subject: Re: Openssh4.6p1 Make tests failed in sftp John Wong wrote: > After configuring and compiling OpenSSH version 4.6p1 in my SUN > Solaris8 ultrasparc machine, I run "make tests" and got the following > errors. The compiler used is GCC3.3. 4.7p1 was just released in the last day or so. Could you please repeat the tests with that version? I test on Solaris 8/sparc regularly so there's no fundamental reason why it shouldn't work. > I do not get these errors when running "make tests" with OpenSSH > version 4.3p2 in the same machine. > > When I installed the 4.6p1 package to my machine and test sftp from a > client, I got the following log messages in the authlog: > > Sep 5 17:09:51 wcarsx0h sshd[23483]: subsystem request for sftp Sep > 5 17:09:56 wcarsx0h sftp-server[23840]: error: process_write: write > failed Sep 5 17:09:56 wcarsx0h sshd[23483]: error: channel 0: > chan_read_failed for ist These are spurious and can be ignored. They are fixed in 4.7p1. > Further debugging on process_write of sftp-server.c, I found that the > errno returned from the "write" function is always "File too large" no > matter what is the size of the file. I appreciate your help to further > investigate the possible casue of the problem. I'm wondering if configure some how got something like large file support wrong... Could you please post the content of config.h (eg "grep '#define' config.h" to strip out the comments and blanks). Also, what CFLAGS are set in the Makefile? Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From postmaster at dpaschoal.com.br Fri Sep 7 00:12:12 2007 From: postmaster at dpaschoal.com.br (postmaster at dpaschoal.com.br) Date: Thu, 6 Sep 2007 11:12:12 -0300 Subject: Delivery Status Notification (Failure) Message-ID: This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. rh at dpaschoal.com.br -------------- next part -------------- An embedded message was scrubbed... From: openssh-unix-dev at mindrot.org Subject: Failed (rh at dpaschoal.com.br) Date: Thu, 6 Sep 2007 11:08:50 -0300 Size: 1973 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070906/dd6240ab/attachment-0001.mht From jwwong at nortel.com Fri Sep 7 05:02:56 2007 From: jwwong at nortel.com (John Wong) Date: Thu, 6 Sep 2007 15:02:56 -0400 Subject: Openssh4.6p1 Make tests failed in sftp In-Reply-To: <46DF3BB8.1000008@zip.com.au> Message-ID: <549FD0754C7E1D468D93A34B42AC5F92099D0D19@zcarhxm1.corp.nortel.com> Hi Darren, I tested 4.7p1 and got the same error in sftp of "make tests". I made the following changes before applying the configure command: - change to Makefile.in "DESTDIR=/soamp/SSSecurity/OpenSSH/openssh-4.7p1" - add /soamp/SSCommon/GCC/gcc3.3/bin to $PATH (setup the PATH to GCC) - setenv LD_LIBRARY_PATH /soamp/SSCommon/GCC/gcc3.3/lib - setenv PERL /opt/corp/unsupported/bin/perl5 - setenv INSTALL "/opt/corp/unsupported/bin/ginstall -c" - setenv CFLAGS "-g -02 -0 -mcpu=ultrasparc" The configure command I used was: ./configure --prefix=/opt/openssh --without-zlib-version-check --with-ssl-dir=/vobs/OpenSSL/0.9.8e/loadbuild/SunOS_5.10 --with-pam --with-cflags I used "without-zlib-version-check" because the version of zlib in my machine is 1.1.3, but I don't think this would cause the sftp problem. Hope that may help in finding the cause of the problem. Thanks, John -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Wednesday, September 05, 2007 7:29 PM To: Wong, John (CAR:CP04) Cc: openssh-unix-dev at mindrot.org Subject: Re: Openssh4.6p1 Make tests failed in sftp John Wong wrote: > After configuring and compiling OpenSSH version 4.6p1 in my SUN > Solaris8 ultrasparc machine, I run "make tests" and got the following > errors. The compiler used is GCC3.3. 4.7p1 was just released in the last day or so. Could you please repeat the tests with that version? I test on Solaris 8/sparc regularly so there's no fundamental reason why it shouldn't work. > I do not get these errors when running "make tests" with OpenSSH > version 4.3p2 in the same machine. > > When I installed the 4.6p1 package to my machine and test sftp from a > client, I got the following log messages in the authlog: > > Sep 5 17:09:51 wcarsx0h sshd[23483]: subsystem request for sftp Sep > 5 17:09:56 wcarsx0h sftp-server[23840]: error: process_write: write > failed Sep 5 17:09:56 wcarsx0h sshd[23483]: error: channel 0: > chan_read_failed for ist These are spurious and can be ignored. They are fixed in 4.7p1. > Further debugging on process_write of sftp-server.c, I found that the > errno returned from the "write" function is always "File too large" no > matter what is the size of the file. I appreciate your help to further > investigate the possible casue of the problem. I'm wondering if configure some how got something like large file support wrong... Could you please post the content of config.h (eg "grep '#define' config.h" to strip out the comments and blanks). Also, what CFLAGS are set in the Makefile? Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From ast at domdv.de Fri Sep 7 03:21:07 2007 From: ast at domdv.de (Andreas Steinmetz) Date: Thu, 06 Sep 2007 19:21:07 +0200 Subject: openssh 4.6p1 closing connection with strange packet length Message-ID: <46E03703.3010502@domdv.de> server is running openssh 4.6p1 on linux x86 (32bit) client is running openssh 4.6p1 on linux x86_64 (64bit) Just connecting from the client to the server and running "top" long enough results in: Disconnecting: Bad packet length 3690378913. This seems like a 32/64 bit problem to me. -- Andreas Steinmetz SPAMmers use robotrap at domdv.de From ssklar at stanford.edu Fri Sep 7 12:32:39 2007 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Thu, 6 Sep 2007 19:32:39 -0700 Subject: OpenSSH 4.7p1, AIX 5.2, with IBM Kerberos = No Joy. Message-ID: <08693B69-9983-48C5-9C55-2CA184A9D449@stanford.edu> I just tried to build the 4.7p1 on AIX 5.2, with Kerberos 5 enabled, using the IBM Kerberos implementation (krb5.client.rte, krb5.toolkit.adt, etc.) Is this supposed to work, or is the full MIT Kerberos distribution required? IBM provides an older version of OpenSSH (4.3p2), with Kerberos support, but there are some problems with it, and I was hoping the problems would be resolved with a newer version. Unfortunately, I couldn't even get it to build successfully: CC=gcc ./configure --with-kerberos5=/usr/krb5 ... produces ... checking for gss_init_sec_context in -lgssapi... no checking for gss_init_sec_context in -lgssapi_krb5... no configure: WARNING: Cannot find any suitable gss-api library - build may fail checking gssapi.h usability... no checking gssapi.h presence... no checking for gssapi.h... no checking gssapi.h usability... no checking gssapi.h presence... no checking for gssapi.h... no configure: WARNING: Cannot find any suitable gss-api header - build may fail checking gssapi_krb5.h usability... no checking gssapi_krb5.h presence... no checking for gssapi_krb5.h... no checking for gssapi.h... (cached) no checking gssapi/gssapi.h usability... yes checking gssapi/gssapi.h presence... yes checking for gssapi/gssapi.h... yes checking for gssapi_krb5.h... (cached) no checking gssapi/gssapi_krb5.h usability... no checking gssapi/gssapi_krb5.h presence... yes configure: WARNING: gssapi/gssapi_krb5.h: present but cannot be compiled configure: WARNING: gssapi/gssapi_krb5.h: check for missing prerequisite headers? configure: WARNING: gssapi/gssapi_krb5.h: see the Autoconf documentation configure: WARNING: gssapi/gssapi_krb5.h: section "Present But Cannot Be Compiled" configure: WARNING: gssapi/gssapi_krb5.h: proceeding with the preprocessor's result configure: WARNING: gssapi/gssapi_krb5.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix- dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for gssapi/gssapi_krb5.h... yes ... and make fails with ... gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/ usr/krb5/lib -Wl,-blibpath:/usr/lib:/lib:/usr/krb5/lib -lssh - lopenbsd-compat -lcrypto -lz -lkrb5 -lk5crypto -lcom_err collect2: library libk5crypto not found make: 1254-004 The error code from the last command is 1. Any ideas, or even a clear statement that this will or not work? I really don't want to build and install MIT Kerberos for our systems, when the IBM-provided tools work for most of what we need. Thanks, -s- -- Sandor W. Sklar Unix Systems Administrator Stanford University Libraries & Academic Information Resources (SULAIR) Digital Libraries Systems & Services (DLSS) From rob at inversepath.com Fri Sep 7 21:25:50 2007 From: rob at inversepath.com (rob at inversepath.com) Date: Fri, 7 Sep 2007 11:25:50 +0000 Subject: Public key reading abstraction (to allow future work) Message-ID: <20070907112550.GA26117@fuse.inversepath.com> Damien, I've filed a bug for this on mindrot as requested, https://bugzilla.mindrot.org/show_bug.cgi?id=1348. Patch attached in case that helps reviewing. Comments welcome, Rob -- Rob Holland http://www.inversepath.com - Chief R & D Engineer Inverse Path Ltd, 63 Park Road, Peterborough, PE1 2TN, UK Registered in England: 5555973 -------------- next part -------------- === modified file 'auth-rsa.c' --- auth-rsa.c 2007-07-30 09:54:36 +0000 +++ auth-rsa.c 2007-08-02 12:17:32 +0000 @@ -173,7 +173,6 @@ u_int bits; FILE *f; u_long linenum = 0; - struct stat st; Key *key; /* Temporarily use the user's uid. */ @@ -183,26 +182,9 @@ file = authorized_keys_file(pw); debug("trying public RSA key file %s", file); - /* Fail quietly if file does not exist */ - if (stat(file, &st) < 0) { - /* Restore the privileged uid. */ - restore_uid(); - xfree(file); - return (0); - } - /* Open the file containing the authorized keys. */ - f = fopen(file, "r"); + f = open_keyfile(file, pw, options.strict_modes); if (!f) { - /* Restore the privileged uid. */ - restore_uid(); - xfree(file); - return (0); - } - if (options.strict_modes && - secure_filename(f, file, pw, line, sizeof(line)) != 0) { - xfree(file); - fclose(f); - logit("Authentication refused: %s", line); + xfree(file); restore_uid(); return (0); } === modified file 'auth.c' --- auth.c 2007-07-30 09:54:36 +0000 +++ auth.c 2007-08-02 12:03:02 +0000 @@ -397,79 +397,6 @@ return host_status; } - -/* - * Check a given file for security. This is defined as all components - * of the path to the file must be owned by either the owner of - * of the file or root and no directories must be group or world writable. - * - * XXX Should any specific check be done for sym links ? - * - * Takes an open file descriptor, the file name, a uid and and - * error buffer plus max size as arguments. - * - * Returns 0 on success and -1 on failure - */ -int -secure_filename(FILE *f, const char *file, struct passwd *pw, - char *err, size_t errlen) -{ - uid_t uid = pw->pw_uid; - char buf[MAXPATHLEN], homedir[MAXPATHLEN]; - char *cp; - int comparehome = 0; - struct stat st; - - if (realpath(file, buf) == NULL) { - snprintf(err, errlen, "realpath %s failed: %s", file, - strerror(errno)); - return -1; - } - if (realpath(pw->pw_dir, homedir) != NULL) - comparehome = 1; - - /* check the open file to avoid races */ - if (fstat(fileno(f), &st) < 0 || - (st.st_uid != 0 && st.st_uid != uid) || - (st.st_mode & 022) != 0) { - snprintf(err, errlen, "bad ownership or modes for file %s", - buf); - return -1; - } - - /* for each component of the canonical path, walking upwards */ - for (;;) { - if ((cp = dirname(buf)) == NULL) { - snprintf(err, errlen, "dirname() failed"); - return -1; - } - strlcpy(buf, cp, sizeof(buf)); - - debug3("secure_filename: checking '%s'", buf); - if (stat(buf, &st) < 0 || - (st.st_uid != 0 && st.st_uid != uid) || - (st.st_mode & 022) != 0) { - snprintf(err, errlen, - "bad ownership or modes for directory %s", buf); - return -1; - } - - /* If are passed the homedir then we can stop */ - if (comparehome && strcmp(homedir, buf) == 0) { - debug3("secure_filename: terminating check at '%s'", - buf); - break; - } - /* - * dirname should always complete with a "/" path, - * but we can be paranoid and check for "." too - */ - if ((strcmp("/", buf) == 0) || (strcmp(".", buf) == 0)) - break; - } - return 0; -} - struct passwd * getpwnamallow(const char *user) { === modified file 'auth.h' --- auth.h 2007-07-30 09:54:36 +0000 +++ auth.h 2007-08-02 12:02:24 +0000 @@ -166,8 +166,6 @@ char *authorized_keys_file(struct passwd *); char *authorized_keys_file2(struct passwd *); -int -secure_filename(FILE *, const char *, struct passwd *, char *, size_t); HostStatus check_key_in_hostfiles(struct passwd *, Key *, const char *, === modified file 'auth2-pubkey.c' --- auth2-pubkey.c 2007-07-30 09:54:36 +0000 +++ auth2-pubkey.c 2007-08-02 12:19:19 +0000 @@ -183,34 +183,21 @@ int found_key = 0; FILE *f; u_long linenum = 0; - struct stat st; Key *found; char *fp; /* Temporarily use the user's uid. */ temporarily_use_uid(pw); + /* The authorized keys. */ + file = authorized_keys_file(pw); debug("trying public key file %s", file); - /* Fail quietly if file does not exist */ - if (stat(file, &st) < 0) { - /* Restore the privileged uid. */ - restore_uid(); - return 0; - } - /* Open the file containing the authorized keys. */ - f = fopen(file, "r"); + f = open_keyfile(file, pw, options.strict_modes); if (!f) { - /* Restore the privileged uid. */ - restore_uid(); - return 0; - } - if (options.strict_modes && - secure_filename(f, file, pw, line, sizeof(line)) != 0) { - fclose(f); - logit("Authentication refused: %s", line); - restore_uid(); - return 0; + xfree(file); + restore_uid(); + return (0); } found_key = 0; === modified file 'misc.c' --- misc.c 2007-07-30 09:54:36 +0000 +++ misc.c 2007-08-02 12:47:54 +0000 @@ -46,6 +46,9 @@ # include #include #endif +#ifdef HAVE_LIBGEN_H +#include +#endif #ifdef SSH_TUN_OPENBSD #include #endif @@ -608,6 +611,102 @@ } /* + * Check a given file for security. This is defined as all components + * of the path to the file must be owned by either the owner of + * of the file or root and no directories must be group or world writable. + * + * XXX Should any specific check be done for sym links ? + * + * Takes an open file descriptor, the file name, a uid and and + * error buffer plus max size as arguments. + * + * Returns 0 on success and -1 on failure + */ +static int +secure_filename(FILE *f, const char *file, struct passwd *pw, + char *err, size_t errlen) +{ + uid_t uid = pw->pw_uid; + char buf[MAXPATHLEN], homedir[MAXPATHLEN]; + char *cp; + int comparehome = 0; + struct stat st; + + if (realpath(file, buf) == NULL) { + snprintf(err, errlen, "realpath %s failed: %s", file, + strerror(errno)); + return -1; + } + if (realpath(pw->pw_dir, homedir) != NULL) + comparehome = 1; + + /* check the open file to avoid races */ + if (fstat(fileno(f), &st) < 0 || + (st.st_uid != 0 && st.st_uid != uid) || + (st.st_mode & 022) != 0) { + snprintf(err, errlen, "bad ownership or modes for file %s", + buf); + return -1; + } + + /* for each component of the canonical path, walking upwards */ + for (;;) { + if ((cp = dirname(buf)) == NULL) { + snprintf(err, errlen, "dirname() failed"); + return -1; + } + strlcpy(buf, cp, sizeof(buf)); + + debug3("secure_filename: checking '%s'", buf); + if (stat(buf, &st) < 0 || + (st.st_uid != 0 && st.st_uid != uid) || + (st.st_mode & 022) != 0) { + snprintf(err, errlen, + "bad ownership or modes for directory %s", buf); + return -1; + } + + /* If are passed the homedir then we can stop */ + if (comparehome && strcmp(homedir, buf) == 0) { + debug3("secure_filename: terminating check at '%s'", + buf); + break; + } + /* + * dirname should always complete with a "/" path, + * but we can be paranoid and check for "." too + */ + if ((strcmp("/", buf) == 0) || (strcmp(".", buf) == 0)) + break; + } + return 0; +} + +FILE * +open_keyfile(const char *filename, struct passwd *pw, int strict_modes) +{ + char err[1024]; + struct stat st; + FILE *f; + + if (stat(filename, &st) < 0) + return NULL; + + f = fopen(filename, "r"); + if (!f) + return NULL; + + if (strict_modes && + secure_filename(f, filename, pw, err, sizeof(err)) != 0) { + fclose(f); + logit("Authentication refused: %s", err); + return NULL; + } + + return f; +} + +/* * Read an entire line from a public key file into a static buffer, discarding * lines that exceed the buffer size. Returns 0 on success, -1 on failure. */ === modified file 'misc.h' --- misc.h 2007-07-30 09:54:36 +0000 +++ misc.h 2007-08-02 12:12:51 +0000 @@ -85,6 +85,7 @@ char *read_passphrase(const char *, int); int ask_permission(const char *, ...) __attribute__((format(printf, 1, 2))); +FILE *open_keyfile(const char *, struct passwd *, int); int read_keyfile_line(FILE *, const char *, char *, size_t, u_long *); #endif /* _MISC_H */ From sgtphou at fire-eyes.org Sat Sep 8 00:03:28 2007 From: sgtphou at fire-eyes.org (fire-eyes) Date: Fri, 07 Sep 2007 14:03:28 +0000 Subject: openssh 4.6p1 closing connection with strange packet length In-Reply-To: <46E03703.3010502@domdv.de> References: <46E03703.3010502@domdv.de> Message-ID: <46E15A30.2010605@fire-eyes.org> Andreas Steinmetz wrote: > server is running openssh 4.6p1 on linux x86 (32bit) > client is running openssh 4.6p1 on linux x86_64 (64bit) > > Just connecting from the client to the server and running "top" long > enough results in: > > Disconnecting: Bad packet length 3690378913. > > This seems like a 32/64 bit problem to me. I am getting similar results. What follows is a dirty cut-n-paste of the issues I told gentoo's bugzilla about, I hope it is enough information (I am short on time). The client is 32 bit, the server is 64 bit. The server runs 4.6_p1. I use ssh "4.7_p1" (gentooism?) to connect to my server, like so: ssh -p someport -D localport -R remoteIP:remotelistenPORT:localIP:localPORT username at remoteIP -C -2 On the server, a backup script which uses rsync runs. This script connects to its local port remotelistenPORT from above. This is then tunneled back over SSH and comes out to localIP and localPORT, to connect to an rsync server. This all worked fine prior to ssh "4.7_p1". After that, any time this script runs at 40 minutes after every hour, my ssh session dies, and apps that were using the tunnel get disconnected. Here is the output I see: Client side: buffer_get_string_ret: bad string length 364172 buffer_get_string: buffer error Server side: Sep 5 11:40:06 thing sshd[23786]: fatal: buffer_append_space: len 1646878 not supported Sep 5 11:40:06 thing sshd(pam_unix)[23786]: session closed for user myuser Sep 5 11:40:06 thing sshd[23784]: syslogin_perform_logout: logout() returned an error I tried running my backup script manually and was able to reproduce. Client side: buffer_get_string_ret: bad string length 270072 buffer_get_string: buffer error Server side: Sep 5 11:43:41 thing sshd[24104]: fatal: buffer_append_space: len 1440384 not supported Sep 5 11:43:41 thing sshd(pam_unix)[24104]: session closed for user myuser Sep 5 11:43:41 thing sshd[24102]: syslogin_perform_logout: logout() returned an error From jwwong at nortel.com Sat Sep 8 04:51:36 2007 From: jwwong at nortel.com (John Wong) Date: Fri, 7 Sep 2007 14:51:36 -0400 Subject: Openssh4.6p1 Make tests failed in sftp In-Reply-To: <549FD0754C7E1D468D93A34B42AC5F92099D0D19@zcarhxm1.corp.nortel.com> Message-ID: <549FD0754C7E1D468D93A34B42AC5F92099D0D1B@zcarhxm1.corp.nortel.com> Hi Darren, I tested again in another machine using GCC version 3.4.6 without the issue. Looks like it's the GCC version 3.3 caused the problem. Thanks, John -----Original Message----- From: Wong, John (CAR:CP04) Sent: Thursday, September 06, 2007 3:03 PM To: 'Darren Tucker' Cc: openssh-unix-dev at mindrot.org Subject: RE: Openssh4.6p1 Make tests failed in sftp Hi Darren, I tested 4.7p1 and got the same error in sftp of "make tests". I made the following changes before applying the configure command: - change to Makefile.in "DESTDIR=/soamp/SSSecurity/OpenSSH/openssh-4.7p1" - add /soamp/SSCommon/GCC/gcc3.3/bin to $PATH (setup the PATH to GCC) - setenv LD_LIBRARY_PATH /soamp/SSCommon/GCC/gcc3.3/lib - setenv PERL /opt/corp/unsupported/bin/perl5 - setenv INSTALL "/opt/corp/unsupported/bin/ginstall -c" - setenv CFLAGS "-g -02 -0 -mcpu=ultrasparc" The configure command I used was: ./configure --prefix=/opt/openssh --without-zlib-version-check --with-ssl-dir=/vobs/OpenSSL/0.9.8e/loadbuild/SunOS_5.10 --with-pam --with-cflags I used "without-zlib-version-check" because the version of zlib in my machine is 1.1.3, but I don't think this would cause the sftp problem. Hope that may help in finding the cause of the problem. Thanks, John -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Wednesday, September 05, 2007 7:29 PM To: Wong, John (CAR:CP04) Cc: openssh-unix-dev at mindrot.org Subject: Re: Openssh4.6p1 Make tests failed in sftp John Wong wrote: > After configuring and compiling OpenSSH version 4.6p1 in my SUN > Solaris8 ultrasparc machine, I run "make tests" and got the following > errors. The compiler used is GCC3.3. 4.7p1 was just released in the last day or so. Could you please repeat the tests with that version? I test on Solaris 8/sparc regularly so there's no fundamental reason why it shouldn't work. > I do not get these errors when running "make tests" with OpenSSH > version 4.3p2 in the same machine. > > When I installed the 4.6p1 package to my machine and test sftp from a > client, I got the following log messages in the authlog: > > Sep 5 17:09:51 wcarsx0h sshd[23483]: subsystem request for sftp Sep > 5 17:09:56 wcarsx0h sftp-server[23840]: error: process_write: write > failed Sep 5 17:09:56 wcarsx0h sshd[23483]: error: channel 0: > chan_read_failed for ist These are spurious and can be ignored. They are fixed in 4.7p1. > Further debugging on process_write of sftp-server.c, I found that the > errno returned from the "write" function is always "File too large" no > matter what is the size of the file. I appreciate your help to further > investigate the possible casue of the problem. I'm wondering if configure some how got something like large file support wrong... Could you please post the content of config.h (eg "grep '#define' config.h" to strip out the comments and blanks). Also, what CFLAGS are set in the Makefile? Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sat Sep 8 11:19:18 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 Sep 2007 11:19:18 +1000 Subject: Openssh4.6p1 Make tests failed in sftp In-Reply-To: <549FD0754C7E1D468D93A34B42AC5F92099D0D1B@zcarhxm1.corp.nortel.com> References: <549FD0754C7E1D468D93A34B42AC5F92099D0D1B@zcarhxm1.corp.nortel.com> Message-ID: <46E1F896.4030803@zip.com.au> John Wong wrote: > Hi Darren, > > I tested again in another machine using GCC version 3.4.6 without the > issue. > > Looks like it's the GCC version 3.3 caused the problem. Excellent, thanks for letting us know. I've seen problems on Solaris caused by gcc installations that had headers from previous Solaris versions (ie the ones in /usr/local/lib/lib-gcc/ that are created by fixincludes when gcc itself is built). Perhaps that was the case here. -- 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 leel at igpp.ucla.edu Sat Sep 8 16:31:44 2007 From: leel at igpp.ucla.edu (leel) Date: Fri, 07 Sep 2007 23:31:44 -0700 Subject: curious behavior with ssh OpenSSH_3.9p1 Message-ID: <46E241D0.1050409@igpp.ucla.edu> Sirs, I'm trying to figure out why ssh (red hatOpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003) hangs to a solaris (Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f) after some time. the times seem variable. the process is still alive on the remote site. I can connect to another red hat machine on the same site with longer sessions. This computer has an older version of openssh (red hat OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f) This did not happen until I've changed my modem/router to a linksys wcg200. when the red-hat machine connects to a solaris machine at work there are no hang ups. I fear that the combination of the modem, solaris and ssh is causing the problem and I have tried every angle I could think of the fix this. Also with the same pc under windows xp ( this is a dual boot system) it does not hang since I am using ssh to execute a command to create a xterminal from the remote computer but using putty or ssh on my pc eventually hangs.. I've updated the sshd_config file to keep the session alive but to no avail. other programs such as downloading and internet radio don't seem to be affected. The download lasted for an hour. If you have time, do you have any suggestions or websites on why this is causing the problem? do you have any documentation on how ssh works and whether there are problems with cable modems and how do check if the cable modem is blocking the keepalive signals? I would like to make sure that it's the particular modem/router I am using thats causing the problem so that I can determine that I just need a different modem/router. Thank you for reading this Louise Lee From djm at mindrot.org Mon Sep 10 07:23:16 2007 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Sep 2007 07:23:16 +1000 (EST) Subject: curious behavior with ssh OpenSSH_3.9p1 In-Reply-To: <46E241D0.1050409@igpp.ucla.edu> References: <46E241D0.1050409@igpp.ucla.edu> Message-ID: On Fri, 7 Sep 2007, leel wrote: > Sirs, > I'm trying to figure out why ssh (red hatOpenSSH_3.9p1, OpenSSL 0.9.7a > Feb 19 2003) > hangs to a solaris (Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL > 0x0090704f) You might start by upgrading your OpenSSH to something more recent. openssh-3.9 is over three years old, and a lot of improvements have been made since then. -d From darryl-mailinglists at netbauds.net Tue Sep 11 00:12:09 2007 From: darryl-mailinglists at netbauds.net (Darryl L. Miles) Date: Mon, 10 Sep 2007 15:12:09 +0100 Subject: ssh client stays connected after remote forward fails to bind Message-ID: <46E550B9.5060708@netbauds.net> My command line looks like this: ssh -2 -C -o BatchMode=yes -o KeepAlive=yes -o ServerAliveInterval=600 -N -T -x -a -R2401:127.0.0.1:2401 I've tried to instruct SSH that the only purpose it has in life is to provide remote port forwarding (hence the -N -T) but if the remote fails to bind I get an error locally (Could not bind to remove address) and the SSH connection stays open and the client running. I think the ssh client should terminate at this point as there is no other channel open nor any possibility of a channel being opened (say through dynamic port forwarding). Maybe this is user error on my part ? Would this be considered a bug or a feature ? I'm using OpenSSH_3.9p1 in the client I've just investigated. The scenario that causes this problem is that my previous ssh client remote port forward is still active at the remote end, due to a half open connection (my end was rebooted, but the remote end is still open), so the TCP port is still bound and in use by the remote end, but its only a matter of time before ServerAliveInterval=600 kicks in and kills that connection. So my new ssh client instance reconnects and quickly sees the failure to setup remote port forward it then just stays connected (doing keep alives I guess) but with no useful purpose. I am thinking that the ssh client could be better by implementing: * Exit after the initial round of channel setups if they all fail because there was no further work to do once the remote bind failed is reported back. This should be the default IMHO with an option to disable. * In the case there is another channel open (multiple forwards multiplexed) then there should be a background timer which will reattempt to execute the command line / configured port forwards that are not currently available/active. This background timer should be configurable in seconds in an option, I think the default should be 60 seconds or so, I can't think use case that would want the default to be never (as it behaves right now, i.e. if you configured a forward and the ssh client is still running then we can presume you want that port forward to be setup ASAP, not a one shot attempt at startup that has little practical use that I can see). Thanks for reading, Darryl From dtucker at zip.com.au Tue Sep 11 00:34:53 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 11 Sep 2007 00:34:53 +1000 Subject: ssh client stays connected after remote forward fails to bind In-Reply-To: <46E550B9.5060708@netbauds.net> References: <46E550B9.5060708@netbauds.net> Message-ID: <20070910143453.GA3267@gate.dtucker.net> On Mon, Sep 10, 2007 at 03:12:09PM +0100, Darryl L. Miles wrote: > > My command line looks like this: > > ssh -2 -C -o BatchMode=yes -o KeepAlive=yes -o ServerAliveInterval=600 > -N -T -x -a -R2401:127.0.0.1:2401 > > I've tried to instruct SSH that the only purpose it has in life is to > provide remote port forwarding (hence the -N -T) but if the remote fails > to bind I get an error locally (Could not bind to remove address) and > the SSH connection stays open and the client running. I think the ssh > client should terminate at this point as there is no other channel open > nor any possibility of a channel being opened (say through dynamic port > forwarding). > > Maybe this is user error on my part ? Would this be considered a bug or > a feature ? I'm using OpenSSH_3.9p1 in the client I've just investigated. What you're looking for is "ExitOnForwardFailure", which was added in 4.4. -- 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 dbradford at never-enuff.net Mon Sep 10 22:49:38 2007 From: dbradford at never-enuff.net ( Dickie Bradford ) Date: Mon, 10 Sep 2007 08:49:38 -0400 Subject: SSH Problem?? - HELP Message-ID: Hi I am not sure if I have found a bug or exploit or what I have found, but here is an entry I found in my secure logs multiple times Sep 9 17:00:44 www webmin[8685]: Non-existent login as a a 1 new 1234567890 root from fordf350.never-enuff.net and I have also found a user root at notty logged in, I have disabled sshd for now until i find out whats going on, could anyone please tell me if this is a bug or exploit and if so, how to avoid it. My System is Mandrake 10.1 2.6.8.1-12mdk-i586-up-1GB OpenSSH_4.3p1, OpenSSL 0.9.7d 17 Mar 2004 Anything else that i can provide to help? Thnx Dickie Bradford ------------------------------------------------------------ (A)bort, (R)etry, (S)mack the @#$&*~ thing! ------------------------------------------------------------ No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.485 / Virus Database: 269.13.13/998 - Release Date: 9/10/2007 8:48 AM From dkg-openssh.com at fifthhorseman.net Tue Sep 11 01:00:29 2007 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 10 Sep 2007 11:00:29 -0400 Subject: ssh client stays connected after remote forward fails to bind In-Reply-To: <20070910143453.GA3267@gate.dtucker.net> (Darren Tucker's message of "Tue\, 11 Sep 2007 00\:34\:53 +1000") References: <46E550B9.5060708@netbauds.net> <20070910143453.GA3267@gate.dtucker.net> Message-ID: <87y7fe8t0y.fsf@squeak.fifthhorseman.net> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070910/9f497ace/attachment.bin From imorgan at nas.nasa.gov Tue Sep 11 02:22:09 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 10 Sep 2007 09:22:09 -0700 Subject: curious behavior with ssh OpenSSH_3.9p1 In-Reply-To: <46E241D0.1050409@igpp.ucla.edu> References: <46E241D0.1050409@igpp.ucla.edu> Message-ID: <20070910162209.GA21800@linux55.nas.nasa.gov> On Fri, Sep 07, 2007 at 23:31:44 -0700, leel wrote: > Sirs, > I'm trying to figure out why ssh (red hatOpenSSH_3.9p1, OpenSSL 0.9.7a > Feb 19 2003) > hangs to a solaris (Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL > 0x0090704f) after some time. the times seem > variable. the process is still alive on the remote site. > I can connect to another red hat machine on the same site with longer > sessions. This computer has an older > version of openssh (red hat OpenSSH_3.4p1, SSH protocols 1.5/2.0, > OpenSSL 0x0090602f) > This did not happen until I've changed > my modem/router to a linksys wcg200. when the red-hat machine connects > to a solaris machine at work > there are no hang ups. I fear that the combination of the modem, > solaris and ssh is causing the problem > and I have tried every angle I could think of the fix this. Also with > the same pc under windows xp > ( this is a dual boot system) it does not hang since I am using ssh to > execute a command to create a xterminal > from the remote computer but using putty or ssh on my pc eventually hangs.. > I've updated the sshd_config file to keep the session alive but to no > avail. other programs such as downloading > and internet radio don't seem to be affected. The download lasted for an > hour. > If you have time, do you have any suggestions or websites on why this is > causing the problem? > do you have any documentation on how ssh works and whether there are > problems with cable modems > and how do check if the cable modem is blocking the keepalive signals? > I would like to make sure that it's the particular modem/router I am > using thats causing the problem so that > I can determine that I just need a different modem/router. > Thank you for reading this > Louise Lee > > I've occasionally seen situations where certain Linksys (and NetGear) routers appear to break idle ssh sessions. This seems to happen even with TCP keepalive enabled. The solution has usually been to enable the ServerAliveInterval mechanism in the client ssh_config (or ~/.ssh/config). I don't recall if the Sun SSH 1.1 implementation supports the ServerAliveInterval or ClientAliveInterval mechanisms. I suspect it does not, in which case this solution won't work for you. -- Iain Morgan From rac at tenzing.org Tue Sep 11 04:55:18 2007 From: rac at tenzing.org (Roger Cornelius) Date: Mon, 10 Sep 2007 14:55:18 -0400 Subject: 4.7p1 password auth broken on SCO OSR6 Message-ID: <20070910185518.GA12718@tenzing.org> openssh 4.7p1 SCO OSR6 Password authentication is non-functional. This seems dependent on USE_LIBIAF which further depends on HAVE_LIBIAF (in defines.h), but there is no longer any code in configure to define the latter. Building with HAVE_LIBIAF defined enables password authentication, but only for non-long (<9 char) passwords, even though UNIXWARE_LONG_PASSWORDS seems to be defined. I haven't had time yet to investigate further. -- Roger Cornelius rac at tenzing.org From tim at multitalents.net Tue Sep 11 09:14:48 2007 From: tim at multitalents.net (Tim Rice) Date: Mon, 10 Sep 2007 16:14:48 -0700 (PDT) Subject: 4.7p1 password auth broken on SCO OSR6 In-Reply-To: <20070910185518.GA12718@tenzing.org> References: <20070910185518.GA12718@tenzing.org> Message-ID: On Mon, 10 Sep 2007, Roger Cornelius wrote: > openssh 4.7p1 > SCO OSR6 > > Password authentication is non-functional. This seems dependent on > USE_LIBIAF which further depends on HAVE_LIBIAF (in defines.h), but > there is no longer any code in configure to define the latter. Building This patch will solve the missing HAVE_LIBIAF ------------ --- configure.ac.old 2007-08-15 09:16:29.007892000 -0700 +++ configure.ac 2007-09-10 15:54:26.072835157 -0700 @@ -2004,7 +2004,10 @@ saved_LIBS="$LIBS" AC_CHECK_LIB(iaf, ia_openinfo, [ LIBS="$LIBS -liaf" - AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf"]) + AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf" + AC_DEFINE(HAVE_LIBIAF, 1, + [Define if system has libiaf that supports set_id]) + ]) ]) LIBS="$saved_LIBS" ------------ > with HAVE_LIBIAF defined enables password authentication, but only for > non-long (<9 char) passwords, even though UNIXWARE_LONG_PASSWORDS seems > to be defined. I haven't had time yet to investigate further. Authentication in the SVR5 space on OpenServer 6 is still lacking. (getluid/setluid) Probably best to build in the osr5 space for now. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From ribas at c3sl.ufpr.br Tue Sep 11 11:28:27 2007 From: ribas at c3sl.ufpr.br (Bruno Cesar Ribas) Date: Mon, 10 Sep 2007 22:28:27 -0300 Subject: [patch] sftp-server basepath [yet another] In-Reply-To: <20070901202211.GA22122@c3sl.ufpr.br> References: <20070901202211.GA22122@c3sl.ufpr.br> Message-ID: <20070911012827.GA5078@c3sl.ufpr.br> I made some changes [as attached]. For some reason i did not receive Darren Tucker mail, saw his mail at archive searching for other problem. well.. that's it On Sat, Sep 01, 2007 at 05:22:11PM -0300, Bruno Cesar Ribas wrote: > Hi, > > I made this simple path to make sftp-server restricted to a basepath! > > This was done because use sshfs [wich base is sftp-server] to allow people > access medias [ cdrom,dvdrom, floppy, usb] from x-terms. > > Those x-terms [ diskless] does not have all users, so we share a single user > and a DSA empty passphrase, with some acl scipts at .ssh/authorized keys. > > Main usage of this patch is to NOT allow a user who mounted a floppy access > other mounted media from another user. > > Usage: > sftp-server -b > > My page includes this path: http://www.inf.ufpr.br/ribas/sshfs_help/ > > And it is attached too. > > Thanks for atention > > Bruno Ribas > -- > Bruno Ribas - ribas at c3sl.ufpr.br > http://web.inf.ufpr.br/ribas > C3SL: http://www.c3sl.ufpr.br > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Bruno Ribas - ribas at c3sl.ufpr.br http://web.inf.ufpr.br/ribas C3SL: http://www.c3sl.ufpr.br -------------- next part -------------- A non-text attachment was scrubbed... Name: sftp-server.c.patch Type: text/x-diff Size: 2163 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070910/3259733e/attachment.bin From roman.fiedler at telbiomed.at Wed Sep 12 19:08:30 2007 From: roman.fiedler at telbiomed.at (DI Roman Fiedler) Date: Wed, 12 Sep 2007 11:08:30 +0200 Subject: sftp-server only in subdir possible? Message-ID: <46E7AC8E.1040506@telbiomed.at> I'm searching for a simple solution to allow access to only one directory of an existing user (that may not login) via sftp-server and authorized_keys file using the extended syntax command="/usr/lib/openssh/sftp-server --root /data/exchange",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAA...keydata Is something like that already possible, is there a better solution? If not, how much effort for me would it be to implement it? I've already got the ubuntu sources and looked into the code a little bit. Is the chroot syscall after opening the root directory sufficient to make it work? Never programmed with chroot. Could such patch make it into the trunk? From rac at tenzing.org Thu Sep 13 00:30:57 2007 From: rac at tenzing.org (Roger Cornelius) Date: Wed, 12 Sep 2007 10:30:57 -0400 Subject: 4.7p1 password auth broken on SCO OSR6 In-Reply-To: References: <20070910185518.GA12718@tenzing.org> Message-ID: <20070912143057.GA16769@tenzing.org> Thanks Tim. I will install and test further this week. On 09/10/2007 16:14, Tim Rice wrote: > On Mon, 10 Sep 2007, Roger Cornelius wrote: > > > openssh 4.7p1 > > SCO OSR6 > > > > Password authentication is non-functional. This seems dependent on > > USE_LIBIAF which further depends on HAVE_LIBIAF (in defines.h), but > > there is no longer any code in configure to define the latter. Building > > This patch will solve the missing HAVE_LIBIAF > ------------ > --- configure.ac.old 2007-08-15 09:16:29.007892000 -0700 > +++ configure.ac 2007-09-10 15:54:26.072835157 -0700 > @@ -2004,7 +2004,10 @@ > saved_LIBS="$LIBS" > AC_CHECK_LIB(iaf, ia_openinfo, [ > LIBS="$LIBS -liaf" > - AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf"]) > + AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf" > + AC_DEFINE(HAVE_LIBIAF, 1, > + [Define if system has libiaf that supports set_id]) > + ]) > ]) > LIBS="$saved_LIBS" > > ------------ > > > with HAVE_LIBIAF defined enables password authentication, but only for > > non-long (<9 char) passwords, even though UNIXWARE_LONG_PASSWORDS seems > > to be defined. I haven't had time yet to investigate further. > > Authentication in the SVR5 space on OpenServer 6 is still lacking. > (getluid/setluid) > > Probably best to build in the osr5 space for now. > > > -- > Tim Rice Multitalents (707) 887-1469 > tim at multitalents.net > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Roger Cornelius rac at tenzing.org From jon at cybus.co.uk Thu Sep 13 00:31:39 2007 From: jon at cybus.co.uk (Jonathan Miles) Date: Wed, 12 Sep 2007 15:31:39 +0100 Subject: sftp-server only in subdir possible? In-Reply-To: <46E7AC8E.1040506@telbiomed.at> References: <46E7AC8E.1040506@telbiomed.at> Message-ID: <46E7F84B.7060204@cybus.co.uk> DI Roman Fiedler wrote: > I'm searching for a simple solution to allow access to only one > directory of an existing user (that may not login) via sftp-server and > authorized_keys file using the extended syntax > > command="/usr/lib/openssh/sftp-server --root > /data/exchange",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty > ssh-rsa AAA...keydata > > Is something like that already possible, is there a better solution? I wrote a patch which could facilitate this. It allows requests (as defined in RFC 4254) to be controlled using a configuration like the following: Match Group restricted GlobalReqDeny tcpip-forward GlobalReqDeny direct-tcpip ChannelDeny x11 ChannelReqDeny shell ChannelReqDeny exec ChannelReqDeny x11-req ChannelReqDeny pty-req ChannelReqDeny env Subsystem sftp /usr/lib/openssh/sftp-server --chroot The above would effectively only allow "session" channels to be opened and only "subsystem" requests to be made for any user in the "restricted" group. So X11 requests of any kind, port forwarding and shell/exec requests would be disabled. There are loads of chroot patches around which you could use, but mine jails to the user's home directory. The patch was meant as a proof of concept, which I'd tidy up if there was any interest. There wasn't any and it does everything I personally need, so has been stagnant for a while. Let me know if you want to take a look at it... I've even got a modified Ubuntu package. Jon From Jan.Pechanec at Sun.COM Thu Sep 13 05:38:12 2007 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Wed, 12 Sep 2007 21:38:12 +0200 (CEST) Subject: PATCH: fix incorrect checking of syslog facility in sftp-server Message-ID: hi, there is a typo like error in sftp-server.c - obviously "log_facility" should be used in the comparison for '-f' option, not "log_level". That way the error can't be ever printed because log_level is always not equal to -1 there. However, using incorrect facility will trigger "Unrecognized internal syslog level code ..." in log_init() later though so it will fail eventually as expected. the incorrect code: case 'f': log_facility = log_facility_number(optarg); if (log_level == SYSLOG_FACILITY_NOT_SET) error("Invalid log facility \"%s\"", optarg); break; --- sftp-server.c Sun May 20 07:09:05 2007 +++ sftp-server.c.new Wed Sep 12 16:25:32 2007 @@ -1244,7 +1244,7 @@ break; case 'f': log_facility = log_facility_number(optarg); - if (log_level == SYSLOG_FACILITY_NOT_SET) + if (log_facility == SYSLOG_FACILITY_NOT_SET) error("Invalid log facility \"%s\"", optarg); break; case 'h': -- Jan Pechanec From alan-jenkins at tuffmail.co.uk Thu Sep 13 03:43:41 2007 From: alan-jenkins at tuffmail.co.uk (Alan Jenkins) Date: Wed, 12 Sep 2007 18:43:41 +0100 Subject: openssh-agent polling Message-ID: <46E8254D.90403@tuffmail.co.uk> This may be a stupid question - but why does ssh-agent fork off a child and then exec the subcommand in the *parent* process? It forces the agent in the child process to poll the parent, so it can exit when the parent finishes. If the agent was the parent process, it could use wait() instead. I'm sure there's some reason. It'd be nice to take ssh-agent off the list of polling processes you get with powertop[1], however far down it is. Please CC me in replies Yours, Alan [1] http://www.linux-powertop.org From djm at mindrot.org Thu Sep 13 14:42:54 2007 From: djm at mindrot.org (Damien Miller) Date: Thu, 13 Sep 2007 14:42:54 +1000 (EST) Subject: openssh-agent polling In-Reply-To: <46E8254D.90403@tuffmail.co.uk> References: <46E8254D.90403@tuffmail.co.uk> Message-ID: On Wed, 12 Sep 2007, Alan Jenkins wrote: > This may be a stupid question - but why does ssh-agent fork off a > child and then exec the subcommand in the *parent* process? It forces > the agent in the child process to poll the parent, so it can exit when > the parent finishes. If the agent was the parent process, it could > use wait() instead. I'm sure there's some reason. > > It'd be nice to take ssh-agent off the list of polling processes you > get with powertop[1], however far down it is. I don't understand what you mean by polling - once started, ssh-agent spends all its time sitting in select() waiting for requests. -d From David.Leonard at quest.com Thu Sep 13 16:00:22 2007 From: David.Leonard at quest.com (David Leonard) Date: Thu, 13 Sep 2007 16:00:22 +1000 Subject: openssh-agent polling In-Reply-To: References: <46E8254D.90403@tuffmail.co.uk> Message-ID: <46E8D1F6.9070804@quest.com> Damien Miller wrote: > On Wed, 12 Sep 2007, Alan Jenkins wrote: > > >> This may be a stupid question - but why does ssh-agent fork off a >> child and then exec the subcommand in the *parent* process? It forces >> the agent in the child process to poll the parent, so it can exit when >> the parent finishes. If the agent was the parent process, it could >> use wait() instead. I'm sure there's some reason. >> >> It'd be nice to take ssh-agent off the list of polling processes you >> get with powertop[1], however far down it is. >> > > I don't understand what you mean by polling - once started, ssh-agent > spends all its time sitting in select() waiting for requests. > There is a 10 second parent polling behaviour which is probably what powertop is seeing.. select is using a timeout being the minimum of the poll time (10sec) or the next time a key expires. ssh-agent starts its command in the parent process probably so that you can get something useful from $! returned in your startup script, and to avoid the situation where ssh-agent could get an untrappable signal and leaves the underlying command running. The man page is slightly misleading when it says: "If a commandline is given, this is executed as a subprocess of the agent." I can't see a clean, portable way of getting rid of the poll. On linux, maybe you use inotify or /proc or something?? d -- David Leonard Resource Central software engineer Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 From alan-jenkins at tuffmail.co.uk Thu Sep 13 18:45:51 2007 From: alan-jenkins at tuffmail.co.uk (Alan Jenkins) Date: Thu, 13 Sep 2007 09:45:51 +0100 Subject: openssh-agent polling In-Reply-To: <46E8D1F6.9070804@quest.com> References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> Message-ID: <46E8F8BF.6010909@tuffmail.co.uk> David Leonard wrote: > Damien Miller wrote: >> On Wed, 12 Sep 2007, Alan Jenkins wrote: >>> This may be a stupid question - but why does ssh-agent fork off >>> a child and then exec the subcommand in the *parent* process? >>> It forces the agent in the child process to poll the parent, so >>> it can exit when the parent finishes. If the agent was the >>> parent process, it could use wait() instead. I'm sure there's >>> some reason. >>> >>> It'd be nice to take ssh-agent off the list of polling >>> processes you get with powertop[1], however far down it is. >>> > ssh-agent starts its command in the parent process probably so that > you can get something useful from $! returned in your startup > script, Surely that's fixable - wait() gives you the terminated child's exit code. > and to avoid the situation where ssh-agent could get an untrappable > signal and leaves the underlying command running. Which way round do you mean this? Are we trying to avoid leaving the underlying command running if ssh-agent is killed, or do we want it to carry on running independently? It sounds like you meant the subcommand should be killed if ssh-agent is, but my understanding of the current behaviour is that the subcommand keeps on running. If the aim is to keep the subcommand running, I guess we're stuck with polling. If I've got my un*x right, it's not possible to wait() on a process unless it would get killed if you terminate. > I can't see a clean, portable way of getting rid of the poll. On > linux, maybe you use inotify or /proc or something?? Apparently inotify doesn't tell you when /proc directories go away :-(. There is a netlink message that gets sent for accounting purposes, but you have to configure it in, so I don't know how widely available it would be, and IIRC it's not very well-suited because you get messages for all processes, not just one. Alan From stuge-openssh-unix-dev at cdy.org Thu Sep 13 22:33:18 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 13 Sep 2007 14:33:18 +0200 Subject: openssh-agent polling In-Reply-To: <46E8D1F6.9070804@quest.com> References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> Message-ID: <20070913123318.5044.qmail@cdy.org> On Thu, Sep 13, 2007 at 04:00:22PM +1000, David Leonard wrote: > There is a 10 second parent polling behaviour which is probably > what powertop is seeing.. select is using a timeout being the > minimum of the poll time (10sec) or the next time a key expires. What if you remove the timeout? //Peter From dtucker at zip.com.au Thu Sep 13 22:50:57 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 13 Sep 2007 22:50:57 +1000 Subject: openssh-agent polling In-Reply-To: <20070913123318.5044.qmail@cdy.org> References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <20070913123318.5044.qmail@cdy.org> Message-ID: <46E93231.3090506@zip.com.au> Peter Stuge wrote: > On Thu, Sep 13, 2007 at 04:00:22PM +1000, David Leonard wrote: >> There is a 10 second parent polling behaviour which is probably >> what powertop is seeing.. select is using a timeout being the >> minimum of the poll time (10sec) or the next time a key expires. > > What if you remove the timeout? The agent will hang around forever after the process it's serving has gone away, unless a key happens to expire. also, with regard to having the agent running as the parent, Alan Jenkins wrote: > > Damien Miller wrote: [...] > > ssh-agent starts its command in the parent process probably so that > > you can get something useful from $! returned in your startup > > script, > > Surely that's fixable - wait() gives you the terminated child's exit > code. ssh-agent would probably end up as the process group leader too. I'm not sure what impact that would have on, eg job control. -- 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 Jan.Pechanec at Sun.COM Fri Sep 14 01:07:55 2007 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Thu, 13 Sep 2007 17:07:55 +0200 (CEST) Subject: PATCH: missing free() in vasprintf() in openbsd-compat Message-ID: hi, it can hardly be considered a memleak since I can see that the ret value is always checked in parent code (xasprintf() for example) and fatal() called if it's equal to -1 but the free() call is definitely missing there. --- bsd-asprintf.c Tue Dec 5 12:58:12 2006 +++ bsd-asprintf.c.new Thu Sep 13 16:51:40 2007 @@ -55,6 +55,7 @@ if (ret >= 0 && ret < INIT_SZ) { /* succeeded with initial alloc */ *str = string; } else if (ret == INT_MAX || ret < 0) { /* Bad length */ + free(string); goto fail; } else { /* bigger than initial, realloc allowing for nul */ len = (size_t)ret + 1; -- Jan Pechanec From rac at tenzing.org Fri Sep 14 05:18:24 2007 From: rac at tenzing.org (Roger Cornelius) Date: Thu, 13 Sep 2007 15:18:24 -0400 Subject: 4.7p1 password auth broken on SCO OSR6 In-Reply-To: References: <20070910185518.GA12718@tenzing.org> Message-ID: <20070913191824.GA13875@tenzing.org> On 09/10/2007 16:14, Tim Rice wrote: > On Mon, 10 Sep 2007, Roger Cornelius wrote: > > > openssh 4.7p1 > > SCO OSR6 > > > > Password authentication is non-functional. This seems dependent on > > USE_LIBIAF which further depends on HAVE_LIBIAF (in defines.h), but > > there is no longer any code in configure to define the latter. Building > > This patch will solve the missing HAVE_LIBIAF > ------------ > --- configure.ac.old 2007-08-15 09:16:29.007892000 -0700 > +++ configure.ac 2007-09-10 15:54:26.072835157 -0700 > @@ -2004,7 +2004,10 @@ > saved_LIBS="$LIBS" > AC_CHECK_LIB(iaf, ia_openinfo, [ > LIBS="$LIBS -liaf" > - AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf"]) > + AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf" > + AC_DEFINE(HAVE_LIBIAF, 1, > + [Define if system has libiaf that supports set_id]) > + ]) > ]) > LIBS="$saved_LIBS" > > ------------ > > > with HAVE_LIBIAF defined enables password authentication, but only for > > non-long (<9 char) passwords, even though UNIXWARE_LONG_PASSWORDS seems > > to be defined. I haven't had time yet to investigate further. > > Authentication in the SVR5 space on OpenServer 6 is still lacking. > (getluid/setluid) > > Probably best to build in the osr5 space for now. Your patch fixed password auth for short passwords as expected. Needed for long passwords is -DHAVE_SECUREWARE, and -lprot (must be searched before -lcrypt). I also found the following patch to openbsd-compat/xcrypt.c was needed though I don't know why. xcrypt.c did not change from 4.6p1 to 4.7p1. I no longer use password authentication so maybe I forgot to test it on 4.6p1. This is for udk mode. I have not tried building in osr mode. Roger ------------ --- xcrypt.c.orig 2007-09-13 14:58:13.726207003 -0400 +++ xcrypt.c 2007-09-13 14:56:01.376847016 -0400 @@ -30,0 +31,5 @@ +# ifdef HAVE_SECUREWARE +# include +# include +# include +# else @@ -33,0 +39 @@ +# endif @@ -40,6 +45,0 @@ -# ifdef HAVE_SECUREWARE -# include -# include -# include -# endif - @@ -110 +110 @@ - struct pr_passwd *spw = getprpwnam(pw->pw_name); + struct pr_passwd *swspw = getprpwnam(pw->pw_name); @@ -112,2 +112,2 @@ - if (spw != NULL) - pw_password = spw->ufld.fd_encrypt; + if (swspw != NULL) + pw_password = swspw->ufld.fd_encrypt; ------------ -- Roger Cornelius rac at tenzing.org From srinath_balaraman at mentor.com Fri Sep 14 14:22:50 2007 From: srinath_balaraman at mentor.com (Balaraman, Srinath) Date: Thu, 13 Sep 2007 23:22:50 -0500 Subject: DH Key negotiation in OpenSSH. In-Reply-To: <20070913191824.GA13875@tenzing.org> References: <20070910185518.GA12718@tenzing.org> <20070913191824.GA13875@tenzing.org> Message-ID: Hello All, I am trying to run an SSH client from an embedded Coldfire platform connecting to a Linux machine running OpenSSH v 3.9 p1. The DH Key negotiation on this Coldfire platform takes about 10 minutes before which the ssh daemon on the Linux box kicks this client out. I am trying to find out if there is a way to configure the ssh server daemon to "not kick out" any client no matter how long they take to respond? Thanks, Srinath From djm at mindrot.org Fri Sep 14 19:48:55 2007 From: djm at mindrot.org (Damien Miller) Date: Fri, 14 Sep 2007 19:48:55 +1000 (EST) Subject: DH Key negotiation in OpenSSH. In-Reply-To: References: <20070910185518.GA12718@tenzing.org> <20070913191824.GA13875@tenzing.org> Message-ID: On Thu, 13 Sep 2007, Balaraman, Srinath wrote: > Hello All, > > I am trying to run an SSH client from an embedded Coldfire platform > connecting to a Linux machine running OpenSSH v 3.9 p1. The DH Key > negotiation on this Coldfire platform takes about 10 minutes before > which the ssh daemon on the Linux box kicks this client out. > > I am trying to find out if there is a way to configure the ssh server > daemon to "not kick out" any client no matter how long they take to > respond? You can adjust LoginGraceTime on the server, but if you have a NAT between you and the server you might run afoul of expiring NAT states. {Client,Server}AliveInterval won't help here, as IIRC they kick in after key exchange. There is a patch to add a faster, less secure key exchange method at https://bugzilla.mindrot.org/b/1314 but we are loath to add more KEX methods - these are direct increases in pre-auth attack surface. -d From stuge-openssh-unix-dev at cdy.org Fri Sep 14 21:57:24 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 14 Sep 2007 13:57:24 +0200 Subject: openssh-agent polling In-Reply-To: <46E93231.3090506@zip.com.au> References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <20070913123318.5044.qmail@cdy.org> <46E93231.3090506@zip.com.au> Message-ID: <20070914115724.28193.qmail@cdy.org> On Thu, Sep 13, 2007 at 10:50:57PM +1000, Darren Tucker wrote: > Peter Stuge wrote: > > On Thu, Sep 13, 2007 at 04:00:22PM +1000, David Leonard wrote: > >> There is a 10 second parent polling behaviour which is probably > >> what powertop is seeing.. select is using a timeout being the > >> minimum of the poll time (10sec) or the next time a key expires. > > > > What if you remove the timeout? > > The agent will hang around forever after the process it's serving > has gone away, unless a key happens to expire. I see. The only solution to this that I can come up with is another process who waitpid()s on the parent, and a pipe() or signal back to the main ssh-agent so that it can select() without a timeout. A small improvement over the current state would be that ssh-agent then exits as soon as the parent exits, rather than after an arbitrary timeout - at the cost of a new process. //Peter From rac at tenzing.org Sat Sep 15 01:53:37 2007 From: rac at tenzing.org (Roger Cornelius) Date: Fri, 14 Sep 2007 11:53:37 -0400 Subject: 4.7p1 password auth broken on SCO OSR6 In-Reply-To: <20070913191824.GA13875@tenzing.org> References: <20070910185518.GA12718@tenzing.org> <20070913191824.GA13875@tenzing.org> Message-ID: <20070914155336.GA16347@tenzing.org> On 09/13/2007 15:18, Roger Cornelius wrote: > On 09/10/2007 16:14, Tim Rice wrote: > > On Mon, 10 Sep 2007, Roger Cornelius wrote: > > > > > openssh 4.7p1 > > > SCO OSR6 > > > > > > Password authentication is non-functional. This seems dependent on > > > USE_LIBIAF which further depends on HAVE_LIBIAF (in defines.h), but > > > there is no longer any code in configure to define the latter. Building > > > > This patch will solve the missing HAVE_LIBIAF > > ------------ > > --- configure.ac.old 2007-08-15 09:16:29.007892000 -0700 > > +++ configure.ac 2007-09-10 15:54:26.072835157 -0700 > > @@ -2004,7 +2004,10 @@ > > saved_LIBS="$LIBS" > > AC_CHECK_LIB(iaf, ia_openinfo, [ > > LIBS="$LIBS -liaf" > > - AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf"]) > > + AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf" > > + AC_DEFINE(HAVE_LIBIAF, 1, > > + [Define if system has libiaf that supports set_id]) > > + ]) > > ]) > > LIBS="$saved_LIBS" > > > > ------------ > > > > > with HAVE_LIBIAF defined enables password authentication, but only for > > > non-long (<9 char) passwords, even though UNIXWARE_LONG_PASSWORDS seems > > > to be defined. I haven't had time yet to investigate further. > > > > Authentication in the SVR5 space on OpenServer 6 is still lacking. > > (getluid/setluid) > > > > Probably best to build in the osr5 space for now. > > Your patch fixed password auth for short passwords as expected. > > Needed for long passwords is -DHAVE_SECUREWARE, and -lprot (must be > searched before -lcrypt). I also found the following patch to > openbsd-compat/xcrypt.c was needed though I don't know why. xcrypt.c > did not change from 4.6p1 to 4.7p1. I no longer use password > authentication so maybe I forgot to test it on 4.6p1. > > This is for udk mode. I have not tried building in osr mode. [ prev patch deleted ] Here's the minimal patch required to get 4.7p1 running with functional password authentication and long passwords on OSR6 w/MP2 installed (the patch incorporates the missing HAVE_LIBIAF patch Tim provided above): ------------- diff -ru orig/openssh-4.7p1/configure.ac openssh-4.7p1/configure.ac --- orig/openssh-4.7p1/configure.ac 2007-08-10 00:36:12.000000000 -0400 +++ openssh-4.7p1/configure.ac 2007-09-14 10:10:15.768048004 -0400 @@ -672,6 +672,9 @@ case "$host" in *-*-sysv5SCO_SV*) # SCO OpenServer 6.x TEST_SHELL=/u95/bin/sh + LIBS="$LIBS -lprot" + AC_DEFINE(DISABLE_SHADOW) + AC_DEFINE(HAVE_SECUREWARE) AC_DEFINE(BROKEN_LIBIAF, 1, [ia_uinfo routines not supported by OS yet]) AC_DEFINE(BROKEN_UPDWTMPX) @@ -2004,7 +2007,10 @@ saved_LIBS="$LIBS" AC_CHECK_LIB(iaf, ia_openinfo, [ LIBS="$LIBS -liaf" - AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf"]) + AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf" + AC_DEFINE(HAVE_LIBIAF, 1, + [Define if system has libiaf that supports set_id]) + ]) ]) LIBS="$saved_LIBS" diff -ru orig/openssh-4.7p1/openbsd-compat/xcrypt.c openssh-4.7p1/openbsd-compat/xcrypt.c --- orig/openssh-4.7p1/openbsd-compat/xcrypt.c 2007-03-26 12:35:28.000000000 -0400 +++ openssh-4.7p1/openbsd-compat/xcrypt.c 2007-09-14 10:05:57.565168003 -0400 @@ -28,21 +28,21 @@ #include #include +# ifdef HAVE_SECUREWARE +# include +# include +# include +# else # ifdef HAVE_CRYPT_H # include # endif +# endif # ifdef __hpux # include # include # endif -# ifdef HAVE_SECUREWARE -# include -# include -# include -# endif - # if defined(HAVE_SHADOW_H) && !defined(DISABLE_SHADOW) # include # endif ------------- -- Roger Cornelius rac at tenzing.org From jan.iven at cern.ch Sat Sep 15 02:53:38 2007 From: jan.iven at cern.ch (Jan Iven) Date: Fri, 14 Sep 2007 18:53:38 +0200 Subject: GSSAPI vs load-balanced servers - anything we can do? Message-ID: <46EABC92.4060408@cern.ch> Dear all, (apologoies - this has nothing to do with 4.7 being out, but is rather a long-standing issue that regularly bites us). Is there anything I could do to further the case of https://bugzilla.mindrot.org/show_bug.cgi?id=1008 As a summary, GSSAPI auth against machine in a DNS load-balanced server farm fails. SSH-1 Kerberos works. DNS load-balanced farm: Individual machines in the farm have separate IP addresses (ipA, ipB), separate hostnames (nameA, nameB, ..) and separate Kerberos identities (host/nameA.domain at REALM) . A common DNS name (clustername) resolves to one or several IPs. Reverse lookup on the IP gives the individual machine name. (seems to be a common & cheap way to spread load). The problem is that GSSAPI insists on doing its own DNS lookup (forward+reverse) to determine the (Kerberos) identity of the server, and has a fair chance of getting a different reply. So a typical session looks like client: gethostbyname( clustername) -> ipA connect (ipA) (KEX and other wonderful SSH stuff) do GSSAPI auth gethostbyname(clustername) -> ipB gethostbyaddr( ipB) -> nameB get service ticket for host/nameB.domain at REALM send ticket to connected machine (nameA) server: huh? Enotmynameinticketgoaway. The GSSAPI behaviour is apparently mandated by RFC1964 (2.1.3): > When a reference to a name of this type is resolved, the "hostname" > is canonicalized by attempting a DNS lookup and using the fully- > qualified domain name which is returned, or by using the "hostname" > as provided if the DNS lookup fails. The canonicalization operation > also maps the host's name into lower-case characters. so is unlikely to change. The only workaround seems to be feeding the canonical hostname (or IP) of the currently-connected server machine into GSSAPI, instead of the hostname the user provided (this is what SSH-1 Kerberos did, by the way). While in principle we could change the reverse DNS of the cluster machines to point to the cluster name, this would introduce confusion for everything that known already which exact host to connect to. This is a client-side issue, so no amount of patching on the server will make this issue go away. In addition, we need to convince vendors to provide patches to their deployed "legacy" versions, which is made difficult by the fact that this is not fixed "upstream". We seem to have convinced Red Hat that this is an issue. Two-line patch is at https://bugzilla.mindrot.org/attachment.cgi?id=1202. https://bugzilla.mindrot.org/show_bug.cgi?id=1008 also has a more elaborate version by Simon that introduces a new config option. I'd be happy to forward-port either to 4.7, if there is a chance that this will get applied one day. Sorry for the lengthy post, thanks for your time. Jan From djm at mindrot.org Sat Sep 15 08:37:02 2007 From: djm at mindrot.org (Damien Miller) Date: Sat, 15 Sep 2007 08:37:02 +1000 (EST) Subject: openssh-agent polling In-Reply-To: <20070914115724.28193.qmail@cdy.org> References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <20070913123318.5044.qmail@cdy.org> <46E93231.3090506@zip.com.au> <20070914115724.28193.qmail@cdy.org> Message-ID: On Fri, 14 Sep 2007, Peter Stuge wrote: > On Thu, Sep 13, 2007 at 10:50:57PM +1000, Darren Tucker wrote: > > Peter Stuge wrote: > > > On Thu, Sep 13, 2007 at 04:00:22PM +1000, David Leonard wrote: > > >> There is a 10 second parent polling behaviour which is probably > > >> what powertop is seeing.. select is using a timeout being the > > >> minimum of the poll time (10sec) or the next time a key expires. > > > > > > What if you remove the timeout? > > > > The agent will hang around forever after the process it's serving > > has gone away, unless a key happens to expire. > > I see. The only solution to this that I can come up with is another > process who waitpid()s on the parent, and a pipe() or signal back to > the main ssh-agent so that it can select() without a timeout. > > A small improvement over the current state would be that ssh-agent > then exits as soon as the parent exits, rather than after an > arbitrary timeout - at the cost of a new process. You can avoid the polling now by not executing a subcommand when starting ssh-agent. I.e. run: eval `ssh-agent` instead of: ssh-agent whatever This will leave an ssh-agent around unless you have a symmetric "ssh-agent -k" in your logout scripts. -d From srinath_balaraman at mentor.com Sat Sep 15 15:03:51 2007 From: srinath_balaraman at mentor.com (Balaraman, Srinath) Date: Sat, 15 Sep 2007 00:03:51 -0500 Subject: DH Key negotiation in OpenSSH. In-Reply-To: References: <20070910185518.GA12718@tenzing.org> <20070913191824.GA13875@tenzing.org> Message-ID: Thanks a lot Damien. Adjusting the LoginGraceTime solved my problem. Srinath -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Friday, September 14, 2007 4:49 AM To: Balaraman, Srinath Cc: openssh-unix-dev at mindrot.org Subject: Re: DH Key negotiation in OpenSSH. On Thu, 13 Sep 2007, Balaraman, Srinath wrote: > Hello All, > > I am trying to run an SSH client from an embedded Coldfire platform > connecting to a Linux machine running OpenSSH v 3.9 p1. The DH Key > negotiation on this Coldfire platform takes about 10 minutes before > which the ssh daemon on the Linux box kicks this client out. > > I am trying to find out if there is a way to configure the ssh server > daemon to "not kick out" any client no matter how long they take to > respond? You can adjust LoginGraceTime on the server, but if you have a NAT between you and the server you might run afoul of expiring NAT states. {Client,Server}AliveInterval won't help here, as IIRC they kick in after key exchange. There is a patch to add a faster, less secure key exchange method at https://bugzilla.mindrot.org/b/1314 but we are loath to add more KEX methods - these are direct increases in pre-auth attack surface. -d From ben at psc.edu Sun Sep 16 08:33:26 2007 From: ben at psc.edu (Benjamin Bennett) Date: Sat, 15 Sep 2007 18:33:26 -0400 Subject: PATCH: atomicio doesn't poll() Message-ID: <46EC5DB6.8040006@psc.edu> atomicio contains the following in the read/write loop: ----- case -1: #ifdef EWOULDBLOCK if (errno == EINTR || errno == EWOULDBLOCK) #else if (errno == EINTR) #endif continue; if (errno == EAGAIN) { (void)poll(&pfd, 1, -1); continue; } return 0; ----- On systems where errno is set to EWOULDBLOCK we spin on the read or write without polling. On many other systems (Linux, Solaris, IRIX, ...) EWOULDBLOCK is defined as EAGAIN, and when errno is set to EAGAIN we spin on the read or write without polling. Please see patch. thanks, --ben -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-atomicio-polling.patch Type: text/x-patch Size: 1005 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070915/65cc1662/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070915/65cc1662/attachment-0001.bin From tim at multitalents.net Sun Sep 16 12:24:38 2007 From: tim at multitalents.net (Tim Rice) Date: Sat, 15 Sep 2007 19:24:38 -0700 (PDT) Subject: 4.7p1 password auth broken on SCO OSR6 In-Reply-To: <20070914155336.GA16347@tenzing.org> References: <20070910185518.GA12718@tenzing.org> <20070913191824.GA13875@tenzing.org> <20070914155336.GA16347@tenzing.org> Message-ID: On Fri, 14 Sep 2007, Roger Cornelius wrote: RC On 09/13/2007 15:18, Roger Cornelius wrote: RC > On 09/10/2007 16:14, Tim Rice wrote: RC > > On Mon, 10 Sep 2007, Roger Cornelius wrote: RC > > RC > > > openssh 4.7p1 RC > > > SCO OSR6 RC > > > RC > > > Password authentication is non-functional. This seems dependent on RC > > > USE_LIBIAF which further depends on HAVE_LIBIAF (in defines.h), but RC > > > there is no longer any code in configure to define the latter. Building RC > > RC > > This patch will solve the missing HAVE_LIBIAF RC > > ------------ RC > > --- configure.ac.old 2007-08-15 09:16:29.007892000 -0700 RC > > +++ configure.ac 2007-09-10 15:54:26.072835157 -0700 RC > > @@ -2004,7 +2004,10 @@ RC > > saved_LIBS="$LIBS" RC > > AC_CHECK_LIB(iaf, ia_openinfo, [ RC > > LIBS="$LIBS -liaf" RC > > - AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf"]) RC > > + AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf" RC > > + AC_DEFINE(HAVE_LIBIAF, 1, RC > > + [Define if system has libiaf that supports set_id]) RC > > + ]) RC > > ]) RC > > LIBS="$saved_LIBS" RC > > RC > > ------------ RC > > RC > > > with HAVE_LIBIAF defined enables password authentication, but only for RC > > > non-long (<9 char) passwords, even though UNIXWARE_LONG_PASSWORDS seems RC > > > to be defined. I haven't had time yet to investigate further. I tracked down the problem. CUSTOM_SYS_AUTH_PASSWD was not defined so the UNIXWARE_LONG_PASSWORDS bit were never used. Please backout your changes to configure.ac (leave my patch in) and openbsd-compat/xcrypt.c and try this patch. Thanks. ---------------------------- --- defines.h.old 2007-08-15 09:16:29.167892001 -0700 +++ defines.h 2007-09-15 19:17:15.331975020 -0700 @@ -694,9 +694,11 @@ # define CUSTOM_SYS_AUTH_PASSWD 1 #endif +#if defined(HAVE_LIBIAF) && defined(HAVE_SET_ID) +# define CUSTOM_SYS_AUTH_PASSWD 1 +#endif #if defined(HAVE_LIBIAF) && defined(HAVE_SET_ID) && !defined(BROKEN_LIBIAF) # define USE_LIBIAF -# define CUSTOM_SYS_AUTH_PASSWD 1 #endif /* HP-UX 11.11 */ ---------------------------- -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bob at proulx.com Mon Sep 17 08:08:11 2007 From: bob at proulx.com (Bob Proulx) Date: Sun, 16 Sep 2007 16:08:11 -0600 Subject: openssh-agent polling In-Reply-To: References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <20070913123318.5044.qmail@cdy.org> <46E93231.3090506@zip.com.au> <20070914115724.28193.qmail@cdy.org> Message-ID: <20070916220811.GA30238@dementia.proulx.com> Damien Miller wrote: > You can avoid the polling now by not executing a subcommand when starting > ssh-agent. I.e. run: > eval `ssh-agent` > ... > This will leave an ssh-agent around unless you have a symmetric > "ssh-agent -k" in your logout scripts. I have often seen users who mess this up and will leave literally hundreds of ssh-agents running on machines. One large advantage of 'ssh-agent command' is that the ssh-agent will exit when the command exits. But users who do "eval `ssh-agent`" rarely clean up after themselves. Bob From Jefferson.Ogata at noaa.gov Mon Sep 17 08:52:13 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 16 Sep 2007 22:52:13 +0000 Subject: openssh-agent polling In-Reply-To: <20070916220811.GA30238@dementia.proulx.com> References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <20070913123318.5044.qmail@cdy.org> <46E93231.3090506@zip.com.au> <20070914115724.28193.qmail@cdy.org> <20070916220811.GA30238@dementia.proulx.com> Message-ID: <46EDB39D.2050705@noaa.gov> On 09/16/07 22:08, Bob Proulx wrote: > Damien Miller wrote: >> You can avoid the polling now by not executing a subcommand when starting >> ssh-agent. I.e. run: >> eval `ssh-agent` >> ... >> This will leave an ssh-agent around unless you have a symmetric >> "ssh-agent -k" in your logout scripts. > > I have often seen users who mess this up and will leave literally > hundreds of ssh-agents running on machines. One large advantage of > 'ssh-agent command' is that the ssh-agent will exit when the command > exits. But users who do "eval `ssh-agent`" rarely clean up after > themselves. All that is needed is for the users' shells to discover their running agents when they log in, so they never need to run more than one agent. You can add a few lines to the common profile (YMMV): if [ -n "$SSH_AUTH_SOCK" ] then if [ -S "$SSH_AUTH_SOCK" -a -O "$SSH_AUTH_SOCK" ] then SSH_AUTH_SOCK="$SSH_AUTH_SOCK" ssh-add -l >/dev/null 2>&1 if [ $? -ne 2 ]; then export SSH_AUTH_SOCK else unset SSH_AUTH_SOCK fi else unset SSH_AUTH_SOCK fi fi if [ -z "$SSH_AUTH_SOCK" ] then for x in /tmp/ssh*/agent* do if [ -S "$x" -a -O "$x" ] then SSH_AUTH_SOCK="$x" ssh-add -l >/dev/null 2>&1 if [ $? -ne 2 ]; then SSH_AUTH_SOCK="$x" export SSH_AUTH_SOCK break fi fi done fi After that, they only need to run ssh-agent once and new shells will find the running instance regardless of ancestry. (If they do run ssh-agent with a command, however, the discovered ssh-agent may disappear.) You can also append: if [ -z "$SSH_AUTH_SOCK" ] then eval `ssh-agent` fi So they never even have to run ssh-agent the first time. (This is of course assuming you don't see the use of ssh-agent as fundamentally dangerous, as some of us do.) -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From opensshbugs at fjarlq.com Mon Sep 17 07:56:53 2007 From: opensshbugs at fjarlq.com (Matt Day) Date: Sun, 16 Sep 2007 15:56:53 -0600 Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: <20070315084012.GA58996@fjarlq.com> References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> <20070315011208.GA48513@fjarlq.com> <20070315024347.GA10841@gate.dtucker.net> <20070315025904.GA50787@fjarlq.com> <20070315032213.GA12369@gate.dtucker.net> <20070315055242.GA15006@gate.dtucker.net> <20070315084012.GA58996@fjarlq.com> Message-ID: <20070916215653.GA92678@fjarlq.com> Hi, The fix for this bug which I reported and helped fix back in March: http://marc.info/?t=117394251600035 wash't included in the OpenSSH 4.7 release. Was there a problem with the fix? It has been running on my system for months, and has successfully avoided the problem 15 times. I can't seem to find the OpenSSH bug database. Is this bug being tracked? As far as I can tell I followed the bug reporting procedure properly. Thanks, Matt Day On Thu, Mar 15, 2007 at 02:40:12AM -0600, Matt Day wrote: > Awesome, thanks! > > I applied the patch and ran into one problem during testing: outbound > ssh connections immediately received the new "timed out" error. > > The problem was in packet_set_timeout: packet_wait_tvp was only > getting set to NULL when *both* timeout and count were 0. The default > is interval=0 count=3, so it used the timeval with tv_sec = 0. > > I fixed that (use || instead of && in packet_set_timeout) and also > made the two new "timed out" error messages unique. That might be > handy someday if one is wondering if it timed out waiting to read > or to write (which I found myself wondering while debugging this). > > I have installed these changes on my server and will let you know > when I get confirmation in my logfile that the fix is working. > > Thank you very much! > Matt > > =================================================================== > diff -u -p packet.c.orig packet.c > [..] From djm at mindrot.org Mon Sep 17 10:47:22 2007 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Sep 2007 10:47:22 +1000 (EST) Subject: openssh-agent polling In-Reply-To: <46EDB39D.2050705@noaa.gov> References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <20070913123318.5044.qmail@cdy.org> <46E93231.3090506@zip.com.au> <20070914115724.28193.qmail@cdy.org> <20070916220811.GA30238@dementia.proulx.com> <46EDB39D.2050705@noaa.gov> Message-ID: On Sun, 16 Sep 2007, Jefferson Ogata wrote: > if [ -z "$SSH_AUTH_SOCK" ] > then > for x in /tmp/ssh*/agent* > do > if [ -S "$x" -a -O "$x" ] > then > SSH_AUTH_SOCK="$x" ssh-add -l >/dev/null 2>&1 > if [ $? -ne 2 ]; then > SSH_AUTH_SOCK="$x" > export SSH_AUTH_SOCK > break > fi > fi > done > fi This might connect you to a hostile ssh-agent that harvests your keys. Better to set the agent socket location using ssh-agent's -a option to either a canonical location, or a randomised location in a user-owned directory. -d From Jefferson.Ogata at noaa.gov Mon Sep 17 10:48:49 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 17 Sep 2007 00:48:49 +0000 Subject: openssh-agent polling In-Reply-To: References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <20070913123318.5044.qmail@cdy.org> <46E93231.3090506@zip.com.au> <20070914115724.28193.qmail@cdy.org> <20070916220811.GA30238@dementia.proulx.com> <46EDB39D.2050705@noaa.gov> Message-ID: <46EDCEF1.9090004@noaa.gov> On 09/17/07 00:47, Damien Miller wrote: > On Sun, 16 Sep 2007, Jefferson Ogata wrote: > >> if [ -z "$SSH_AUTH_SOCK" ] >> then >> for x in /tmp/ssh*/agent* >> do >> if [ -S "$x" -a -O "$x" ] >> then >> SSH_AUTH_SOCK="$x" ssh-add -l >/dev/null 2>&1 >> if [ $? -ne 2 ]; then >> SSH_AUTH_SOCK="$x" >> export SSH_AUTH_SOCK >> break >> fi >> fi >> done >> fi > > This might connect you to a hostile ssh-agent that harvests your keys. That's precisely what the -O "$x" is there to prevent. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From djm at mindrot.org Mon Sep 17 11:05:35 2007 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Sep 2007 11:05:35 +1000 (EST) Subject: openssh-agent polling In-Reply-To: <46EDCEF1.9090004@noaa.gov> References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <20070913123318.5044.qmail@cdy.org> <46E93231.3090506@zip.com.au> <20070914115724.28193.qmail@cdy.org> <20070916220811.GA30238@dementia.proulx.com> <46EDB39D.2050705@noaa.gov> <46EDCEF1.9090004@noaa.gov> Message-ID: On Mon, 17 Sep 2007, Jefferson Ogata wrote: > > This might connect you to a hostile ssh-agent that harvests your keys. > > That's precisely what the -O "$x" is there to prevent. Sorry - I missed that. There is still a small, unlikely race if an agent is exiting at the moment you shell initialisation is running :) From djm at mindrot.org Mon Sep 17 11:09:11 2007 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Sep 2007 11:09:11 +1000 (EST) Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: <20070916215653.GA92678@fjarlq.com> References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> <20070315011208.GA48513@fjarlq.com> <20070315024347.GA10841@gate.dtucker.net> <20070315025904.GA50787@fjarlq.com> <20070315032213.GA12369@gate.dtucker.net> <20070315055242.GA15006@gate.dtucker.net> <20070315084012.GA58996@fjarlq.com> <20070916215653.GA92678@fjarlq.com> Message-ID: On Sun, 16 Sep 2007, Matt Day wrote: > Hi, > > The fix for this bug which I reported and helped fix back in March: > http://marc.info/?t=117394251600035 > wash't included in the OpenSSH 4.7 release. > > Was there a problem with the fix? It has been running on my system > for months, and has successfully avoided the problem 15 times. Moral of the story: patches not in Bugzilla get missed. Darren or Matt: could you please file a bug for this at http://bugzilla.mindrot.org/ and attach the latest version of the patch? I don't see any reason why this shouldn't make 4.8. On a related note, OpenSSH -current (*) extends ConnectTimeout to cover both the initial TCP connection and banner exchange, so another point at which connections can indefinitely stall is removed. -d (*) It's definitely in OpenBSD CVS, but I'm not sure if the change has been synced to the portable repository yet From Jefferson.Ogata at noaa.gov Mon Sep 17 11:13:05 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 17 Sep 2007 01:13:05 +0000 Subject: openssh-agent polling In-Reply-To: References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <20070913123318.5044.qmail@cdy.org> <46E93231.3090506@zip.com.au> <20070914115724.28193.qmail@cdy.org> <20070916220811.GA30238@dementia.proulx.com> <46EDB39D.2050705@noaa.gov> <46EDCEF1.9090004@noaa.gov> Message-ID: <46EDD4A1.7040305@noaa.gov> On 09/17/07 01:05, Damien Miller wrote: > On Mon, 17 Sep 2007, Jefferson Ogata wrote: > >>> This might connect you to a hostile ssh-agent that harvests your keys. >> That's precisely what the -O "$x" is there to prevent. > > Sorry - I missed that. There is still a small, unlikely race if an agent > is exiting at the moment you shell initialisation is running :) True, and in retrospect I think there's a race on someone doing somethink like the following: mkdir /tmp/ssh-00000 ln /tmp/ssh-XYXYXYX/agent.11111 /tmp/ssh-00000/ where /tmp/XYXYXY/agent.11111 is a legitimate agent running as the user. Then wait till the user has found it, and rm /tmp/ssh-00000 ln /tmp/ssh-ZZZZZZZ/agent.31337 /tmp/ssh-00000/ where /tmp/ssh-ZZZZZZZZ/agent.31337 is the harvester. There are ways of mitigating this--check ownership of /tmp/ssh-ZZZZZZZZ directory as well (should be root), but overall I agree with you that the explicit location in the user's home is superior. I actually have always wondered why the agent sockets have been put under /tmp and not ~ or ~/.ssh. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From opensshbugs at fjarlq.com Mon Sep 17 16:23:45 2007 From: opensshbugs at fjarlq.com (Matt Day) Date: Mon, 17 Sep 2007 00:23:45 -0600 Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> <20070315011208.GA48513@fjarlq.com> <20070315024347.GA10841@gate.dtucker.net> <20070315025904.GA50787@fjarlq.com> <20070315032213.GA12369@gate.dtucker.net> <20070315055242.GA15006@gate.dtucker.net> <20070315084012.GA58996@fjarlq.com> <20070916215653.GA92678@fjarlq.com> Message-ID: <20070917062345.GA3763@fjarlq.com> On Mon, Sep 17, 2007 at 11:09:11AM +1000, Damien Miller wrote: > Moral of the story: patches not in Bugzilla get missed. Darren or Matt: > could you please file a bug for this at http://bugzilla.mindrot.org/ and > attach the latest version of the patch? I don't see any reason why this > shouldn't make 4.8. Cool, thanks. Done: https://bugzilla.mindrot.org/show_bug.cgi?id=1363 I should have done that in the first place, your bugzilla is easy to find. Matt From djm at mindrot.org Mon Sep 17 18:29:49 2007 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Sep 2007 18:29:49 +1000 (EST) Subject: sshd gets stuck: select() in packet_read_seqnr waits indefinitely In-Reply-To: References: <20070314185309.GA40932@fjarlq.com> <20070315001416.GA28880@gate.dtucker.net> <20070315011208.GA48513@fjarlq.com> <20070315024347.GA10841@gate.dtucker.net> <20070315025904.GA50787@fjarlq.com> <20070315032213.GA12369@gate.dtucker.net> <20070315055242.GA15006@gate.dtucker.net> <20070315084012.GA58996@fjarlq.com> <20070916215653.GA92678@fjarlq.com> Message-ID: On Mon, 17 Sep 2007, Damien Miller wrote: > On a related note, OpenSSH -current (*) extends ConnectTimeout to cover > both the initial TCP connection and banner exchange, so another point at > which connections can indefinitely stall is removed. > > (*) It's definitely in OpenBSD CVS, but I'm not sure if the change has > been synced to the portable repository yet It is in portable now, and will be in snapshots 20070918 and later. -d From rac at tenzing.org Tue Sep 18 00:29:50 2007 From: rac at tenzing.org (Roger Cornelius) Date: Mon, 17 Sep 2007 10:29:50 -0400 Subject: 4.7p1 password auth broken on SCO OSR6 In-Reply-To: References: <20070910185518.GA12718@tenzing.org> <20070913191824.GA13875@tenzing.org> <20070914155336.GA16347@tenzing.org> Message-ID: <20070917142629.GA13474@tenzing.org> On 09/15/2007 19:24, Tim Rice wrote: > On Fri, 14 Sep 2007, Roger Cornelius wrote: > > RC On 09/13/2007 15:18, Roger Cornelius wrote: > RC > On 09/10/2007 16:14, Tim Rice wrote: > RC > > On Mon, 10 Sep 2007, Roger Cornelius wrote: > RC > > > RC > > > openssh 4.7p1 > RC > > > SCO OSR6 > RC > > > > RC > > > Password authentication is non-functional. This seems dependent on > RC > > > USE_LIBIAF which further depends on HAVE_LIBIAF (in defines.h), but > RC > > > there is no longer any code in configure to define the latter. Building > RC > > > RC > > This patch will solve the missing HAVE_LIBIAF > RC > > ------------ > RC > > --- configure.ac.old 2007-08-15 09:16:29.007892000 -0700 > RC > > +++ configure.ac 2007-09-10 15:54:26.072835157 -0700 > RC > > @@ -2004,7 +2004,10 @@ > RC > > saved_LIBS="$LIBS" > RC > > AC_CHECK_LIB(iaf, ia_openinfo, [ > RC > > LIBS="$LIBS -liaf" > RC > > - AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf"]) > RC > > + AC_CHECK_FUNCS(set_id, [SSHDLIBS="$SSHDLIBS -liaf" > RC > > + AC_DEFINE(HAVE_LIBIAF, 1, > RC > > + [Define if system has libiaf that supports set_id]) > RC > > + ]) > RC > > ]) > RC > > LIBS="$saved_LIBS" > RC > > > RC > > ------------ > RC > > > RC > > > with HAVE_LIBIAF defined enables password authentication, but only for > RC > > > non-long (<9 char) passwords, even though UNIXWARE_LONG_PASSWORDS seems > RC > > > to be defined. I haven't had time yet to investigate further. > > I tracked down the problem. CUSTOM_SYS_AUTH_PASSWD was not defined so > the UNIXWARE_LONG_PASSWORDS bit were never used. > > Please backout your changes to configure.ac (leave my patch in) and > openbsd-compat/xcrypt.c and try this patch. > > Thanks. > > ---------------------------- > --- defines.h.old 2007-08-15 09:16:29.167892001 -0700 > +++ defines.h 2007-09-15 19:17:15.331975020 -0700 > @@ -694,9 +694,11 @@ > # define CUSTOM_SYS_AUTH_PASSWD 1 > #endif > > +#if defined(HAVE_LIBIAF) && defined(HAVE_SET_ID) > +# define CUSTOM_SYS_AUTH_PASSWD 1 > +#endif > #if defined(HAVE_LIBIAF) && defined(HAVE_SET_ID) && !defined(BROKEN_LIBIAF) > # define USE_LIBIAF > -# define CUSTOM_SYS_AUTH_PASSWD 1 > #endif > > /* HP-UX 11.11 */ > ---------------------------- Yes, that works. Thank you Tim. -- Roger Cornelius rac at tenzing.org From jan.iven at cern.ch Tue Sep 18 01:28:36 2007 From: jan.iven at cern.ch (Jan Iven) Date: Mon, 17 Sep 2007 17:28:36 +0200 Subject: GSSAPI vs load-balanced servers - anything we can do? In-Reply-To: <2480C7C8-01F4-401A-B5C3-C2183ED6A2B4@inf.ed.ac.uk> References: <46EABC92.4060408@cern.ch> <2480C7C8-01F4-401A-B5C3-C2183ED6A2B4@inf.ed.ac.uk> Message-ID: <46EE9D24.2040808@cern.ch> On 14/09/07 22:26, Simon Wilkinson wrote: .. > RFC4120 (the revised Kerberos RFC) states > Implementations of Kerberos and protocols based on Kerberos MUST NOT > use insecure DNS queries to canonicalize the hostname components of > the service principal names > > So, I suspect that the language in 1964 will get updated at some point > in the future. There are already vendors who ship Kerberos GSSAPI > libraries with canonicalisation disabled. Interesting (even though this is just for Kerberos, not GSSAPI - and the GSSAPI RFC 2743 still says "the 'hostname' may (as an example implementation strategy) be canonicalized by attempting a DNS lookup"..). But "GSSAPI-for-SSH" rfc4462 is rather clear on the issue. Do you know whether there is something foreseen to determine whether a given GSSAPI library will do canonicalization? > Bear in mind, too, that the client side GSSAPI support is completely > mechanism independent - you can use it with X509 based mechanisms such > as GSI, and indeed any other GSSAPI mech that you have a library for. > So, hardcoding canonicalisation is the wrong thing to do. Thanks for reminding me. For now, we seem to get by with client-side canonicalization due to Kerberos being the only native mechanism on the server-side (i.e. without Globus patches). > The best bet at the moment is to provide a configuration option that > allows the user to indicate whether or not they wish to trust the DNS to > canonicalise the host name - which is what my GSSAPITrustDNS patch does > (This patch is also included in my GSSAPI patch bundle, which really > needs updated to 4.7 ...) Nice, looking forward to it. It means we would have to store two identities in the keytab (hostname+DNS-cluster-name), I remember that you had a path for using both as well somewhere. Will have a look. Regards Jan From tim at multitalents.net Tue Sep 18 01:38:14 2007 From: tim at multitalents.net (Tim Rice) Date: Mon, 17 Sep 2007 08:38:14 -0700 (PDT) Subject: 4.7p1 password auth broken on SCO OSR6 In-Reply-To: <20070917142629.GA13474@tenzing.org> References: <20070910185518.GA12718@tenzing.org> <20070913191824.GA13875@tenzing.org> <20070914155336.GA16347@tenzing.org> <20070917142629.GA13474@tenzing.org> Message-ID: On Mon, 17 Sep 2007, Roger Cornelius wrote: > On 09/15/2007 19:24, Tim Rice wrote: > > > > I tracked down the problem. CUSTOM_SYS_AUTH_PASSWD was not defined so > > the UNIXWARE_LONG_PASSWORDS bit were never used. > > > > Please backout your changes to configure.ac (leave my patch in) and > > openbsd-compat/xcrypt.c and try this patch. > > > > Thanks. > > > > ---------------------------- > > --- defines.h.old 2007-08-15 09:16:29.167892001 -0700 > > +++ defines.h 2007-09-15 19:17:15.331975020 -0700 > > @@ -694,9 +694,11 @@ > > # define CUSTOM_SYS_AUTH_PASSWD 1 > > #endif > > > > +#if defined(HAVE_LIBIAF) && defined(HAVE_SET_ID) > > +# define CUSTOM_SYS_AUTH_PASSWD 1 > > +#endif > > #if defined(HAVE_LIBIAF) && defined(HAVE_SET_ID) && !defined(BROKEN_LIBIAF) > > # define USE_LIBIAF > > -# define CUSTOM_SYS_AUTH_PASSWD 1 > > #endif > > > > /* HP-UX 11.11 */ > > ---------------------------- > > Yes, that works. Thank you Tim. OK, I've commited the patch to HEAD and the V_4_7 branch. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From wmertens at cisco.com Tue Sep 18 23:59:47 2007 From: wmertens at cisco.com (Wout Mertens) Date: Tue, 18 Sep 2007 15:59:47 +0200 Subject: [openssh-unix-dev] Re: openssh-agent polling In-Reply-To: <46EDD4A1.7040305@noaa.gov> References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <20070913123318.5044.qmail@cdy.org> <46E93231.3090506@zip.com.au> <20070914115724.28193.qmail@cdy.org> <20070916220811.GA30238@dementia.proulx.com> <46EDB39D.2050705@noaa.gov> <46EDCEF1.9090004@noaa.gov> <46EDD4A1.7040305@noaa.gov> Message-ID: <6B32830F-6ED2-4FE9-8676-BEC422D3AC99@cisco.com> On Sep 17, 2007, at 3:13 AM, Jefferson Ogata wrote: > There are ways of mitigating this--check ownership of /tmp/ssh- > ZZZZZZZZ > directory as well (should be root), but overall I agree with you that > the explicit location in the user's home is superior. I actually have > always wondered why the agent sockets have been put under /tmp and > not ~ > or ~/.ssh. If you have NFS-mounted homedirs, a socket can only have a process connected to it on one single host. At least on Solaris... There's also a bug on Mac OS 10.4 that won't let you connect to an unused socket that was in use when your system crashed. I ran into both issues trying just what you describe ;-) Hmm, the socket name could be randomized and amended with the hostname to mitigate these problems. This would also give you an insight in the hosts where you have agents running. Interesting... so that gives us: ============================================= # Only create a new agent if not logging in remotely or sudoing if [ -z "$SSH_AUTH_SOCK$SUDO_USER$SSH_CLIENT" -a -w ~/.ssh -a -O ~/.ssh ]; then export SSH_AUTH_SOCK for i in ~/.ssh/socket-`hostname`_*; do if [ -S "$i" -a -O "$i" ]; then SSH_AUTH_SOCK="$i" ssh-add -l >/dev/null 2>&1 if [ $? -le 1 ]; then SSH_AUTH_SOCK="$i" break fi # Clean up socket? fi done if [ -z "$SSH_AUTH_SOCK" ]; then SSH_AUTH_SOCK=~/.ssh/socket-`hostname`_$RANDOM$$ eval `ssh-agent -a "$SSH_AUTH_SOCK" -s` fi fi ============================================= Note that I add $RANDOM to the name - plain old sh doesn't have that, so I add $$ as well. The concatenation of environment variables is an AND function that doesn't take as much space ;-) Unfortunately this approach doesn't work on OS X - the hostname changes depending on what the DNS returns for the current IP address when using DHCP. Cheers, Wout. From deane at ipst.umd.edu Tue Sep 18 04:13:29 2007 From: deane at ipst.umd.edu (Anil Deane) Date: Mon, 17 Sep 2007 14:13:29 -0400 Subject: No subject Message-ID: Hi, when trying to install openssh I get the following errors. Any idea of why? This is on a mac 10.4.10 system, and with the 4.7p1 version. Appreciate any tips. Thanks, Anil if test ! -z ""; then \ /usr/bin/perl ./fixprogs ssh_prng_cmds ; \ fi (cd openbsd-compat && make) make[1]: Nothing to be done for `all'. gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -I. -I. -DSSHDIR= \"/sw/HPN-ssh/etc\" -D_PAT H_SSH_PROGRAM=\"/sw/HPN-ssh/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/ sw/HPN-ssh/libexec/ssh-as kpass\" -D_PATH_SFTP_SERVER=\"/sw/HPN-ssh/libexec/sftp-server\" - D_PATH_SSH_KEY_SIGN=\"/sw/HPN -ssh/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" - D_PATH_PRIVSEP_CHROOT_DIR=\"/var/e mpty\" -DSSH_RAND_HELPER=\"/sw/HPN-ssh/libexec/ssh-rand-helper\" - DHAVE_CONFIG_H -c readpass.c openbsd-compat/vis.h:85: bad attribute specification, expecting identifier, found `)' openbsd-compat/vis.h:87: bad attribute specification, expecting identifier, found `)' openbsd-compat/vis.h:91: bad attribute specification, expecting identifier, found `)' readpass.c:40: warning: could not use precompiled header '/usr/ include/unistd-gcc3.p', because : readpass.c:40: warning: macro 'optreset' defined by defines.h conflicts with precomp misc.h:33: bad attribute specification, expecting identifier, found `)' misc.h:66: bad attribute specification, expecting identifier, found `)' misc.h:68: bad attribute specification, expecting identifier, found `)' misc.h:70: bad attribute specification, expecting identifier, found `)' misc.h:72: bad attribute specification, expecting identifier, found `)' misc.h:74: bad attribute specification, expecting identifier, found `)' misc.h:76: bad attribute specification, expecting identifier, found `)' cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode In file included from readpass.c:42: xmalloc.h:26: warning: `__nonnull__' attribute directive ignored readpass.c: In function `read_passphrase': readpass.c:119: `RPP_ECHO_ON' undeclared (first use in this function) readpass.c:119: (Each undeclared identifier is reported only once readpass.c:119: for each function it appears in.) readpass.c:119: `RPP_ECHO_OFF' undeclared (first use in this function) readpass.c:128: `RPP_REQUIRE_TTY' undeclared (first use in this function) readpass.c:153: warning: implicit declaration of function `readpassphrase' make: *** [readpass.o] Error 1 ------------------------------------------------------------------- Dr. Anil Deane Associate Research Professor Institute for Physical Science and Technology University of Maryland College Park, MD 20742-2431 Tel: (301) 405-4866 Fax: (301) 314-9363 ------------------------------------------------------------------- From bacon at cs.nyu.edu Wed Sep 19 09:52:45 2007 From: bacon at cs.nyu.edu (David Bacon) Date: Tue, 18 Sep 2007 17:52:45 -0600 Subject: poll.h vs sys/poll.h on QNX Neutrino Message-ID: <46F064CD.4060607@cs.nyu.edu> From the ChangeLog: - dtucker at cvs.openbsd.org 2007/06/25 12:02:27 [atomicio.c] Include like the man page says rather than . ok djm@ This was probably ill-advised given the history of this header file. Some older systems, and some not-quite-XSI-compliant systems such as QNX Neutrino, still have but not . I suggest having configure.ac look for both, and put the check for first in atomicio.c, as in: #ifdef HAVE_POLL_H #include #else #ifdef HAVE_SYS_POLL_H #include #endif #endif dB From bacon at cs.nyu.edu Wed Sep 19 11:39:11 2007 From: bacon at cs.nyu.edu (David Bacon) Date: Tue, 18 Sep 2007 19:39:11 -0600 Subject: sp_expire is 0 in QNX Neutrino Message-ID: <46F07DBF.4070007@cs.nyu.edu> QNX Neutrino does not support the shadow password database properly. Apart from misdocumenting /etc/shadow as having 4 fields when in fact it has 5 (including the "last changed" field), its getspnam() fills in the sp_expire field of the spwd structure with 0. And since by default, shadow support is enabled and the configure script turns on HAS_SHADOW_EXPIRE when it finds that field, the built sshd ends up refusing all connections on the grounds of an expired account. I have dealt with this temporarily by hacking as follows: ========== cut ========= *** auth-shadow.c.was Sun Apr 29 02:10:58 2007 --- auth-shadow.c Wed Sep 19 01:04:18 2007 *************** *** 66,71 **** --- 66,72 ---- if (spw->sp_expire == -1) { debug3("account expiration disabled"); + #ifndef __QNXNTO__ } else if (daysleft < 0) { logit("Account %.100s has expired", spw->sp_namp); return 1; *************** *** 75,80 **** --- 76,82 ---- "Your account will expire in %d day%s.\n", daysleft, daysleft == 1 ? "" : "s"); buffer_append(&loginmsg, buf, strlen(buf)); + #endif } return 0; ========= tuc ========== Note that this also turns off a login message warning (daysleft is always negative in Neutrino). dB From tim at multitalents.net Wed Sep 19 14:20:14 2007 From: tim at multitalents.net (Tim Rice) Date: Tue, 18 Sep 2007 21:20:14 -0700 (PDT) Subject: sp_expire is 0 in QNX Neutrino In-Reply-To: <46F07DBF.4070007@cs.nyu.edu> References: <46F07DBF.4070007@cs.nyu.edu> Message-ID: On Tue, 18 Sep 2007, David Bacon wrote: > QNX Neutrino does not support the shadow > password database properly. Apart from > misdocumenting /etc/shadow as having 4 > fields when in fact it has 5 (including > the "last changed" field), its getspnam() > fills in the sp_expire field of the spwd > structure with 0. And since by default, > shadow support is enabled and the > configure script turns on HAS_SHADOW_EXPIRE > when it finds that field, the built sshd > ends up refusing all connections on the > grounds of an expired account. What happens if you undef HAS_SHADOW_EXPIRE in config.h? -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bacon at cs.nyu.edu Wed Sep 19 22:55:23 2007 From: bacon at cs.nyu.edu (David Bacon) Date: Wed, 19 Sep 2007 06:55:23 -0600 Subject: sp_expire is 0 in QNX Neutrino In-Reply-To: References: <46F07DBF.4070007@cs.nyu.edu> Message-ID: <46F11C3B.6060809@cs.nyu.edu> Tim Rice wrote, circa 2007-09-18 22:20 MDT: > On Tue, 18 Sep 2007, David Bacon wrote: > >> QNX Neutrino does not support the shadow >> password database properly. Apart from >> misdocumenting /etc/shadow as having 4 >> fields when in fact it has 5 (including >> the "last changed" field), its getspnam() >> fills in the sp_expire field of the spwd >> structure with 0. And since by default, >> shadow support is enabled and the >> configure script turns on HAS_SHADOW_EXPIRE >> when it finds that field, the built sshd >> ends up refusing all connections on the >> grounds of an expired account. > > What happens if you undef HAS_SHADOW_EXPIRE in config.h? I would expect that to work, but be harder to maintain. (Odd that this macro isn't called HAVE_SHADOW_EXPIRE, by the way, isn't it.) Presumably a proper solution is to have configure.ac recognize the existence of broken shadow password expiry support, and define a symbol reflecting that. Or at least to have it beef up the check that allows HAS_SHADOW_EXPIRE to be defined. dB From rapier at psc.edu Thu Sep 20 06:15:20 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 19 Sep 2007 16:15:20 -0400 Subject: Forcing IPv4 with SFTP Message-ID: <46F18358.2000401@psc.edu> I'm wondering if I'm missing something. With ssh and scp you can force the use of IPv4 with the -4 option. This doesn't seem to be an option or sftp. Is this by design or oversight? From bob at proulx.com Thu Sep 20 06:31:18 2007 From: bob at proulx.com (Bob Proulx) Date: Wed, 19 Sep 2007 14:31:18 -0600 Subject: Forcing IPv4 with SFTP In-Reply-To: <46F18358.2000401@psc.edu> References: <46F18358.2000401@psc.edu> Message-ID: <20070919203118.GA30386@dementia.proulx.com> Chris Rapier wrote: > I'm wondering if I'm missing something. With ssh and scp you can force > the use of IPv4 with the -4 option. This doesn't seem to be an option or > sftp. Is this by design or oversight? Use the long option name. All of the options listed in ssh_config(5) are available this way. AddressFamily Specifies which address family to use when connecting. Valid arguments are "any", "inet" (Use IPv4 only) or "inet6" (Use IPv6 only.) For IPv4 only you would use: sftp -oAddressFamily=inet example.com Bob From rapier at psc.edu Thu Sep 20 06:37:03 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 19 Sep 2007 16:37:03 -0400 Subject: Forcing IPv4 with SFTP In-Reply-To: <20070919203118.GA30386@dementia.proulx.com> References: <46F18358.2000401@psc.edu> <20070919203118.GA30386@dementia.proulx.com> Message-ID: <46F1886F.10700@psc.edu> I didn't even think of using the -o format. Thanks for the insight. Bob Proulx wrote: > Chris Rapier wrote: >> I'm wondering if I'm missing something. With ssh and scp you can force >> the use of IPv4 with the -4 option. This doesn't seem to be an option or >> sftp. Is this by design or oversight? > > Use the long option name. All of the options listed in ssh_config(5) > are available this way. > > AddressFamily > Specifies which address family to use when connecting. Valid > arguments are "any", "inet" (Use IPv4 only) or "inet6" (Use IPv6 > only.) > > For IPv4 only you would use: > > sftp -oAddressFamily=inet example.com > > Bob > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From pwo at qimonda.com Fri Sep 21 05:05:17 2007 From: pwo at qimonda.com (Peter W. Osel) Date: Thu, 20 Sep 2007 15:05:17 -0400 Subject: OpenSSH 4.7p1 - support the use of netgroups in AllowUsers and DenyUsers configuration options Message-ID: <20070920190516.GL3087@rdusxi01.muc.infineon.com> Hello, I have attached a small patch that enables OpenSSH 4.7p1 to use netgroups for users and hosts entries in the AllowUsers and DenyUsers configuration options in sshd_config. This has the following advantages: * hostnames or ip addresses don't have to be maintained in sshd_config, but you can use meaningful names for groups of users and groups of hosts. * large scale installations can manage user groups and host groups in a central name service like NIS, NIS+, LDAP. * sshd_config files no longer change when users and/or hosts are added/removed from the groups of users/hosts. * administration effort for large installations is reduced * maintaining a consistent setup across a large set of systems is much easier. * systems without PAM support (that cannot use e.g. pam_list or pam_access) can now use netgroup based access restrictions. * the patch uses innetgr(3c) so netgroups can be stored in NIS, NIS+ or LDAP, or any other directory service that is plugged into nsswitch and that has a netgroup back end. The changes were developed by Albert Fluegel af at muc.de and he has given me permission to submit them to OpenSSH. I have ported them to the current OpenSSH version, 4.7p1. I also want to thank Darren J Moffat for proposing to use innetgr(3c). Any errors in the attached code though are strictly mine. While the syntax is not the nicest one (@myusers@@myhosts is a valid entry), but using @ as a netgroup name prefix seems to be fairly common (e.g. Linux NFS exports, shosts/rhosts, ...). It also avoids that user or host names are accidentally interpreted as netgroups or vice versa. Cheers --pwo -- Peter W. Osel -- http://pwo.de/ -- pwo at pwo.de ---snip--snap------------------------------------------------------------------- diff -ru openssh-4.7p1/match.c openssh-4.7p1_pwo0/match.c --- openssh-4.7p1/match.c Fri Aug 4 22:39:40 2006 +++ openssh-4.7p1_pwo0/match.c Mon Sep 17 15:49:57 2007 @@ -204,6 +204,39 @@ } /* + * match user in @netgroup + */ +int +match_user_or_netgroup(const char *user, char *pattern) +{ + if(pattern[0] != '@') + return match_pattern(user, pattern); + +#ifdef HAVE_INNETGR + return innetgr(pattern + 1, NULL, user, NULL); +#else + return 0; +#endif +} + +/* + * match host in @netgroup + */ +int +match_host_and_ip_or_netgroup(const char *host, const char * ipaddr, char *pattern) +{ + if(pattern[0] != '@') + return match_host_and_ip(host, ipaddr, pattern); + +#ifdef HAVE_INNETGR + return innetgr(pattern + 1, host, NULL, NULL) + || innetgr(pattern + 1, ipaddr, NULL, NULL); +#else + return 0; +#endif +} + +/* * match user, user at host_or_ip, user at host_or_ip_list against pattern */ int @@ -213,15 +246,18 @@ char *p, *pat; int ret; - if ((p = strchr(pattern,'@')) == NULL) - return match_pattern(user, pattern); + if (strlen(pattern) < 1) + return 0; + if ((p = strchr(pattern + 1, '@')) == NULL) + return match_user_or_netgroup(user, pattern); + pat = xstrdup(pattern); - p = strchr(pat, '@'); + p = strchr(pat + 1, '@'); *p++ = '\0'; - if ((ret = match_pattern(user, pat)) == 1) - ret = match_host_and_ip(host, ipaddr, p); + if ((ret = match_user_or_netgroup(user, pat)) == 1) + ret = match_host_and_ip_or_netgroup(host, ipaddr, p); xfree(pat); return ret; diff -ru openssh-4.7p1/sshd_config.5 openssh-4.7p1_pwo0/sshd_config.5 --- openssh-4.7p1/sshd_config.5 Mon Jun 11 00:07:13 2007 +++ openssh-4.7p1_pwo0/sshd_config.5 Mon Sep 17 16:04:55 2007 @@ -130,7 +130,10 @@ By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular -users from particular hosts. +users from particular hosts. If NIS or LDAP +is available and netgroup querying is built in, either USER and +HOST can be the name of a netgroup of users or hosts, respectively, +prefixed with a @. Then @myusers@@myhosts is a valid entry here. The allow/deny directives are processed in the following order: .Cm DenyUsers , .Cm AllowUsers , @@ -268,8 +271,11 @@ By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular -users from particular hosts. -The allow/deny directives are processed in the following order: +users from particular hosts. If NIS or LDAP is available and +netgroup querying is built in, either USER and HOST can be the +name of a netgroup of users or hosts, respectively, prefixed with +the character @ . Then e.g. @myusers@@myhosts is a valid entry +here. The allow/deny directives are processed in the following order: .Cm DenyUsers , .Cm AllowUsers , .Cm DenyGroups , ---snip--snap------------------------------------------------------------------- From alan-jenkins at tuffmail.co.uk Fri Sep 21 06:14:28 2007 From: alan-jenkins at tuffmail.co.uk (Alan Jenkins) Date: Thu, 20 Sep 2007 21:14:28 +0100 Subject: [PATCH] openssh-agent polling In-Reply-To: <46E8F8BF.6010909@tuffmail.co.uk> References: <46E8254D.90403@tuffmail.co.uk> <46E8D1F6.9070804@quest.com> <46E8F8BF.6010909@tuffmail.co.uk> Message-ID: <46F2D4A4.8050105@tuffmail.co.uk> Alan Jenkins wrote: > David Leonard wrote: >> Damien Miller wrote: >>> On Wed, 12 Sep 2007, Alan Jenkins wrote: >>>> This may be a stupid question - but why does ssh-agent fork off >>>> a child and then exec the subcommand in the *parent* process? It >>>> forces the agent in the child process to poll the parent, so >>>> it can exit when the parent finishes. If the agent was the parent >>>> process, it could use wait() instead. I'm sure there's some reason. >>>> >>>> It'd be nice to take ssh-agent off the list of polling processes you >>>> get with powertop[1], however far down it is. >>>> > >> ssh-agent starts its command in the parent process probably so that >> you can get something useful from $! returned in your startup script, > > Surely that's fixable - wait() gives you the terminated child's exit code. > >> and to avoid the situation where ssh-agent could get an untrappable >> signal and leaves the underlying command running. > > Which way round do you mean this? Are we trying to avoid leaving the > underlying command running if ssh-agent is killed, or do we want it to > carry on running independently? It sounds like you meant the subcommand > should be killed if ssh-agent is, but my understanding of the current > behaviour is that the subcommand keeps on running. > > If the aim is to keep the subcommand running, I guess we're stuck with > polling. If I've got my un*x right, it's not possible to wait() on a > process unless it would get killed if you terminate. I had my un*x wrong. In general child processes keep on running when their parent dies. So you can do: fork(); parent: /* foreground process */ int status = 0; wait(&status); exit(status); child: /* agent */ fork(); parent: signal(SIGCHLD, { int status = 0; wait(&status); exit(status); }); detach(); run_agent(); /* does not return */ child: /* subcommand */ exec(subcommand); I think you can't get rid of the extra fork. You need it in order for setsid() to be guaranteed to succeed in the agent process (this is a required in order to daemonize, which is represented above by the detach() function). I has a patch. It makes things a little harder to understand but it does work. Anyone like, dislike? To recap: this avoids polling when a subcommand is started, by waiting for SIGCHLD instead of waking up every 10 seconds to check the subcommand is still alive. An extra wakeup every 10 seconds is not practically significant, but means that ssh-agent will show up on profiling tools such as powertop[1] for no good reason. [1] http://www.linuxpowertop.org Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-agent.diff Type: text/x-patch Size: 4166 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070920/939e075e/attachment.bin From dtucker at zip.com.au Fri Sep 21 12:52:20 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 21 Sep 2007 12:52:20 +1000 Subject: vis.h:85: bad attribute specification In-Reply-To: References: Message-ID: <20070921025220.GA682@gate.dtucker.net> On Mon, Sep 17, 2007 at 02:13:29PM -0400, Anil Deane wrote: > Hi, when trying to install openssh I get the following errors. Any > idea of why? > This is on a mac 10.4.10 system, and with the 4.7p1 version. > Appreciate any tips. Which gcc version are you using? [...] > openbsd-compat/vis.h:85: bad attribute specification, expecting > identifier, found `)' Looks like the compiler doesn't have the __bounded__ attribute, and also doesn't like having an empty __attribute__ list. You could try the following patch which substitutes a (mostly) harmless attribute that is supported back as gcc 2.7.2.3 (and at worst, should only cause a warning). Index: defines.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/defines.h,v retrieving revision 1.144 diff -u -p -r1.144 defines.h --- defines.h 17 Sep 2007 15:32:33 -0000 1.144 +++ defines.h 21 Sep 2007 02:41:58 -0000 @@ -440,7 +440,7 @@ struct winsize { #endif #if !defined(HAVE_ATTRIBUTE__BOUNDED__) && !defined(__bounded__) -# define __bounded__(x, y, z) +# define __bounded__(x, y, z) __unused__ #endif #if !defined(HAVE_ATTRIBUTE__NONNULL__) && !defined(__nonnull__) -- 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 21 13:02:56 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 21 Sep 2007 13:02:56 +1000 Subject: poll.h vs sys/poll.h on QNX Neutrino In-Reply-To: <46F064CD.4060607@cs.nyu.edu> References: <46F064CD.4060607@cs.nyu.edu> Message-ID: <20070921030256.GA1052@gate.dtucker.net> On Tue, Sep 18, 2007 at 05:52:45PM -0600, David Bacon wrote: > [...] Some older > systems, and some not-quite-XSI-compliant > systems such as QNX Neutrino, still have > but not . > > I suggest having configure.ac look for > both, and put the check for first > in atomicio.c, as in: Sounds reasonable. Could you please confirm that this works? You will need to run "autoreconf" to rebuild configure, then re-run configure. Thanks. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v retrieving revision 1.384 diff -u -p -r1.384 configure.ac --- configure.ac 10 Sep 2007 23:24:18 -0000 1.384 +++ configure.ac 21 Sep 2007 02:59:09 -0000 @@ -223,6 +223,7 @@ AC_CHECK_HEADERS( \ sys/dir.h \ sys/mman.h \ sys/ndir.h \ + sys/poll.h \ sys/prctl.h \ sys/pstat.h \ sys/select.h \ Index: atomicio.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/atomicio.c,v retrieving revision 1.35 diff -u -p -r1.35 atomicio.c --- atomicio.c 25 Jun 2007 12:15:12 -0000 1.35 +++ atomicio.c 21 Sep 2007 02:57:54 -0000 @@ -34,6 +34,10 @@ #include #ifdef HAVE_POLL_H #include +#else +# ifdef HAVE_SYS_POLL_H +# include +# endif #endif #include #include -- 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 21 13:13:49 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 21 Sep 2007 13:13:49 +1000 Subject: sp_expire is 0 in QNX Neutrino In-Reply-To: <46F11C3B.6060809@cs.nyu.edu> References: <46F07DBF.4070007@cs.nyu.edu> <46F11C3B.6060809@cs.nyu.edu> Message-ID: <20070921031349.GB1052@gate.dtucker.net> On Wed, Sep 19, 2007 at 06:55:23AM -0600, David Bacon wrote: > Tim Rice wrote, circa 2007-09-18 22:20 MDT: [...] > > What happens if you undef HAS_SHADOW_EXPIRE in config.h? > > I would expect that to work, but be harder to > maintain. (Odd that this macro isn't called > HAVE_SHADOW_EXPIRE, by the way, isn't it.) > > Presumably a proper solution is to have > configure.ac recognize the existence of > broken shadow password expiry support, and > define a symbol reflecting that. Right. > Or at > least to have it beef up the check that > allows HAS_SHADOW_EXPIRE to be defined. That's probably hard as reading the shadow file requires privilege and configure can (and usually does) run without privilege. Could you please confirm that the following patch works? Again, you will need to run "autoreconf" to rebuild configure and then rerun configure. Thanks. Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v retrieving revision 1.384 diff -u -p -r1.384 configure.ac --- configure.ac 10 Sep 2007 23:24:18 -0000 1.384 +++ configure.ac 21 Sep 2007 03:11:35 -0000 @@ -785,6 +785,7 @@ mips-sony-bsd|mips-sony-newsos4) AC_DEFINE(MISSING_FD_MASK, 1, [Define on *nto-qnx systems]) AC_DEFINE(DISABLE_LASTLOG) AC_DEFINE(SSHD_ACQUIRES_CTTY) + AC_DEFINE(BROKEN_SHADOW_EXPIRE, 1, [QNX shadow support is broken]) enable_etc_default_login=no # has incompatible /etc/default/login case "$host" in *-*-nto-qnx6*) Index: defines.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/defines.h,v retrieving revision 1.144 diff -u -p -r1.144 defines.h --- defines.h 17 Sep 2007 15:32:33 -0000 1.144 +++ defines.h 21 Sep 2007 03:07:29 -0000 @@ -540,6 +540,10 @@ struct winsize { # undef HAVE_UPDWTMPX #endif +#if defined(BROKEN_SHADOW_EXPIRE) && defined(HAS_SHADOW_EXPIRE) +# undef HAS_SHADOW_EXPIRE +#endif + #if defined(HAVE_OPENLOG_R) && defined(SYSLOG_DATA_INIT) && \ defined(SYSLOG_R_SAFE_IN_SIGHAND) # define DO_LOG_SAFE_IN_SIGHAND -- 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 wgja at sanger.ac.uk Fri Sep 21 06:57:52 2007 From: wgja at sanger.ac.uk (Will Angenent) Date: Thu, 20 Sep 2007 20:57:52 UT Subject: openssh-4.7p1 & RemoteForward to openssh-3.6.1p2 Disconnecting: Bad packet length Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070920/f113ba3a/attachment.ksh From wgja at sanger.ac.uk Fri Sep 21 22:35:01 2007 From: wgja at sanger.ac.uk (Will Angenent) Date: Fri, 21 Sep 2007 13:35:01 +0100 Subject: openssh-4.7p1 & RemoteForward to openssh-3.6.1p2 Disconnecting: Bad, packet length Message-ID: <46F3BA75.1070506@sanger.ac.uk> Hi, I've just upgraded to openssh-4.7p1 on my gentoo box, and I've noticed a incompatibility with openssh-3.6.1p2 running on a redhat AS3 server. If I ssh from my openssh-4.7_p1 client to the openssh-3.6.1p2 server, and RemoteForward a port, the ssh connection closes if I try to send more than roughly 300K through the tunneled port. The problem isn't present when I use openssh-4.6p1 as a client. A typical error is: Disconnecting: Bad packet length 327708. The number varies with retries. The problem is easily reproducible. Steps to reproduce: - ssh from client ssh openssh-4.7p1 -> server openssh-3.6.1p2 with -R2000:127.0.0.1:2000 - on client: nc -l -p 2000 > /dev/null - on server cat a_big_ish_file |nc 127.0.0.1 2000 => the ssh connection terminates with the error If I'd have a clue where to begin to look for, I'd give you more info, but I'm afraid I'm not too initiated in the openssh world. If I can do anything to help with the diagnosis, please let me know. Regards, Will -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. From vmhetre at hotmail.com Fri Sep 21 10:35:44 2007 From: vmhetre at hotmail.com (Vikram Mhetre) Date: Thu, 20 Sep 2007 19:35:44 -0500 Subject: Diffie Hellman key exchange algorithms Message-ID: A few questions regarding the OpenSSH support for the Diffie Hellman key exchange algorithms: (1) Are the diffie-hellman-group-exchange-sha256", "diffie-hellman-group-exchange-sha1" , "diffie-hellman-group14-sha1" "diffie-hellman-group1-sha1" (as defined in RFCs 4253 and RFC 4419) the complete list of key exchange algorithms supported by OpenSSH? (2) Is there a way to configure the DH key exchange algorithms to be supported? For e.g. if we want to support only "diffie-hellman-group14-sha1", is it possible to configure it? It looks like it is possible to configure the data encryption algorithms (like AES) using the Ciphers keyword and the data integrity algorithms (like HMAC-SHA-1) using the MACs keyword in the sshd_config file. However there doesn't seem to be a keyword to configure key exchange algorithms. (3) The /etc/primes file is used for the "diffie-hellman-group-exchange-sha256", "diffie-hellman-group-exchange-sha1" algorithms. However if the primes file does not exist does the SSH connection simply fail if one of these two algorithms is chosen during the initial part of the setup. That is, based on RFC 4419, since the server cannot choose a suitable prime group (p,g) from the primes file (since it does not exist) will it simply reject the SSH connection? Thanks, Vik _________________________________________________________________ Gear up for Halo? 3 with free downloads and an exclusive offer. It?s our way of saying thanks for using Windows Live?. http://gethalo3gear.com?ocid=SeptemberWLHalo3_WLHMTxt_2 From djm at mindrot.org Sat Sep 22 13:06:26 2007 From: djm at mindrot.org (Damien Miller) Date: Sat, 22 Sep 2007 13:06:26 +1000 (EST) Subject: Diffie Hellman key exchange algorithms In-Reply-To: References: Message-ID: On Thu, 20 Sep 2007, Vikram Mhetre wrote: > A few questions regarding the OpenSSH support for the Diffie Hellman key exchange algorithms: > > (1) Are the diffie-hellman-group-exchange-sha256", > "diffie-hellman-group-exchange-sha1" , "diffie-hellman-group14-sha1" > "diffie-hellman-group1-sha1" (as defined in RFCs 4253 and RFC 4419) > the complete list of key exchange algorithms supported by OpenSSH? Yes > (2) Is there a way to configure the DH key exchange algorithms to be > supported? No > (3) The /etc/primes file is used for the > "diffie-hellman-group-exchange-sha256", > "diffie-hellman-group-exchange-sha1" algorithms. However if the primes > file does not exist does the SSH connection simply fail if one of > these two algorithms is chosen during the initial part of the setup. > That is, based on RFC 4419, since the server cannot choose a suitable > prime group (p,g) from the primes file (since it does not exist) will > it simply reject the SSH connection? That is incorrect. The group exchange methods will fall back to a fixed modulus (the same used in diffie-hellman-group14-sha1) if they cannot open /etc/moduli. -d From ryanfrantz at informed-llc.com Sun Sep 23 07:10:40 2007 From: ryanfrantz at informed-llc.com (Ryan Frantz) Date: Sat, 22 Sep 2007 17:10:40 -0400 Subject: chroot support for ssh and sftp Message-ID: List, I'm current running an older, patched version of OpenSSH with chroot support (OpenSSH_4.2-chrootsshp1). It's the chrootssh patch that James Dennis has been providing. I checked back lately and found that even with the portable OpenSSH source currently at 4.7p1, James doesn't have anything newer than 4.5p1. I'd like to upgrade so I tried my hand at implementing the patch in the 4.7p1 source. Everything compiles just fine and I even get a successful chroot for ssh sessions. My problem is that calls to the sftp-server subsystem fail miserably (and quietly). Even with debugging turned on in the server and client, I still can't get any decent output to start troubleshooting. My questions are two-fold, then: 1. Are there plans to support chroot()'ing in the portable source? 2. What other chroot options are there available for the portable source (I've seen Damien Miller's patch for OpenBSD, but I don't really have any experience coding in C)? Ryan Frantz Senior System Engineer InforMed, LLC 410-972-2025 x2131 ryanfrantz at informed-llc.com From Postmaster at relay22i.sun.com Mon Sep 24 20:13:33 2007 From: Postmaster at relay22i.sun.com (Postmaster at relay22i.sun.com) Date: Mon, 24 Sep 2007 10:13:33 +0000 Subject: Undeliverable mail Message-ID: Your message was not delivered to the following recipients: opensparc-interest at sun.com: 550 5.7.1 ... Access denied -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/rfc822-headers Size: 1086 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070924/5964fa0f/attachment.bin From bacon at cs.nyu.edu Tue Sep 25 01:38:09 2007 From: bacon at cs.nyu.edu (David Bacon) Date: Mon, 24 Sep 2007 09:38:09 -0600 Subject: poll.h vs sys/poll.h on QNX Neutrino In-Reply-To: <20070921030256.GA1052@gate.dtucker.net> References: <46F064CD.4060607@cs.nyu.edu> <20070921030256.GA1052@gate.dtucker.net> Message-ID: <46F7D9E1.8030408@cs.nyu.edu> This works fine. dB Darren Tucker wrote, circa 2007-09-20 21:02 MDT: > On Tue, Sep 18, 2007 at 05:52:45PM -0600, David Bacon wrote: >> [...] Some older >> systems, and some not-quite-XSI-compliant >> systems such as QNX Neutrino, still have >> but not . >> >> I suggest having configure.ac look for >> both, and put the check for first >> in atomicio.c, as in: > > Sounds reasonable. Could you please confirm that this works? You will need > to run "autoreconf" to rebuild configure, then re-run configure. Thanks. > > > Index: configure.ac > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v > retrieving revision 1.384 > diff -u -p -r1.384 configure.ac > --- configure.ac 10 Sep 2007 23:24:18 -0000 1.384 > +++ configure.ac 21 Sep 2007 02:59:09 -0000 > @@ -223,6 +223,7 @@ AC_CHECK_HEADERS( \ > sys/dir.h \ > sys/mman.h \ > sys/ndir.h \ > + sys/poll.h \ > sys/prctl.h \ > sys/pstat.h \ > sys/select.h \ > Index: atomicio.c > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/atomicio.c,v > retrieving revision 1.35 > diff -u -p -r1.35 atomicio.c > --- atomicio.c 25 Jun 2007 12:15:12 -0000 1.35 > +++ atomicio.c 21 Sep 2007 02:57:54 -0000 > @@ -34,6 +34,10 @@ > #include > #ifdef HAVE_POLL_H > #include > +#else > +# ifdef HAVE_SYS_POLL_H > +# include > +# endif > #endif > #include > #include > From bacon at cs.nyu.edu Tue Sep 25 01:42:20 2007 From: bacon at cs.nyu.edu (David Bacon) Date: Mon, 24 Sep 2007 09:42:20 -0600 Subject: sp_expire is 0 in QNX Neutrino In-Reply-To: <20070921031349.GB1052@gate.dtucker.net> References: <46F07DBF.4070007@cs.nyu.edu> <46F11C3B.6060809@cs.nyu.edu> <20070921031349.GB1052@gate.dtucker.net> Message-ID: <46F7DADC.1000904@cs.nyu.edu> This patch also seems to work fine, and I agree completely with you about the environment in which configure runs, of course. In fact, I may try to set up cross-compilation of both OpenSSL and OpenSSH for an embedded PowerPC CPU (a big-endian target, but I'm sure this is well covered ground because of the Mac). dB Darren Tucker wrote, circa 2007-09-20 21:13 MDT: > On Wed, Sep 19, 2007 at 06:55:23AM -0600, David Bacon wrote: >> Tim Rice wrote, circa 2007-09-18 22:20 MDT: > [...] >>> What happens if you undef HAS_SHADOW_EXPIRE in config.h? >> I would expect that to work, but be harder to >> maintain. (Odd that this macro isn't called >> HAVE_SHADOW_EXPIRE, by the way, isn't it.) >> >> Presumably a proper solution is to have >> configure.ac recognize the existence of >> broken shadow password expiry support, and >> define a symbol reflecting that. > > Right. > >> Or at >> least to have it beef up the check that >> allows HAS_SHADOW_EXPIRE to be defined. > > That's probably hard as reading the shadow file requires privilege and > configure can (and usually does) run without privilege. > > Could you please confirm that the following patch works? Again, you will > need to run "autoreconf" to rebuild configure and then rerun configure. > Thanks. > > Index: configure.ac > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v > retrieving revision 1.384 > diff -u -p -r1.384 configure.ac > --- configure.ac 10 Sep 2007 23:24:18 -0000 1.384 > +++ configure.ac 21 Sep 2007 03:11:35 -0000 > @@ -785,6 +785,7 @@ mips-sony-bsd|mips-sony-newsos4) > AC_DEFINE(MISSING_FD_MASK, 1, [Define on *nto-qnx systems]) > AC_DEFINE(DISABLE_LASTLOG) > AC_DEFINE(SSHD_ACQUIRES_CTTY) > + AC_DEFINE(BROKEN_SHADOW_EXPIRE, 1, [QNX shadow support is broken]) > enable_etc_default_login=no # has incompatible /etc/default/login > case "$host" in > *-*-nto-qnx6*) > Index: defines.h > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/defines.h,v > retrieving revision 1.144 > diff -u -p -r1.144 defines.h > --- defines.h 17 Sep 2007 15:32:33 -0000 1.144 > +++ defines.h 21 Sep 2007 03:07:29 -0000 > @@ -540,6 +540,10 @@ struct winsize { > # undef HAVE_UPDWTMPX > #endif > > +#if defined(BROKEN_SHADOW_EXPIRE) && defined(HAS_SHADOW_EXPIRE) > +# undef HAS_SHADOW_EXPIRE > +#endif > + > #if defined(HAVE_OPENLOG_R) && defined(SYSLOG_DATA_INIT) && \ > defined(SYSLOG_R_SAFE_IN_SIGHAND) > # define DO_LOG_SAFE_IN_SIGHAND > From srinath_balaraman at mentor.com Tue Sep 25 02:46:51 2007 From: srinath_balaraman at mentor.com (Balaraman, Srinath) Date: Mon, 24 Sep 2007 11:46:51 -0500 Subject: Diffie Hellman key exchange algorithms In-Reply-To: References: Message-ID: Hello All, To add to this question, I also am interested in knowing if the size of the DH key to be negotiated both from the Server and the Client can be configured? If yes, how? Thanks, Srinath -----Original Message----- From: openssh-unix-dev-bounces+srinath_balaraman=mentor.com at mindrot.org [mailto:openssh-unix-dev-bounces+srinath_balaraman=mentor.com at mindrot.or g] On Behalf Of Damien Miller Sent: Friday, September 21, 2007 10:06 PM To: Vikram Mhetre Cc: openssh-unix-dev at mindrot.org Subject: Re: Diffie Hellman key exchange algorithms On Thu, 20 Sep 2007, Vikram Mhetre wrote: > A few questions regarding the OpenSSH support for the Diffie Hellman key exchange algorithms: > > (1) Are the diffie-hellman-group-exchange-sha256", > "diffie-hellman-group-exchange-sha1" , "diffie-hellman-group14-sha1" > "diffie-hellman-group1-sha1" (as defined in RFCs 4253 and RFC 4419) > the complete list of key exchange algorithms supported by OpenSSH? Yes > (2) Is there a way to configure the DH key exchange algorithms to be > supported? No > (3) The /etc/primes file is used for the > "diffie-hellman-group-exchange-sha256", > "diffie-hellman-group-exchange-sha1" algorithms. However if the primes > file does not exist does the SSH connection simply fail if one of > these two algorithms is chosen during the initial part of the setup. > That is, based on RFC 4419, since the server cannot choose a suitable > prime group (p,g) from the primes file (since it does not exist) will > it simply reject the SSH connection? That is incorrect. The group exchange methods will fall back to a fixed modulus (the same used in diffie-hellman-group14-sha1) if they cannot open /etc/moduli. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From rwaite1 at tampabay.rr.com Tue Sep 25 03:39:04 2007 From: rwaite1 at tampabay.rr.com (rwaite1 at tampabay.rr.com) Date: Mon, 24 Sep 2007 13:39:04 -0400 Subject: Diffie Hellman key exchange algorithms Message-ID: <23387842.204821190655544253.JavaMail.root@hrndva-web28-z02> In response to being able to configure the DH key algorithms to be used... the changes to the code are failrly small and seem safe to me. If someone is interested in what needs to change I had posted the changes needed to openbsd-misc back in January of this year. I did not make a patch file.. I only described it in text. I would appreciate comments if anyone sees something that is not safe. I did not add any logic or algorithms... I just made changes to the existing code. The subject of the thread was "How to remove group1 and group14 from OpenSSH.." In retrospect.. it never belonged on that board and perhaps would have been better here. I kinda wish that sshd would let you configure this as it seems like an important security decision for an admin. I made the changes to the code on my machine because I spent a good amount of time making very large primes. The only way to use them is to use the KEX method. If the user that logs in does not have the KEX method enabled.. I believe that it will use the group 1 or group 14. It has been a while since I looked at this code so perhaps my logic here is not so clear.. but I know at the time I had researched it I had definite reason for doing it. One of the RFCs states that you have to include the ability to use group 1 and 14. To me.. this is nice for everyone in the world to happily be able to negotiate with any server... but that is not my desire. To me.. if someone is using an old client that does not allow KEX.. then I don't want them on my system.. and I think I have a right to decide that. In all likelihood, no one is going to break your data being sent with group 1. But that doesn't mean I don't want to force a higher level of security. You could also force KEX_DH_GEX_SHA256 and not allow KEX_DH_GEX_SHA1 but I have found that a number of clients don't support this and at this time I have left KEX_DH_GEX_SHA1 as usable. Also if anyone is new to playing around in the code for OpenSSH... I found the following page pretty useful for getting an overview of the protocol: http://cs.wellesley.edu/~cs342/SSH2Protocol.html Then of course the RFCs I believe generally in the rfc425X range. And then getting a good packet sniffer so you can see what a particular ssh client is allowing. From djm at mindrot.org Tue Sep 25 10:41:43 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 25 Sep 2007 10:41:43 +1000 (EST) Subject: Diffie Hellman key exchange algorithms In-Reply-To: References: Message-ID: On Mon, 24 Sep 2007, Balaraman, Srinath wrote: > Hello All, > > To add to this question, I also am interested in knowing if the size of > the DH key to be negotiated both from the Server and the Client can be > configured? If yes, how? Do you mean the size of the key generated by DH or the size of the group used in diffie-hellman-group-exchange-*? If you mean the former, then the key length is that of the symmetric cipher that has been negotiated. If you mean the latter, then the size of the group is chosen to yield a similar attack complexity as the negotiated symmetric cipher. See dh.c:dh_estimate() and the comment that preceeds it. Either way, there is are no configuration knobs. -d From djm at mindrot.org Tue Sep 25 10:49:08 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 25 Sep 2007 10:49:08 +1000 (EST) Subject: chroot support for ssh and sftp In-Reply-To: References: Message-ID: On Sat, 22 Sep 2007, Ryan Frantz wrote: > 1. Are there plans to support chroot()'ing in the portable source? I'd like to, but doing chroot safely is quite tricky - there are all sorts of small corner cases that can make it quite unsafe. I have been working on it a little recently, but I'm not sure that it will make the 4.8 release. > 2. What other chroot options are there available for the portable source > (I've seen Damien Miller's patch for OpenBSD, but I don't really have > any experience coding in C)? There are no chroot patches that I'd recommend for general use at the moment. -d From rwaite1 at tampabay.rr.com Tue Sep 25 14:55:59 2007 From: rwaite1 at tampabay.rr.com (Rob Waite) Date: Tue, 25 Sep 2007 00:55:59 -0400 Subject: Diffie Hellman key exchange algorithms References: Message-ID: <001201c7ff30$5d8d4180$c801010a@PUFF> Isn't dh_estimate() only used on the client to find the desired group size? This is then taken by the server and used to find p and g correct? OpenSSH is not configurable in this manner... but if someone wanted to force larger primes... couldn't they do this by altering the code? In the code changes I sent earlier... you could force group exchange. And if you picked only large primes in your moduli file... you should be able to force the client to get a large p as long as it is within the min and max sent by the client. I just started looking at the code again (it has been a while) but it seems like the server can control at the very least the size of the public and private numbers generated from p. He would not be able to control how powerful the client made their public and private numbers from the given p... but at least data sent out from the server would be forced to have the symmetric key encrypted using larges primes for the assymmetric. That is assuming that the server has its own symmetric cipher key and the client has their own. If they do in fact share the same key... then I guess you would not be protected as the client could generate a small private number from p... no matter how large. I would then expect that there would be a way to code the server to only accept a certain size for the public number given back to the server by the client. Is this line of thinking correct? Or does it sounds like garbled nonsense? I am kinda sleepy. ----- Original Message ----- From: "Damien Miller" To: "Balaraman, Srinath" Cc: "Vikram Mhetre" ; Sent: Monday, September 24, 2007 8:41 PM Subject: RE: Diffie Hellman key exchange algorithms > On Mon, 24 Sep 2007, Balaraman, Srinath wrote: > >> Hello All, >> >> To add to this question, I also am interested in knowing if the size of >> the DH key to be negotiated both from the Server and the Client can be >> configured? If yes, how? > > Do you mean the size of the key generated by DH or the size of the group > used in diffie-hellman-group-exchange-*? > > If you mean the former, then the key length is that of the symmetric > cipher that has been negotiated. > > If you mean the latter, then the size of the group is chosen to yield > a similar attack complexity as the negotiated symmetric cipher. See > dh.c:dh_estimate() and the comment that preceeds it. > > Either way, there is are no configuration knobs. > > -d > _______________________________________________ > 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 Tue Sep 25 15:10:47 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 25 Sep 2007 15:10:47 +1000 (EST) Subject: Diffie Hellman key exchange algorithms In-Reply-To: <001201c7ff30$5d8d4180$c801010a@PUFF> References: <001201c7ff30$5d8d4180$c801010a@PUFF> Message-ID: On Tue, 25 Sep 2007, Rob Waite wrote: > Isn't dh_estimate() only used on the client to find the desired group > size? Yes > This is then taken by the server and used to find p and g correct? Yes > OpenSSH is not configurable in this manner... but if someone wanted to force > larger primes... > couldn't they do this by altering the code? Yes - OpenSSH allows the client to request DH groups up to 8192 bits. > In the code changes I sent > earlier... you could > force group exchange. It's the default anyway :) > And if you picked only large primes in your moduli > file... > you should be able to force the client to get a large p as long as it is > within the min > and max sent by the client. I just started looking at the code again (it has > been a while) > but it seems like the server can control at the very least the size of the > public and private > numbers generated from p. He would not be able to control how powerful the > client made > their public and private numbers from the given p... but at least data sent > out from the server would > be forced to have the symmetric key encrypted using larges primes for the > assymmetric. The client don't have any special control over the output of the DH protocol - the only get to specify one input (the server specifies the others), and OpenSSH will refuse to accept the obviously bogus values of that (see dh_pub_is_valid() in dh.c). > That is assuming that the server has its own symmetric cipher key and the > client has their own. > If they do in fact share the same key... then I guess you would not be > protected as the client The SSH protocol uses separate keys for client-to-server and server-to-client. > could generate a small private number from p... no matter how large. The client doesn't get to choose what number they generate as it has to match exactly what the server generated (DH is a deterministic protocol, even if some of the inputs should be based on random numbers). If the client and server's DH output differ then the IVs and {crypto, MAC} keys will differ two and the connection will fail as soon as either end tries to send any data. -d From alon.barlev at gmail.com Tue Sep 25 15:33:44 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 25 Sep 2007 08:33:44 +0300 Subject: OpenSSH PKCS#11merge Message-ID: <200709250733.47491.alon.barlev@gmail.com> [[Sending again, as for some strange reason it is not accepted]] Hello OpenSSH developers, I maintain external patch for PKCS#11 smartcard support into OpenSSH[1] , many users already apply and use this patch. I wish to know if anyone is interesting in working toward merging this into mainline. I had some discussion with Damien Miller, but then he disappeared. Having standard smartcard interface will enable many users to have more secure environment, without the need to acquire card of specific vendor. In order to merge it cleanly, we should also discuss a modification for the agent protocol. As smartcards are dynamic in nature, there should be an option for the agent to ask the caller to provide information, for example "Insert token " or "Please enter passphrase for token ". Current implementation does not modify the agent protocol but execute dialog from within the agent. Best Regards, Alon Bar-Lev [1] http://alon.barlev.googlepages.com/openssh-pkcs11 From storm.richard at gmail.com Tue Sep 25 18:59:18 2007 From: storm.richard at gmail.com (Richard Storm) Date: Tue, 25 Sep 2007 11:59:18 +0300 Subject: OpenSSH PKCS#11merge Message-ID: <6ac10b630709250159s43731f39j1b5601b11679f94a@mail.gmail.com> Yeah, that would be very usefull to have pkcs11 interface out of box, so I could pkg_add opensc on fresh openbsd box and use smart card for authentication. This patching thing is overkill. Why not to incorporate it into openssh? pkcs11 is open standart and patch is bsd licensed, right? From alon.barlev at gmail.com Tue Sep 25 20:55:09 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 25 Sep 2007 12:55:09 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <6ac10b630709250159s43731f39j1b5601b11679f94a@mail.gmail.com> References: <6ac10b630709250159s43731f39j1b5601b11679f94a@mail.gmail.com> Message-ID: <9e0cf0bf0709250355h6505dab9obc9f427edc736101@mail.gmail.com> On 9/25/07, Richard Storm wrote: > Yeah, that would be very usefull to have pkcs11 interface out of box, > so I could pkg_add opensc on fresh openbsd box and use smart card for > authentication. > This patching thing is overkill. > Why not to incorporate it into openssh? pkcs11 is open standart and > patch is bsd licensed, right? Yes. The patch and the pkcs11-helper library both BSD licensed. Alon. From imorgan at nas.nasa.gov Wed Sep 26 01:31:48 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 25 Sep 2007 08:31:48 -0700 Subject: OpenSSH PKCS#11merge In-Reply-To: <200709250733.47491.alon.barlev@gmail.com> References: <200709250733.47491.alon.barlev@gmail.com> Message-ID: <20070925153148.GA29980@linux55.nas.nasa.gov> On Tue, Sep 25, 2007 at 08:33:44 +0300, Alon Bar-Lev wrote: > > [[Sending again, as for some strange reason it is not accepted]] > > Hello OpenSSH developers, > > I maintain external patch for PKCS#11 smartcard support into > OpenSSH[1] , many users already apply and use this patch. > > I wish to know if anyone is interesting in working toward merging this > into mainline. > > I had some discussion with Damien Miller, but then he disappeared. > > Having standard smartcard interface will enable many users to have > more secure environment, without the need to acquire card of specific > vendor. > > In order to merge it cleanly, we should also discuss a modification > for the agent protocol. As smartcards are dynamic in nature, there > should be an option for the agent to ask the caller to provide > information, for example "Insert token " or "Please enter > passphrase for token ". Current implementation does not modify > the agent protocol but execute dialog from within the agent. > > Best Regards, > Alon Bar-Lev > > [1] http://alon.barlev.googlepages.com/openssh-pkcs11 Due to HSPD-12, US government agencies are switching to the use of smartcards for authentication. (Some agencies havve already made this transition.) Presumably any improvements in the smartcard support that OpenSSH offers would be useful. -- Iain Morgan From deengert at anl.gov Wed Sep 26 04:50:41 2007 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 25 Sep 2007 13:50:41 -0500 Subject: OpenSSH PKCS#11merge In-Reply-To: <20070925153148.GA29980@linux55.nas.nasa.gov> References: <200709250733.47491.alon.barlev@gmail.com> <20070925153148.GA29980@linux55.nas.nasa.gov> Message-ID: <46F95881.7030400@anl.gov> Iain Morgan wrote: > > Due to HSPD-12, US government agencies are switching to the use > of smartcards for authentication. (Some agencies havve already > made this transition.) Presumably any improvements in the > smartcard support that OpenSSH offers would be useful. Another way to do this especially with HSPD-12 PIV cards is via Kerberos. Over the last few years, I have been working on the combination of kinit or pam_krb5 with Heimdal or MIT Kerberos using PKINIT to authenticate to a KDC: Heimdal, MIT or AD. The Kerberos client would use the OpenSC PKCS#11. OpenSC has support for the PIV cards. http://www.opensc-project.org/opensc/wiki/UnitedStatesPIV With this combination there are no changes to SSH as it would use the existing Kerberos via GSS. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From alon.barlev at gmail.com Tue Sep 25 07:40:14 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 24 Sep 2007 23:40:14 +0200 Subject: PKCS#11merge Message-ID: <9e0cf0bf0709241440s67f58765y3d971ec7d83b80ed@mail.gmail.com> Hello OpenSSH developers, I maintain external patch for PKCS#11 smartcard support into OpenSSH[1] , many users already apply and use this patch. I wish to know if anyone is interesting in working toward merging this into mainline. I had some discussion with Damien Miller, but then he disappeared. Having standard smartcard interface will enable many users to have more secure environment, without the need to acquire card of specific vendor. In order to merge it cleanly, we should also discuss a modification for the agent protocol. As smartcards are dynamic in nature, there should be an option for the agent to ask the caller to provide information, for example "Insert token " or "Please enter passphrase for token ". Current implementation does not modify the agent protocol but execute dialog from within the agent. Best Regards, Alon Bar-Lev [1] http://alon.barlev.googlepages.com/openssh-pkcs11 From rapier at psc.edu Thu Sep 27 05:32:44 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 26 Sep 2007 15:32:44 -0400 Subject: Inconsistent none cipher behavior Message-ID: <46FAB3DC.6040504@psc.edu> Using stock OpenSSH 4.7 I found different behavior when trying to specify the use of the 'none' cipher depending on the command line option nomenclature. This is under linux 2.6.19-web100 using -ocipher=none [root at delta openssh-4.7p1-hpnv19]# /home/rapier/ssh47/bin/scp -S /home/rapier/ssh47/bin/ssh -ocipher=none -P 2222 ~rapier/2gb rapier at localhost:/dev/null rapier at localhost's password: 2gb 3% 74MB 32.7MB/s 01:00 ETA using -cnone [root at delta openssh-4.7p1-hpnv19]# /home/rapier/ssh47/bin/scp -S /home/rapier/ssh47/bin/ssh -cnone -P 2222 ~rapier/2gb rapier at localhost:/dev/null No valid ciphers for protocol version 2 given, using defaults. rapier at localhost's password: 2gb 1% 33MB 32.7MB/s 01:01 ETA The difference being, of course, the warning given. In both cases the behaviour is the same and results in a fall back to the default cipher. Should this be made consistent? Chris Rapier From dtucker at zip.com.au Thu Sep 27 09:29:31 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 27 Sep 2007 09:29:31 +1000 Subject: Inconsistent none cipher behavior In-Reply-To: <46FAB3DC.6040504@psc.edu> References: <46FAB3DC.6040504@psc.edu> Message-ID: <20070926232931.GA21027@gate.dtucker.net> On Wed, Sep 26, 2007 at 03:32:44PM -0400, Chris Rapier wrote: > Using stock OpenSSH 4.7 I found different behavior when trying to > specify the use of the 'none' cipher depending on the command line > option nomenclature. This is under linux 2.6.19-web100 > > using -ocipher=none > [root at delta openssh-4.7p1-hpnv19]# /home/rapier/ssh47/bin/scp -S > /home/rapier/ssh47/bin/ssh -ocipher=none -P 2222 ~rapier/2gb "Cipher" is an SSHv1-only directive so it will have no effect unless your connection is using Protocol 1. Try "Ciphers". -- 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 rwaite1 at tampabay.rr.com Thu Sep 27 13:14:41 2007 From: rwaite1 at tampabay.rr.com (Rob Waite) Date: Wed, 26 Sep 2007 23:14:41 -0400 Subject: Diffie Hellman key exchange algorithms References: <001201c7ff30$5d8d4180$c801010a@PUFF> Message-ID: <000d01c800b4$8b8128b0$c801010a@PUFF> >> In the code changes I sent >> earlier... you could >> force group exchange. >It's the default anyway :) If it is the default.. isn't the client software given the option to not accept group exchange? So by that reasoning... the client is given the power to decrease the level of security of your server (although... I realize that it is unlikely to actually be cracked anyway) They can send a SSH_MSG_KEXINIT that only has group1 for example. >The client doesn't get to choose what number they generate as it has to >match exactly what the server generated (DH is a deterministic protocol, >even if some of the inputs should be based on random numbers). If the >client and server's DH output differ then the IVs and {crypto, MAC} keys >will differ two and the connection will fail as soon as either end tries >to send any data. They are not able to choose the public prime but they do have the ability to choose their private exponent. The way I read the RFC is that the client software chooses the size of the private exponent. So it seems that they are given control on the strength of the private key used to encrypt their messages going out. I guess in general cases it doesn't matter. You have given someone a login to your server so you would have to trust that they are not trying to be bad. Once they get the file which you have already given them permission to... they could just give it to anyone. I guess you are unable to control the strength of the messages that they are sending you. And this is probably something that can't be worked around since the client's private exponent is known to them alone... so there is no way for the server to enforce a length. It just seemed to me that there are some things that the server can do to force increased security. Right now this is not configurable.. but can be done in code. For example... the server won't allow you to pick the key exchange methods allowed and block others that are not. This allows a user to log into the server with an old or weak client. They are given the control to decide to pick group1 instead of group exchange. ----- Original Message ----- From: "Damien Miller" To: "Rob Waite" Cc: Sent: Tuesday, September 25, 2007 1:10 AM Subject: Re: Diffie Hellman key exchange algorithms > On Tue, 25 Sep 2007, Rob Waite wrote: > >> Isn't dh_estimate() only used on the client to find the desired group >> size? > > Yes > >> This is then taken by the server and used to find p and g correct? > > Yes > >> OpenSSH is not configurable in this manner... but if someone wanted to >> force >> larger primes... >> couldn't they do this by altering the code? > > Yes - OpenSSH allows the client to request DH groups up to 8192 bits. > >> In the code changes I sent >> earlier... you could >> force group exchange. > > It's the default anyway :) > >> And if you picked only large primes in your moduli >> file... >> you should be able to force the client to get a large p as long as it is >> within the min >> and max sent by the client. I just started looking at the code again (it >> has >> been a while) >> but it seems like the server can control at the very least the size of >> the >> public and private >> numbers generated from p. He would not be able to control how powerful >> the >> client made >> their public and private numbers from the given p... but at least data >> sent >> out from the server would >> be forced to have the symmetric key encrypted using larges primes for the >> assymmetric. > > The client don't have any special control over the output of the DH > protocol - the only get to specify one input (the server specifies the > others), and OpenSSH will refuse to accept the obviously bogus values of > that (see dh_pub_is_valid() in dh.c). > >> That is assuming that the server has its own symmetric cipher key and the >> client has their own. >> If they do in fact share the same key... then I guess you would not be >> protected as the client > > The SSH protocol uses separate keys for client-to-server and > server-to-client. > >> could generate a small private number from p... no matter how large. > > The client doesn't get to choose what number they generate as it has to > match exactly what the server generated (DH is a deterministic protocol, > even if some of the inputs should be based on random numbers). If the > client and server's DH output differ then the IVs and {crypto, MAC} keys > will differ two and the connection will fail as soon as either end tries > to send any data. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From rwaite1 at tampabay.rr.com Thu Sep 27 14:54:15 2007 From: rwaite1 at tampabay.rr.com (Rob Waite) Date: Thu, 27 Sep 2007 00:54:15 -0400 Subject: Diffie Hellman key exchange algorithms References: <001201c7ff30$5d8d4180$c801010a@PUFF> <000d01c800b4$8b8128b0$c801010a@PUFF> Message-ID: <002201c800c2$74a3dad0$c801010a@PUFF> Also... in RFC 4419... the authors say that the private exponent should be a random number x where 1 < x < (p-1)/2. This is the private secret that would allow one to find the shared secret. They say later in the paper that the size of this number can be reduced to make computation faster. They say that it should be at least twice the size of the key material that will be generated from the shared secret. To me it appears that the size of the key material is a value kex->we_need which is set in kex_choose_conf. This is passed into dh_gen_key multiplied by 8. This is to convert it to bits needed from bytes. I believe in AES256's case.. this would end up being 256 passed in here... This is used in dh_gen_key by passing it to BN_rand as 2*need. This sets the number of bits to make the random number created by BN_rand. So from what I can gather.. OpenSSH follows the minimum size to make the private exponent. If an attacker was to try to attack OpenSSH... they would be able to eliminate a huge number of possible choices for the private exponent. They would in fact know the number of bits. In reality... I don't think even if they knew it was a 512 bit number... they would not be able to crack it. But it seems to me that the security of the underlying public key encryption system of OpenSSH could be strengthened by making the size of the private exponent more variable. So.. for example.. if your public prime was 8000 bits long... your random needs to be less than 4000 bits long. So if the size of the private exponent was more variable... an attacker would have to guess all of the numbers between 512 bits and 4000 bits (assuming that 256 is indeed the value of "need") I may be reading the code incorrectly but this seems logical to me. It is true that almost certainly.. no one is going to crack, let alone care about the traffic I am sending across the net. But since when do cryptographers make it easier for them ; ) Also... I have not done tests to see if expanding the length of the exponent makes the initial key negotiation grindingly slow. If that is the case.. then maybe it doesn't need to be 4000 bits long... but it seems that giving a little bit of randomness here would be a good thing and not too hard to implement. ----- Original Message ----- From: "Rob Waite" To: "Damien Miller" Cc: Sent: Wednesday, September 26, 2007 11:14 PM Subject: Re: Diffie Hellman key exchange algorithms >>> In the code changes I sent >>> earlier... you could >>> force group exchange. > >>It's the default anyway :) > > If it is the default.. isn't the client software given the option to not > accept group exchange? > So by that reasoning... the client is given the power to decrease > the level of security of your server (although... I > realize that it is unlikely to actually be cracked anyway) > They can send a SSH_MSG_KEXINIT that only has group1 for example. > >>The client doesn't get to choose what number they generate as it has to >>match exactly what the server generated (DH is a deterministic protocol, >>even if some of the inputs should be based on random numbers). If the >>client and server's DH output differ then the IVs and {crypto, MAC} keys >>will differ two and the connection will fail as soon as either end tries >>to send any data. > > They are not able to choose the public prime but they do have the ability > to choose their private exponent. The way I read the RFC is that the > client software chooses the size of the private exponent. So it seems > that they are given control on the strength of the private key used to > encrypt their messages going out. > > I guess in general cases it doesn't matter. You have given someone > a login to your server so you would have to trust that they are not > trying to be bad. Once they get the file which you have already given > them permission to... they could just give it to anyone. I guess you > are unable to control the strength of the messages that they are sending > you. And this is probably something that can't be worked around > since the client's private exponent is known to them alone... so there > is no way for the server to enforce a length. > > It just seemed to me that there are some things that the server can do > to force increased security. Right now this is not configurable.. but can > be done in code. For example... the server won't allow you to pick the > key exchange methods allowed and block others that are not. This > allows a user to log into the server with an old or weak client. They > are given the control to decide to pick group1 instead of group exchange. > > > > ----- Original Message ----- > From: "Damien Miller" > To: "Rob Waite" > Cc: > Sent: Tuesday, September 25, 2007 1:10 AM > Subject: Re: Diffie Hellman key exchange algorithms > > >> On Tue, 25 Sep 2007, Rob Waite wrote: >> >>> Isn't dh_estimate() only used on the client to find the desired group >>> size? >> >> Yes >> >>> This is then taken by the server and used to find p and g correct? >> >> Yes >> >>> OpenSSH is not configurable in this manner... but if someone wanted to >>> force >>> larger primes... >>> couldn't they do this by altering the code? >> >> Yes - OpenSSH allows the client to request DH groups up to 8192 bits. >> >>> In the code changes I sent >>> earlier... you could >>> force group exchange. >> >> It's the default anyway :) >> >>> And if you picked only large primes in your moduli >>> file... >>> you should be able to force the client to get a large p as long as it is >>> within the min >>> and max sent by the client. I just started looking at the code again (it >>> has >>> been a while) >>> but it seems like the server can control at the very least the size of >>> the >>> public and private >>> numbers generated from p. He would not be able to control how powerful >>> the >>> client made >>> their public and private numbers from the given p... but at least data >>> sent >>> out from the server would >>> be forced to have the symmetric key encrypted using larges primes for >>> the >>> assymmetric. >> >> The client don't have any special control over the output of the DH >> protocol - the only get to specify one input (the server specifies the >> others), and OpenSSH will refuse to accept the obviously bogus values of >> that (see dh_pub_is_valid() in dh.c). >> >>> That is assuming that the server has its own symmetric cipher key and >>> the >>> client has their own. >>> If they do in fact share the same key... then I guess you would not be >>> protected as the client >> >> The SSH protocol uses separate keys for client-to-server and >> server-to-client. >> >>> could generate a small private number from p... no matter how large. >> >> The client doesn't get to choose what number they generate as it has to >> match exactly what the server generated (DH is a deterministic protocol, >> even if some of the inputs should be based on random numbers). If the >> client and server's DH output differ then the IVs and {crypto, MAC} keys >> will differ two and the connection will fail as soon as either end tries >> to send any data. >> >> -d >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From alon.barlev at gmail.com Thu Sep 27 18:28:22 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 27 Sep 2007 11:28:22 +0300 Subject: OpenSSH PKCS#11merge In-Reply-To: <46F95881.7030400@anl.gov> References: <200709250733.47491.alon.barlev@gmail.com> <20070925153148.GA29980@linux55.nas.nasa.gov> <46F95881.7030400@anl.gov> Message-ID: <9e0cf0bf0709270128n1d432a9m8ea1068206bfabd5@mail.gmail.com> Hello, On 9/25/07, Douglas E. Engert wrote: > Another way to do this especially with HSPD-12 PIV cards is via Kerberos. > Over the last few years, I have been working on the combination of > kinit or pam_krb5 with Heimdal or MIT Kerberos using PKINIT to authenticate > to a KDC: Heimdal, MIT or AD. The Kerberos client would use the OpenSC > PKCS#11. OpenSC has support for the PIV cards. Kerberos is a single point of failure in term of availability and security. Even if Kerberos is a good solution for one domain network, how can you access foreign networks? And even if you Kerberos the whole world... How can you securely access the Kerberos KDC when the KDC is down? Just like OpenSSH can access file based keys it should be able to use smarcard based keys and PKCS#11 is the common interface to access smartcards. Best Regards, Alon Bar-Lev. From carson at taltos.org Thu Sep 27 19:38:30 2007 From: carson at taltos.org (Carson Gaspar) Date: Thu, 27 Sep 2007 02:38:30 -0700 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0709270128n1d432a9m8ea1068206bfabd5@mail.gmail.com> References: <200709250733.47491.alon.barlev@gmail.com> <20070925153148.GA29980@linux55.nas.nasa.gov> <46F95881.7030400@anl.gov> <9e0cf0bf0709270128n1d432a9m8ea1068206bfabd5@mail.gmail.com> Message-ID: <46FB7A16.3030407@taltos.org> Alon Bar-Lev wrote: > Kerberos is a single point of failure in term of availability and security. Ummm... how? If you have 50 KDCs, what single point of availability failure is there? Yes, a compromised KDC key store is bad, but then so is a compromised CA. Actually, I'd say the compromised CA is worse (or has revocation actually been deployed in the real world yet? Oh wait, it hasn't been.) > Even if Kerberos is a good solution for one domain network, how can > you access foreign networks? Cross-realm trust > And even if you Kerberos the whole world... How can you securely > access the Kerberos KDC when the KDC is down? Have more than one... duh. > Just like OpenSSH can access file based keys it should be able to use > smarcard based keys and PKCS#11 is the common interface to access > smartcards. I'm not against smartcard support. But Kerberos bashing is not the way to get it. Especially underinformed (if I'm being charitable) bashing. PKI, solving yesterday's problems, tomorrow, for over a decade... -- Carson From alon.barlev at gmail.com Thu Sep 27 21:26:46 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 27 Sep 2007 14:26:46 +0300 Subject: OpenSSH PKCS#11merge In-Reply-To: <46FB7A16.3030407@taltos.org> References: <200709250733.47491.alon.barlev@gmail.com> <20070925153148.GA29980@linux55.nas.nasa.gov> <46F95881.7030400@anl.gov> <9e0cf0bf0709270128n1d432a9m8ea1068206bfabd5@mail.gmail.com> <46FB7A16.3030407@taltos.org> Message-ID: <9e0cf0bf0709270426t7d8e7413t147ec5f8c9899483@mail.gmail.com> On 9/27/07, Carson Gaspar wrote: > PKI, solving yesterday's problems, tomorrow, for over a decade... Never said that PKI is the way to go... Please read again... Alon. From rapier at psc.edu Fri Sep 28 00:37:40 2007 From: rapier at psc.edu (Chris Rapier) Date: Thu, 27 Sep 2007 10:37:40 -0400 Subject: Inconsistent none cipher behavior In-Reply-To: <20070926232931.GA21027@gate.dtucker.net> References: <46FAB3DC.6040504@psc.edu> <20070926232931.GA21027@gate.dtucker.net> Message-ID: <46FBC034.4010802@psc.edu> So Cipher is protocol 1 only Ciphers is protocol 2 only and -c is both and how its handled is context dependent Is this about right? Sorry if I'm being a pest about this I'm trying to get some information together for one of our users who is trying to support their users. I just want to make sure I give them the right information. Darren Tucker wrote: > On Wed, Sep 26, 2007 at 03:32:44PM -0400, Chris Rapier wrote: >> Using stock OpenSSH 4.7 I found different behavior when trying to >> specify the use of the 'none' cipher depending on the command line >> option nomenclature. This is under linux 2.6.19-web100 >> >> using -ocipher=none >> [root at delta openssh-4.7p1-hpnv19]# /home/rapier/ssh47/bin/scp -S >> /home/rapier/ssh47/bin/ssh -ocipher=none -P 2222 ~rapier/2gb > > "Cipher" is an SSHv1-only directive so it will have no effect unless your > connection is using Protocol 1. Try "Ciphers". > From deengert at anl.gov Fri Sep 28 01:05:52 2007 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 27 Sep 2007 10:05:52 -0500 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0709270128n1d432a9m8ea1068206bfabd5@mail.gmail.com> References: <200709250733.47491.alon.barlev@gmail.com> <20070925153148.GA29980@linux55.nas.nasa.gov> <46F95881.7030400@anl.gov> <9e0cf0bf0709270128n1d432a9m8ea1068206bfabd5@mail.gmail.com> Message-ID: <46FBC6D0.1040009@anl.gov> Alon Bar-Lev wrote: > Hello, > > On 9/25/07, Douglas E. Engert wrote: >> Another way to do this especially with HSPD-12 PIV cards is via Kerberos. >> Over the last few years, I have been working on the combination of >> kinit or pam_krb5 with Heimdal or MIT Kerberos using PKINIT to authenticate >> to a KDC: Heimdal, MIT or AD. The Kerberos client would use the OpenSC >> PKCS#11. OpenSC has support for the PIV cards. > > Kerberos is a single point of failure in term of availability and security. > Even if Kerberos is a good solution for one domain network, how can > you access foreign networks? > And even if you Kerberos the whole world... How can you securely > access the Kerberos KDC when the KDC is down? > > Just like OpenSSH can access file based keys it should be able to use > smarcard based keys and PKCS#11 is the common interface to access > smartcards. I was responding to the poster who said he was interested in using PIV cards. Based on the name of his organization, I know that they are looking at using the PIV cards with Kerberos and Active Directory, so I offered an alternative way to use OpenSSH with Kerberos. This is not to say that its the only way. Adding your mods would be another. > > Best Regards, > Alon Bar-Lev. > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From imorgan at nas.nasa.gov Fri Sep 28 01:42:06 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 27 Sep 2007 08:42:06 -0700 Subject: OpenSSH PKCS#11merge In-Reply-To: <46FBC6D0.1040009@anl.gov> References: <200709250733.47491.alon.barlev@gmail.com> <20070925153148.GA29980@linux55.nas.nasa.gov> <46F95881.7030400@anl.gov> <9e0cf0bf0709270128n1d432a9m8ea1068206bfabd5@mail.gmail.com> <46FBC6D0.1040009@anl.gov> Message-ID: <20070927154206.GJ21697@linux55.nas.nasa.gov> On Thu, Sep 27, 2007 at 10:05:52 -0500, Douglas E. Engert wrote: > [snip] > > I was responding to the poster who said he was interested in using PIV > cards. > Based on the name of his organization, I know that they are looking at using > the PIV cards with Kerberos and Active Directory, so I offered an > alternative > way to use OpenSSH with Kerberos. And your input was appreciated. I haven't been involved sufficiently in the HSPD-12 planning, so I was concerned as to how OpenSSH would fit into this brave new world. I expect that the Kerberos approach will be used. > > This is not to say that its the only way. Adding your mods would be another. > Not having any first-hand experience with Kerberos, there might be some cases where it could be problematic for us. I know some issues can be addressed by cross-realm agreements, but we have users that ssh in when on travel as well as users from academic or commercial sites that may not have local Kerberos infrastructure. Since I'm Kerberos-ignorant, there may already be ways to address these issues, but it would be nice to have enhanced smartcard support as an alternative. Thanks. -- Iain Morgan From mocleiri at jpint.utoronto.ca Fri Sep 28 03:14:32 2007 From: mocleiri at jpint.utoronto.ca (Michael O'Cleirigh) Date: Thu, 27 Sep 2007 13:14:32 -0400 Subject: Q: how to restrict access selectively to client initiated local port forward Message-ID: <46FBE4F8.5020507@jpint.utoronto.ca> Hello, At work we have an internal application that implements a proxy. It works by counting the number of connections per IP address and using this to enforce usage limits (i.e. not more than X connections from a given IP). The important thing for us is a unique IP per client. We have this implemented where each client first authenticates through OpenVPN and is assigned a unique IP address. But some of our users can't get their corporate firewall changed to allow the tunnel to be established. So we've come up with a way that they can use ssh local port forwarding to accomplish the same thing. For example: This is the idealized case, the client connects to the proxy and their connections are managed: client ---------------------> proxy VPN: With the vpn the client is given a unique IP and all works well. client (10.8.0.x) ---------------> proxy (10.8.0.1) Open SSH: With open ssh we use the following command: ssh -L yyyy:10.8.0.x:yyyy user at proxy client (a.b.c.d) ------------------> proxy local redirect to -------> (10.8.0.x) where yyyy is the port being forwarded and lo:x is a loopback alias on the proxy to be 10.8.0.x (a differnent loopback IP will exist for each connecting client) This works since it appears to the proxy that the connections are originating from 10.8.0.x. However as far as I can tell there is no way in OpenSSH to define an access control policy for which connecting users are allowed to redirect through which local IP. i.e. we can't enforce that only user1 can local redirect through 10.8.0.12. which would allow anyone with system access to redirect through 10.8.0.12. I've downloaded and locally modified openssh-4.7p1 to include a new module that will allow this decision to be made (reads a custom configuration file that answers the question: can $user redirect through $hostname). But I can't figure out the exact place to insertit in the OpenSSH source code. Could someone point me to the source file and line that is responsible for the server side inialization of a client local forward? I tried connecting in serverloop.c function: static void server_input_global_request(int type, u_int32_t seq, void *ctxt); which by its comment says it deals with "-R" style forwarding but this doesn't seem to be the correct place for "-L" style forwarding. Thanks for your help, Mike From william at 25thandClement.com Fri Sep 28 03:28:33 2007 From: william at 25thandClement.com (William Ahern) Date: Thu, 27 Sep 2007 10:28:33 -0700 Subject: Q: how to restrict access selectively to client initiated local port forward In-Reply-To: <46FBE4F8.5020507@jpint.utoronto.ca> References: <46FBE4F8.5020507@jpint.utoronto.ca> Message-ID: <20070927172832.GA31226@wilbur.25thandClement.com> On Thu, Sep 27, 2007 at 01:14:32PM -0400, Michael O'Cleirigh wrote: > However as far as I can tell there is no way in OpenSSH to define an > access control policy for which connecting users are allowed to redirect > through which local IP. > > i.e. we can't enforce that only user1 can local redirect through > 10.8.0.12. which would allow anyone with system access to redirect > through 10.8.0.12. > > I've downloaded and locally modified openssh-4.7p1 to include a new > module that will allow this decision to be made (reads a custom > configuration file that answers the question: can $user redirect through > $hostname). But I can't figure out the exact place to insertit in the > OpenSSH source code. > > Could someone point me to the source file and line that is responsible > for the server side inialization of a client local forward? I've long forgotten how I did it, but when I was at Barracuda Networks I did just this while working on this work: http://wilbur.25thandclement.com/~william/projects/streamlocal.html I forgot why I didn't release the other work. But, I added a feature to execute a progam which transformed port forward requests on the server side; if the script exited with non-zero the request was denied. It had the configuration work and everything. You can try querying denis at barracuda.com and he might be able to give you the patch (diff against the vendor tree and the production/development tree), or bits of it to get you started. IIRC, it was non-trivial, like the stream local patch. You can't easily just "drop in" a feature into the OpenSSH code (i.e. add a function somewhere which plugs-in a complex branch of logic), because the codebase is rather brittle at this point. Good luck. From stuge-openssh-unix-dev at cdy.org Fri Sep 28 03:43:57 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 27 Sep 2007 19:43:57 +0200 Subject: Q: how to restrict access selectively to client initiated local port forward In-Reply-To: <46FBE4F8.5020507@jpint.utoronto.ca> References: <46FBE4F8.5020507@jpint.utoronto.ca> Message-ID: <20070927174357.9543.qmail@cdy.org> On Thu, Sep 27, 2007 at 01:14:32PM -0400, Michael O'Cleirigh wrote: > The important thing for us is a unique IP per client. We have this > implemented where each client first authenticates through OpenVPN > and is assigned a unique IP address. > > But some of our users can't get their corporate firewall changed to > allow the tunnel to be established. So we've come up with a way > that they can use ssh local port forwarding to accomplish the same > thing. Then you should run OpenVPN over TCP on port 22 or whatever you're using for SSH that can be reached from clients, on another public IP address and be done. > However as far as I can tell there is no way in OpenSSH to define > an access control policy for which connecting users are allowed to > redirect through which local IP. Right, because there's no way for OpenSSH to implement it anyway. > answers the question: can $user redirect through $hostname) Does the socket API keep track of socket owners? //Peter From rapier at psc.edu Fri Sep 28 05:12:36 2007 From: rapier at psc.edu (Chris Rapier) Date: Thu, 27 Sep 2007 15:12:36 -0400 Subject: Q: how to restrict access selectively to client initiated local port forward In-Reply-To: <20070927174357.9543.qmail@cdy.org> References: <46FBE4F8.5020507@jpint.utoronto.ca> <20070927174357.9543.qmail@cdy.org> Message-ID: <46FC00A4.5060608@psc.edu> > Then you should run OpenVPN over TCP on port 22 or whatever you're > using for SSH that can be reached from clients, on another public IP > address and be done. This is likely the correct solution. >> However as far as I can tell there is no way in OpenSSH to define >> an access control policy for which connecting users are allowed to >> redirect through which local IP. > > Right, because there's no way for OpenSSH to implement it anyway. You are right in that it can't be done in the base OpenSSH code. However, I know it can be done with patches to OpenSSH because we actually implemented it. We even had it so that one user wouldn't be able bogart well known ports. So it can be done. Its just not easy and probably not worth the hassle in this instance. From sxw at inf.ed.ac.uk Fri Sep 28 07:33:49 2007 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Thu, 27 Sep 2007 22:33:49 +0100 Subject: GSSAPI Key Exchange Patch for OpenSSH 4.7p1 Message-ID: <0DC5C238-7F48-41F5-A0DB-DEF62E0698D8@inf.ed.ac.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm pleased to (finally) announce the availability of my GSSAPI Key Exchange patch for OpenSSH 4.7p1. Whilst OpenSSH contains support for doing GSSAPI user authentication, this only allows the underlying security mechanism to authenticate the user to the server, and continues to use SSH host keys to authenticate the server to the user. For many sites who already have security infrastructures such as Kerberos deployed, managing large numbers of SSH host keys is an additional, unneccessary, burden. GSSAPI key exchange allows the use of security mechanisms such as Kerberos to authenticate the server to the user, removing the need for trusted ssh host keys, and allowing the use of a single security architecture. This patch adds support for the RFC4462 GSSAPI key exchange mechanisms to OpenSSH, along with adding some additional features to the GSSAPI code that is already in the tree. The patch implements: *) gss-group1-sha1-*, gss-group14-sha1-* and gss-gex-sha1-* key exchange mechanisms. (#1242) *) Support for the null host key type (#1242) *) Support for CCAPI credentials caches on Mac OS X (#1245) *) Support for better error handling when an authentication exchange fails due to server misconfiguration (#1244) *) Support for GSSAPI connections to hosts behind a round-robin load balancer (#1008) *) Support for GSSAPI connections to multi-homed hosts, where each interface has a unique name (#928) (bugzilla.mindrot.org bug numbers are in brackets) There are no code changes since the previous release. As usual, the code is available from http://www.sxw.org.uk/computing/patches/openssh.html I'm also interesting in hearing from people who might be interested in testing some new cascading credentials delegation code. When you renew your Kerberos credentials on the client, this code will automatically propagate these renewed credentials to the server, allowing the seamless renewal of credentials across ssh sessions distributed across many different machines. If you have an interest in testing this code in a non-production environment, please let me know! Cheers, Simon. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFG/CG9qWndc26pXmcRAikbAKDLw84hjqy2Z4dF6/H4ZmK6/gY4XwCffEWm FQleDwIuPJI8sJQ/I9SSRDo= =RJHh -----END PGP SIGNATURE----- From mocleiri at jpint.utoronto.ca Sat Sep 29 00:36:32 2007 From: mocleiri at jpint.utoronto.ca (Michael O'Cleirigh) Date: Fri, 28 Sep 2007 10:36:32 -0400 Subject: Q: how to restrict access selectively to client initiated local port forward In-Reply-To: <46FC00A4.5060608@psc.edu> References: <46FBE4F8.5020507@jpint.utoronto.ca> <20070927174357.9543.qmail@cdy.org> <46FC00A4.5060608@psc.edu> Message-ID: <46FD1170.10307@jpint.utoronto.ca> Hello, First, thanks for all the feedback to my question. >> Then you should run OpenVPN over TCP on port 22 or whatever you're >> using for SSH that can be reached from clients, on another public IP >> address and be done. >> > > This is likely the correct solution. > I hadn't done this because the OpenVPN Documentation recommends not tunneling TCP/IP through TCP/IP but I see know that thats exactly what ssh is doing anyways. >>> However as far as I can tell there is no way in OpenSSH to define >>> an access control policy for which connecting users are allowed to >>> redirect through which local IP. >>> >> Right, because there's no way for OpenSSH to implement it anyway. >> > > You are right in that it can't be done in the base OpenSSH code. > However, I know it can be done with patches to OpenSSH because we > actually implemented it. We even had it so that one user wouldn't be > able bogart well known ports. So it can be done. Its just not easy and > probably not worth the hassle in this instance. I finally figured out how to modify the OpenSSH source to hook in my module. Here are some of the details for the benefit of the people searching the list archives in the future: Our module reads a custom passwd file that contains: 1. username 2. password 3. list of common names they are allowed to connect to (in our setup all common names have a client configuration directory file; the module will parse this file to extract the IP that is allowed to accessed by that common_name). We have an OpenVPN authentication plugin and a PAM module that also use the same core module authenticating our users for this proxy. For OpenSSH the modification is to change how the channels.c:channel_connect_to(...) method works from checking the permitted_open array which is setup at startup to checking my configuration files which are changeable at runtime. We modify channels.c:channel_connect_to() as follows: 1. Add a new parameter of type Authctxt* which is passed in from the serverloop.c as the_authctxt and NULL everywhere else. This holds the username which is what we need for testing the allowability of a given (username, host) tcp forward. 2. The comment 'channel_connect_to' was: /* XXX check permission */ which turned out to indicate the insertion point for my method: _is_tcp_forward_allowed (). 3. Change the names of a few structures in sshconnect2.c which overlap with Authctxt, Authmethod as defined in auth.h (vim global replace is all that is required). This is because channels.h needs to be modified for the channel_connect_to prototype and is used in a wider context. 4. The new method works like: /* Check if connecting to that port is permitted and connect. */ int channel_connect_to(const char *host, u_short port, Authctxt *authctxt) { error ("channel_connect_to: host=%s, port = %d\n", host, port); if (authctxt != NULL) { if (_is_tcp_forward_allowed ("/etc/proxy_passwd", "/etc/openvpn/ccd", authctxt->user, host) == 0) { logit("Proxy Extension: Port forwarding NOT permitted (user=%s, host=%s).", authctxt->user, host); return -1; } else { /* fall through to initiate the request */ logit("Proxy Extension: Port forwarding IS permitted (user=%s, host=%s).", authctxt->user, host); } } return connect_to(host, port); } Thanks again, Mike From Jefferson.Ogata at noaa.gov Sat Sep 29 05:10:29 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Fri, 28 Sep 2007 19:10:29 +0000 Subject: Q: how to restrict access selectively to client initiated local port forward In-Reply-To: <46FD1170.10307@jpint.utoronto.ca> References: <46FBE4F8.5020507@jpint.utoronto.ca> <20070927174357.9543.qmail@cdy.org> <46FC00A4.5060608@psc.edu> <46FD1170.10307@jpint.utoronto.ca> Message-ID: <46FD51A5.7060008@noaa.gov> On 09/28/07 14:36, Michael O'Cleirigh wrote: > I hadn't done this because the OpenVPN Documentation recommends not > tunneling TCP/IP through TCP/IP but I see know that thats exactly what > ssh is doing anyways. I don't think that's in the same sense as warned about by OpenVPN docs. Issues occur when two TCP stacks process a packet, e.g. when a source system creates a TCP packet which is then transmitted in its entirety over a TCP-based tunnel. If a packet is lost in the tunnel, both the system managing the tunnel and the system which generated the original packet will retransmit. This is not an issue with native SSH tunnels since these are tunneling payloads after TCP decapsulation, not entire TCP-encapsulated packets. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From imorgan at nas.nasa.gov Sat Sep 29 07:02:12 2007 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 28 Sep 2007 14:02:12 -0700 Subject: Whatever happened to bz#983? Message-ID: <20070928210212.GA6063@linux55.nas.nasa.gov> Hello all, Some time ago there seemed to be progress on the RequiredAuthentication patch that would allow sshd to require that multiple authentication methods be successful in order to grant access to a system. [1] That patch was used as a poster-child for the Match keyword that was subsequently added. Unfortunately, it looks like development on this feature has stalled. Are there plans to revive this feature enhancement or was there insufficient feedback from the community to warrant the effort? Just curious. It looked like an interesting feature that could be useful in some environments. Thanks -- Iain Morgan [1] https://bugzilla.mindrot.org/show_bug.cgi?id=983 From openssh at roumenpetrov.info Sat Sep 29 06:01:28 2007 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Fri, 28 Sep 2007 23:01:28 +0300 Subject: GSSAPI Key Exchange Patch for OpenSSH 4.7p1 In-Reply-To: <0DC5C238-7F48-41F5-A0DB-DEF62E0698D8@inf.ed.ac.uk> References: <0DC5C238-7F48-41F5-A0DB-DEF62E0698D8@inf.ed.ac.uk> Message-ID: <46FD5D98.5090308@roumenpetrov.info> Simon Wilkinson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I'm pleased to (finally) announce the availability of my GSSAPI Key > Exchange patch for OpenSSH 4.7p1. Whilst OpenSSH contains support for > doing GSSAPI user authentication, this only allows the underlying > security mechanism to authenticate the user to the server, and > continues to use SSH host keys to authenticate the server to the > user. O-o-o-ops , I'm not familiar with GSS-API but partially support is not a option for an open-source product. [SNIP] Roumen -- Get X.509 certificates support in OpenSSH: http://roumenpetrov.info/openssh/ From deengert at anl.gov Sat Sep 29 07:26:14 2007 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 28 Sep 2007 16:26:14 -0500 Subject: GSSAPI Key Exchange Patch for OpenSSH 4.7p1 In-Reply-To: <0DC5C238-7F48-41F5-A0DB-DEF62E0698D8@inf.ed.ac.uk> References: <0DC5C238-7F48-41F5-A0DB-DEF62E0698D8@inf.ed.ac.uk> Message-ID: <46FD7176.3020108@anl.gov> Sounds interesting. And yes, I would be interested in the cascading credentials delegation code. Does the delegation code depend on the key exchange code? What would it take to get both of these in to PuTTY? Simon Wilkinson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I'm pleased to (finally) announce the availability of my GSSAPI Key > Exchange patch for OpenSSH 4.7p1. Whilst OpenSSH contains support for > doing GSSAPI user authentication, this only allows the underlying > security mechanism to authenticate the user to the server, and > continues to use SSH host keys to authenticate the server to the > user. For many sites who already have security infrastructures such > as Kerberos deployed, managing large numbers of SSH host keys is an > additional, unneccessary, burden. GSSAPI key exchange allows the use > of security mechanisms such as Kerberos to authenticate the server to > the user, removing the need for trusted ssh host keys, and allowing > the use of a single security architecture. > > This patch adds support for the RFC4462 GSSAPI key exchange > mechanisms to OpenSSH, along with adding some additional features to > the GSSAPI code that is already in the tree. > > The patch implements: > *) gss-group1-sha1-*, gss-group14-sha1-* and gss-gex-sha1-* key > exchange mechanisms. (#1242) > *) Support for the null host key type (#1242) > *) Support for CCAPI credentials caches on Mac OS X (#1245) > *) Support for better error handling when an authentication > exchange fails due to server misconfiguration (#1244) > *) Support for GSSAPI connections to hosts behind a round-robin > load balancer (#1008) > *) Support for GSSAPI connections to multi-homed hosts, where each > interface has a unique name (#928) > > (bugzilla.mindrot.org bug numbers are in brackets) > > There are no code changes since the previous release. > > As usual, the code is available from > http://www.sxw.org.uk/computing/patches/openssh.html > > I'm also interesting in hearing from people who might be interested > in testing some new cascading credentials delegation code. When you > renew your Kerberos credentials on the client, this code will > automatically propagate these renewed credentials to the server, > allowing the seamless renewal of credentials across ssh sessions > distributed across many different machines. If you have an interest > in testing this code in a non-production environment, please let me > know! > > Cheers, > > Simon. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > > iD8DBQFG/CG9qWndc26pXmcRAikbAKDLw84hjqy2Z4dF6/H4ZmK6/gY4XwCffEWm > FQleDwIuPJI8sJQ/I9SSRDo= > =RJHh > -----END PGP SIGNATURE----- > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From alon.barlev at gmail.com Sat Sep 29 18:08:23 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 29 Sep 2007 11:08:23 +0300 Subject: OpenSSH PKCS#11merge In-Reply-To: <200709250733.47491.alon.barlev@gmail.com> References: <200709250733.47491.alon.barlev@gmail.com> Message-ID: <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> Hello OpenSSH developers, Please response, a reject is also a valid response... For the last year or so, I did not received any formal response. Please note that, for example, redhat[1] is patching OpenSSH with nss to work with PKCS#11, which is a *HUGE* overhead/overcomplex. This is required functionality and having each distribution introduce its own solution is not good solution for the end users. Best Regards, Alon Bar-Lev. [1] https://bugzilla.redhat.com/show_bug.cgi?id=186469 On 9/25/07, Alon Bar-Lev wrote: > > [[Sending again, as for some strange reason it is not accepted]] > > Hello OpenSSH developers, > > I maintain external patch for PKCS#11 smartcard support into > OpenSSH[1] , many users already apply and use this patch. > > I wish to know if anyone is interesting in working toward merging this > into mainline. > > I had some discussion with Damien Miller, but then he disappeared. > > Having standard smartcard interface will enable many users to have > more secure environment, without the need to acquire card of specific > vendor. > > In order to merge it cleanly, we should also discuss a modification > for the agent protocol. As smartcards are dynamic in nature, there > should be an option for the agent to ask the caller to provide > information, for example "Insert token " or "Please enter > passphrase for token ". Current implementation does not modify > the agent protocol but execute dialog from within the agent. > > Best Regards, > Alon Bar-Lev > > [1] http://alon.barlev.googlepages.com/openssh-pkcs11 > From djm at mindrot.org Sat Sep 29 19:48:49 2007 From: djm at mindrot.org (Damien Miller) Date: Sat, 29 Sep 2007 19:48:49 +1000 (EST) Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> Message-ID: On Sat, 29 Sep 2007, Alon Bar-Lev wrote: > Hello OpenSSH developers, > > Please response, a reject is also a valid response... > For the last year or so, I did not received any formal response. Speaking for myself: I won't have time or hardware to review or merge this patch for the forseeable future. Perhaps one of the other developers might, but I don't know if anyone has the hardware necessary to test it properly either. I'd suggest that you put the patch, or a link to it in an enhancement bug in bugzilla. -d From alon.barlev at gmail.com Sat Sep 29 23:36:28 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 29 Sep 2007 15:36:28 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> Message-ID: <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> On 9/29/07, Damien Miller wrote: > Speaking for myself: I won't have time or hardware to review or merge > this patch for the forseeable future. Perhaps one of the other > developers might, but I don't know if anyone has the hardware necessary > to test it properly either. Thank you for the reply! Just interested... Do you use any hardware in order to secure your keys? If you do which types do you use? Maybe some of the hardware do support PKCS#11. I believe that security product without decent hardware cryptography support miss some of its major targets. I will be glad to work with you in order to make this happen. > I'd suggest that you put the patch, or a link to it in an enhancement > bug in bugzilla. Done: https://bugzilla.mindrot.org/show_bug.cgi?id=1371 Best Regards, Alon Bar-Lev. From stuge-openssh-unix-dev at cdy.org Sat Sep 29 23:43:48 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 29 Sep 2007 15:43:48 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> Message-ID: <20070929134348.4885.qmail@cdy.org> On Sat, Sep 29, 2007 at 07:48:49PM +1000, Damien Miller wrote: > Speaking for myself: I won't have time or hardware to review or > merge this patch for the forseeable future. Perhaps one of the > other developers might, but I don't know if anyone has the hardware > necessary to test it properly either. I have some cards and readers and can help test. //Peter From stuge-openssh-unix-dev at cdy.org Sun Sep 30 00:26:28 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 29 Sep 2007 16:26:28 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> Message-ID: <20070929142628.13104.qmail@cdy.org> Some comments from a quick read of the patch. I did not look at what the code does in great detail. On Sat, Sep 29, 2007 at 03:36:28PM +0200, Alon Bar-Lev wrote: > https://bugzilla.mindrot.org/show_bug.cgi?id=1371 * Upstream I don't know what OpenBSD thinks about PKCS#11 but unless they fiercely reject it, I think the patch should be worked into the OpenBSD version of OpenSSH first, instead of the portable tree. * X.509 I agree with your reasoning that PKCS#11 goes well with X.509. However, since the X.509 patch is not included in OpenSSH, I don't think there should be anything X.509-related in the p11 patch. --8<-- config.h.in +/* Define if you want to use X509 with PKCS11 */ +#undef ENABLE_PKCS11_X509 -->8-- I think this and everything else about X.509 should go into Roumen's X.509 patch instead. * Related changes --8<-- pkcs11.c + * WARNING!!! + * There is no way to get log level, + * so set to minimum. + * After fix in log.c it can be fixed. -->8-- What fix is needed in log.c? Maybe you already have a patch? --8<-- ssh-add.c + * TEMP TEMP TEMP TEMP + * + * This should be fixed if another mechanism + * will be propsed. -->8-- I for one would like to avoid temporary solutions that are known to be incorrect but work well enough. You mentioned extending the agent protocol. Can you expand on that a little? Is it really neccessary? Can't the agent figure out when it needs help from the user just from how it is being used without actually being instructed by anyone? If, in your opinion, the p11 patch can do everything that the current OpenSC support can, I think the current code should be removed and replaced with a compatibility layer that uses p11 to do what direct OpenSC use does now, and maybe even removed completely some time long in the future. * Coding style The patch doesn't follow the OpenSSH coding style. pkcs11_show_ids() is pretty crazy. * Copyright > + * The ssh_from_x509 is dirived of Tatu and Markus work. Please put all copyright notices in a file at the top of the file. * do_pkcs11() Implementing a (file-)local getopt_long() surely can't be a good idea? //Peter From alon.barlev at gmail.com Sun Sep 30 04:09:38 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 29 Sep 2007 20:09:38 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <20070929142628.13104.qmail@cdy.org> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> Message-ID: <200709292009.39873.alon.barlev@gmail.com> On 9/29/07, Peter Stuge wrote: > Some comments from a quick read of the patch. I did not look at what > the code does in great detail. Thank you so much for your time! > * Upstream > > I don't know what OpenBSD thinks about PKCS#11 but unless they > fiercely reject it, I think the patch should be worked into the > OpenBSD version of OpenSSH first, instead of the portable tree. Oh... I will be glad to do so, but I don't have a test environment for this... I don't think I've done anything that prevent it to work with the OpenBSD version... :) If this is a requirement to proceed I will setup my first OpenBSD machine :) > * X.509 > > I agree with your reasoning that PKCS#11 goes well with X.509. > > However, since the X.509 patch is not included in OpenSSH, I don't > think there should be anything X.509-related in the p11 patch. > I think this and everything else about X.509 should go into Roumen's > X.509 patch instead. I agree. I've talked to Roumen in the past regarding this, if PKCS#11 support is merged then the X.509 patch will enable PKCS#11 X.509 features. But as long as this is an external patch, it is comfortable to users to have this packaged this way. But regardless the above, a self-signed X.509 certificate is needed in the public area of the token, in order to extract the public key. This is required as many providers stores only X.509 certificate and private key objects. > * Related changes > > --8<-- pkcs11.c > + * WARNING!!! > + * There is no way to get log level, > + * so set to minimum. > + * After fix in log.c it can be fixed. > -->8-- > > What fix is needed in log.c? Maybe you already have a patch? Oh... Simple... Just to be able to return current log level... :) Just return log_level from log.c, something like: LogLevel get_log_level () { return log_level; } > --8<-- ssh-add.c > + * TEMP TEMP TEMP TEMP > + * > + * This should be fixed if another mechanism > + * will be propsed. > -->8-- > > I for one would like to avoid temporary solutions that are known to > be incorrect but work well enough. You mentioned extending the agent > protocol. Can you expand on that a little? Is it really neccessary? > Can't the agent figure out when it needs help from the user just from > how it is being used without actually being instructed by anyone? This is the major change all smartcard components requires, there are some opened issues in bugzilla regarding this. Smartcards are dynamic in nature unlike file based keys, smartcards can be removed and inserted by the users, also the session between the application and the smartcard is sometime time limited. When smartcards are also used in order to open the door for your office, it tends to become even more dynamic. There are two kinds of user prompts that an smartcard enabled application needs to have: 1. Token prompt - When key should be used but the hardware device is not available the application should prompt the user to insert his token. This is very important when re-negotiation is performed, as users don't expect session disconnect because their token is not available. 2. Passphrase prompt - Private key is used first time on session, may be triggered when: a. A new session is created. b. Card was removed and inserted, this actually forces application to create a new session. c. Provider forces session duration timeout, this also forces application to create a new session. Because I did not wanted to touch more than I needed, I currently implemented these callbacks using external program the ssh-agent execute when needed. But a much cleaner solution would be modifying the ssh-agent protocol so that it inform the forground application to perform the prompt. So basically SSH2_AGENTC_SIGN_REQUEST and SSH_AGENTC_PKCS11_ADD_ID may return an error with indication that a user interactive prompt is needed with the details for the prompt (for example a string and type of required prompt), so that application may handle the user interaction. There should be added some more command, such as introduce key passphrase and optionally wait for token. > If, in your opinion, the p11 patch can do everything that the current > OpenSC support can, I think the current code should be removed and > replaced with a compatibility layer that uses p11 to do what direct > OpenSC use does now, and maybe even removed completely some time long > in the future. Yes, it does anything and much more, many OpenSC users already using this patch as it support dynamic smartcard availability and adding identities into the agent without card available. I think OpenSSH should support only PKCS#11 for hardware cryptography, making the code much cleaner. I suggested this in the past but it was rejected by some OpenSC users, as I only updated the agent, while current OpenSC support does not require agent configuration. I have implemented agent only configuration to minimize my modification, but if we proceed in merging I will add this support. One thing we need to discuss is if we add all keys (as in OpenSC case) or only user requested ones. I don't like adding all keys... :) BTW: I don't understood why ssh does not execute ssh-agent internally if one is not available... GnuPG does this and it seems to minimize code duplication... > * Coding style > > The patch doesn't follow the OpenSSH coding style. pkcs11_show_ids() > is pretty crazy. Is there any document I can read? I will convert it to whatever style needed. The pkcs11_show_ids is crazy as we need to discuss where you want to put this one... It can be exported to a standalone executable... Or stay within this one... Also we should discuss the output format that looks right for you... > * Copyright > > > + * The ssh_from_x509 is dirived of Tatu and Markus work. > > Please put all copyright notices in a file at the top of the file. Will do. > * do_pkcs11() > > Implementing a (file-)local getopt_long() surely can't be a good > idea? I don't follow you... Can you please explain... In the past I asked to allocate some BSD style short option letters for this one... :) But I think most options should go into configuration file, but the ssh-agent does not currently have configuration file, so in order to minimize my changes I've added these long options. Maybe we can make ssh-agent read the ssh_config and take some options from there? The ssh-add will only requires --pkcs11-add-id, --pkcs11-remove-id and optionally --pkcs11-show-ids. Thanks for quick reviewing, Alon Bar-Lev. From alon.barlev at gmail.com Sun Sep 30 02:38:57 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 29 Sep 2007 18:38:57 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <20070929142628.13104.qmail@cdy.org> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> Message-ID: <9e0cf0bf0709290938m407f95f0g52665f1cc2d29c3f@mail.gmail.com> On 9/29/07, Peter Stuge wrote: > Some comments from a quick read of the patch. I did not look at what > the code does in great detail. Thank you so much for your time! > * Upstream > > I don't know what OpenBSD thinks about PKCS#11 but unless they > fiercely reject it, I think the patch should be worked into the > OpenBSD version of OpenSSH first, instead of the portable tree. Oh... I will be glad to do so, but I don't have a test environment for this... I don't think I've done anything that prevent it to work with the OpenBSD version... :) If this is a requirement to proceed I will setup my first OpenBSD machine :) > * X.509 > > I agree with your reasoning that PKCS#11 goes well with X.509. > > However, since the X.509 patch is not included in OpenSSH, I don't > think there should be anything X.509-related in the p11 patch. > I think this and everything else about X.509 should go into Roumen's > X.509 patch instead. I agree. I've talked to Roumen in the past regarding this, if PKCS#11 support is merged then the X.509 patch will enable PKCS#11 X.509 features. But as long as this is an external patch, it is comfortable to users to have this packaged this way. But regardless the above, a self-signed X.509 certificate is needed in the public area of the token, in order to extract the public key. This is required as many providers stores only X.509 certificate and private key objects. > * Related changes > > --8<-- pkcs11.c > + * WARNING!!! > + * There is no way to get log level, > + * so set to minimum. > + * After fix in log.c it can be fixed. > -->8-- > > What fix is needed in log.c? Maybe you already have a patch? Oh... Simple... Just to be able to return current log level... :) Just return log_level from log.c, something like: LogLevel get_log_level () { return log_level; } > --8<-- ssh-add.c > + * TEMP TEMP TEMP TEMP > + * > + * This should be fixed if another mechanism > + * will be propsed. > -->8-- > > I for one would like to avoid temporary solutions that are known to > be incorrect but work well enough. You mentioned extending the agent > protocol. Can you expand on that a little? Is it really neccessary? > Can't the agent figure out when it needs help from the user just from > how it is being used without actually being instructed by anyone? This is the major change all smartcard components requires, there are some opened issues in bugzilla regarding this. Smartcards are dynamic in nature unlike file based keys, smartcards can be removed and inserted by the users, also the session between the application and the smartcard is sometime time limited. When smartcards are also used in order to open the door for your office, it tends to become even more dynamic. There are two kinds of user prompts that an smartcard enabled application needs to have: 1. Token prompt - When key should be used but the hardware device is not available the application should prompt the user to insert his token. This is very important when re-negotiation is performed, as users don't expect session disconnect because their token is not available. 2. Passphrase prompt - Private key is used first time on session, may be triggered when: a. A new session is created. b. Card was removed and inserted, this actually forces application to create a new session. c. Provider forces session duration timeout, this also forces application to create a new session. Because I did not wanted to touch more than I needed, I currently implemented these callbacks using external program the ssh-agent execute when needed. But a much cleaner solution would be modifying the ssh-agent protocol so that it inform the forground application to perform the prompt. So basically SSH2_AGENTC_SIGN_REQUEST and SSH_AGENTC_PKCS11_ADD_ID may return an error with indication that a user interactive prompt is needed with the details for the prompt (for example a string and type of required prompt), so that application may handle the user interaction. There should be added some more command, such as introduce key passphrase and optionally wait for token. > If, in your opinion, the p11 patch can do everything that the current > OpenSC support can, I think the current code should be removed and > replaced with a compatibility layer that uses p11 to do what direct > OpenSC use does now, and maybe even removed completely some time long > in the future. Yes, it does anything and much more, many OpenSC users already using this patch as it support dynamic smartcard availability and adding identities into the agent without card available. I think OpenSSH should support only PKCS#11 for hardware cryptography, making the code much cleaner. I suggested this in the past but it was rejected by some OpenSC users, as I only updated the agent, while current OpenSC support does not require agent configuration. I have implemented agent only configuration to minimize my modification, but if we proceed in merging I will add this support. One thing we need to discuss is if we add all keys (as in OpenSC case) or only user requested ones. I don't like adding all keys... :) BTW: I don't understood why ssh does not execute ssh-agent internally if one is not available... GnuPG does this and it seems to minimize code duplication... > * Coding style > > The patch doesn't follow the OpenSSH coding style. pkcs11_show_ids() > is pretty crazy. Is there any document I can read? I will convert it to whatever style needed. The pkcs11_show_ids is crazy as we need to discuss where you want to put this one... It can be exported to a standalone executable... Or stay within this one... Also we should discuss the output format that looks right for you... > * Copyright > > > + * The ssh_from_x509 is dirived of Tatu and Markus work. > > Please put all copyright notices in a file at the top of the file. Will do. > * do_pkcs11() > > Implementing a (file-)local getopt_long() surely can't be a good > idea? I don't follow you... Can you please explain... In the past I asked to allocate some BSD style short option letters for this one... :) But I think most options should go into configuration file, but the ssh-agent does not currently have configuration file, so in order to minimize my changes I've added these long options. Maybe we can make ssh-agent read the ssh_config and take some options from there? The ssh-add will only requires --pkcs11-add-id, --pkcs11-remove-id and optionally --pkcs11-show-ids. Thanks for quick reviewing, Alon Bar-Lev. From thmo-13 at gmx.de Sun Sep 30 19:50:06 2007 From: thmo-13 at gmx.de (ThMO) Date: Sun, 30 Sep 2007 11:50:06 +0200 Subject: openssh v4.7p1: References: <45322194.1B9F836F@gmx.de> <20061016095012.GA3330@gate.dtucker.net> Message-ID: <46FF714E.53EB346D@gmx.de> Hello Darren and others, I've appended a small, unified diff fixing a compilation problem under Linux v2.0.35 using libc v5.4.46: ? atomicio.c: ins't present, but is available. THX for listening. CU Tom. (Thomas M.Ott) Germany -------------- next part -------------- --- openssh-4.7p1/atomicio.c.orig 2007-06-25 14:15:12.000000000 +0200 +++ openssh-4.7p1/atomicio.c 2007-09-30 11:23:01.000000000 +0200 @@ -34,6 +34,8 @@ #include #ifdef HAVE_POLL_H #include +#elif defined( __linux__) +#include #endif #include #include