From dtucker at zip.com.au Sat Apr 1 00:48:08 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 01 Apr 2006 00:48:08 +1100 Subject: Portable OpenSSH anoncvs Message-ID: <442D3318.70905@zip.com.au> Hi all. The OpenSSH Portable anoncvs service has found a temporary home (mine :-). It's on a DSL link so please be nice to it. It may move in future so please use the "anoncvs.mindrot.org" alias. $ cvs -z5 -d anoncvs at anoncvs.mindrot.org:/cvs co openssh_cvs The key fingerprints are: RSA 8e:09:e9:fb:dc:af:e4:a5:e6:a0:e2:28:59:63:84:17 DSA 3e:38:50:b8:d7:b7:dc:bc:13:c4:d8:76:c8:31:e3:44 RSA v1 78:27:3c:67:3b:b9:59:96:f3:5d:45:52:0d:4d:be:8b -- 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 Apr 1 00:56:32 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 01 Apr 2006 00:56:32 +1100 Subject: Portable OpenSSH anoncvs In-Reply-To: <442D3318.70905@zip.com.au> References: <442D3318.70905@zip.com.au> Message-ID: <442D3510.2000406@zip.com.au> Darren Tucker wrote: > Hi all. > > The OpenSSH Portable anoncvs service has found a temporary home (mine :-). > > It's on a DSL link so please be nice to it. It may move in future so > please use the "anoncvs.mindrot.org" alias. > > $ cvs -z5 -d anoncvs at anoncvs.mindrot.org:/cvs co openssh_cvs > > The key fingerprints are: > RSA 8e:09:e9:fb:dc:af:e4:a5:e6:a0:e2:28:59:63:84:17 > DSA 3e:38:50:b8:d7:b7:dc:bc:13:c4:d8:76:c8:31:e3:44 > RSA v1 78:27:3c:67:3b:b9:59:96:f3:5d:45:52:0d:4d:be:8b Oh yeah, one other thing: ssh only (ports 22 and 2022), no pserver so don't forget to set CVS_RSH=ssh. -- 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 mouring at eviladmin.org Sat Apr 1 17:32:48 2006 From: mouring at eviladmin.org (Ben Lindstrom) Date: Sat, 1 Apr 2006 00:32:48 -0600 (CST) Subject: sftp tab completion patch (First release - NOT FOR INCLUDING YET) Message-ID: This applies to the OpenBSD --current tree. Don't see why it shouldn't work under portable. Within the patch are the updates I need to make before I'll actually submit it for real, but I figured I'd make a public drop. Since I'm not on this list anymore keep me in the CC: if you want me to respond. I'll continue to work as time permits, but it would be nice if people who want this in step up and give feedback. - Ben Index: sftp.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp.c,v retrieving revision 1.80 diff -u -r1.80 sftp.c --- sftp.c 27 Mar 2006 23:15:46 -0000 1.80 +++ sftp.c 31 Mar 2006 23:31:13 -0000 @@ -64,6 +64,9 @@ int remote_glob(struct sftp_conn *, const char *, int, int (*)(const char *, int), glob_t *); /* proto for sftp-glob.c */ +/* sftp connection structure */ +struct sftp_conn *conn; + /* Separators for interactive commands */ #define WHITESPACE " \t\r\n" @@ -108,42 +111,49 @@ struct CMD { const char *c; const int n; + const int t; }; +/* Type of completion */ +#define NOARGS 0 +#define REMOTE 1 +#define LOCAL 2 + + static const struct CMD cmds[] = { - { "bye", I_QUIT }, - { "cd", I_CHDIR }, - { "chdir", I_CHDIR }, - { "chgrp", I_CHGRP }, - { "chmod", I_CHMOD }, - { "chown", I_CHOWN }, - { "dir", I_LS }, - { "exit", I_QUIT }, - { "get", I_GET }, - { "mget", I_GET }, - { "help", I_HELP }, - { "lcd", I_LCHDIR }, - { "lchdir", I_LCHDIR }, - { "lls", I_LLS }, - { "lmkdir", I_LMKDIR }, - { "ln", I_SYMLINK }, - { "lpwd", I_LPWD }, - { "ls", I_LS }, - { "lumask", I_LUMASK }, - { "mkdir", I_MKDIR }, - { "progress", I_PROGRESS }, - { "put", I_PUT }, - { "mput", I_PUT }, - { "pwd", I_PWD }, - { "quit", I_QUIT }, - { "rename", I_RENAME }, - { "rm", I_RM }, - { "rmdir", I_RMDIR }, - { "symlink", I_SYMLINK }, - { "version", I_VERSION }, - { "!", I_SHELL }, - { "?", I_HELP }, - { NULL, -1} + { "bye", I_QUIT, NOARGS }, + { "cd", I_CHDIR, REMOTE }, + { "chdir", I_CHDIR, REMOTE }, + { "chgrp", I_CHGRP, REMOTE }, + { "chmod", I_CHMOD, REMOTE }, + { "chown", I_CHOWN, REMOTE }, + { "dir", I_LS, REMOTE }, + { "exit", I_QUIT, NOARGS }, + { "get", I_GET, REMOTE }, + { "mget", I_GET, REMOTE }, + { "help", I_HELP, NOARGS }, + { "lcd", I_LCHDIR, LOCAL }, + { "lchdir", I_LCHDIR, LOCAL }, + { "lls", I_LLS, LOCAL }, + { "lmkdir", I_LMKDIR, LOCAL }, + { "ln", I_SYMLINK, REMOTE }, + { "lpwd", I_LPWD, LOCAL }, + { "ls", I_LS, REMOTE }, + { "lumask", I_LUMASK, NOARGS }, + { "mkdir", I_MKDIR, REMOTE }, + { "progress", I_PROGRESS, NOARGS }, + { "put", I_PUT, LOCAL }, + { "mput", I_PUT, LOCAL }, + { "pwd", I_PWD, REMOTE }, + { "quit", I_QUIT, NOARGS }, + { "rename", I_RENAME, REMOTE }, + { "rm", I_RM, REMOTE }, + { "rmdir", I_RMDIR, REMOTE }, + { "symlink", I_SYMLINK, REMOTE }, + { "version", I_VERSION, NOARGS }, + { "!", I_SHELL, NOARGS }, + { "?", I_HELP, NOARGS }, + { NULL, -1, -1} }; int interactive_loop(int fd_in, int fd_out, char *file1, char *file2); @@ -1231,13 +1241,194 @@ return ("sftp> "); } +/* + * Before Asking to be included: + * XXX Support Quoting in file completion + * XXX Fix MAXARG to be more dynamic + * XXX Better column display of multi-matches + * XXX Kill the need for MAXLIST limit [if I don't will be yelled at?] + * XXX Side by side comparision of ftp and tweak the code to better mimicing + * XXX Ask for $50 per user of this patch so I can give up my day job + * XXX Ask for Nate's (from undeadly.org fourm) head for making me "rue the day" + * XXX Wait for Theo to rip me a new one due to the code below + * XXX Sit on the patch for another year and rewrite using libunedit 2.0 + */ +char * +complete_ambiguous(char *word, char **list, size_t count) +{ + if (count > 1) { + char *match = list[0]; + size_t y, matchlen = strlen(match); + + printf("\n"); + printf("%s\t", list[0]); + for (y = 1; list[y]; y++) { + int x; + + printf("%s\t", list[y]); + for (x = 0; x < matchlen; x++) + if (match[x] != list[y][x]) + break; + + matchlen = x; + } + printf("\n"); + if (matchlen > strlen(word)) { + char *tmp = xstrdup(list[0]); + + tmp[matchlen] = NULL; + return (tmp); + } + } else + return (xstrdup(list[0])); + + return (NULL); +} + + +int +complete_cmd_parse(EditLine *el, char *cmd) +{ + int y, count = 0; + #define MAXLIST 20 + char *list[MAXLIST], *tmp; + int cmdlen = strlen(cmd); + + for (y = 0; cmds[y].c; y++) { + if (!strncasecmp(cmd, cmds[y].c, cmdlen)) { + list[count++] = xstrdup(cmds[y].c); + if (count >= MAXLIST) + fatal("Exceeded MAXLIST."); + } + list[count] = NULL; + } + + if (count > 0) { + tmp = complete_ambiguous(cmd, list, count); + for (y = 1; list[y]; y++) + xfree(list[y]); + + if (tmp != NULL && strlen(tmp) > strlen(cmd)) { + if (el_insertstr(el, tmp + strlen(cmd)) == -1) + fatal("el_insertstr failed."); + xfree(tmp); + } + } + + return (count); +} + +int +complete_is_remote(char *cmd) { + int i; + + for (i = 0; cmds[i].c; i++) { + size_t cmdlen = strlen(cmds[i].c); + + if (!strncasecmp(cmd, cmds[i].c, cmdlen)) + return cmds[i].t; + } + + return (-1); +} + +int +complete_match(EditLine *el, char *file, int remote) +{ + glob_t g; + size_t len = strlen(file) + 2; + char *tmp = xmalloc(len); + + memset(&g, 0, sizeof(g)); + snprintf(tmp, len, "%s*", file); + if (remote == LOCAL) + glob(tmp, GLOB_DOOFFS, NULL, &g); + else + remote_glob(conn, tmp, 0, NULL, &g); + + xfree(tmp); + + if (g.gl_matchc == 0) + return (0); + + tmp = complete_ambiguous(file, g.gl_pathv, g.gl_matchc); + globfree(&g); + if (tmp != NULL && strlen(tmp) > strlen(file)) { + if (el_insertstr(el, tmp + strlen(file)) == -1) + fatal("el_insertstr failed."); + xfree(tmp); + } + return (g.gl_matchc); +} + +unsigned char +complete(EditLine *el, int ch) +{ + const LineInfo *lf; + size_t len, pos; + char *line; + int argc = 0, ap_loc = 0, ap_cur = 0; + #define MAXARG 99 + char **ap, *argv[MAXARG]; + + ch = ch; /* not used */ + lf = el_line(el); + len = lf->lastchar - lf->buffer + 1; + line = (char *)malloc(len); + strlcpy(line, lf->buffer, len); + pos = len - (lf->lastchar - lf->cursor); + + /* build an array of items */ + for (ap = argv; ap < &argv[MAXARG - 1] && + (*ap = strsep(&line, " ")) != NULL; ) { + if (**ap != '\0') { + int ap_new; + + ap_new = ap_loc + strlen(*ap); + if (ap_new >= pos && ap_loc <= pos) + ap_cur = argc; + ap_loc = ap_new; + ap++; + argc++; + } + } + *ap = NULL; + + if (argc == 0) + return(CC_ERROR); + + if (pos == len) + ap_cur = argc - 1; + + /* Complete Stuff */ + if (ap_cur == 0) { /* Command Match */ + if (complete_cmd_parse(el, argv[0]) == 0) + return (CC_ERROR); + + return (CC_REDISPLAY); + } else { /* File Matching */ + int remote = complete_is_remote(argv[0]); + + if (remote != 0) { + if (complete_match(el, argv[ap_cur], remote) == 0) + return (CC_ERROR); + + return (CC_REDISPLAY); + } + + return (CC_ERROR); + } + + /* Clean up */ + xfree(line); +} + int interactive_loop(int fd_in, int fd_out, char *file1, char *file2) { char *pwd; char *dir = NULL; char cmd[2048]; - struct sftp_conn *conn; int err, interactive; EditLine *el = NULL; History *hl = NULL; @@ -1257,6 +1448,11 @@ el_set(el, EL_TERMINAL, NULL); el_set(el, EL_SIGNAL, 1); el_source(el, NULL); + + /* Tab Completion */ + el_set(el, EL_ADDFN, "ftp-complete", + "Context senstive argument completion", complete); + el_set(el, EL_BIND, "^I", "ftp-complete", NULL); } conn = do_init(fd_in, fd_out, copy_buffer_len, num_requests); From dtucker at zip.com.au Sat Apr 1 22:19:19 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 1 Apr 2006 21:19:19 +1000 Subject: sshd config parser In-Reply-To: <442A890C.9050003@zip.com.au> References: <442A890C.9050003@zip.com.au> Message-ID: <20060401111919.GA6812@gate.dtucker.net> On Thu, Mar 30, 2006 at 12:18:04AM +1100, Darren Tucker wrote: > For various reasons, we're currently looking at extending (or even > overhauling) the config parser used for sshd_config. > > Right now the syntax I'm looking at is a cumulative "Match" keyword [...] Here's some initial work toward this. At the moment it only supports a couple of existing directives (AllowTcpForwarding, GatewayPorts and AcceptEnv). Example syntax is below (from my test config). It works by breaking the config parsing into two stages: once at startup for the global directives and syntax checking of Match blocks, and once after the connection is established to process the Match blocks. This seems to be consistent with what you would expect although it's not exactly first-match (it's first-match for the global block and first-match for the Match blocks, but a Match block overrides a global setting). Diff is against 4.3p2. There are surely bugs (consider it a working prototype). Feedback welcome. # Example config AllowTcpForwarding yes Match Address 192.168.32.*,127.0.0.1 AllowTcpForwarding no GatewayPorts no Match User bar,baz AllowTcpForwarding yes Match Host t* AllowTcpForwarding yes -- 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. -------------- next part -------------- Index: auth.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth.c,v retrieving revision 1.101 diff -u -p -r1.101 auth.c --- auth.c 31 Aug 2005 16:59:49 -0000 1.101 +++ auth.c 1 Apr 2006 10:52:03 -0000 @@ -587,3 +587,51 @@ fakepw(void) return (&fake); } + +int +cfg_match_line(Authctxt *ctxt, char **condition) +{ + int result = 1; + char *arg, *attrib, *cp = *condition; + const char *remhost; + size_t len; + + if (ctxt == NULL) + debug("checking syntax for 'Match %s'", cp); + else + debug("checking match for '%s'", cp); + + while ((attrib = strdelim(&cp)) && *attrib != '\0') { + if ((arg = strdelim(&cp)) == NULL || *arg == '\0') { + error("Missing Match criteria for %s", attrib); + return -1; + } + len = strlen(arg); + if (strcasecmp(attrib, "user") == 0) { + if (!ctxt) + break; + if (match_pattern_list(ctxt->user, arg, len, 0) != 1) + /* XXX what about negative match? */ + result = 0; + } else if (strcasecmp(attrib, "host") == 0) { + if (!ctxt) + break; + remhost = get_canonical_hostname(options.use_dns); + debug("match remhost %s arg %s", remhost, arg); + if (match_hostname(remhost, arg, len) != 1) + result = 0; + } else if (strcasecmp(attrib, "address") == 0) { + if (!ctxt) + break; + remhost = get_remote_ipaddr(); + if (match_hostname(remhost, arg, len) != 1) + result = 0; + } else { + error("Unsupported Match attribute %s", attrib); + return -1; + } + } + *condition = cp; + debug("cfg_check_match: returning %d", result); + return result; +} Index: auth.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth.h,v retrieving revision 1.68 diff -u -p -r1.68 auth.h --- auth.h 7 Jul 2005 01:50:20 -0000 1.68 +++ auth.h 1 Apr 2006 10:41:07 -0000 @@ -185,6 +185,7 @@ void auth_debug_send(void); void auth_debug_reset(void); struct passwd *fakepw(void); +int cfg_match_line(Authctxt *, char **); int sys_auth_passwd(Authctxt *, const char *); Index: auth1.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth1.c,v retrieving revision 1.111 diff -u -p -r1.111 auth1.c --- auth1.c 17 Jul 2005 07:26:44 -0000 1.111 +++ auth1.c 1 Apr 2006 08:40:47 -0000 @@ -385,6 +385,8 @@ do_authentication(Authctxt *authctxt) authctxt->user = user; authctxt->style = style; + parse_server_match_config(&options, authctxt); + /* Verify that the user is a valid user. */ if ((authctxt->pw = PRIVSEP(getpwnamallow(user))) != NULL) authctxt->valid = 1; Index: auth2.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth2.c,v retrieving revision 1.136 diff -u -p -r1.136 auth2.c --- auth2.c 24 Sep 2005 02:43:51 -0000 1.136 +++ auth2.c 1 Apr 2006 08:41:11 -0000 @@ -153,6 +153,7 @@ input_userauth_request(int type, u_int32 /* setup auth context */ authctxt->pw = PRIVSEP(getpwnamallow(user)); authctxt->user = xstrdup(user); + parse_server_match_config(&options, authctxt); if (authctxt->pw && strcmp(service, "ssh-connection")==0) { authctxt->valid = 1; debug2("input_userauth_request: setting up authctxt for %s", user); Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor.c,v retrieving revision 1.88 diff -u -p -r1.88 monitor.c --- monitor.c 5 Nov 2005 04:07:05 -0000 1.88 +++ monitor.c 1 Apr 2006 08:42:01 -0000 @@ -592,6 +592,8 @@ mm_answer_pwnamallow(int sock, Buffer *m buffer_clear(m); + parse_server_match_config(&options, authctxt); + if (pwent == NULL) { buffer_put_char(m, 0); authctxt->pw = fakepw(); Index: servconf.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/servconf.c,v retrieving revision 1.136 diff -u -p -r1.136 servconf.c --- servconf.c 13 Dec 2005 08:33:20 -0000 1.136 +++ servconf.c 1 Apr 2006 10:41:36 -0000 @@ -22,12 +22,15 @@ RCSID("$OpenBSD: servconf.c,v 1.146 2005 #include "cipher.h" #include "kex.h" #include "mac.h" +#include "auth.h" +#include "match.h" static void add_listen_addr(ServerOptions *, char *, u_short); static void add_one_listen_addr(ServerOptions *, char *, u_short); /* Use of privilege separation or not */ extern int use_privsep; +extern Buffer cfg; /* Initializes the server options to their default values. */ @@ -102,9 +105,6 @@ initialize_server_options(ServerOptions options->authorized_keys_file2 = NULL; options->num_accept_env = 0; options->permit_tun = -1; - - /* Needs to be accessable in many places */ - use_privsep = -1; } void @@ -274,6 +274,7 @@ typedef enum { sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, sGssAuthentication, sGssCleanupCreds, sAcceptEnv, sPermitTunnel, + sMatch, sUsePrivilegeSeparation, sDeprecated, sUnsupported } ServerOpCodes; @@ -377,6 +378,7 @@ static struct { { "useprivilegeseparation", sUsePrivilegeSeparation}, { "acceptenv", sAcceptEnv }, { "permittunnel", sPermitTunnel }, + { "match", sMatch }, { NULL, sBadOption } }; @@ -437,12 +439,41 @@ add_one_listen_addr(ServerOptions *optio options->listen_addrs = aitop; } +/* + * The strategy for the Match blocks is that the config file is parsed twice. + * + * The first time is at startup. activep is initialized to 1 and the + * directives in the global context are processed and acted on. Hitting a + * Match directive unsets activep and the directives inside the block are + * checked for syntax only. + * + * The second time is after a connection has been established but before + * authentication. activep is initialized to 0 and global config directives + * are ignored since they have already been processed. If the criteria in a + * Match block is met, activep is set and the subsequent directives + * processed and actioned until EOF or another Match block unsets it. Any + * options set are copied into the main server config. + */ +static int +allowed_in_match(ServerOpCodes code) +{ + switch (code) { + case sAcceptEnv: + case sAllowTcpForwarding: + case sGatewayPorts: + case sMatch: + return 1; + default: + return 0; + } +} + int process_server_config_line(ServerOptions *options, char *line, - const char *filename, int linenum) + const char *filename, int linenum, int *activep, Authctxt *ctxt) { char *cp, **charptr, *arg, *p; - int *intptr, value, n; + int cmdline = 0, *intptr, value, n; ServerOpCodes opcode; u_short port; u_int i; @@ -457,6 +488,24 @@ process_server_config_line(ServerOptions intptr = NULL; charptr = NULL; opcode = parse_token(arg, filename, linenum); + + if (activep == NULL) { + /* We are processing a command line directive */ + cmdline = 1; + activep = &cmdline; + } + if (*activep == 0 && !allowed_in_match(opcode)) { + if (ctxt == NULL) { + fatal("%s line %d: Directive %s is not allowed within " + "a Match block", filename, linenum, arg); + } else { + /* this is a directive we have already processed */ + while (arg) + arg = strdelim(&cp); + return 0; + } + } + switch (opcode) { /* Portable-specific options */ case sUsePAM: @@ -494,7 +543,7 @@ parse_int: fatal("%s line %d: missing integer value.", filename, linenum); value = atoi(arg); - if (*intptr == -1) + if (*activep && *intptr == -1) *intptr = value; break; @@ -625,7 +674,7 @@ parse_flag: else fatal("%s line %d: Bad yes/no argument: %s", filename, linenum, arg); - if (*intptr == -1) + if (*activep && *intptr == -1) *intptr = value; break; @@ -961,6 +1010,8 @@ parse_flag: if (options->num_accept_env >= MAX_ACCEPT_ENV) fatal("%s line %d: too many allow env.", filename, linenum); + if (!activep) + break; options->accept_env[options->num_accept_env++] = xstrdup(arg); } @@ -988,6 +1039,17 @@ parse_flag: *intptr = value; break; + case sMatch: + if (cmdline) + fatal("Match directive not supported as a command-line " + "option"); + value = cfg_match_line(ctxt, &cp); + if (value < 0) + fatal("%s line %d: Bad Match condition", filename, + linenum); + *activep = value; + break; + case sDeprecated: logit("%s line %d: Deprecated option %s", filename, linenum, arg); @@ -1044,18 +1106,45 @@ load_server_config(const char *filename, } void -parse_server_config(ServerOptions *options, const char *filename, Buffer *conf) +parse_server_match_config(ServerOptions *options, Authctxt *ctxt) { - int linenum, bad_options = 0; + u_int i; + ServerOptions mo; + + initialize_server_options(&mo); + parse_server_config(&mo, "reprocess config", &cfg, ctxt); + + /* now copy any (supported) values set */ + if (mo.allow_tcp_forwarding != -1) + options->allow_tcp_forwarding = mo.allow_tcp_forwarding; + if (mo.gateway_ports != -1) + options->gateway_ports = mo.gateway_ports; + if (mo.num_accept_env > 0) { + for (i = 0; i < mo.num_accept_env; i++) { + if (options->num_accept_env >= MAX_ACCEPT_ENV) + fatal("Too many allow env in Match block."); + options->accept_env[options->num_accept_env++] = + mo.accept_env[i]; + } + } +} + +void +parse_server_config(ServerOptions *options, const char *filename, Buffer *conf, + Authctxt *ctxt) +{ + int active, linenum, bad_options = 0; char *cp, *obuf, *cbuf; debug2("%s: config %s len %d", __func__, filename, buffer_len(conf)); obuf = cbuf = xstrdup(buffer_ptr(conf)); + + active = ctxt ? 0 : 1; linenum = 1; while ((cp = strsep(&cbuf, "\n")) != NULL) { if (process_server_config_line(options, cp, filename, - linenum++) != 0) + linenum++, &active, ctxt) != 0) bad_options++; } xfree(obuf); Index: servconf.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/servconf.h,v retrieving revision 1.64 diff -u -p -r1.64 servconf.h --- servconf.h 13 Dec 2005 08:29:03 -0000 1.64 +++ servconf.h 1 Apr 2006 09:23:25 -0000 @@ -17,6 +17,7 @@ #define SERVCONF_H #include "buffer.h" +#include "auth.h" #define MAX_PORTS 256 /* Max # ports. */ @@ -141,8 +142,11 @@ typedef struct { void initialize_server_options(ServerOptions *); void fill_default_server_options(ServerOptions *); -int process_server_config_line(ServerOptions *, char *, const char *, int); +int process_server_config_line(ServerOptions *, char *, const char *, int, + int *, Authctxt *); void load_server_config(const char *, Buffer *); -void parse_server_config(ServerOptions *, const char *, Buffer *); +void parse_server_config(ServerOptions *, const char *, Buffer *, + Authctxt *); +void parse_server_match_config(ServerOptions *, Authctxt *); #endif /* SERVCONF_H */ Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v retrieving revision 1.320 diff -u -p -r1.320 sshd.c --- sshd.c 24 Dec 2005 03:59:12 -0000 1.320 +++ sshd.c 1 Apr 2006 09:45:57 -0000 @@ -201,12 +201,15 @@ int *startup_pipes = NULL; int startup_pipe; /* in child */ /* variables used for privilege separation */ -int use_privsep; +int use_privsep = -1; /* Needs to be accessable in many places */ struct monitor *pmonitor = NULL; /* global authentication context */ Authctxt *the_authctxt = NULL; +/* sshd_config buffer */ +Buffer cfg; + /* message to be displayed after login */ Buffer loginmsg; @@ -892,7 +895,6 @@ main(int ac, char **av) Key *key; Authctxt *authctxt; int ret, key_used = 0; - Buffer cfg; #ifdef HAVE_SECUREWARE (void)set_auth_parameters(ac, av); @@ -1011,7 +1013,7 @@ main(int ac, char **av) case 'o': line = xstrdup(optarg); if (process_server_config_line(&options, line, - "command-line", 0) != 0) + "command-line", 0, NULL, NULL) != 0) exit(1); xfree(line); break; @@ -1070,10 +1072,7 @@ main(int ac, char **av) load_server_config(config_file_name, &cfg); parse_server_config(&options, - rexeced_flag ? "rexec" : config_file_name, &cfg); - - if (!rexec_flag) - buffer_free(&cfg); + rexeced_flag ? "rexec" : config_file_name, &cfg, NULL); seed_rng(); From senthilkumar_sen at hotpop.com Sat Apr 1 22:53:01 2006 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Sat, 1 Apr 2006 17:23:01 +0530 Subject: sshd config parser References: <442A890C.9050003@zip.com.au> Message-ID: <153901c65583$1ae686f0$220110ac@sekco> Hi Darren, This is what I need. I have filed an enhancement request for this at http://bugzilla.mindrot.org/show_bug.cgi?id=1169 I would prefer to extend the current Host directive for this purpose. Cheers, Senthil Kumar. ----- Original Message ----- From: "Darren Tucker" To: "OpenSSH Devel List" Sent: Wednesday, March 29, 2006 6:48 PM Subject: sshd config parser > Hi All. > > For various reasons, we're currently looking at extending (or even > overhauling) the config parser used for sshd_config. > > Right now the syntax I'm looking at is a cumulative "Match" keyword that > matches when all of the specified criteria are met. This would be > similar the the Host directive used in ssh_config, although it's still > limiting (eg you can't easily nest directives). > > "Match" would be first-match, same as ssh_config. (I think this is > simpler for both implementation and configuration, but needs more > careful planning of the directives). > > This would be especially useful with the RequiredAuthentications patch > in bugzilla, eg: > > # allow anyone to authenticate normally from the local net > Match Address 192.168.0.0/24 > RequiredAuthentications default > > # allow admins from the dmz with pubkey and password > Match Group admins Address 1.2.3.0/24 > RequiredAuthentications publickey,password > > # deny untrusted and local users from any other net > Match Group untrusted,lusers > RequiredAuthentications deny > > # anyone else gets normal behaviour > Match all > RequiredAuthentications default > > There's also some potential for other things too: > > Match User anoncvs > PermitTcpForwarding no > > Match Group nosftp > Subsystem sftp /bin/false > > Anyway, some food for thought. > > -- > 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. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Sat Apr 1 23:02:49 2006 From: djm at mindrot.org (Damien Miller) Date: Sat, 1 Apr 2006 23:02:49 +1100 (EST) Subject: sshd config parser In-Reply-To: <153901c65583$1ae686f0$220110ac@sekco> References: <442A890C.9050003@zip.com.au> <153901c65583$1ae686f0$220110ac@sekco> Message-ID: On Sat, 1 Apr 2006, Senthil Kumar wrote: > Hi Darren, > > This is what I need. I have filed an enhancement request for this at > http://bugzilla.mindrot.org/show_bug.cgi?id=1169 > > I would prefer to extend the current Host directive for this purpose. You realise that Darren is taling about *sshd_config* and not *ssh_config* as in your bug. Changing ssh_config to support network addresses is difficult because a Host declaration can change the actual destination host using the Hostname command. Also, a host may have multiple addresses - which one should be used? Therefore making Host support subnets means possibly three passes over the config file - what happens when options collide between a "Host name" and a "Host addr" block? It is far more tricky than it looks... -d From dtucker at zip.com.au Sun Apr 2 00:10:24 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 1 Apr 2006 23:10:24 +1000 Subject: sshd config parser In-Reply-To: <20060401111919.GA6812@gate.dtucker.net> References: <442A890C.9050003@zip.com.au> <20060401111919.GA6812@gate.dtucker.net> Message-ID: <20060401131024.GA8769@gate.dtucker.net> On Sat, Apr 01, 2006 at 09:19:19PM +1000, Darren Tucker wrote: > On Thu, Mar 30, 2006 at 12:18:04AM +1100, Darren Tucker wrote: > Here's some initial work toward this. At the moment it only supports > a couple of existing directives (AllowTcpForwarding, GatewayPorts and > AcceptEnv). Example syntax is below (from my test config). Here's some more work toward this. It now supports multiple criteria per "Match" line (in theory it did before but it didn't, well, work :-) The tokens that it supports inside a match block are the directives corresponding to these: use_pam num_accept_env allow_tcp_forwarding banner password_authentication challenge_response_authentication client_alive_count_max client_alive_interval gateway_ports gss_authentication hostbased_authentication kerberos_authentication kerberos_or_local_passwd kerberos_ticket_cleanup kerberos_get_afs_token login_grace_time log_level max_authtries permit_tun pubkey_authentication rsa_authentication strict_modes use_login x11_forwarding x11_use_localhost > Diff is against 4.3p2. There are surely bugs (consider it a working > prototype). Feedback welcome. Same still applies. -- 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. -------------- next part -------------- Index: auth.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth.c,v retrieving revision 1.101 diff -u -p -r1.101 auth.c --- auth.c 31 Aug 2005 16:59:49 -0000 1.101 +++ auth.c 1 Apr 2006 11:36:30 -0000 @@ -587,3 +587,51 @@ fakepw(void) return (&fake); } + +int +cfg_match_line(Authctxt *ctxt, char **condition) +{ + int result = 1; + char *arg, *attrib, *cp = *condition; + const char *remhost; + size_t len; + + if (ctxt == NULL) + debug("checking syntax for 'Match %s'", cp); + else + debug("checking match for '%s'", cp); + + while ((attrib = strdelim(&cp)) && *attrib != '\0') { + if ((arg = strdelim(&cp)) == NULL || *arg == '\0') { + error("Missing Match criteria for %s", attrib); + return -1; + } + len = strlen(arg); + if (strcasecmp(attrib, "user") == 0) { + if (!ctxt) + continue; + if (match_pattern_list(ctxt->user, arg, len, 0) != 1) + /* XXX what about negative match? */ + result = 0; + } else if (strcasecmp(attrib, "host") == 0) { + if (!ctxt) + continue; + remhost = get_canonical_hostname(options.use_dns); + debug("match remhost %s arg %s", remhost, arg); + if (match_hostname(remhost, arg, len) != 1) + result = 0; + } else if (strcasecmp(attrib, "address") == 0) { + if (!ctxt) + continue; + remhost = get_remote_ipaddr(); + if (match_hostname(remhost, arg, len) != 1) + result = 0; + } else { + error("Unsupported Match attribute %s", attrib); + return -1; + } + } + *condition = cp; + debug("cfg_check_match: returning %d", result); + return result; +} Index: auth.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth.h,v retrieving revision 1.68 diff -u -p -r1.68 auth.h --- auth.h 7 Jul 2005 01:50:20 -0000 1.68 +++ auth.h 1 Apr 2006 10:41:07 -0000 @@ -185,6 +185,7 @@ void auth_debug_send(void); void auth_debug_reset(void); struct passwd *fakepw(void); +int cfg_match_line(Authctxt *, char **); int sys_auth_passwd(Authctxt *, const char *); Index: auth1.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth1.c,v retrieving revision 1.111 diff -u -p -r1.111 auth1.c --- auth1.c 17 Jul 2005 07:26:44 -0000 1.111 +++ auth1.c 1 Apr 2006 08:40:47 -0000 @@ -385,6 +385,8 @@ do_authentication(Authctxt *authctxt) authctxt->user = user; authctxt->style = style; + parse_server_match_config(&options, authctxt); + /* Verify that the user is a valid user. */ if ((authctxt->pw = PRIVSEP(getpwnamallow(user))) != NULL) authctxt->valid = 1; Index: auth2.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth2.c,v retrieving revision 1.136 diff -u -p -r1.136 auth2.c --- auth2.c 24 Sep 2005 02:43:51 -0000 1.136 +++ auth2.c 1 Apr 2006 08:41:11 -0000 @@ -153,6 +153,7 @@ input_userauth_request(int type, u_int32 /* setup auth context */ authctxt->pw = PRIVSEP(getpwnamallow(user)); authctxt->user = xstrdup(user); + parse_server_match_config(&options, authctxt); if (authctxt->pw && strcmp(service, "ssh-connection")==0) { authctxt->valid = 1; debug2("input_userauth_request: setting up authctxt for %s", user); Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor.c,v retrieving revision 1.88 diff -u -p -r1.88 monitor.c --- monitor.c 5 Nov 2005 04:07:05 -0000 1.88 +++ monitor.c 1 Apr 2006 08:42:01 -0000 @@ -592,6 +592,8 @@ mm_answer_pwnamallow(int sock, Buffer *m buffer_clear(m); + parse_server_match_config(&options, authctxt); + if (pwent == NULL) { buffer_put_char(m, 0); authctxt->pw = fakepw(); Index: servconf.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/servconf.c,v retrieving revision 1.136 diff -u -p -r1.136 servconf.c --- servconf.c 13 Dec 2005 08:33:20 -0000 1.136 +++ servconf.c 1 Apr 2006 12:59:39 -0000 @@ -22,12 +22,15 @@ RCSID("$OpenBSD: servconf.c,v 1.146 2005 #include "cipher.h" #include "kex.h" #include "mac.h" +#include "auth.h" +#include "match.h" static void add_listen_addr(ServerOptions *, char *, u_short); static void add_one_listen_addr(ServerOptions *, char *, u_short); /* Use of privilege separation or not */ extern int use_privsep; +extern Buffer cfg; /* Initializes the server options to their default values. */ @@ -102,9 +105,6 @@ initialize_server_options(ServerOptions options->authorized_keys_file2 = NULL; options->num_accept_env = 0; options->permit_tun = -1; - - /* Needs to be accessable in many places */ - use_privsep = -1; } void @@ -274,110 +274,121 @@ typedef enum { sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, sGssAuthentication, sGssCleanupCreds, sAcceptEnv, sPermitTunnel, + sMatch, sUsePrivilegeSeparation, sDeprecated, sUnsupported } ServerOpCodes; +#define SSHCFG_GLOBAL 0x01 +#define SSHCFG_MATCH 0x02 +#define SSHCFG_ALL (SSHCFG_GLOBAL|SSHCFG_MATCH) + /* Textual representation of the tokens. */ static struct { const char *name; ServerOpCodes opcode; + u_int flags; } keywords[] = { /* Portable-specific options */ #ifdef USE_PAM - { "usepam", sUsePAM }, + { "usepam", sUsePAM, SSHCFG_ALL }, #else - { "usepam", sUnsupported }, + { "usepam", sUnsupported, SSHCFG_ALL }, #endif - { "pamauthenticationviakbdint", sDeprecated }, + { "pamauthenticationviakbdint", sDeprecated, SSHCFG_GLOBAL }, /* Standard Options */ - { "port", sPort }, - { "hostkey", sHostKeyFile }, - { "hostdsakey", sHostKeyFile }, /* alias */ - { "pidfile", sPidFile }, - { "serverkeybits", sServerKeyBits }, - { "logingracetime", sLoginGraceTime }, - { "keyregenerationinterval", sKeyRegenerationTime }, - { "permitrootlogin", sPermitRootLogin }, - { "syslogfacility", sLogFacility }, - { "loglevel", sLogLevel }, - { "rhostsauthentication", sDeprecated }, - { "rhostsrsaauthentication", sRhostsRSAAuthentication }, - { "hostbasedauthentication", sHostbasedAuthentication }, - { "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly }, - { "rsaauthentication", sRSAAuthentication }, - { "pubkeyauthentication", sPubkeyAuthentication }, - { "dsaauthentication", sPubkeyAuthentication }, /* alias */ + { "port", sPort, SSHCFG_GLOBAL }, + { "hostkey", sHostKeyFile, SSHCFG_GLOBAL }, + { "hostdsakey", sHostKeyFile, SSHCFG_GLOBAL }, /* alias */ + { "pidfile", sPidFile, SSHCFG_GLOBAL }, + { "serverkeybits", sServerKeyBits, SSHCFG_GLOBAL }, + { "logingracetime", sLoginGraceTime, SSHCFG_ALL }, + { "keyregenerationinterval", sKeyRegenerationTime, SSHCFG_GLOBAL }, + { "permitrootlogin", sPermitRootLogin, SSHCFG_GLOBAL }, + { "syslogfacility", sLogFacility, SSHCFG_GLOBAL }, + { "loglevel", sLogLevel, SSHCFG_ALL }, + { "rhostsauthentication", sDeprecated, SSHCFG_GLOBAL }, + { "rhostsrsaauthentication", sRhostsRSAAuthentication, SSHCFG_ALL }, + { "hostbasedauthentication", sHostbasedAuthentication, SSHCFG_ALL }, + { "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly, + SSHCFG_ALL }, + { "rsaauthentication", sRSAAuthentication, SSHCFG_ALL }, + { "pubkeyauthentication", sPubkeyAuthentication, SSHCFG_ALL }, + { "dsaauthentication", sPubkeyAuthentication, SSHCFG_ALL }, /* alias */ #ifdef KRB5 - { "kerberosauthentication", sKerberosAuthentication }, - { "kerberosorlocalpasswd", sKerberosOrLocalPasswd }, - { "kerberosticketcleanup", sKerberosTicketCleanup }, + { "kerberosauthentication", sKerberosAuthentication, SSHCFG_ALL }, + { "kerberosorlocalpasswd", sKerberosOrLocalPasswd, SSHCFG_ALL }, + { "kerberosticketcleanup", sKerberosTicketCleanup, SSHCFG_ALL }, #ifdef USE_AFS - { "kerberosgetafstoken", sKerberosGetAFSToken }, + { "kerberosgetafstoken", sKerberosGetAFSToken, SSHCFG_ALL }, #else - { "kerberosgetafstoken", sUnsupported }, + { "kerberosgetafstoken", sUnsupported, SSHCFG_ALL }, #endif #else - { "kerberosauthentication", sUnsupported }, - { "kerberosorlocalpasswd", sUnsupported }, - { "kerberosticketcleanup", sUnsupported }, - { "kerberosgetafstoken", sUnsupported }, + { "kerberosauthentication", sUnsupported, SSHCFG_ALL }, + { "kerberosorlocalpasswd", sUnsupported, SSHCFG_ALL }, + { "kerberosticketcleanup", sUnsupported, SSHCFG_ALL }, + { "kerberosgetafstoken", sUnsupported, SSHCFG_ALL }, #endif - { "kerberostgtpassing", sUnsupported }, - { "afstokenpassing", sUnsupported }, + { "kerberostgtpassing", sUnsupported, SSHCFG_ALL }, + { "afstokenpassing", sUnsupported, SSHCFG_ALL }, #ifdef GSSAPI - { "gssapiauthentication", sGssAuthentication }, - { "gssapicleanupcredentials", sGssCleanupCreds }, + { "gssapiauthentication", sGssAuthentication, SSHCFG_ALL }, + { "gssapicleanupcredentials", sGssCleanupCreds, SSHCFG_ALL }, #else - { "gssapiauthentication", sUnsupported }, - { "gssapicleanupcredentials", sUnsupported }, + { "gssapiauthentication", sUnsupported, SSHCFG_ALL }, + { "gssapicleanupcredentials", sUnsupported, SSHCFG_ALL }, #endif - { "passwordauthentication", sPasswordAuthentication }, - { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, - { "challengeresponseauthentication", sChallengeResponseAuthentication }, - { "skeyauthentication", sChallengeResponseAuthentication }, /* alias */ - { "checkmail", sDeprecated }, - { "listenaddress", sListenAddress }, - { "addressfamily", sAddressFamily }, - { "printmotd", sPrintMotd }, - { "printlastlog", sPrintLastLog }, - { "ignorerhosts", sIgnoreRhosts }, - { "ignoreuserknownhosts", sIgnoreUserKnownHosts }, - { "x11forwarding", sX11Forwarding }, - { "x11displayoffset", sX11DisplayOffset }, - { "x11uselocalhost", sX11UseLocalhost }, - { "xauthlocation", sXAuthLocation }, - { "strictmodes", sStrictModes }, - { "permitemptypasswords", sEmptyPasswd }, - { "permituserenvironment", sPermitUserEnvironment }, - { "uselogin", sUseLogin }, - { "compression", sCompression }, - { "tcpkeepalive", sTCPKeepAlive }, - { "keepalive", sTCPKeepAlive }, /* obsolete alias */ - { "allowtcpforwarding", sAllowTcpForwarding }, - { "allowusers", sAllowUsers }, - { "denyusers", sDenyUsers }, - { "allowgroups", sAllowGroups }, - { "denygroups", sDenyGroups }, - { "ciphers", sCiphers }, - { "macs", sMacs }, - { "protocol", sProtocol }, - { "gatewayports", sGatewayPorts }, - { "subsystem", sSubsystem }, - { "maxstartups", sMaxStartups }, - { "maxauthtries", sMaxAuthTries }, - { "banner", sBanner }, - { "usedns", sUseDNS }, - { "verifyreversemapping", sDeprecated }, - { "reversemappingcheck", sDeprecated }, - { "clientaliveinterval", sClientAliveInterval }, - { "clientalivecountmax", sClientAliveCountMax }, - { "authorizedkeysfile", sAuthorizedKeysFile }, - { "authorizedkeysfile2", sAuthorizedKeysFile2 }, - { "useprivilegeseparation", sUsePrivilegeSeparation}, - { "acceptenv", sAcceptEnv }, - { "permittunnel", sPermitTunnel }, - { NULL, sBadOption } + { "passwordauthentication", sPasswordAuthentication, SSHCFG_ALL }, + { "kbdinteractiveauthentication", sKbdInteractiveAuthentication, + SSHCFG_ALL }, + { "challengeresponseauthentication", sChallengeResponseAuthentication, + SSHCFG_ALL }, + { "skeyauthentication", sChallengeResponseAuthentication, + SSHCFG_ALL }, /* alias */ + { "checkmail", sDeprecated, SSHCFG_GLOBAL }, + { "listenaddress", sListenAddress, SSHCFG_GLOBAL }, + { "addressfamily", sAddressFamily, SSHCFG_GLOBAL }, + { "printmotd", sPrintMotd, SSHCFG_ALL }, + { "printlastlog", sPrintLastLog, SSHCFG_ALL }, + { "ignorerhosts", sIgnoreRhosts, SSHCFG_ALL }, + { "ignoreuserknownhosts", sIgnoreUserKnownHosts, SSHCFG_ALL }, + { "x11forwarding", sX11Forwarding, SSHCFG_ALL }, + { "x11displayoffset", sX11DisplayOffset, SSHCFG_GLOBAL }, + { "x11uselocalhost", sX11UseLocalhost, SSHCFG_ALL }, + { "xauthlocation", sXAuthLocation, SSHCFG_ALL }, + { "strictmodes", sStrictModes, SSHCFG_ALL }, + { "permitemptypasswords", sEmptyPasswd, SSHCFG_ALL }, + { "permituserenvironment", sPermitUserEnvironment, SSHCFG_ALL }, + { "uselogin", sUseLogin, SSHCFG_ALL }, + { "compression", sCompression, SSHCFG_GLOBAL }, + { "tcpkeepalive", sTCPKeepAlive, SSHCFG_ALL }, + { "keepalive", sTCPKeepAlive, SSHCFG_ALL }, /* obsolete alias */ + { "allowtcpforwarding", sAllowTcpForwarding, SSHCFG_ALL }, + { "allowusers", sAllowUsers, SSHCFG_GLOBAL }, + { "denyusers", sDenyUsers, SSHCFG_GLOBAL }, + { "allowgroups", sAllowGroups, SSHCFG_GLOBAL }, + { "denygroups", sDenyGroups, SSHCFG_GLOBAL }, + { "ciphers", sCiphers, SSHCFG_GLOBAL }, + { "macs", sMacs, SSHCFG_GLOBAL }, + { "protocol", sProtocol, SSHCFG_GLOBAL }, + { "gatewayports", sGatewayPorts, SSHCFG_ALL }, + { "subsystem", sSubsystem, SSHCFG_GLOBAL }, + { "maxstartups", sMaxStartups, SSHCFG_GLOBAL }, + { "maxauthtries", sMaxAuthTries, SSHCFG_ALL }, + { "banner", sBanner, SSHCFG_ALL }, + { "usedns", sUseDNS, SSHCFG_GLOBAL }, + { "verifyreversemapping", sDeprecated, SSHCFG_GLOBAL }, + { "reversemappingcheck", sDeprecated, SSHCFG_GLOBAL }, + { "clientaliveinterval", sClientAliveInterval, SSHCFG_ALL }, + { "clientalivecountmax", sClientAliveCountMax, SSHCFG_ALL }, + { "authorizedkeysfile", sAuthorizedKeysFile, SSHCFG_GLOBAL }, + { "authorizedkeysfile2", sAuthorizedKeysFile2, SSHCFG_GLOBAL }, + { "useprivilegeseparation", sUsePrivilegeSeparation, SSHCFG_GLOBAL}, + { "acceptenv", sAcceptEnv, SSHCFG_ALL }, + { "permittunnel", sPermitTunnel, SSHCFG_ALL }, + { "match", sMatch, SSHCFG_ALL }, + { NULL, sBadOption, 0 } }; /* @@ -386,13 +397,15 @@ static struct { static ServerOpCodes parse_token(const char *cp, const char *filename, - int linenum) + int linenum, u_int *flags) { u_int i; for (i = 0; keywords[i].name; i++) - if (strcasecmp(cp, keywords[i].name) == 0) + if (strcasecmp(cp, keywords[i].name) == 0) { + *flags = keywords[i].flags; return keywords[i].opcode; + } error("%s: line %d: Bad configuration option: %s", filename, linenum, cp); @@ -437,15 +450,31 @@ add_one_listen_addr(ServerOptions *optio options->listen_addrs = aitop; } +/* + * The strategy for the Match blocks is that the config file is parsed twice. + * + * The first time is at startup. activep is initialized to 1 and the + * directives in the global context are processed and acted on. Hitting a + * Match directive unsets activep and the directives inside the block are + * checked for syntax only. + * + * The second time is after a connection has been established but before + * authentication. activep is initialized to 0 and global config directives + * are ignored since they have already been processed. If the criteria in a + * Match block is met, activep is set and the subsequent directives + * processed and actioned until EOF or another Match block unsets it. Any + * options set are copied into the main server config. + */ + int process_server_config_line(ServerOptions *options, char *line, - const char *filename, int linenum) + const char *filename, int linenum, int *activep, Authctxt *ctxt) { char *cp, **charptr, *arg, *p; - int *intptr, value, n; + int cmdline = 0, *intptr, value, n; ServerOpCodes opcode; u_short port; - u_int i; + u_int i, flags = 0; cp = line; arg = strdelim(&cp); @@ -456,7 +485,25 @@ process_server_config_line(ServerOptions return 0; intptr = NULL; charptr = NULL; - opcode = parse_token(arg, filename, linenum); + opcode = parse_token(arg, filename, linenum, &flags); + + if (activep == NULL) { + /* We are processing a command line directive */ + cmdline = 1; + activep = &cmdline; + } + if (*activep == 0 && !(flags & SSHCFG_MATCH)) { + if (ctxt == NULL) { + fatal("%s line %d: Directive %s is not allowed within " + "a Match block", filename, linenum, arg); + } else { + /* this is a directive we have already processed */ + while (arg) + arg = strdelim(&cp); + return 0; + } + } + switch (opcode) { /* Portable-specific options */ case sUsePAM: @@ -494,7 +541,7 @@ parse_int: fatal("%s line %d: missing integer value.", filename, linenum); value = atoi(arg); - if (*intptr == -1) + if (*activep && *intptr == -1) *intptr = value; break; @@ -574,7 +621,7 @@ parse_filename: if (!arg || *arg == '\0') fatal("%s line %d: missing file name.", filename, linenum); - if (*charptr == NULL) { + if (*activep && *charptr == NULL) { *charptr = tilde_expand_filename(arg, getuid()); /* increase optional counter */ if (intptr != NULL) @@ -625,7 +672,7 @@ parse_flag: else fatal("%s line %d: Bad yes/no argument: %s", filename, linenum, arg); - if (*intptr == -1) + if (*activep && *intptr == -1) *intptr = value; break; @@ -961,6 +1008,8 @@ parse_flag: if (options->num_accept_env >= MAX_ACCEPT_ENV) fatal("%s line %d: too many allow env.", filename, linenum); + if (!activep) + break; options->accept_env[options->num_accept_env++] = xstrdup(arg); } @@ -988,6 +1037,17 @@ parse_flag: *intptr = value; break; + case sMatch: + if (cmdline) + fatal("Match directive not supported as a command-line " + "option"); + value = cfg_match_line(ctxt, &cp); + if (value < 0) + fatal("%s line %d: Bad Match condition", filename, + linenum); + *activep = value; + break; + case sDeprecated: logit("%s line %d: Deprecated option %s", filename, linenum, arg); @@ -1044,18 +1104,93 @@ load_server_config(const char *filename, } void -parse_server_config(ServerOptions *options, const char *filename, Buffer *conf) +parse_server_match_config(ServerOptions *options, Authctxt *ctxt) { - int linenum, bad_options = 0; + u_int i; + ServerOptions mo; + + initialize_server_options(&mo); + parse_server_config(&mo, "reprocess config", &cfg, ctxt); + + /* now copy any (supported) values set */ + if (mo.use_pam != -1) + options->use_pam = mo.use_pam; + if (mo.num_accept_env > 0) { + for (i = 0; i < mo.num_accept_env; i++) { + if (options->num_accept_env >= MAX_ACCEPT_ENV) + fatal("Too many allow env in Match block."); + options->accept_env[options->num_accept_env++] = + mo.accept_env[i]; + } + } + if (mo.allow_tcp_forwarding != -1) + options->allow_tcp_forwarding = mo.allow_tcp_forwarding; + if (mo.banner != NULL) { + if (options->banner != NULL) + xfree(options->banner); + options->banner = mo.banner; + } + if (mo.password_authentication != -1) + options->password_authentication = mo.password_authentication; + if (mo.challenge_response_authentication != -1) + options->challenge_response_authentication = + mo.challenge_response_authentication; + if (mo.client_alive_count_max != -1) + options->client_alive_count_max = mo.client_alive_count_max; + if (mo.client_alive_interval != -1) + options->client_alive_interval = mo.client_alive_interval; + if (mo.gateway_ports != -1) + options->gateway_ports = mo.gateway_ports; + if (mo.gss_authentication != -1) + options->gss_authentication = mo.gss_authentication; + if (mo.hostbased_authentication != -1) + options->hostbased_authentication = mo.hostbased_authentication; + if (mo.kerberos_authentication != -1) + options->kerberos_authentication = mo.kerberos_authentication; + if (mo.kerberos_or_local_passwd != -1) + options->kerberos_or_local_passwd = mo.kerberos_or_local_passwd; + if (mo.kerberos_ticket_cleanup != -1) + options->kerberos_ticket_cleanup = mo.kerberos_ticket_cleanup; + if (mo.kerberos_get_afs_token != -1) + options->kerberos_get_afs_token = mo.kerberos_get_afs_token; + if (mo.login_grace_time != -1) + options->login_grace_time = mo.login_grace_time; + if (mo.log_level != -1) + options->log_level = mo.log_level; + if (mo.max_authtries != -1) + options->max_authtries = mo.max_authtries; + if (mo.permit_tun != -1) + options->permit_tun = mo.permit_tun; + if (mo.pubkey_authentication != -1) + options->pubkey_authentication = mo.pubkey_authentication; + if (mo.rsa_authentication != -1) + options->rsa_authentication = mo.rsa_authentication; + if (mo.strict_modes != -1) + options->strict_modes = mo.strict_modes; + if (mo.use_login != -1) + options->use_login = mo.use_login; + if (mo.x11_forwarding != -1) + options->x11_forwarding = mo.x11_forwarding; + if (mo.x11_use_localhost != -1) + options->x11_use_localhost = mo.x11_use_localhost; +} + +void +parse_server_config(ServerOptions *options, const char *filename, Buffer *conf, + Authctxt *ctxt) +{ + int active, linenum, bad_options = 0; char *cp, *obuf, *cbuf; debug2("%s: config %s len %d", __func__, filename, buffer_len(conf)); obuf = cbuf = xstrdup(buffer_ptr(conf)); + + active = ctxt ? 0 : 1; linenum = 1; while ((cp = strsep(&cbuf, "\n")) != NULL) { if (process_server_config_line(options, cp, filename, - linenum++) != 0) + linenum++, &active, ctxt) != 0) bad_options++; } xfree(obuf); Index: servconf.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/servconf.h,v retrieving revision 1.64 diff -u -p -r1.64 servconf.h --- servconf.h 13 Dec 2005 08:29:03 -0000 1.64 +++ servconf.h 1 Apr 2006 09:23:25 -0000 @@ -17,6 +17,7 @@ #define SERVCONF_H #include "buffer.h" +#include "auth.h" #define MAX_PORTS 256 /* Max # ports. */ @@ -141,8 +142,11 @@ typedef struct { void initialize_server_options(ServerOptions *); void fill_default_server_options(ServerOptions *); -int process_server_config_line(ServerOptions *, char *, const char *, int); +int process_server_config_line(ServerOptions *, char *, const char *, int, + int *, Authctxt *); void load_server_config(const char *, Buffer *); -void parse_server_config(ServerOptions *, const char *, Buffer *); +void parse_server_config(ServerOptions *, const char *, Buffer *, + Authctxt *); +void parse_server_match_config(ServerOptions *, Authctxt *); #endif /* SERVCONF_H */ Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v retrieving revision 1.320 diff -u -p -r1.320 sshd.c --- sshd.c 24 Dec 2005 03:59:12 -0000 1.320 +++ sshd.c 1 Apr 2006 09:45:57 -0000 @@ -201,12 +201,15 @@ int *startup_pipes = NULL; int startup_pipe; /* in child */ /* variables used for privilege separation */ -int use_privsep; +int use_privsep = -1; /* Needs to be accessable in many places */ struct monitor *pmonitor = NULL; /* global authentication context */ Authctxt *the_authctxt = NULL; +/* sshd_config buffer */ +Buffer cfg; + /* message to be displayed after login */ Buffer loginmsg; @@ -892,7 +895,6 @@ main(int ac, char **av) Key *key; Authctxt *authctxt; int ret, key_used = 0; - Buffer cfg; #ifdef HAVE_SECUREWARE (void)set_auth_parameters(ac, av); @@ -1011,7 +1013,7 @@ main(int ac, char **av) case 'o': line = xstrdup(optarg); if (process_server_config_line(&options, line, - "command-line", 0) != 0) + "command-line", 0, NULL, NULL) != 0) exit(1); xfree(line); break; @@ -1070,10 +1072,7 @@ main(int ac, char **av) load_server_config(config_file_name, &cfg); parse_server_config(&options, - rexeced_flag ? "rexec" : config_file_name, &cfg); - - if (!rexec_flag) - buffer_free(&cfg); + rexeced_flag ? "rexec" : config_file_name, &cfg, NULL); seed_rng(); From kop at meme.com Sun Apr 2 04:58:44 2006 From: kop at meme.com (Karl O. Pinc) Date: Sat, 01 Apr 2006 18:58:44 +0000 Subject: sshd config parser Message-ID: <1143917924l.4560l.2l@mofo> I had thoughts on this functionality/syntax some time ago. At the time it seemed to me that the best approach, syntax wise, is the one that bind 9 uses for for views. http://www.bind9.net/manual/bind/9.3.0/Bv9ARM.ch06.html#view_statement_grammar view view_name [class] { match-clients { address_match_list } ; match-destinations { address_match_list } ; match-recursive-only yes_or_no ; [ view_option; ...] [ zone_statement; ...] }; Frankly, the brackets rock when it comes to readability, for one thing they allow various matches to apply to blocks of statements. You could even allow nesting if you liked. You still need semantics, first match, etc. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein From dtucker at zip.com.au Sun Apr 2 12:43:30 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 2 Apr 2006 12:43:30 +1000 Subject: sshd config parser In-Reply-To: <20060401131024.GA8769@gate.dtucker.net> References: <442A890C.9050003@zip.com.au> <20060401111919.GA6812@gate.dtucker.net> <20060401131024.GA8769@gate.dtucker.net> Message-ID: <20060402024330.GA11219@gate.dtucker.net> Hi All. Here's an updated patch. It's not actually as big as it looks as nearly half of it as adding a flag to the keyword struct and large comment. The supported Match directives are User, Group, Host and Address. The directives supported inside a Match block are: UsePAM, LoginGraceTime, PermitRootLogin, LogFacility, LogLevel, RhostsRSAAuthentication, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, RSAAuthentication, PubkeyAuthentication, PubkeyAuthentication, KerberosAuthentication, KerberosOrLocalPasswd, KerberosTicketCleanup, KerberosGetAFSToken, GssAuthentication, GssCleanupCreds, PasswordAuthentication, KbdInteractiveAuthentication, ChallengeResponseAuthentication, ChallengeResponseAuthentication, PrintMotd, PrintLastLog, IgnoreRhosts, IgnoreUserKnownHosts, X11Forwarding, X11DisplayOffset, X11UseLocalhost, XAuthLocation, StrictModes, PermitEmptyPasswd, PermitUserEnvironment, UseLogin, AllowTcpForwarding, GatewayPorts, MaxAuthTries, Banner, ClientAliveInterval, ClientAliveCountMax, AuthorizedKeysFile, AuthorizedKeysFile2, AcceptEnv, PermitTunnel (not all of those are tested, though) It seems to have some decent potential: # Password is OK from the local net but not from the Net PasswordAuthentication no Match 192.168.0.* PasswordAuthentication yes # Only trusted users can use forwarding AllowTcpForwarding no Match Group fwd AllowTcpForwarding yes GatewayPorts clientspecified -- 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. -------------- next part -------------- Index: auth.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth.c,v retrieving revision 1.101 diff -u -p -r1.101 auth.c --- auth.c 31 Aug 2005 16:59:49 -0000 1.101 +++ auth.c 2 Apr 2006 02:23:02 -0000 @@ -492,6 +492,9 @@ getpwnamallow(const char *user) #endif struct passwd *pw; + parse_server_match_config(&options, user, + get_canonical_hostname(options.use_dns), get_remote_ipaddr()); + pw = getpwnam(user); if (pw == NULL) { logit("Invalid user %.100s from %.100s", Index: match.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/match.c,v retrieving revision 1.19 diff -u -p -r1.19 match.c --- match.c 17 Jun 2005 02:59:35 -0000 1.19 +++ match.c 2 Apr 2006 02:20:16 -0000 @@ -39,6 +39,10 @@ RCSID("$OpenBSD: match.c,v 1.20 2005/06/ #include "match.h" #include "xmalloc.h" +#include "log.h" +#include "misc.h" +#include "canohost.h" +#include "groupaccess.h" /* * Returns true if the given string matches the pattern (which may contain ? @@ -267,3 +271,89 @@ match_list(const char *client, const cha xfree(s); return NULL; } + +int +match_cfg_line(char **condition, int line, const char *user, const char *host, + const char *address) +{ + int result = 1; + char *arg, *attrib, *cp = *condition, *grplist[1]; + size_t len; + struct passwd *pw; + + if (user == NULL) + debug3("checking syntax for 'Match %s'", cp); + else + debug3("checking match for '%s'", cp); + + while ((attrib = strdelim(&cp)) && *attrib != '\0') { + if ((arg = strdelim(&cp)) == NULL || *arg == '\0') { + error("Missing Match criteria for %s", attrib); + return -1; + } + len = strlen(arg); + if (strcasecmp(attrib, "user") == 0) { + if (!user) { + result = 0; + continue; + } + if (match_pattern_list(user, arg, len, 0) != 1) + /* XXX what about negative match? */ + result = 0; + else + debug("user %.100s matched 'User %.100s' at " + "line %d", user, arg, line); + } else if (strcasecmp(attrib, "group") == 0) { + if (!user) { + result = 0; + continue; + } + grplist[0] = arg; /* XXX split on comma */ + if ((pw = getpwnam(user)) == NULL) { + debug("Can't match group at line %d because " + "user %.100s does not exist", line, user); + result = 0; + } else if (ga_init(pw->pw_name, pw->pw_gid) == 0) { + debug("Can't Match group because user %.100s " + "not in any group at line %d", user, + line); + result = 0; + } else if (ga_match(grplist, 1) != 1) { + debug("User %.100s does not match group " + "%.100s at line %d", user, arg, + line); + result = 0; + } else { + debug("User %.100s matched Group %.100s at " + "line %d", user, arg, line); + } + } else if (strcasecmp(attrib, "host") == 0) { + if (!host) { + result = 0; + continue; + } + if (match_hostname(host, arg, len) != 1) + result = 0; + else + debug("connection from %.100s matched 'Host " + "%.100s' at line %d", host, arg, line); + } else if (strcasecmp(attrib, "address") == 0) { + debug3("%s: address %s", __func__, address); + if (!address) { + result = 0; + continue; + } + if (match_hostname(address, arg, len) != 1) + result = 0; + else + debug("connection from %.100s matched 'Address " + "%.100s' at line %d", address, arg, line); + } else { + error("Unsupported Match attribute %s", attrib); + return -1; + } + } + *condition = cp; + debug3("match_cfg_line: returning %d", result); + return result; +} Index: match.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/match.h,v retrieving revision 1.11 diff -u -p -r1.11 match.h --- match.h 5 Mar 2002 01:42:43 -0000 1.11 +++ match.h 2 Apr 2006 01:27:11 -0000 @@ -20,5 +20,6 @@ int match_hostname(const char *, const int match_host_and_ip(const char *, const char *, const char *); int match_user(const char *, const char *, const char *, const char *); char *match_list(const char *, const char *, u_int *); +int match_cfg_line(char **, int, const char *, const char *, const char *); #endif Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor.c,v retrieving revision 1.88 diff -u -p -r1.88 monitor.c --- monitor.c 5 Nov 2005 04:07:05 -0000 1.88 +++ monitor.c 2 Apr 2006 01:08:28 -0000 @@ -612,6 +612,7 @@ mm_answer_pwnamallow(int sock, Buffer *m #endif buffer_put_cstring(m, pwent->pw_dir); buffer_put_cstring(m, pwent->pw_shell); + buffer_put_string(m, &options, sizeof(options)); out: debug3("%s: sending MONITOR_ANS_PWNAM: %d", __func__, allowed); Index: monitor_wrap.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor_wrap.c,v retrieving revision 1.54 diff -u -p -r1.54 monitor_wrap.c --- monitor_wrap.c 29 Sep 2005 12:01:10 -0000 1.54 +++ monitor_wrap.c 2 Apr 2006 01:45:05 -0000 @@ -196,7 +196,8 @@ mm_getpwnamallow(const char *username) { Buffer m; struct passwd *pw; - u_int pwlen; + u_int len; + void *p; debug3("%s entering", __func__); @@ -212,8 +213,8 @@ mm_getpwnamallow(const char *username) buffer_free(&m); return (NULL); } - pw = buffer_get_string(&m, &pwlen); - if (pwlen != sizeof(struct passwd)) + pw = buffer_get_string(&m, &len); + if (len != sizeof(struct passwd)) fatal("%s: struct passwd size mismatch", __func__); pw->pw_name = buffer_get_string(&m, NULL); pw->pw_passwd = buffer_get_string(&m, NULL); @@ -223,6 +224,10 @@ mm_getpwnamallow(const char *username) #endif pw->pw_dir = buffer_get_string(&m, NULL); pw->pw_shell = buffer_get_string(&m, NULL); + p = buffer_get_string(&m, &len); + if (len != sizeof(options)) + fatal("%s: option block size mismatch", __func__); + memcpy(&options, p, len); buffer_free(&m); return (pw); Index: servconf.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/servconf.c,v retrieving revision 1.136 diff -u -p -r1.136 servconf.c --- servconf.c 13 Dec 2005 08:33:20 -0000 1.136 +++ servconf.c 2 Apr 2006 02:14:03 -0000 @@ -22,12 +22,14 @@ RCSID("$OpenBSD: servconf.c,v 1.146 2005 #include "cipher.h" #include "kex.h" #include "mac.h" +#include "match.h" static void add_listen_addr(ServerOptions *, char *, u_short); static void add_one_listen_addr(ServerOptions *, char *, u_short); /* Use of privilege separation or not */ extern int use_privsep; +extern Buffer cfg; /* Initializes the server options to their default values. */ @@ -102,9 +104,6 @@ initialize_server_options(ServerOptions options->authorized_keys_file2 = NULL; options->num_accept_env = 0; options->permit_tun = -1; - - /* Needs to be accessable in many places */ - use_privsep = -1; } void @@ -274,110 +273,121 @@ typedef enum { sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, sGssAuthentication, sGssCleanupCreds, sAcceptEnv, sPermitTunnel, + sMatch, sUsePrivilegeSeparation, sDeprecated, sUnsupported } ServerOpCodes; +#define SSHCFG_GLOBAL 0x01 +#define SSHCFG_MATCH 0x02 +#define SSHCFG_ALL (SSHCFG_GLOBAL|SSHCFG_MATCH) + /* Textual representation of the tokens. */ static struct { const char *name; ServerOpCodes opcode; + u_int flags; } keywords[] = { /* Portable-specific options */ #ifdef USE_PAM - { "usepam", sUsePAM }, + { "usepam", sUsePAM, SSHCFG_ALL }, #else - { "usepam", sUnsupported }, + { "usepam", sUnsupported, SSHCFG_ALL }, #endif - { "pamauthenticationviakbdint", sDeprecated }, + { "pamauthenticationviakbdint", sDeprecated, SSHCFG_GLOBAL }, /* Standard Options */ - { "port", sPort }, - { "hostkey", sHostKeyFile }, - { "hostdsakey", sHostKeyFile }, /* alias */ - { "pidfile", sPidFile }, - { "serverkeybits", sServerKeyBits }, - { "logingracetime", sLoginGraceTime }, - { "keyregenerationinterval", sKeyRegenerationTime }, - { "permitrootlogin", sPermitRootLogin }, - { "syslogfacility", sLogFacility }, - { "loglevel", sLogLevel }, - { "rhostsauthentication", sDeprecated }, - { "rhostsrsaauthentication", sRhostsRSAAuthentication }, - { "hostbasedauthentication", sHostbasedAuthentication }, - { "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly }, - { "rsaauthentication", sRSAAuthentication }, - { "pubkeyauthentication", sPubkeyAuthentication }, - { "dsaauthentication", sPubkeyAuthentication }, /* alias */ + { "port", sPort, SSHCFG_GLOBAL }, + { "hostkey", sHostKeyFile, SSHCFG_GLOBAL }, + { "hostdsakey", sHostKeyFile, SSHCFG_GLOBAL }, /* alias */ + { "pidfile", sPidFile, SSHCFG_GLOBAL }, + { "serverkeybits", sServerKeyBits, SSHCFG_GLOBAL }, + { "logingracetime", sLoginGraceTime, SSHCFG_ALL }, + { "keyregenerationinterval", sKeyRegenerationTime, SSHCFG_GLOBAL }, + { "permitrootlogin", sPermitRootLogin, SSHCFG_ALL }, + { "syslogfacility", sLogFacility, SSHCFG_ALL }, + { "loglevel", sLogLevel, SSHCFG_ALL }, + { "rhostsauthentication", sDeprecated, SSHCFG_GLOBAL }, + { "rhostsrsaauthentication", sRhostsRSAAuthentication, SSHCFG_ALL }, + { "hostbasedauthentication", sHostbasedAuthentication, SSHCFG_ALL }, + { "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly, + SSHCFG_ALL }, + { "rsaauthentication", sRSAAuthentication, SSHCFG_ALL }, + { "pubkeyauthentication", sPubkeyAuthentication, SSHCFG_ALL }, + { "dsaauthentication", sPubkeyAuthentication, SSHCFG_ALL }, /* alias */ #ifdef KRB5 - { "kerberosauthentication", sKerberosAuthentication }, - { "kerberosorlocalpasswd", sKerberosOrLocalPasswd }, - { "kerberosticketcleanup", sKerberosTicketCleanup }, + { "kerberosauthentication", sKerberosAuthentication, SSHCFG_ALL }, + { "kerberosorlocalpasswd", sKerberosOrLocalPasswd, SSHCFG_ALL }, + { "kerberosticketcleanup", sKerberosTicketCleanup, SSHCFG_ALL }, #ifdef USE_AFS - { "kerberosgetafstoken", sKerberosGetAFSToken }, + { "kerberosgetafstoken", sKerberosGetAFSToken, SSHCFG_ALL }, #else - { "kerberosgetafstoken", sUnsupported }, + { "kerberosgetafstoken", sUnsupported, SSHCFG_ALL }, #endif #else - { "kerberosauthentication", sUnsupported }, - { "kerberosorlocalpasswd", sUnsupported }, - { "kerberosticketcleanup", sUnsupported }, - { "kerberosgetafstoken", sUnsupported }, + { "kerberosauthentication", sUnsupported, SSHCFG_ALL }, + { "kerberosorlocalpasswd", sUnsupported, SSHCFG_ALL }, + { "kerberosticketcleanup", sUnsupported, SSHCFG_ALL }, + { "kerberosgetafstoken", sUnsupported, SSHCFG_ALL }, #endif - { "kerberostgtpassing", sUnsupported }, - { "afstokenpassing", sUnsupported }, + { "kerberostgtpassing", sUnsupported, SSHCFG_ALL }, + { "afstokenpassing", sUnsupported, SSHCFG_ALL }, #ifdef GSSAPI - { "gssapiauthentication", sGssAuthentication }, - { "gssapicleanupcredentials", sGssCleanupCreds }, + { "gssapiauthentication", sGssAuthentication, SSHCFG_ALL }, + { "gssapicleanupcredentials", sGssCleanupCreds, SSHCFG_ALL }, #else - { "gssapiauthentication", sUnsupported }, - { "gssapicleanupcredentials", sUnsupported }, + { "gssapiauthentication", sUnsupported, SSHCFG_ALL }, + { "gssapicleanupcredentials", sUnsupported, SSHCFG_ALL }, #endif - { "passwordauthentication", sPasswordAuthentication }, - { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, - { "challengeresponseauthentication", sChallengeResponseAuthentication }, - { "skeyauthentication", sChallengeResponseAuthentication }, /* alias */ - { "checkmail", sDeprecated }, - { "listenaddress", sListenAddress }, - { "addressfamily", sAddressFamily }, - { "printmotd", sPrintMotd }, - { "printlastlog", sPrintLastLog }, - { "ignorerhosts", sIgnoreRhosts }, - { "ignoreuserknownhosts", sIgnoreUserKnownHosts }, - { "x11forwarding", sX11Forwarding }, - { "x11displayoffset", sX11DisplayOffset }, - { "x11uselocalhost", sX11UseLocalhost }, - { "xauthlocation", sXAuthLocation }, - { "strictmodes", sStrictModes }, - { "permitemptypasswords", sEmptyPasswd }, - { "permituserenvironment", sPermitUserEnvironment }, - { "uselogin", sUseLogin }, - { "compression", sCompression }, - { "tcpkeepalive", sTCPKeepAlive }, - { "keepalive", sTCPKeepAlive }, /* obsolete alias */ - { "allowtcpforwarding", sAllowTcpForwarding }, - { "allowusers", sAllowUsers }, - { "denyusers", sDenyUsers }, - { "allowgroups", sAllowGroups }, - { "denygroups", sDenyGroups }, - { "ciphers", sCiphers }, - { "macs", sMacs }, - { "protocol", sProtocol }, - { "gatewayports", sGatewayPorts }, - { "subsystem", sSubsystem }, - { "maxstartups", sMaxStartups }, - { "maxauthtries", sMaxAuthTries }, - { "banner", sBanner }, - { "usedns", sUseDNS }, - { "verifyreversemapping", sDeprecated }, - { "reversemappingcheck", sDeprecated }, - { "clientaliveinterval", sClientAliveInterval }, - { "clientalivecountmax", sClientAliveCountMax }, - { "authorizedkeysfile", sAuthorizedKeysFile }, - { "authorizedkeysfile2", sAuthorizedKeysFile2 }, - { "useprivilegeseparation", sUsePrivilegeSeparation}, - { "acceptenv", sAcceptEnv }, - { "permittunnel", sPermitTunnel }, - { NULL, sBadOption } + { "passwordauthentication", sPasswordAuthentication, SSHCFG_ALL }, + { "kbdinteractiveauthentication", sKbdInteractiveAuthentication, + SSHCFG_ALL }, + { "challengeresponseauthentication", sChallengeResponseAuthentication, + SSHCFG_ALL }, + { "skeyauthentication", sChallengeResponseAuthentication, + SSHCFG_ALL }, /* alias */ + { "checkmail", sDeprecated, SSHCFG_GLOBAL }, + { "listenaddress", sListenAddress, SSHCFG_GLOBAL }, + { "addressfamily", sAddressFamily, SSHCFG_GLOBAL }, + { "printmotd", sPrintMotd, SSHCFG_ALL }, + { "printlastlog", sPrintLastLog, SSHCFG_ALL }, + { "ignorerhosts", sIgnoreRhosts, SSHCFG_ALL }, + { "ignoreuserknownhosts", sIgnoreUserKnownHosts, SSHCFG_ALL }, + { "x11forwarding", sX11Forwarding, SSHCFG_ALL }, + { "x11displayoffset", sX11DisplayOffset, SSHCFG_ALL }, + { "x11uselocalhost", sX11UseLocalhost, SSHCFG_ALL }, + { "xauthlocation", sXAuthLocation, SSHCFG_ALL }, + { "strictmodes", sStrictModes, SSHCFG_ALL }, + { "permitemptypasswords", sEmptyPasswd, SSHCFG_ALL }, + { "permituserenvironment", sPermitUserEnvironment, SSHCFG_ALL }, + { "uselogin", sUseLogin, SSHCFG_ALL }, + { "compression", sCompression, SSHCFG_GLOBAL }, + { "tcpkeepalive", sTCPKeepAlive, SSHCFG_GLOBAL }, + { "keepalive", sTCPKeepAlive, SSHCFG_GLOBAL }, /* obsolete alias */ + { "allowtcpforwarding", sAllowTcpForwarding, SSHCFG_ALL }, + { "allowusers", sAllowUsers, SSHCFG_GLOBAL }, + { "denyusers", sDenyUsers, SSHCFG_GLOBAL }, + { "allowgroups", sAllowGroups, SSHCFG_GLOBAL }, + { "denygroups", sDenyGroups, SSHCFG_GLOBAL }, + { "ciphers", sCiphers, SSHCFG_GLOBAL }, + { "macs", sMacs, SSHCFG_GLOBAL }, + { "protocol", sProtocol, SSHCFG_GLOBAL }, + { "gatewayports", sGatewayPorts, SSHCFG_ALL }, + { "subsystem", sSubsystem, SSHCFG_GLOBAL }, + { "maxstartups", sMaxStartups, SSHCFG_GLOBAL }, + { "maxauthtries", sMaxAuthTries, SSHCFG_ALL }, + { "banner", sBanner, SSHCFG_ALL }, + { "usedns", sUseDNS, SSHCFG_GLOBAL }, + { "verifyreversemapping", sDeprecated, SSHCFG_GLOBAL }, + { "reversemappingcheck", sDeprecated, SSHCFG_GLOBAL }, + { "clientaliveinterval", sClientAliveInterval, SSHCFG_ALL }, + { "clientalivecountmax", sClientAliveCountMax, SSHCFG_ALL }, + { "authorizedkeysfile", sAuthorizedKeysFile, SSHCFG_ALL }, + { "authorizedkeysfile2", sAuthorizedKeysFile2, SSHCFG_ALL }, + { "useprivilegeseparation", sUsePrivilegeSeparation, SSHCFG_GLOBAL}, + { "acceptenv", sAcceptEnv, SSHCFG_ALL }, + { "permittunnel", sPermitTunnel, SSHCFG_ALL }, + { "match", sMatch, SSHCFG_ALL }, + { NULL, sBadOption, 0 } }; /* @@ -386,13 +396,15 @@ static struct { static ServerOpCodes parse_token(const char *cp, const char *filename, - int linenum) + int linenum, u_int *flags) { u_int i; for (i = 0; keywords[i].name; i++) - if (strcasecmp(cp, keywords[i].name) == 0) + if (strcasecmp(cp, keywords[i].name) == 0) { + *flags = keywords[i].flags; return keywords[i].opcode; + } error("%s: line %d: Bad configuration option: %s", filename, linenum, cp); @@ -437,15 +449,49 @@ add_one_listen_addr(ServerOptions *optio options->listen_addrs = aitop; } +/* + * The strategy for the Match blocks is that the config file is parsed twice. + * + * The first time is at startup. activep is initialized to 1 and the + * directives in the global context are processed and acted on. Hitting a + * Match directive unsets activep and the directives inside the block are + * checked for syntax only. + * + * The second time is after a connection has been established but before + * authentication. activep is initialized to 0 and global config directives + * are ignored since they have already been processed. If the criteria in a + * Match block is met, activep is set and the subsequent directives + * processed and actioned until EOF or another Match block unsets it. Any + * options set are copied into the main server config. + * + * Potential additions/improvements: + * - Add Match support for pre-kex directives, eg Protocol, Ciphers. + * + * - Add a Tag directive (idea from David Leonard) ala pf, eg: + * Match Address 192.168.0.* + * Tag trusted + * Match Group wheel + * Tag trusted + * Match Tag trusted + * AllowTcpForwarding yes + * GatewayPorts clientspecified + * [...] + * + * - Add a PermittedChannelRequests directive + * Match Group shell + * PermittedChannelRequests session,forwarded-tcpip + */ + int process_server_config_line(ServerOptions *options, char *line, - const char *filename, int linenum) + const char *filename, int linenum, int *activep, const char *user, + const char *host, const char *address) { char *cp, **charptr, *arg, *p; - int *intptr, value, n; + int cmdline = 0, *intptr, value, n; ServerOpCodes opcode; u_short port; - u_int i; + u_int i, flags = 0; cp = line; arg = strdelim(&cp); @@ -456,7 +502,26 @@ process_server_config_line(ServerOptions return 0; intptr = NULL; charptr = NULL; - opcode = parse_token(arg, filename, linenum); + opcode = parse_token(arg, filename, linenum, &flags); + + if (activep == NULL) { + /* We are processing a command line directive */ + cmdline = 1; + activep = &cmdline; + } + debug("match: line %s active %d flags %d", line, *activep, flags); + if (*activep == 0 && !(flags & SSHCFG_MATCH)) { + if (user == NULL) { + fatal("%s line %d: Directive '%s' is not allowed " + " within a Match block", filename, linenum, arg); + } else { + /* this is a directive we have already processed */ + while (arg) + arg = strdelim(&cp); + return 0; + } + } + switch (opcode) { /* Portable-specific options */ case sUsePAM: @@ -494,7 +559,7 @@ parse_int: fatal("%s line %d: missing integer value.", filename, linenum); value = atoi(arg); - if (*intptr == -1) + if (*activep && *intptr == -1) *intptr = value; break; @@ -574,7 +639,7 @@ parse_filename: if (!arg || *arg == '\0') fatal("%s line %d: missing file name.", filename, linenum); - if (*charptr == NULL) { + if (*activep && *charptr == NULL) { *charptr = tilde_expand_filename(arg, getuid()); /* increase optional counter */ if (intptr != NULL) @@ -625,7 +690,7 @@ parse_flag: else fatal("%s line %d: Bad yes/no argument: %s", filename, linenum, arg); - if (*intptr == -1) + if (*activep && *intptr == -1) *intptr = value; break; @@ -961,6 +1026,8 @@ parse_flag: if (options->num_accept_env >= MAX_ACCEPT_ENV) fatal("%s line %d: too many allow env.", filename, linenum); + if (!*activep) + break; options->accept_env[options->num_accept_env++] = xstrdup(arg); } @@ -988,6 +1055,17 @@ parse_flag: *intptr = value; break; + case sMatch: + if (cmdline) + fatal("Match directive not supported as a command-line " + "option"); + value = match_cfg_line(&cp, linenum, user, host, address); + if (value < 0) + fatal("%s line %d: Bad Match condition", filename, + linenum); + *activep = value; + break; + case sDeprecated: logit("%s line %d: Deprecated option %s", filename, linenum, arg); @@ -1044,18 +1122,124 @@ load_server_config(const char *filename, } void -parse_server_config(ServerOptions *options, const char *filename, Buffer *conf) +parse_server_match_config(ServerOptions *options, const char *user, + const char *host, const char *address) { - int linenum, bad_options = 0; + u_int i; + ServerOptions mo; + + initialize_server_options(&mo); + parse_server_config(&mo, "reprocess config", &cfg, user, host, address); + + /* now copy any (supported) values set */ + if (mo.use_pam != -1) + options->use_pam = mo.use_pam; + if (mo.num_accept_env > 0) { + for (i = 0; i < mo.num_accept_env; i++) { + if (options->num_accept_env >= MAX_ACCEPT_ENV) + fatal("Too many allow env in Match block."); + options->accept_env[options->num_accept_env++] = + mo.accept_env[i]; + } + } + if (mo.allow_tcp_forwarding != -1) + options->allow_tcp_forwarding = mo.allow_tcp_forwarding; + if (mo.authorized_keys_file != NULL) { + if (options->authorized_keys_file != NULL) + xfree(options->authorized_keys_file); + options->authorized_keys_file = mo.authorized_keys_file; + } + if (mo.authorized_keys_file2 != NULL) { + if (options->authorized_keys_file2 != NULL) + xfree(options->authorized_keys_file2); + options->authorized_keys_file2 = mo.authorized_keys_file2; + } + if (mo.banner != NULL) { + if (options->banner != NULL) + xfree(options->banner); + options->banner = mo.banner; + } + if (mo.password_authentication != -1) + options->password_authentication = mo.password_authentication; + if (mo.challenge_response_authentication != -1) + options->challenge_response_authentication = + mo.challenge_response_authentication; + if (mo.client_alive_count_max != -1) + options->client_alive_count_max = mo.client_alive_count_max; + if (mo.client_alive_interval != -1) + options->client_alive_interval = mo.client_alive_interval; + if (mo.gateway_ports != -1) + options->gateway_ports = mo.gateway_ports; + if (mo.gss_authentication != -1) + options->gss_authentication = mo.gss_authentication; + if (mo.hostbased_authentication != -1) + options->hostbased_authentication = mo.hostbased_authentication; + if (mo.hostbased_uses_name_from_packet_only != -1) + options->hostbased_uses_name_from_packet_only = + mo.hostbased_uses_name_from_packet_only; + if (mo.kerberos_authentication != -1) + options->kerberos_authentication = mo.kerberos_authentication; + if (mo.kerberos_or_local_passwd != -1) + options->kerberos_or_local_passwd = mo.kerberos_or_local_passwd; + if (mo.kerberos_ticket_cleanup != -1) + options->kerberos_ticket_cleanup = mo.kerberos_ticket_cleanup; + if (mo.kerberos_get_afs_token != -1) + options->kerberos_get_afs_token = mo.kerberos_get_afs_token; + if (mo.login_grace_time != -1) + options->login_grace_time = mo.login_grace_time; + if (mo.log_facility != -1) + options->log_facility = mo.log_facility; + if (mo.log_level != -1) + options->log_level = mo.log_level; + if (mo.permit_root_login != -1) + options->permit_root_login = mo.permit_root_login; + if (mo.max_authtries != -1) + options->max_authtries = mo.max_authtries; + if (mo.permit_empty_passwd != -1) + options->permit_empty_passwd = mo.permit_empty_passwd; + if (mo.permit_tun != -1) + options->permit_tun = mo.permit_tun; + if (mo.permit_user_env != -1) + options->permit_user_env = mo.permit_user_env; + if (mo.print_motd != -1) + options->print_motd = mo.print_motd; + if (mo.pubkey_authentication != -1) + options->pubkey_authentication = mo.pubkey_authentication; + if (mo.rsa_authentication != -1) + options->rsa_authentication = mo.rsa_authentication; + if (mo.strict_modes != -1) + options->strict_modes = mo.strict_modes; + if (mo.use_login != -1) + options->use_login = mo.use_login; + if (mo.xauth_location != NULL) { + if (options->xauth_location != NULL) + xfree(options->xauth_location); + options->xauth_location = mo.xauth_location; + } + if (mo.x11_display_offset != -1) + options->x11_display_offset = mo.x11_display_offset; + if (mo.x11_forwarding != -1) + options->x11_forwarding = mo.x11_forwarding; + if (mo.x11_use_localhost != -1) + options->x11_use_localhost = mo.x11_use_localhost; +} + +void +parse_server_config(ServerOptions *options, const char *filename, Buffer *conf, + const char *user, const char *host, const char *address) +{ + int active, linenum, bad_options = 0; char *cp, *obuf, *cbuf; debug2("%s: config %s len %d", __func__, filename, buffer_len(conf)); obuf = cbuf = xstrdup(buffer_ptr(conf)); + + active = user ? 0 : 1; linenum = 1; while ((cp = strsep(&cbuf, "\n")) != NULL) { if (process_server_config_line(options, cp, filename, - linenum++) != 0) + linenum++, &active, user, host, address) != 0) bad_options++; } xfree(obuf); Index: servconf.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/servconf.h,v retrieving revision 1.64 diff -u -p -r1.64 servconf.h --- servconf.h 13 Dec 2005 08:29:03 -0000 1.64 +++ servconf.h 2 Apr 2006 01:36:33 -0000 @@ -141,8 +141,12 @@ typedef struct { void initialize_server_options(ServerOptions *); void fill_default_server_options(ServerOptions *); -int process_server_config_line(ServerOptions *, char *, const char *, int); +int process_server_config_line(ServerOptions *, char *, const char *, int, + int *, const char *, const char *, const char *); void load_server_config(const char *, Buffer *); -void parse_server_config(ServerOptions *, const char *, Buffer *); +void parse_server_config(ServerOptions *, const char *, Buffer *, + const char *, const char *, const char *); +void parse_server_match_config(ServerOptions *, const char *, const char *, + const char *); #endif /* SERVCONF_H */ Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v retrieving revision 1.320 diff -u -p -r1.320 sshd.c --- sshd.c 24 Dec 2005 03:59:12 -0000 1.320 +++ sshd.c 2 Apr 2006 01:37:38 -0000 @@ -201,12 +201,15 @@ int *startup_pipes = NULL; int startup_pipe; /* in child */ /* variables used for privilege separation */ -int use_privsep; +int use_privsep = -1; /* Needs to be accessable in many places */ struct monitor *pmonitor = NULL; /* global authentication context */ Authctxt *the_authctxt = NULL; +/* sshd_config buffer */ +Buffer cfg; + /* message to be displayed after login */ Buffer loginmsg; @@ -892,7 +895,6 @@ main(int ac, char **av) Key *key; Authctxt *authctxt; int ret, key_used = 0; - Buffer cfg; #ifdef HAVE_SECUREWARE (void)set_auth_parameters(ac, av); @@ -1011,7 +1013,7 @@ main(int ac, char **av) case 'o': line = xstrdup(optarg); if (process_server_config_line(&options, line, - "command-line", 0) != 0) + "command-line", 0, NULL, NULL, NULL, NULL) != 0) exit(1); xfree(line); break; @@ -1070,10 +1072,7 @@ main(int ac, char **av) load_server_config(config_file_name, &cfg); parse_server_config(&options, - rexeced_flag ? "rexec" : config_file_name, &cfg); - - if (!rexec_flag) - buffer_free(&cfg); + rexeced_flag ? "rexec" : config_file_name, &cfg, NULL, NULL, NULL); seed_rng(); From dtucker at zip.com.au Mon Apr 3 23:22:41 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 3 Apr 2006 23:22:41 +1000 Subject: sshd config parser In-Reply-To: <20060401131024.GA8769@gate.dtucker.net> References: <442A890C.9050003@zip.com.au> <20060401111919.GA6812@gate.dtucker.net> <20060401131024.GA8769@gate.dtucker.net> Message-ID: <20060403132241.GA13968@gate.dtucker.net> Hi all. New Match patch. Old bugs out, new bugs in :-) Feedback welcome. -- 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. -------------- next part -------------- Index: Makefile.in =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/Makefile.in,v retrieving revision 1.274 diff -u -p -r1.274 Makefile.in --- Makefile.in 1 Jan 2006 08:47:05 -0000 1.274 +++ Makefile.in 2 Apr 2006 10:19:10 -0000 @@ -81,7 +81,7 @@ SSHDOBJS=sshd.o auth-rhosts.o auth-passw auth.o auth1.o auth2.o auth-options.o session.o \ auth-chall.o auth2-chall.o groupaccess.o \ auth-skey.o auth-bsdauth.o auth2-hostbased.o auth2-kbdint.o \ - auth2-none.o auth2-passwd.o auth2-pubkey.o \ + auth2-none.o auth2-passwd.o auth2-pubkey.o cfgmatch.o \ monitor_mm.o monitor.o monitor_wrap.o kexdhs.o kexgexs.o \ auth-krb5.o \ auth2-gss.o gss-serv.o gss-serv-krb5.o \ Index: auth.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth.c,v retrieving revision 1.101 diff -u -p -r1.101 auth.c --- auth.c 31 Aug 2005 16:59:49 -0000 1.101 +++ auth.c 2 Apr 2006 02:23:02 -0000 @@ -492,6 +492,9 @@ getpwnamallow(const char *user) #endif struct passwd *pw; + parse_server_match_config(&options, user, + get_canonical_hostname(options.use_dns), get_remote_ipaddr()); + pw = getpwnam(user); if (pw == NULL) { logit("Invalid user %.100s from %.100s", Index: cfgmatch.c =================================================================== RCS file: cfgmatch.c diff -N cfgmatch.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ cfgmatch.c 3 Apr 2006 10:23:55 -0000 @@ -0,0 +1,116 @@ +/* + * Copyright (c) 2006 Darren Tucker. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "includes.h" + +#include "match.h" +#include "log.h" +#include "misc.h" +#include "canohost.h" +#include "groupaccess.h" + +int +match_cfg_line(char **condition, int line, const char *user, const char *host, + const char *address) +{ + int result = 1; + char *arg, *attrib, *cp = *condition, *grplist[1]; + size_t len; + struct passwd *pw; + + if (user == NULL) + debug3("checking syntax for 'Match %s'", cp); + else + debug3("checking match for '%s'", cp); + + while ((attrib = strdelim(&cp)) && *attrib != '\0') { + if ((arg = strdelim(&cp)) == NULL || *arg == '\0') { + error("Missing Match criteria for %s", attrib); + return -1; + } + len = strlen(arg); + if (strcasecmp(attrib, "user") == 0) { + if (!user) { + result = 0; + continue; + } + if (match_pattern_list(user, arg, len, 0) != 1) + /* XXX what about negative match? */ + result = 0; + else + debug("user %.100s matched 'User %.100s' at " + "line %d", user, arg, line); + } else if (strcasecmp(attrib, "group") == 0) { + if (!user) { + result = 0; + continue; + } + grplist[0] = arg; /* XXX split on comma */ + if ((pw = getpwnam(user)) == NULL) { + debug("Can't match group at line %d because " + "user %.100s does not exist", line, user); + result = 0; + } else if (ga_init(pw->pw_name, pw->pw_gid) == 0) { + debug("Can't Match group because user %.100s " + "not in any group at line %d", user, + line); + result = 0; + } else if (ga_match(grplist, 1) != 1) { + debug("User %.100s does not match group " + "%.100s at line %d", user, arg, + line); + result = 0; + } else { + debug("User %.100s matched Group %.100s at " + "line %d", user, arg, line); + } + } else if (strcasecmp(attrib, "host") == 0) { + if (!host) { + result = 0; + continue; + } + if (match_hostname(host, arg, len) != 1) + result = 0; + else + debug("connection from %.100s matched 'Host " + "%.100s' at line %d", host, arg, line); + } else if (strcasecmp(attrib, "address") == 0) { + if (!address) { + result = 0; + continue; + } + if (match_hostname(address, arg, len) != 1) + result = 0; + else + debug("connection from %.100s matched 'Address " + "%.100s' at line %d", address, arg, line); + } else { + error("Unsupported Match attribute %s", attrib); + return -1; + } + } + *condition = cp; + debug3("match_cfg_line: returning %d", result); + return result; +} Index: match.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/match.h,v retrieving revision 1.11 diff -u -p -r1.11 match.h --- match.h 5 Mar 2002 01:42:43 -0000 1.11 +++ match.h 2 Apr 2006 01:27:11 -0000 @@ -20,5 +20,6 @@ int match_hostname(const char *, const int match_host_and_ip(const char *, const char *, const char *); int match_user(const char *, const char *, const char *, const char *); char *match_list(const char *, const char *, u_int *); +int match_cfg_line(char **, int, const char *, const char *, const char *); #endif Index: monitor.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor.c,v retrieving revision 1.88 diff -u -p -r1.88 monitor.c --- monitor.c 5 Nov 2005 04:07:05 -0000 1.88 +++ monitor.c 2 Apr 2006 01:08:28 -0000 @@ -612,6 +612,7 @@ mm_answer_pwnamallow(int sock, Buffer *m #endif buffer_put_cstring(m, pwent->pw_dir); buffer_put_cstring(m, pwent->pw_shell); + buffer_put_string(m, &options, sizeof(options)); out: debug3("%s: sending MONITOR_ANS_PWNAM: %d", __func__, allowed); Index: monitor_wrap.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/monitor_wrap.c,v retrieving revision 1.54 diff -u -p -r1.54 monitor_wrap.c --- monitor_wrap.c 29 Sep 2005 12:01:10 -0000 1.54 +++ monitor_wrap.c 3 Apr 2006 10:17:00 -0000 @@ -196,7 +196,8 @@ mm_getpwnamallow(const char *username) { Buffer m; struct passwd *pw; - u_int pwlen; + u_int len; + void *p; debug3("%s entering", __func__); @@ -212,8 +213,8 @@ mm_getpwnamallow(const char *username) buffer_free(&m); return (NULL); } - pw = buffer_get_string(&m, &pwlen); - if (pwlen != sizeof(struct passwd)) + pw = buffer_get_string(&m, &len); + if (len != sizeof(struct passwd)) fatal("%s: struct passwd size mismatch", __func__); pw->pw_name = buffer_get_string(&m, NULL); pw->pw_passwd = buffer_get_string(&m, NULL); @@ -223,7 +224,28 @@ mm_getpwnamallow(const char *username) #endif pw->pw_dir = buffer_get_string(&m, NULL); pw->pw_shell = buffer_get_string(&m, NULL); - buffer_free(&m); + p = buffer_get_string(&m, &len); + if (len != sizeof(options)) + fatal("%s: option block size mismatch", __func__); + memcpy(&options, p, len); + buffer_free(&m); + + /* we don't use these options, so zero for safety */ + options.num_ports = 0; + options.ports_from_cmdline = 0; + options.pid_file = NULL; + options.xauth_location = NULL; + options.ciphers = NULL; + options.num_allow_users = 0; + options.num_deny_users = 0; + options.num_allow_groups = 0; + options.num_deny_groups = 0; + options.macs = NULL; + options.num_subsystems = 0; + options.banner = NULL; + options.authorized_keys_file = NULL; + options.authorized_keys_file2 = NULL; + options.num_accept_env = 0; return (pw); } Index: servconf.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/servconf.c,v retrieving revision 1.136 diff -u -p -r1.136 servconf.c --- servconf.c 13 Dec 2005 08:33:20 -0000 1.136 +++ servconf.c 3 Apr 2006 12:14:12 -0000 @@ -22,12 +22,14 @@ RCSID("$OpenBSD: servconf.c,v 1.146 2005 #include "cipher.h" #include "kex.h" #include "mac.h" +#include "match.h" static void add_listen_addr(ServerOptions *, char *, u_short); static void add_one_listen_addr(ServerOptions *, char *, u_short); /* Use of privilege separation or not */ extern int use_privsep; +extern Buffer cfg; /* Initializes the server options to their default values. */ @@ -102,9 +104,6 @@ initialize_server_options(ServerOptions options->authorized_keys_file2 = NULL; options->num_accept_env = 0; options->permit_tun = -1; - - /* Needs to be accessable in many places */ - use_privsep = -1; } void @@ -274,110 +273,117 @@ typedef enum { sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, sGssAuthentication, sGssCleanupCreds, sAcceptEnv, sPermitTunnel, + sMatch, sUsePrivilegeSeparation, sDeprecated, sUnsupported } ServerOpCodes; +#define SSHCFG_GLOBAL 0x01 +#define SSHCFG_MATCH 0x02 +#define SSHCFG_ALL (SSHCFG_GLOBAL|SSHCFG_MATCH) + /* Textual representation of the tokens. */ static struct { const char *name; ServerOpCodes opcode; + u_int flags; } keywords[] = { /* Portable-specific options */ #ifdef USE_PAM - { "usepam", sUsePAM }, + { "usepam", sUsePAM, SSHCFG_ALL }, #else - { "usepam", sUnsupported }, + { "usepam", sUnsupported, SSHCFG_ALL }, #endif - { "pamauthenticationviakbdint", sDeprecated }, + { "pamauthenticationviakbdint", sDeprecated, SSHCFG_GLOBAL }, /* Standard Options */ - { "port", sPort }, - { "hostkey", sHostKeyFile }, - { "hostdsakey", sHostKeyFile }, /* alias */ - { "pidfile", sPidFile }, - { "serverkeybits", sServerKeyBits }, - { "logingracetime", sLoginGraceTime }, - { "keyregenerationinterval", sKeyRegenerationTime }, - { "permitrootlogin", sPermitRootLogin }, - { "syslogfacility", sLogFacility }, - { "loglevel", sLogLevel }, - { "rhostsauthentication", sDeprecated }, - { "rhostsrsaauthentication", sRhostsRSAAuthentication }, - { "hostbasedauthentication", sHostbasedAuthentication }, - { "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly }, - { "rsaauthentication", sRSAAuthentication }, - { "pubkeyauthentication", sPubkeyAuthentication }, - { "dsaauthentication", sPubkeyAuthentication }, /* alias */ + { "port", sPort, SSHCFG_GLOBAL }, + { "hostkey", sHostKeyFile, SSHCFG_GLOBAL }, + { "hostdsakey", sHostKeyFile, SSHCFG_GLOBAL }, /* alias */ + { "pidfile", sPidFile, SSHCFG_GLOBAL }, + { "serverkeybits", sServerKeyBits, SSHCFG_GLOBAL }, + { "logingracetime", sLoginGraceTime, SSHCFG_ALL }, + { "keyregenerationinterval", sKeyRegenerationTime, SSHCFG_GLOBAL }, + { "permitrootlogin", sPermitRootLogin, SSHCFG_ALL }, + { "syslogfacility", sLogFacility, SSHCFG_ALL }, + { "loglevel", sLogLevel, SSHCFG_ALL }, + { "rhostsauthentication", sDeprecated, SSHCFG_GLOBAL }, + { "rhostsrsaauthentication", sRhostsRSAAuthentication, SSHCFG_ALL }, + { "hostbasedauthentication", sHostbasedAuthentication, SSHCFG_ALL }, + { "hostbasedusesnamefrompacketonly", sHostbasedUsesNameFromPacketOnly, SSHCFG_ALL }, + { "rsaauthentication", sRSAAuthentication, SSHCFG_ALL }, + { "pubkeyauthentication", sPubkeyAuthentication, SSHCFG_ALL }, + { "dsaauthentication", sPubkeyAuthentication, SSHCFG_ALL }, /* alias */ #ifdef KRB5 - { "kerberosauthentication", sKerberosAuthentication }, - { "kerberosorlocalpasswd", sKerberosOrLocalPasswd }, - { "kerberosticketcleanup", sKerberosTicketCleanup }, + { "kerberosauthentication", sKerberosAuthentication, SSHCFG_ALL }, + { "kerberosorlocalpasswd", sKerberosOrLocalPasswd, SSHCFG_ALL }, + { "kerberosticketcleanup", sKerberosTicketCleanup, SSHCFG_ALL }, #ifdef USE_AFS - { "kerberosgetafstoken", sKerberosGetAFSToken }, + { "kerberosgetafstoken", sKerberosGetAFSToken, SSHCFG_ALL }, #else - { "kerberosgetafstoken", sUnsupported }, + { "kerberosgetafstoken", sUnsupported, SSHCFG_ALL }, #endif #else - { "kerberosauthentication", sUnsupported }, - { "kerberosorlocalpasswd", sUnsupported }, - { "kerberosticketcleanup", sUnsupported }, - { "kerberosgetafstoken", sUnsupported }, + { "kerberosauthentication", sUnsupported, SSHCFG_ALL }, + { "kerberosorlocalpasswd", sUnsupported, SSHCFG_ALL }, + { "kerberosticketcleanup", sUnsupported, SSHCFG_ALL }, + { "kerberosgetafstoken", sUnsupported, SSHCFG_ALL }, #endif - { "kerberostgtpassing", sUnsupported }, - { "afstokenpassing", sUnsupported }, + { "kerberostgtpassing", sUnsupported, SSHCFG_ALL }, + { "afstokenpassing", sUnsupported, SSHCFG_ALL }, #ifdef GSSAPI - { "gssapiauthentication", sGssAuthentication }, - { "gssapicleanupcredentials", sGssCleanupCreds }, + { "gssapiauthentication", sGssAuthentication, SSHCFG_ALL }, + { "gssapicleanupcredentials", sGssCleanupCreds, SSHCFG_ALL }, #else - { "gssapiauthentication", sUnsupported }, - { "gssapicleanupcredentials", sUnsupported }, + { "gssapiauthentication", sUnsupported, SSHCFG_ALL }, + { "gssapicleanupcredentials", sUnsupported, SSHCFG_ALL }, #endif - { "passwordauthentication", sPasswordAuthentication }, - { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, - { "challengeresponseauthentication", sChallengeResponseAuthentication }, - { "skeyauthentication", sChallengeResponseAuthentication }, /* alias */ - { "checkmail", sDeprecated }, - { "listenaddress", sListenAddress }, - { "addressfamily", sAddressFamily }, - { "printmotd", sPrintMotd }, - { "printlastlog", sPrintLastLog }, - { "ignorerhosts", sIgnoreRhosts }, - { "ignoreuserknownhosts", sIgnoreUserKnownHosts }, - { "x11forwarding", sX11Forwarding }, - { "x11displayoffset", sX11DisplayOffset }, - { "x11uselocalhost", sX11UseLocalhost }, - { "xauthlocation", sXAuthLocation }, - { "strictmodes", sStrictModes }, - { "permitemptypasswords", sEmptyPasswd }, - { "permituserenvironment", sPermitUserEnvironment }, - { "uselogin", sUseLogin }, - { "compression", sCompression }, - { "tcpkeepalive", sTCPKeepAlive }, - { "keepalive", sTCPKeepAlive }, /* obsolete alias */ - { "allowtcpforwarding", sAllowTcpForwarding }, - { "allowusers", sAllowUsers }, - { "denyusers", sDenyUsers }, - { "allowgroups", sAllowGroups }, - { "denygroups", sDenyGroups }, - { "ciphers", sCiphers }, - { "macs", sMacs }, - { "protocol", sProtocol }, - { "gatewayports", sGatewayPorts }, - { "subsystem", sSubsystem }, - { "maxstartups", sMaxStartups }, - { "maxauthtries", sMaxAuthTries }, - { "banner", sBanner }, - { "usedns", sUseDNS }, - { "verifyreversemapping", sDeprecated }, - { "reversemappingcheck", sDeprecated }, - { "clientaliveinterval", sClientAliveInterval }, - { "clientalivecountmax", sClientAliveCountMax }, - { "authorizedkeysfile", sAuthorizedKeysFile }, - { "authorizedkeysfile2", sAuthorizedKeysFile2 }, - { "useprivilegeseparation", sUsePrivilegeSeparation}, - { "acceptenv", sAcceptEnv }, - { "permittunnel", sPermitTunnel }, - { NULL, sBadOption } + { "passwordauthentication", sPasswordAuthentication, SSHCFG_ALL }, + { "kbdinteractiveauthentication", sKbdInteractiveAuthentication, SSHCFG_ALL }, + { "challengeresponseauthentication", sChallengeResponseAuthentication, SSHCFG_ALL }, + { "skeyauthentication", sChallengeResponseAuthentication, SSHCFG_ALL }, /* alias */ + { "checkmail", sDeprecated, SSHCFG_GLOBAL }, + { "listenaddress", sListenAddress, SSHCFG_GLOBAL }, + { "addressfamily", sAddressFamily, SSHCFG_GLOBAL }, + { "printmotd", sPrintMotd, SSHCFG_ALL }, + { "printlastlog", sPrintLastLog, SSHCFG_ALL }, + { "ignorerhosts", sIgnoreRhosts, SSHCFG_ALL }, + { "ignoreuserknownhosts", sIgnoreUserKnownHosts, SSHCFG_ALL }, + { "x11forwarding", sX11Forwarding, SSHCFG_ALL }, + { "x11displayoffset", sX11DisplayOffset, SSHCFG_ALL }, + { "x11uselocalhost", sX11UseLocalhost, SSHCFG_ALL }, + { "xauthlocation", sXAuthLocation, SSHCFG_ALL }, + { "strictmodes", sStrictModes, SSHCFG_ALL }, + { "permitemptypasswords", sEmptyPasswd, SSHCFG_ALL }, + { "permituserenvironment", sPermitUserEnvironment, SSHCFG_ALL }, + { "uselogin", sUseLogin, SSHCFG_ALL }, + { "compression", sCompression, SSHCFG_GLOBAL }, + { "tcpkeepalive", sTCPKeepAlive, SSHCFG_GLOBAL }, + { "keepalive", sTCPKeepAlive, SSHCFG_GLOBAL }, /* obsolete alias */ + { "allowtcpforwarding", sAllowTcpForwarding, SSHCFG_ALL }, + { "allowusers", sAllowUsers, SSHCFG_GLOBAL }, + { "denyusers", sDenyUsers, SSHCFG_GLOBAL }, + { "allowgroups", sAllowGroups, SSHCFG_GLOBAL }, + { "denygroups", sDenyGroups, SSHCFG_GLOBAL }, + { "ciphers", sCiphers, SSHCFG_GLOBAL }, + { "macs", sMacs, SSHCFG_GLOBAL }, + { "protocol", sProtocol, SSHCFG_GLOBAL }, + { "gatewayports", sGatewayPorts, SSHCFG_ALL }, + { "subsystem", sSubsystem, SSHCFG_ALL }, + { "maxstartups", sMaxStartups, SSHCFG_GLOBAL }, + { "maxauthtries", sMaxAuthTries, SSHCFG_ALL }, + { "banner", sBanner, SSHCFG_ALL }, + { "usedns", sUseDNS, SSHCFG_GLOBAL }, + { "verifyreversemapping", sDeprecated, SSHCFG_GLOBAL }, + { "reversemappingcheck", sDeprecated, SSHCFG_GLOBAL }, + { "clientaliveinterval", sClientAliveInterval, SSHCFG_ALL }, + { "clientalivecountmax", sClientAliveCountMax, SSHCFG_ALL }, + { "authorizedkeysfile", sAuthorizedKeysFile, SSHCFG_ALL }, + { "authorizedkeysfile2", sAuthorizedKeysFile2, SSHCFG_ALL }, + { "useprivilegeseparation", sUsePrivilegeSeparation, SSHCFG_GLOBAL}, + { "acceptenv", sAcceptEnv, SSHCFG_ALL }, + { "permittunnel", sPermitTunnel, SSHCFG_ALL }, + { "match", sMatch, SSHCFG_ALL }, + { NULL, sBadOption, 0 } }; /* @@ -386,13 +392,15 @@ static struct { static ServerOpCodes parse_token(const char *cp, const char *filename, - int linenum) + int linenum, u_int *flags) { u_int i; for (i = 0; keywords[i].name; i++) - if (strcasecmp(cp, keywords[i].name) == 0) + if (strcasecmp(cp, keywords[i].name) == 0) { + *flags = keywords[i].flags; return keywords[i].opcode; + } error("%s: line %d: Bad configuration option: %s", filename, linenum, cp); @@ -437,15 +445,49 @@ add_one_listen_addr(ServerOptions *optio options->listen_addrs = aitop; } +/* + * The strategy for the Match blocks is that the config file is parsed twice. + * + * The first time is at startup. activep is initialized to 1 and the + * directives in the global context are processed and acted on. Hitting a + * Match directive unsets activep and the directives inside the block are + * checked for syntax only. + * + * The second time is after a connection has been established but before + * authentication. activep is initialized to 2 and global config directives + * are ignored since they have already been processed. If the criteria in a + * Match block is met, activep is set and the subsequent directives + * processed and actioned until EOF or another Match block unsets it. Any + * options set are copied into the main server config. + * + * Potential additions/improvements: + * - Add Match support for pre-kex directives, eg Protocol, Ciphers. + * + * - Add a Tag directive (idea from David Leonard) ala pf, eg: + * Match Address 192.168.0.* + * Tag trusted + * Match Group wheel + * Tag trusted + * Match Tag trusted + * AllowTcpForwarding yes + * GatewayPorts clientspecified + * [...] + * + * - Add a PermittedChannelRequests directive + * Match Group shell + * PermittedChannelRequests session,forwarded-tcpip + */ + int process_server_config_line(ServerOptions *options, char *line, - const char *filename, int linenum) + const char *filename, int linenum, int *activep, const char *user, + const char *host, const char *address) { char *cp, **charptr, *arg, *p; - int *intptr, value, n; + int cmdline = 0, *intptr, value, n; ServerOpCodes opcode; u_short port; - u_int i; + u_int i, flags = 0; cp = line; arg = strdelim(&cp); @@ -456,7 +498,24 @@ process_server_config_line(ServerOptions return 0; intptr = NULL; charptr = NULL; - opcode = parse_token(arg, filename, linenum); + opcode = parse_token(arg, filename, linenum, &flags); + + if (activep == NULL) { /* We are processing a command line directive */ + cmdline = 1; + activep = &cmdline; + } + debug3("match: line %s active %d flags %d", line, *activep, flags); + if (*activep == 0 && !(flags & SSHCFG_MATCH)) { + if (user == NULL) { + fatal("%s line %d: Directive '%s' is not allowed " + "within a Match block", filename, linenum, arg); + } else { /* this is a directive we have already processed */ + while (arg) + arg = strdelim(&cp); + return 0; + } + } + switch (opcode) { /* Portable-specific options */ case sUsePAM: @@ -494,7 +553,7 @@ parse_int: fatal("%s line %d: missing integer value.", filename, linenum); value = atoi(arg); - if (*intptr == -1) + if (*activep && *intptr == -1) *intptr = value; break; @@ -574,7 +633,7 @@ parse_filename: if (!arg || *arg == '\0') fatal("%s line %d: missing file name.", filename, linenum); - if (*charptr == NULL) { + if (*activep && *charptr == NULL) { *charptr = tilde_expand_filename(arg, getuid()); /* increase optional counter */ if (intptr != NULL) @@ -625,7 +684,7 @@ parse_flag: else fatal("%s line %d: Bad yes/no argument: %s", filename, linenum, arg); - if (*intptr == -1) + if (*activep && *intptr == -1) *intptr = value; break; @@ -890,6 +949,10 @@ parse_flag: if (!arg || *arg == '\0') fatal("%s line %d: Missing subsystem name.", filename, linenum); + if (!*activep) { + arg = strdelim(&cp); + break; + } for (i = 0; i < options->num_subsystems; i++) if (strcmp(arg, options->subsystem_name[i]) == 0) fatal("%s line %d: Subsystem '%s' already defined.", @@ -961,6 +1024,8 @@ parse_flag: if (options->num_accept_env >= MAX_ACCEPT_ENV) fatal("%s line %d: too many allow env.", filename, linenum); + if (!*activep) + break; options->accept_env[options->num_accept_env++] = xstrdup(arg); } @@ -988,6 +1053,17 @@ parse_flag: *intptr = value; break; + case sMatch: + if (cmdline) + fatal("Match directive not supported as a command-line " + "option"); + value = match_cfg_line(&cp, linenum, user, host, address); + if (value < 0) + fatal("%s line %d: Bad Match condition", filename, + linenum); + *activep = value; + break; + case sDeprecated: logit("%s line %d: Deprecated option %s", filename, linenum, arg); @@ -1044,18 +1120,140 @@ load_server_config(const char *filename, } void -parse_server_config(ServerOptions *options, const char *filename, Buffer *conf) +parse_server_match_config(ServerOptions *options, const char *user, + const char *host, const char *address) +{ + u_int i; + ServerOptions mo; + + initialize_server_options(&mo); + parse_server_config(&mo, "reprocess config", &cfg, user, host, address); + + /* now copy any (supported) values set */ + if (mo.use_pam != -1) + options->use_pam = mo.use_pam; + if (mo.num_accept_env > 0) { + for (i = 0; i < options->num_accept_env; i++) + xfree(options->accept_env[i]); + options->num_accept_env = 0; + for (i = 0; i < mo.num_accept_env; i++) { + if (options->num_accept_env >= MAX_ACCEPT_ENV) + fatal("Too many allow env in Match block."); + options->accept_env[options->num_accept_env++] = + mo.accept_env[i]; + } + } + if (mo.allow_tcp_forwarding != -1) + options->allow_tcp_forwarding = mo.allow_tcp_forwarding; + if (mo.authorized_keys_file != NULL) { + if (options->authorized_keys_file != NULL) + xfree(options->authorized_keys_file); + options->authorized_keys_file = mo.authorized_keys_file; + } + if (mo.authorized_keys_file2 != NULL) { + if (options->authorized_keys_file2 != NULL) + xfree(options->authorized_keys_file2); + options->authorized_keys_file2 = mo.authorized_keys_file2; + } + if (mo.banner != NULL) { + if (options->banner != NULL) + xfree(options->banner); + options->banner = mo.banner; + } + if (mo.password_authentication != -1) + options->password_authentication = mo.password_authentication; + if (mo.challenge_response_authentication != -1) + options->challenge_response_authentication = + mo.challenge_response_authentication; + if (mo.client_alive_count_max != -1) + options->client_alive_count_max = mo.client_alive_count_max; + if (mo.client_alive_interval != -1) + options->client_alive_interval = mo.client_alive_interval; + if (mo.gateway_ports != -1) + options->gateway_ports = mo.gateway_ports; + if (mo.gss_authentication != -1) + options->gss_authentication = mo.gss_authentication; + if (mo.hostbased_authentication != -1) + options->hostbased_authentication = mo.hostbased_authentication; + if (mo.hostbased_uses_name_from_packet_only != -1) + options->hostbased_uses_name_from_packet_only = + mo.hostbased_uses_name_from_packet_only; + if (mo.kerberos_authentication != -1) + options->kerberos_authentication = mo.kerberos_authentication; + if (mo.kerberos_or_local_passwd != -1) + options->kerberos_or_local_passwd = mo.kerberos_or_local_passwd; + if (mo.kerberos_ticket_cleanup != -1) + options->kerberos_ticket_cleanup = mo.kerberos_ticket_cleanup; + if (mo.kerberos_get_afs_token != -1) + options->kerberos_get_afs_token = mo.kerberos_get_afs_token; + if (mo.login_grace_time != -1) + options->login_grace_time = mo.login_grace_time; + if (mo.log_facility != -1) + options->log_facility = mo.log_facility; + if (mo.log_level != -1) + options->log_level = mo.log_level; + if (mo.permit_root_login != -1) + options->permit_root_login = mo.permit_root_login; + if (mo.max_authtries != -1) + options->max_authtries = mo.max_authtries; + if (mo.permit_empty_passwd != -1) + options->permit_empty_passwd = mo.permit_empty_passwd; + if (mo.permit_tun != -1) + options->permit_tun = mo.permit_tun; + if (mo.permit_user_env != -1) + options->permit_user_env = mo.permit_user_env; + if (mo.print_motd != -1) + options->print_motd = mo.print_motd; + if (mo.pubkey_authentication != -1) + options->pubkey_authentication = mo.pubkey_authentication; + if (mo.rsa_authentication != -1) + options->rsa_authentication = mo.rsa_authentication; + if (mo.strict_modes != -1) + options->strict_modes = mo.strict_modes; + if (mo.num_subsystems != 0) { /* Not currently used */ + for (i = 0; i < options->num_subsystems; i++) { + xfree(options->subsystem_name[i]); + xfree(options->subsystem_command[i]); + } + options->num_subsystems = 0; + for (i = 0; i < mo.num_subsystems; i++) { + options->subsystem_name[options->num_subsystems] = + mo.subsystem_name[i]; + options->subsystem_command[options->num_subsystems] = + mo.subsystem_command[i]; + options->num_subsystems++; + } + } + if (mo.use_login != -1) + options->use_login = mo.use_login; + if (mo.xauth_location != NULL) { + if (options->xauth_location != NULL) + xfree(options->xauth_location); + options->xauth_location = mo.xauth_location; + } + if (mo.x11_display_offset != -1) + options->x11_display_offset = mo.x11_display_offset; + if (mo.x11_forwarding != -1) + options->x11_forwarding = mo.x11_forwarding; + if (mo.x11_use_localhost != -1) + options->x11_use_localhost = mo.x11_use_localhost; +} + +void +parse_server_config(ServerOptions *options, const char *filename, Buffer *conf, + const char *user, const char *host, const char *address) { - int linenum, bad_options = 0; + int active, linenum, bad_options = 0; char *cp, *obuf, *cbuf; debug2("%s: config %s len %d", __func__, filename, buffer_len(conf)); obuf = cbuf = xstrdup(buffer_ptr(conf)); + active = user ? 0 : 1; linenum = 1; while ((cp = strsep(&cbuf, "\n")) != NULL) { if (process_server_config_line(options, cp, filename, - linenum++) != 0) + linenum++, &active, user, host, address) != 0) bad_options++; } xfree(obuf); Index: servconf.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/servconf.h,v retrieving revision 1.64 diff -u -p -r1.64 servconf.h --- servconf.h 13 Dec 2005 08:29:03 -0000 1.64 +++ servconf.h 3 Apr 2006 11:31:16 -0000 @@ -141,8 +141,12 @@ typedef struct { void initialize_server_options(ServerOptions *); void fill_default_server_options(ServerOptions *); -int process_server_config_line(ServerOptions *, char *, const char *, int); +int process_server_config_line(ServerOptions *, char *, const char *, int, + int *, const char *, const char *, const char *); void load_server_config(const char *, Buffer *); -void parse_server_config(ServerOptions *, const char *, Buffer *); +void parse_server_config(ServerOptions *, const char *, Buffer *, + const char *, const char *, const char *); +void parse_server_match_config(ServerOptions *, const char *, const char *, + const char *); #endif /* SERVCONF_H */ Index: sshd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd.c,v retrieving revision 1.320 diff -u -p -r1.320 sshd.c --- sshd.c 24 Dec 2005 03:59:12 -0000 1.320 +++ sshd.c 3 Apr 2006 11:30:11 -0000 @@ -201,12 +201,15 @@ int *startup_pipes = NULL; int startup_pipe; /* in child */ /* variables used for privilege separation */ -int use_privsep; +int use_privsep = -1; /* Needs to be accessable in many places */ struct monitor *pmonitor = NULL; /* global authentication context */ Authctxt *the_authctxt = NULL; +/* sshd_config buffer */ +Buffer cfg; + /* message to be displayed after login */ Buffer loginmsg; @@ -892,7 +895,6 @@ main(int ac, char **av) Key *key; Authctxt *authctxt; int ret, key_used = 0; - Buffer cfg; #ifdef HAVE_SECUREWARE (void)set_auth_parameters(ac, av); @@ -1011,7 +1013,7 @@ main(int ac, char **av) case 'o': line = xstrdup(optarg); if (process_server_config_line(&options, line, - "command-line", 0) != 0) + "command-line", 0, NULL, NULL, NULL, NULL) != 0) exit(1); xfree(line); break; @@ -1069,11 +1071,8 @@ main(int ac, char **av) else load_server_config(config_file_name, &cfg); - parse_server_config(&options, - rexeced_flag ? "rexec" : config_file_name, &cfg); - - if (!rexec_flag) - buffer_free(&cfg); + parse_server_config(&options, rexeced_flag ? "rexec" : config_file_name, + &cfg, NULL, NULL, NULL); seed_rng(); Index: sshd_config.5 =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/sshd_config.5,v retrieving revision 1.53 diff -u -p -r1.53 sshd_config.5 --- sshd_config.5 3 Jan 2006 07:47:31 -0000 1.53 +++ sshd_config.5 3 Apr 2006 11:38:30 -0000 @@ -433,6 +433,70 @@ for data integrity protection. Multiple algorithms must be comma-separated. The default is .Dq hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96 . +.It Cm Match +Introduces a conditional block. Keywords on lines following a +.Cm Match +block are only applied if the criteria on the +.Cm Match +are satisfied. +The the arguments to +.Cm Match +block are one or more criteria-pattern pairs. +The available criteria are +.Cm User , +.Cm Group , +.Cm Host , +and +.Cm Address . +Only a subset of keywords may be used on the lines following a +.Cm Match +keyword. +Available keywords are +.Cm AcceptEnv , +.Cm AllowTcpForwarding , +.Cm AuthorizedKeysFile , +.Cm AuthorizedKeysFile2 , +.Cm Banner , +.Cm ChallengeResponseAuthentication , +.Cm ChallengeResponseAuthentication , +.Cm ClientAliveCountMax , +.Cm ClientAliveInterval , +.Cm GatewayPorts , +.Cm GssAuthentication , +.Cm GssCleanupCreds , +.Cm HostbasedAuthentication , +.Cm HostbasedUsesNameFromPacketOnly , +.Cm IgnoreRhosts , +.Cm IgnoreUserKnownHosts , +.Cm KbdInteractiveAuthentication , +.Cm KerberosAuthentication , +.Cm KerberosGetAFSToken , +.Cm KerberosOrLocalPasswd , +.Cm KerberosTicketCleanup , +.Cm LogFacility , +.Cm LogLevel , +.Cm LoginGraceTime , +.Cm MaxAuthTries , +.Cm PasswordAuthentication , +.Cm PermitEmptyPasswd , +.Cm PermitRootLogin , +.Cm PermitTunnel , +.Cm PermitUserEnvironment , +.Cm PrintLastLog , +.Cm PrintMotd , +.Cm PubkeyAuthentication , +.Cm PubkeyAuthentication , +.Cm RSAAuthentication , +.Cm RhostsRSAAuthentication , +.Cm StrictModes , +.Cm Subsystem , +.Cm UseLogin , +.Cm UsePAM , +.Cm X11DisplayOffset , +.Cm X11Forwarding , +.Cm X11UseLocalhost , +and +.Cm XAuthLocation . .It Cm MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. @@ -827,6 +891,17 @@ Contains configuration data for This file should be writable by root only, but it is recommended (though not necessary) that it be world-readable. .El +.Sh EXAMPLES +To allow +.Cm PasswordAuthentication +only from the local private network: +.Bd -literal -offset indent +PasswordAuthentication no +Match Address 192.168.0.* + PasswordAuthentication yes +.Ed +.Bl -tag -width Ds +.Bl -tag -width Ds .Sh SEE ALSO .Xr sshd 8 .Sh AUTHORS From vinschen at redhat.com Tue Apr 4 19:32:33 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 4 Apr 2006 11:32:33 +0200 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <44261AA5.9070407@psc.edu> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> Message-ID: <20060404093233.GA16456@calimero.vinschen.de> On Mar 25 23:37, Chris Rapier wrote: > [http://www.psc.edu/networking/projects/hpn-ssh/] > Development is on going and new version of the patch will be available > shortly. This new version of the patch will hopefully address a > performance issue in LAN transfers. Not sure if it's ok to discuss this here. However, we have some performance problems on Cygwin with the vanilla version of OpenSSH. The main problem is the size of the read buffers in the client loop, resp. client_process_net_input/client_process_input. The buffer size is a fixed 8K. For some reason this degrades performance on Windows enormously, when a copy is made from a remote machine to the local machine, like this: scp remote:file . Consider an example file of 118 Megs. A copy from the Cygwin box to Linux: linux> scp cygwin:file . file 100% 118MB 13.2MB/s 00:09 Copying from Linux to Cygwin on the other hand: cygwin> scp linux:file . file 100% 118MB 1.3MB/s 01:31 By raising the aforementioned buffers in clientloop.c from 8192 to, say, 87380 (default tcp recv buffer size), the latter copy is way faster: cygwin> scp linux:file . file 100% 118MB 6.2MB/s 00:19 I also tried the HPN patch, but it doesn't help for this specific situation. The HPN patch does not touch the application's read buffer size and it turns out that neither changing the underlying SO_RCVBUF buffer sizes nor changing TCP_NODELAY have a really relaxing effect on this situation (less than 10%). On the contrary, keeping the application buffers at 8K, the performance even degrades with the HPN patch: cygwin> scp linux:file . file 100% 118MB 1.0MB/s 01:58 So, to circumvent the performance problem, the only feasible solution for Cygwin is to raise the buffer sizes in client_process_net_input/ client_process_input. My question to the OpenSSH core developer team is this: Is it ok to do that? Is there any problem you would expect from raising the buffer sizes? Is there any reason to keep the buffers at 8K in the vanilla version or would it be ok to raise the buffers to a somewhat bigger value like 64K or the aforementioned 87380 bytes? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From Jefferson.Ogata at noaa.gov Tue Apr 4 23:27:32 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 04 Apr 2006 09:27:32 -0400 Subject: sshd config parser In-Reply-To: <20060402024330.GA11219@gate.dtucker.net> References: <442A890C.9050003@zip.com.au> <20060401111919.GA6812@gate.dtucker.net> <20060401131024.GA8769@gate.dtucker.net> <20060402024330.GA11219@gate.dtucker.net> Message-ID: <44327444.8040107@noaa.gov> On 04/01/2006 09:43 PM, Darren Tucker wrote: > Here's an updated patch. It's not actually as big as it looks as nearly > half of it as adding a flag to the keyword struct and large comment. > > The supported Match directives are User, Group, Host and Address. Overall I'm liking this a lot--it addresses some needs I've had for a long time. Couple of silly questions; sorry if I missed the answer to these: 1. Why the "Match" keyword. Why not just "Host foo.example.com" or "User bozo"? 2. How does "Host" with wildcards interact with DNS? E.g. will "Host 192.168.0.*" match 192.168.0.evil.domain? 3. What is "Address"? 4. What about CIDR notation? -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From rapier at psc.edu Wed Apr 5 06:52:44 2006 From: rapier at psc.edu (Chris Rapier) Date: Tue, 04 Apr 2006 16:52:44 -0400 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <20060404093233.GA16456@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> Message-ID: <4432DC9C.6010103@psc.edu> Corinna Vinschen wrote: > On Mar 25 23:37, Chris Rapier wrote: >> [http://www.psc.edu/networking/projects/hpn-ssh/] >> Development is on going and new version of the patch will be available >> shortly. This new version of the patch will hopefully address a >> performance issue in LAN transfers. > > Not sure if it's ok to discuss this here. However, we have some > performance problems on Cygwin with the vanilla version of OpenSSH. The > main problem is the size of the read buffers in the client loop, resp. > client_process_net_input/client_process_input. The buffer size is a > fixed 8K. For some reason this degrades performance on Windows > enormously, when a copy is made from a remote machine to the local > machine, like this: I'm guessing that this is probably an issue in the implementation of cygwin. Following the code I would again guess that its probably the memcpy in buffer_append doing it. Perhaps many small memcpy's being more expensive than a few larger ones in the cygwin environment? Is there some sort of trace functionality under cygwin? > I also tried the HPN patch, but it doesn't help for this specific > situation. The HPN patch does not touch the application's read buffer > size and it turns out that neither changing the underlying SO_RCVBUF > buffer sizes nor changing TCP_NODELAY have a really relaxing effect on > this situation (less than 10%). > > On the contrary, keeping the application buffers at 8K, the performance > even degrades with the HPN patch: > > cygwin> scp linux:file . > file 100% 118MB 1.0MB/s 01:58 So this is an additional decrease in performance if the HPN patch is used with 8k buffers? What can you tell me about the path? Does it have a very low RTT? The available version of HPN (HPN11) polls the SO_RCVBUF once every window so in low RTT environments the additional cycles spent on this could have an impact. The beta version of the patch (HPN12) provides a switch to disabled buffer polling. I'm still working on this issue (recreating the problems consistently has been an issue for me) but you might want to look at the HPN12 patch set. From dtucker at zip.com.au Wed Apr 5 07:55:47 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 05 Apr 2006 07:55:47 +1000 Subject: sshd config parser In-Reply-To: <44327444.8040107@noaa.gov> References: <442A890C.9050003@zip.com.au> <20060401111919.GA6812@gate.dtucker.net> <20060401131024.GA8769@gate.dtucker.net> <20060402024330.GA11219@gate.dtucker.net> <44327444.8040107@noaa.gov> Message-ID: <4432EB63.7010102@zip.com.au> Jefferson Ogata wrote: > On 04/01/2006 09:43 PM, Darren Tucker wrote: >> Here's an updated patch. It's not actually as big as it looks as nearly >> half of it as adding a flag to the keyword struct and large comment. >> >> The supported Match directives are User, Group, Host and Address. > > Overall I'm liking this a lot--it addresses some needs I've had for a > long time. > > Couple of silly questions; sorry if I missed the answer to these: > > 1. Why the "Match" keyword. Why not just "Host foo.example.com" or "User > bozo"? It's simpler to write that way. There's only one additional keyword, and that keyword can support multiple criteria (ie the conditions on a Match line are a logical AND). This lets you do things like "Match Group trusted Host 192.168.0.*" which would match only members of the "trusted" group connecting from 192.168.0.0/24. Without "Match", each condition would be a keyword in its own right. Matching on multiple conditions would either not be supported, or each keyword would need to explicitly check for other criteria. > 2. How does "Host" with wildcards interact with DNS? E.g. will "Host > 192.168.0.*" match 192.168.0.evil.domain? It would, which is why... > 3. What is "Address"? Source address of the connection. I don't like the way the existing match functionality conflates hostname and address because it causes potential problems like #2 above. > 4. What about CIDR notation? No supported yet but planned. It's a straightforward extension of the existing address matching code (it's orthogonal to the Match keyword stuff so it should also work for existing matching directive such as AllowUsers). -- 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 Wed Apr 5 10:09:15 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 05 Apr 2006 10:09:15 +1000 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <4432DC9C.6010103@psc.edu> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> Message-ID: <44330AAB.1020707@zip.com.au> Chris Rapier wrote: > > Corinna Vinschen wrote: >> On Mar 25 23:37, Chris Rapier wrote: >>> [http://www.psc.edu/networking/projects/hpn-ssh/] >>> Development is on going and new version of the patch will be available >>> shortly. This new version of the patch will hopefully address a >>> performance issue in LAN transfers. >> Not sure if it's ok to discuss this here. However, we have some >> performance problems on Cygwin with the vanilla version of OpenSSH. The >> main problem is the size of the read buffers in the client loop, resp. >> client_process_net_input/client_process_input. The buffer size is a >> fixed 8K. For some reason this degrades performance on Windows >> enormously, when a copy is made from a remote machine to the local >> machine, like this: > > I'm guessing that this is probably an issue in the implementation of > cygwin. Following the code I would again guess that its probably the > memcpy in buffer_append doing it. Perhaps many small memcpy's being more > expensive than a few larger ones in the cygwin environment? Is there > some sort of trace functionality under cygwin? I disagree, see below. >> I also tried the HPN patch, but it doesn't help for this specific >> situation. The HPN patch does not touch the application's read buffer >> size and it turns out that neither changing the underlying SO_RCVBUF >> buffer sizes nor changing TCP_NODELAY have a really relaxing effect on >> this situation (less than 10%). >> >> On the contrary, keeping the application buffers at 8K, the performance >> even degrades with the HPN patch: >> >> cygwin> scp linux:file . >> file 100% 118MB 1.0MB/s 01:58 > > So this is an additional decrease in performance if the HPN patch is > used with 8k buffers? What can you tell me about the path? Does it have > a very low RTT? The available version of HPN (HPN11) polls the SO_RCVBUF > once every window so in low RTT environments the additional cycles spent > on this could have an impact. The beta version of the patch (HPN12) > provides a switch to disabled buffer polling. I'm still working on this > issue (recreating the problems consistently has been an issue for me) > but you might want to look at the HPN12 patch set. I think this is another symptom of the HPN patch letting the buffers get way too big under some conditions, then ssh spents a disproportionate amount of time compacting those buffers. Assume the the 8k writes are relatively slow on Cygwin (which appears to be the case[1]). ssh will be emptying the output buffer relatively slowly, but the CPU can encrypt much faster than the IO rate. Normally the buffer would peak at 5-10 MB under these conditions, but the BUFFER_MAX_HPN_LEN change means that they can grow really big (up to 2^29 bytes). The buffer gets compacted at 1MB consumed, so the process becomes "read 1MB in 8k chunks then memmove (2^29 - 1M). Corinna, if this is the case you should see ssh consuming a lot more memory, more CPU and, if you can profile it, spending a lot more time in memmove. BTW I think the occurs in the main tree too, but the effects are much less noticable because the buffers are smaller, and this is why scp's reported throughput sometimes drops off slightly after the initial connection. The solution is to not write more than, say, 1-2 x TCP window size to the output buffer. If you're IO bound on the source, you'll never write more than 1 x TCPWINSZ to the socket and have plenty of CPU to fill it up again. If you're CPU bound, you won't spend extra time compacting the buffers so it will be a small performance improvement. I think a similar but inverted problem occurs on the sink. [1] or that small writes is an O(1) operation with a large constant. -- 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 rapier at psc.edu Wed Apr 5 12:06:19 2006 From: rapier at psc.edu (Chris Rapier) Date: Tue, 04 Apr 2006 22:06:19 -0400 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <44330AAB.1020707@zip.com.au> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> Message-ID: <4433261B.1020103@psc.edu> Darren Tucker wrote: > I think this is another symptom of the HPN patch letting the buffers get > way too big under some conditions, then ssh spents a disproportionate > amount of time compacting those buffers. Assuming this is true it doesn't address the performance issue with an unmodified OpenSSH under cygwin. This was the first issue brought up and as such doesn't have anything to do with the HPN patches. I'm not trying to deflect things here just trying to make sure the original issue doesn't fall by the way side. > Assume the the 8k writes are relatively slow on Cygwin (which appears to > be the case[1]). ssh will be emptying the output buffer relatively > slowly, but the CPU can encrypt much faster than the IO rate. Normally > the buffer would peak at 5-10 MB under these conditions, but the > BUFFER_MAX_HPN_LEN change means that they can grow really big (up to > 2^29 bytes). The buffer gets compacted at 1MB consumed, so the process > becomes "read 1MB in 8k chunks then memmove (2^29 - 1M). I will try find out exactly how big the buffer is actually getting in this. I just need to identify exactly which buffer I need to be paying attention to :) I'll also just drop MAX_HPN_LEN to 10MB and see what happens. > The solution is to not write more than, say, 1-2 x TCP window size to > the output buffer. If you're IO bound on the source, you'll never write > more than 1 x TCPWINSZ to the socket and have plenty of CPU to fill it > up again. If you're CPU bound, you won't spend extra time compacting > the buffers so it will be a small performance improvement. I think I'm understanding what you are saying here better now. My apologies for not getting it quicker. What about in situations where the tcp window size is not a constant - like under Linux 2.6 and Vista? From dtucker at zip.com.au Wed Apr 5 12:36:26 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 05 Apr 2006 12:36:26 +1000 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <4433261B.1020103@psc.edu> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> Message-ID: <44332D2A.9040805@zip.com.au> Chris Rapier wrote: > > Darren Tucker wrote: > >> I think this is another symptom of the HPN patch letting the buffers get >> way too big under some conditions, then ssh spents a disproportionate >> amount of time compacting those buffers. > > Assuming this is true it doesn't address the performance issue with an > unmodified OpenSSH under cygwin. That's true, I just didn't want people spending time analyzing (what I think is) the wrong thing. [...] > I will try find out exactly how big the buffer is actually getting in > this. I just need to identify exactly which buffer I need to be paying > attention to :) I'll also just drop MAX_HPN_LEN to 10MB and see what > happens. The existing buffer limit is 10MB so unless you have paths with a BDP/TCPWINSZ of 10MB or higher (do you?) then I think you'll see your throughput go up a little or your CPU and memory utilization go down a little. >> The solution is to not write more than, say, 1-2 x TCP window size to >> the output buffer. If you're IO bound on the source, you'll never write >> more than 1 x TCPWINSZ to the socket and have plenty of CPU to fill it >> up again. If you're CPU bound, you won't spend extra time compacting >> the buffers so it will be a small performance improvement. > > I think I'm understanding what you are saying here better now. My > apologies for not getting it quicker. What about in situations where the > tcp window size is not a constant - like under Linux 2.6 and Vista? At the moment, you do this in channel.c: -limit = MIN(limit, (BUFFER_MAX_LEN - BUFFER_MAX_CHUNK - CHAN_RBUF)); +limit = MIN(limit, (BUFFER_MAX_HPN_LEN-BUFFER_MAX_CHUNK-CHAN_RBUF)); Instead, I suggest leaving the existing line and adding something like: limit = MIN(limit, gettcpwinsz()); or limit = MIN(limit, 2 * gettcpwinsz()); That way the buffer utilization would scale with your window size. BTW hpn12 doesn't seem to be on your web page? To Corinna's question about buffer sizes: I personally would have no objection to making it 64k, possibly with a #define for making it smaller for folks targeting old/embedded systems and such. I suspect it would be a minor performance gain on most platforms. If a similar bottleneck applies to pipe/socketpairs, it may also be work increasing the IO buffer in scp and seeing if that helps your performance (the HPN patch bumps it from 2k to 16k, you may want to bump it to 64k). -- 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 Jefferson.Ogata at noaa.gov Wed Apr 5 13:37:56 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 04 Apr 2006 23:37:56 -0400 Subject: sshd config parser In-Reply-To: <4432EB63.7010102@zip.com.au> References: <442A890C.9050003@zip.com.au> <20060401111919.GA6812@gate.dtucker.net> <20060401131024.GA8769@gate.dtucker.net> <20060402024330.GA11219@gate.dtucker.net> <44327444.8040107@noaa.gov> <4432EB63.7010102@zip.com.au> Message-ID: <44333B94.4030603@noaa.gov> On 04/04/2006 05:55 PM, Darren Tucker wrote: > Jefferson Ogata wrote: >>1. Why the "Match" keyword. Why not just "Host foo.example.com" or "User >>bozo"? > > Without "Match", each condition would be a keyword in its own right. > Matching on multiple conditions would either not be supported, or each > keyword would need to explicitly check for other criteria. Makes sense. Kewl. >>2. How does "Host" with wildcards interact with DNS? E.g. will "Host >>192.168.0.*" match 192.168.0.evil.domain? > > It would, which is why... Oh, my. Don't you think this is going to lead to unexpected results? I'm a bit concerned that people won't realize that DNS is an issue... Could sshd default not to use inverse DNS in Host matches unless another config directive were enabled? Thanks for the cogent response. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From dtucker at zip.com.au Wed Apr 5 15:12:40 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 05 Apr 2006 15:12:40 +1000 Subject: sshd config parser In-Reply-To: <44333B94.4030603@noaa.gov> References: <442A890C.9050003@zip.com.au> <20060401111919.GA6812@gate.dtucker.net> <20060401131024.GA8769@gate.dtucker.net> <20060402024330.GA11219@gate.dtucker.net> <44327444.8040107@noaa.gov> <4432EB63.7010102@zip.com.au> <44333B94.4030603@noaa.gov> Message-ID: <443351C8.2040406@zip.com.au> Jefferson Ogata wrote: >>> 2. How does "Host" with wildcards interact with DNS? E.g. will "Host >>> 192.168.0.*" match 192.168.0.evil.domain? >> It would, which is why... > > Oh, my. Don't you think this is going to lead to unexpected results? I'm > a bit concerned that people won't realize that DNS is an issue... The whole idea of having a "Address" and "Host" as distinct entities is that if you want to match an address you use "Address" and if you want to match a hostname you use "Host". > Could sshd default not to use inverse DNS in Host matches unless another > config directive were enabled? That would be "UseDNS", no? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Wed Apr 5 20:56:27 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 5 Apr 2006 12:56:27 +0200 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <4432DC9C.6010103@psc.edu> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> Message-ID: <20060405105627.GA19284@calimero.vinschen.de> On Apr 4 16:52, Chris Rapier wrote: > Corinna Vinschen wrote: > > On Mar 25 23:37, Chris Rapier wrote: > >> [http://www.psc.edu/networking/projects/hpn-ssh/] > >> Development is on going and new version of the patch will be available > >> shortly. This new version of the patch will hopefully address a > >> performance issue in LAN transfers. > > > > Not sure if it's ok to discuss this here. However, we have some > > performance problems on Cygwin with the vanilla version of OpenSSH. The > > main problem is the size of the read buffers in the client loop, resp. > > client_process_net_input/client_process_input. The buffer size is a > > fixed 8K. For some reason this degrades performance on Windows > > enormously, when a copy is made from a remote machine to the local > > machine, like this: > > I'm guessing that this is probably an issue in the implementation of > cygwin. Following the code I would again guess that its probably the > memcpy in buffer_append doing it. Perhaps many small memcpy's being more > expensive than a few larger ones in the cygwin environment? Is there > some sort of trace functionality under cygwin? memcpy and memmove are optimized handcoded assembler functions, so I don't think they are the culprit. Unfortunaltely, the trace functionality in Cygwin doesn't cover these functions. > > I also tried the HPN patch, but it doesn't help for this specific > > situation. The HPN patch does not touch the application's read buffer > > size and it turns out that neither changing the underlying SO_RCVBUF > > buffer sizes nor changing TCP_NODELAY have a really relaxing effect on > > this situation (less than 10%). > > > > On the contrary, keeping the application buffers at 8K, the performance > > even degrades with the HPN patch: > > > > cygwin> scp linux:file . > > file 100% 118MB 1.0MB/s 01:58 > > So this is an additional decrease in performance if the HPN patch is > used with 8k buffers? What can you tell me about the path? Does it have > a very low RTT? The available version of HPN (HPN11) polls the SO_RCVBUF The RTT is in the <1ms scale. > once every window so in low RTT environments the additional cycles spent > on this could have an impact. The beta version of the patch (HPN12) > provides a switch to disabled buffer polling. I'm still working on this > issue (recreating the problems consistently has been an issue for me) > but you might want to look at the HPN12 patch set. I won't have time to test extensively until next week. But I'll come back to this. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Wed Apr 5 21:02:38 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 5 Apr 2006 13:02:38 +0200 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <44330AAB.1020707@zip.com.au> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> Message-ID: <20060405110238.GB19284@calimero.vinschen.de> On Apr 5 10:09, Darren Tucker wrote: > Chris Rapier wrote: > > So this is an additional decrease in performance if the HPN patch is > > used with 8k buffers? What can you tell me about the path? Does it have > > a very low RTT? The available version of HPN (HPN11) polls the SO_RCVBUF > > once every window so in low RTT environments the additional cycles spent > > on this could have an impact. The beta version of the patch (HPN12) > > provides a switch to disabled buffer polling. I'm still working on this > > issue (recreating the problems consistently has been an issue for me) > > but you might want to look at the HPN12 patch set. > > I think this is another symptom of the HPN patch letting the buffers get > way too big under some conditions, then ssh spents a disproportionate > amount of time compacting those buffers. > > Assume the the 8k writes are relatively slow on Cygwin (which appears to > be the case[1]). ssh will be emptying the output buffer relatively > slowly, but the CPU can encrypt much faster than the IO rate. Normally > the buffer would peak at 5-10 MB under these conditions, but the > BUFFER_MAX_HPN_LEN change means that they can grow really big (up to > 2^29 bytes). The buffer gets compacted at 1MB consumed, so the process > becomes "read 1MB in 8k chunks then memmove (2^29 - 1M). > > Corinna, if this is the case you should see ssh consuming a lot more > memory, more CPU and, if you can profile it, spending a lot more time in > memmove. As I replied to Chris already, I won't be able to make more tests in the next few days, but I'll be back on Tuesday. As for Cygwin's slowness, I think that neither memcpy/memmove, nor malloc are the problem. The only function call in the client loop, which would account for Cygwin's slowness is probably select(2). The select implementation in Cygwin is rather complicated and it's slow by definition. The problem is that Windows' own select only works on sockets, not on any file descriptor. Therefore, to implement a general select, a lot of handstands have to be made. Perhaps that's the problem which slows down the loop when read uses a rather small buffer. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Wed Apr 5 21:03:27 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 5 Apr 2006 13:03:27 +0200 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <44332D2A.9040805@zip.com.au> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> Message-ID: <20060405110327.GC19284@calimero.vinschen.de> On Apr 5 12:36, Darren Tucker wrote: > To Corinna's question about buffer sizes: I personally would have no > objection to making it 64k, possibly with a #define for making it > smaller for folks targeting old/embedded systems and such. I suspect it > would be a minor performance gain on most platforms. > > If a similar bottleneck applies to pipe/socketpairs, it may also be work > increasing the IO buffer in scp and seeing if that helps your > performance (the HPN patch bumps it from 2k to 16k, you may want to bump > it to 64k). Thanks for the hint, I'll give it a try next week. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From rapier at psc.edu Wed Apr 5 22:51:40 2006 From: rapier at psc.edu (Chris Rapier) Date: Wed, 05 Apr 2006 08:51:40 -0400 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <44332D2A.9040805@zip.com.au> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> Message-ID: <4433BD5C.9000400@psc.edu> Darren Tucker wrote: >>> I think this is another symptom of the HPN patch letting the buffers get >>> way too big under some conditions, then ssh spents a disproportionate >>> amount of time compacting those buffers. >> Assuming this is true it doesn't address the performance issue with an >> unmodified OpenSSH under cygwin. > > That's true, I just didn't want people spending time analyzing (what I > think is) the wrong thing. I agree which I why I brought it up :) I'm really just wondering if the problem under cygwin is a memcpy issue. > [...] >> I will try find out exactly how big the buffer is actually getting in >> this. I just need to identify exactly which buffer I need to be paying >> attention to :) I'll also just drop MAX_HPN_LEN to 10MB and see what >> happens. > > The existing buffer limit is 10MB so unless you have paths with a > BDP/TCPWINSZ of 10MB or higher (do you?) then I think you'll see your > throughput go up a little or your CPU and memory utilization go down a > little. Great that 10MB? Oh yes, frequently. I know its not common in the really real world yet but we're working on 30Gb/s end to end paths at this point. There are some specialized transfer tools to make better use of these paths but they tend to be a bit of a pain (various globus tools and GridFTP for example). Obviously, most people won't be working on this but again, its just a matter of time until 10MB is too small. It might be another 5 years but gigabit connectivity to the home is coming - its already pretty common on college campuses. However, you are right in that the current size is probably far to high though at .5GB. I think our original thinking is that in almost all situations the buffer wouldn't grow that high and we might as well future proof it as much as possible. > At the moment, you do this in channel.c: > -limit = MIN(limit, (BUFFER_MAX_LEN - BUFFER_MAX_CHUNK - CHAN_RBUF)); > +limit = MIN(limit, (BUFFER_MAX_HPN_LEN-BUFFER_MAX_CHUNK-CHAN_RBUF)); > > Instead, I suggest leaving the existing line and adding something like: > limit = MIN(limit, gettcpwinsz()); > or > limit = MIN(limit, 2 * gettcpwinsz()); Okay, I'll give that a try. > That way the buffer utilization would scale with your window size. > > BTW hpn12 doesn't seem to be on your web page? Its there, just not advertised until I resolve this issue. :) http://www.psc.edu/networking/projects/hpn-ssh/openssh-4.3p2-hpn12.diff > If a similar bottleneck applies to pipe/socketpairs, it may also be work > increasing the IO buffer in scp and seeing if that helps your > performance (the HPN patch bumps it from 2k to 16k, you may want to bump > it to 64k). I know we got a 2-3% reduction in cpu when we made that switch but I don't think it actually scaled linearly. Of course, this was under linux and os x so the effect under cygwin or *BSD might be much different. Chris From rapier at psc.edu Thu Apr 6 08:23:29 2006 From: rapier at psc.edu (Chris Rapier) Date: Wed, 05 Apr 2006 18:23:29 -0400 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <44332D2A.9040805@zip.com.au> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> Message-ID: <44344361.6090101@psc.edu> Darren Tucker wrote: > The existing buffer limit is 10MB so unless you have paths with a > BDP/TCPWINSZ of 10MB or higher (do you?) then I think you'll see your > throughput go up a little or your CPU and memory utilization go down a > little. I've changed this to 32MB. This should handle up to 3.2Gbps at 80ms RTT - which is a little low for some applications. However, I think I have a way to handle this later on. > At the moment, you do this in channel.c: > -limit = MIN(limit, (BUFFER_MAX_LEN - BUFFER_MAX_CHUNK - CHAN_RBUF)); > +limit = MIN(limit, (BUFFER_MAX_HPN_LEN-BUFFER_MAX_CHUNK-CHAN_RBUF)); > > Instead, I suggest leaving the existing line and adding something like: > limit = MIN(limit, gettcpwinsz()); > or > limit = MIN(limit, 2 * gettcpwinsz()); I made this change. It only checks multiple times if the option to do tcp buffer polling is enabled. It stores the channels associated connections window size in c->tcpwinsz now. I also cleaned up some other stuff in channel.c for the sake of clarity and cleaned up some logic errors in other locations. This latest version of the patch can be found at http://www.psc.edu/networking/projects/hpn-ssh/hpn12v5.diff.gz Usage notes can be found at http://www.psc.edu/networking/projects/hpn-ssh/ssh-hpn12.notes Let me know if anyone finds anything out vis a vis performance. I didn't have the time to test it for anything except functionality today. Its been an annoyingly busy day. From drathi at informatica.com Thu Apr 6 18:14:00 2006 From: drathi at informatica.com (Rathi, Dinesh) Date: Thu, 6 Apr 2006 13:44:00 +0530 Subject: openssh as sftp shared library Message-ID: <02E7FA106DF5944BB0571C25A9243DE626FC5B@in23ex01.informatica.com> Hi Has anyone built openssh src a library and tried using it in an application to do ssh connections/ sftp file transfers? I was wondering if openssh src is multithread safe i.e. if I use it as a library then can I open multiple simultaneous ssh/ sftp connections and do transfer in parallel? Thanks Dinesh From jhumphre at ciena.com Fri Apr 7 02:16:34 2006 From: jhumphre at ciena.com (Humphreys, James) Date: Thu, 6 Apr 2006 12:16:34 -0400 Subject: OpenSSH 4.3 support for TLS in OpenSSL 0.9.8 Message-ID: <0630EE0825D54A429237369546320407013B2391@mdmxm01.ciena.com> Does OpenSSH 4.3 support the use of the TLS ciphersuites that are supported in OpenSSL 0.9.8? If so, is this a compile time option or a run-time option? Or can ssh and sshd support both the SSL and TLS ciphersuites at the same time? Jim Humphreys From jhumphre at ciena.com Fri Apr 7 02:05:45 2006 From: jhumphre at ciena.com (Humphreys, James) Date: Thu, 6 Apr 2006 12:05:45 -0400 Subject: No subject Message-ID: <0630EE0825D54A429237369546320407013B238B@mdmxm01.ciena.com> Does OpenSSH 4.3 support the use of the TLS ciphersuites that are supported in OpenSSL? If so, is this a compile time option or a run-time option? Or can sshd support both the SSL and TLS ciphersuites at the same time? Jim Humphreys From djm at mindrot.org Fri Apr 7 07:19:07 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 7 Apr 2006 07:19:07 +1000 (EST) Subject: your mail In-Reply-To: <0630EE0825D54A429237369546320407013B238B@mdmxm01.ciena.com> References: <0630EE0825D54A429237369546320407013B238B@mdmxm01.ciena.com> Message-ID: On Thu, 6 Apr 2006, Humphreys, James wrote: > > Does OpenSSH 4.3 support the use of the TLS ciphersuites that are > supported in OpenSSL? > If so, is this a compile time option or a run-time option? Or can sshd > support both the SSL and TLS ciphersuites at the same time? OpenSSH doesn't use SSL or TLS - the SSH protocol defines its own transport protocol which is a little different. Have a look at the "Ciphers" and "MACs" options in ssh_config(5) to see what cryptographic methods are supported. -d From don-temp28 at isis.cs3-inc.com Fri Apr 7 07:39:36 2006 From: don-temp28 at isis.cs3-inc.com (Don Cohen) Date: Thu, 6 Apr 2006 14:39:36 -0700 (PDT) Subject: problem specifying port to ssh Message-ID: <20060406213936.55D981A818F@isis.cs3-inc.com> Here's the behavior I see: # ssh don at isis.cs3-inc.com date Thu Apr 6 14:19:16 PDT 2006 # ssh -p 22 don at isis.cs3-inc.com date ssh: isis.cs3-inc.com: System error These ought to be the same thing, since the default port is 22. Whatever port I try to use (other than not specifying one at all) seems to give the same problem. This is on one particular linux (FC4) machine (2.6.15-1.1831_FC4) ssh -V => OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005 I don't see the problem on other machines, and in fact it seems to be a recent problem even on this machine. I don't think I've changed ssh on this machine, so it's probably some other change. The question is what could cause this. If anyone has an idea of what the change might have been that caused it, or how to fix it, I'll be happy to hear about that too. Please respond to me (as well as the list) since I'm not subscribed. From djm at mindrot.org Fri Apr 7 07:48:27 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 7 Apr 2006 07:48:27 +1000 (EST) Subject: problem specifying port to ssh In-Reply-To: <20060406213936.55D981A818F@isis.cs3-inc.com> References: <20060406213936.55D981A818F@isis.cs3-inc.com> Message-ID: On Thu, 6 Apr 2006, Don Cohen wrote: > > Here's the behavior I see: > # ssh don at isis.cs3-inc.com date > Thu Apr 6 14:19:16 PDT 2006 > # ssh -p 22 don at isis.cs3-inc.com date > ssh: isis.cs3-inc.com: System error Please send a debug trace: ssh -vvvp 22 don at isis.cs3-inc.com date Thanks -d From don-temp28 at isis.cs3-inc.com Fri Apr 7 07:55:28 2006 From: don-temp28 at isis.cs3-inc.com (Don Cohen) Date: Thu, 6 Apr 2006 14:55:28 -0700 Subject: problem specifying port to ssh In-Reply-To: References: <20060406213936.55D981A818F@isis.cs3-inc.com> Message-ID: <17461.36432.141543.76919@isis.cs3-inc.com> Damien Miller writes: > On Thu, 6 Apr 2006, Don Cohen wrote: > > > > > Here's the behavior I see: > > # ssh don at isis.cs3-inc.com date > > Thu Apr 6 14:19:16 PDT 2006 > > # ssh -p 22 don at isis.cs3-inc.com date > > ssh: isis.cs3-inc.com: System error > > Please send a debug trace: > > ssh -vvvp 22 don at isis.cs3-inc.com date [root at don-eve tmp]# ssh -vvvp 22 don at isis.cs3-inc.com OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 ssh: isis.cs3-inc.com: System error I actually tried it with strace - about 16KB - want it? How about the last page or so: open("/etc/hosts", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=665, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f61000 read(3, "# Do not remove the following li"..., 4096) = 665 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7f61000, 4096) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=153614, ...}) = 0 old_mmap(NULL, 153614, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f3c000 close(3) = 0 open("/lib/libnss_nisplus.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\31"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=51084, ...}) = 0 old_mmap(NULL, 45564, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x6ac000 old_mmap(0x6b6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9000) = 0x6b6000 close(3) = 0 mprotect(0x6b6000, 4096, PROT_READ) = 0 munmap(0xb7f3c000, 153614) = 0 uname({sys="Linux", node="don-eve.dyndns.org", ...}) = 0 write(2, "ssh: isis.cs3-inc.com: System er"..., 37ssh: isis.cs3-inc.com: System error ) = 37 From djm at mindrot.org Fri Apr 7 08:04:06 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 7 Apr 2006 08:04:06 +1000 (EST) Subject: problem specifying port to ssh In-Reply-To: <17461.36432.141543.76919@isis.cs3-inc.com> References: <20060406213936.55D981A818F@isis.cs3-inc.com> <17461.36432.141543.76919@isis.cs3-inc.com> Message-ID: It looks like your /etc/nsswitch.conf or one of the supporting libraries is messed up - it is failing inside a getaddrinfo() call, probably in /lib/libnss_nisplus.so.2 -d On Thu, 6 Apr 2006, Don Cohen wrote: > Damien Miller writes: > > On Thu, 6 Apr 2006, Don Cohen wrote: > > > > > > > > Here's the behavior I see: > > > # ssh don at isis.cs3-inc.com date > > > Thu Apr 6 14:19:16 PDT 2006 > > > # ssh -p 22 don at isis.cs3-inc.com date > > > ssh: isis.cs3-inc.com: System error > > > > Please send a debug trace: > > > > ssh -vvvp 22 don at isis.cs3-inc.com date > [root at don-eve tmp]# ssh -vvvp 22 don at isis.cs3-inc.com > OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug2: ssh_connect: needpriv 0 > ssh: isis.cs3-inc.com: System error > > I actually tried it with strace - about 16KB - want it? > How about the last page or so: > > open("/etc/hosts", O_RDONLY) = 3 > fcntl64(3, F_GETFD) = 0 > fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 > fstat64(3, {st_mode=S_IFREG|0644, st_size=665, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f61000 > read(3, "# Do not remove the following li"..., 4096) = 665 > read(3, "", 4096) = 0 > close(3) = 0 > munmap(0xb7f61000, 4096) = 0 > open("/etc/ld.so.cache", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=153614, ...}) = 0 > old_mmap(NULL, 153614, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f3c000 > close(3) = 0 > open("/lib/libnss_nisplus.so.2", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\31"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=51084, ...}) = 0 > old_mmap(NULL, 45564, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x6ac000 > old_mmap(0x6b6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9000) = 0x6b6000 > close(3) = 0 > mprotect(0x6b6000, 4096, PROT_READ) = 0 > munmap(0xb7f3c000, 153614) = 0 > uname({sys="Linux", node="don-eve.dyndns.org", ...}) = 0 > write(2, "ssh: isis.cs3-inc.com: System er"..., 37ssh: isis.cs3-inc.com: System error > > ) = 37 > From don-temp28 at isis.cs3-inc.com Fri Apr 7 08:16:32 2006 From: don-temp28 at isis.cs3-inc.com (Don Cohen) Date: Thu, 6 Apr 2006 15:16:32 -0700 Subject: problem specifying port to ssh In-Reply-To: References: <20060406213936.55D981A818F@isis.cs3-inc.com> <17461.36432.141543.76919@isis.cs3-inc.com> Message-ID: <17461.37696.942070.989736@isis.cs3-inc.com> Damien Miller writes: > It looks like your /etc/nsswitch.conf or one of the supporting libraries > is messed up - it is failing inside a getaddrinfo() call, probably > in /lib/libnss_nisplus.so.2 I actually did look at that. This from dired of /etc -rw-r--r-- 1 root root 1750 Sep 8 2005 nsswitch.conf -rw-r--r-- 1 root root 1696 Sep 22 2004 nsswitch.conf.rpmnew suggests that on Sep 8 that file was replaced. But that's too long ago to account for the problem, since I do use ssh -p fairly regularly. The difference between the two files is that the current one contains files nisplus in a lot of places where the other contains only files But I don't understand how this is related to supplying a port. From Jefferson.Ogata at noaa.gov Fri Apr 7 09:04:59 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 06 Apr 2006 19:04:59 -0400 Subject: sshd config parser In-Reply-To: <443351C8.2040406@zip.com.au> References: <442A890C.9050003@zip.com.au> <20060401111919.GA6812@gate.dtucker.net> <20060401131024.GA8769@gate.dtucker.net> <20060402024330.GA11219@gate.dtucker.net> <44327444.8040107@noaa.gov> <4432EB63.7010102@zip.com.au> <44333B94.4030603@noaa.gov> <443351C8.2040406@zip.com.au> Message-ID: <44359E9B.1040909@noaa.gov> On 04/05/2006 01:12 AM, Darren Tucker wrote: > Jefferson Ogata wrote: >>>>2. How does "Host" with wildcards interact with DNS? E.g. will "Host >>>>192.168.0.*" match 192.168.0.evil.domain? >>> >>>It would, which is why... >> >>Oh, my. Don't you think this is going to lead to unexpected results? I'm >>a bit concerned that people won't realize that DNS is an issue... > > The whole idea of having a "Address" and "Host" as distinct entities is > that if you want to match an address you use "Address" and if you want > to match a hostname you use "Host". I follow that. But I'm concerned that people won't expect that Host will behave the way you describe even with an all-numeric + wildcard value such as 192.168.0.*. >>Could sshd default not to use inverse DNS in Host matches unless another >>config directive were enabled? > > That would be "UseDNS", no? >From the description: UseDNS Specifies whether sshd should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is ``yes. it looks to me as if UseDNS controls paranoid lookups. That's an independent issue. An attacker with control over his own DNS can arrange that paranoid checks will succeed. That is, attacking-ip.in-addr.arpa => 192.168.0.evil.domain, and 192.168.0.evil.domain => attacking-ip. I'm saying perhaps Host should default to ignoring DNS entirely. Or, failing that, if the argument to Host matches [0-9\.\*]+ it could behave like Address. In fact, Address might be unnecessary in this case. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From dtucker at zip.com.au Fri Apr 7 09:43:06 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 07 Apr 2006 09:43:06 +1000 Subject: problem specifying port to ssh In-Reply-To: <17461.37696.942070.989736@isis.cs3-inc.com> References: <20060406213936.55D981A818F@isis.cs3-inc.com> <17461.36432.141543.76919@isis.cs3-inc.com> <17461.37696.942070.989736@isis.cs3-inc.com> Message-ID: <4435A78A.8050307@zip.com.au> Don Cohen wrote: > Damien Miller writes: > > It looks like your /etc/nsswitch.conf or one of the supporting libraries > > is messed up - it is failing inside a getaddrinfo() call, probably > > in /lib/libnss_nisplus.so.2 > > I actually did look at that. > This from dired of /etc > -rw-r--r-- 1 root root 1750 Sep 8 2005 nsswitch.conf > -rw-r--r-- 1 root root 1696 Sep 22 2004 nsswitch.conf.rpmnew > suggests that on Sep 8 that file was replaced. No, it suggests that it was replaced with a file that was last modified on Sep 8 2005. When that occurred is not necessarily the same time (compare with the inode creation time: "ls -lc"). > But that's too long ago to account for the problem, since I do use > ssh -p fairly regularly. > The difference between the two files is that the current one contains > files nisplus in a lot of places where the other contains only files You might also want to check the "services" entry in nsswitch.conf. > But I don't understand how this is related to supplying a port. The port number is passed to getaddrinfo() along with the hostname. It would appear that your system can handle hostname alone, but isn't happy with both. -- 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 Jefferson.Ogata at noaa.gov Fri Apr 7 10:05:35 2006 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 06 Apr 2006 20:05:35 -0400 Subject: problem specifying port to ssh In-Reply-To: <4435A78A.8050307@zip.com.au> References: <20060406213936.55D981A818F@isis.cs3-inc.com> <17461.36432.141543.76919@isis.cs3-inc.com> <17461.37696.942070.989736@isis.cs3-inc.com> <4435A78A.8050307@zip.com.au> Message-ID: <4435ACCF.1000505@noaa.gov> The strace excerpt you posted was too close to the end and may simply have reflected a hostname lookup needed for a syslog call. I suggest you post a substantially larger excerpt. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From don-temp28 at isis.cs3-inc.com Fri Apr 7 10:32:02 2006 From: don-temp28 at isis.cs3-inc.com (Don Cohen) Date: Thu, 6 Apr 2006 17:32:02 -0700 Subject: problem specifying port to ssh In-Reply-To: <4435A78A.8050307@zip.com.au> References: <20060406213936.55D981A818F@isis.cs3-inc.com> <17461.36432.141543.76919@isis.cs3-inc.com> <17461.37696.942070.989736@isis.cs3-inc.com> <4435A78A.8050307@zip.com.au> Message-ID: <17461.45826.31115.568369@isis.cs3-inc.com> Darren Tucker writes: > Don Cohen wrote: > > Damien Miller writes: > > > It looks like your /etc/nsswitch.conf or one of the supporting libraries > > > is messed up - it is failing inside a getaddrinfo() call, probably > > > in /lib/libnss_nisplus.so.2 > > > > I actually did look at that. > > This from dired of /etc > > -rw-r--r-- 1 root root 1750 Sep 8 2005 nsswitch.conf > > -rw-r--r-- 1 root root 1696 Sep 22 2004 nsswitch.conf.rpmnew > > suggests that on Sep 8 that file was replaced. > > No, it suggests that it was replaced with a file that was last modified > on Sep 8 2005. When that occurred is not necessarily the same time > (compare with the inode creation time: "ls -lc"). $ ls -lc /etc/nsswitch.conf -rw-r--r-- 1 root root 1750 Sep 8 2005 /etc/nsswitch.conf Never the less, switching these two files does seem to solve the problem. The man page is not very clear on what all this means. Here are the differences - is what works, + is what doesn't. I'd have expected that "files" would give one way to do a lookup and "files nisplus" would only give another way when the first failed. So I expected the new file to work in a SUPERset of cases of the old one, not a strict SUBset. What is the truth of the matter (and where can I see it other than asking)? --- /etc/nsswitch.conf 2004-09-22 18:17:12.000000000 -0700 +++ /etc/nsswitch.conf.new 2005-09-08 15:18:43.000000000 -0700 -passwd: files -shadow: files -group: files +passwd: files nisplus +shadow: files nisplus +group: files nisplus -hosts: files dns +hosts: files nisplus dns The problem seems to be that nisplus comes before dns above. If I add nisplus at the end things still work, if I put it before dns then they don't. So perhaps nisplus fails in some way that causes dns to not be attempted? And what is this nisplus anyhow? Is it supposed to be installed, configured and running in every linux? If it's not perhaps that's the problem? -protocols: files +protocols: files nisplus -services: files +services: files nisplus -netgroup: nisplus +netgroup: files nisplus > You might also want to check the "services" entry in nsswitch.conf. I gather that adding nisplus gives an alternative way of finding a service if not in /etc/services. But I don't see what you thought might be there or what I was supposed to look for. > > But I don't understand how this is related to supplying a port. > The port number is passed to getaddrinfo() along with the hostname. It > would appear that your system can handle hostname alone, but isn't happy > with both. You mean I can somehow arrange that ssh -p 22 isis.cs3-inc.com and ssh -p 2222 isis.cs3-inc.com resolve to different IP addresses? How? Thanks for your help. From dtucker at zip.com.au Fri Apr 7 11:06:27 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 07 Apr 2006 11:06:27 +1000 Subject: problem specifying port to ssh In-Reply-To: <17461.45826.31115.568369@isis.cs3-inc.com> References: <20060406213936.55D981A818F@isis.cs3-inc.com> <17461.36432.141543.76919@isis.cs3-inc.com> <17461.37696.942070.989736@isis.cs3-inc.com> <4435A78A.8050307@zip.com.au> <17461.45826.31115.568369@isis.cs3-inc.com> Message-ID: <4435BB13.5060508@zip.com.au> Don Cohen wrote: [...] > -rw-r--r-- 1 root root 1750 Sep 8 2005 /etc/nsswitch.conf > > Never the less, switching these two files does seem to solve the > problem. The man page is not very clear on what all this means. > Here are the differences - is what works, + is what doesn't. If you were so inclined you could write a little program to call getaddrinfo directly to experiment with it; I suspect you would see the same errors. [...] > You mean I can somehow arrange that > ssh -p 22 isis.cs3-inc.com > and ssh -p 2222 isis.cs3-inc.com > resolve to different IP addresses? How? The getaddrinfo interface seems to allow it although I've never seen it done. I would guess that you would need to write your own nss module. > Thanks for your help. You're welcome. -- 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 dkg-openssh.com at fifthhorseman.net Fri Apr 7 11:07:04 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 6 Apr 2006 21:07:04 -0400 Subject: problem specifying port to ssh In-Reply-To: <17461.45826.31115.568369@isis.cs3-inc.com> References: <20060406213936.55D981A818F@isis.cs3-inc.com> <17461.36432.141543.76919@isis.cs3-inc.com> <17461.37696.942070.989736@isis.cs3-inc.com> <4435A78A.8050307@zip.com.au> <17461.45826.31115.568369@isis.cs3-inc.com> Message-ID: <17461.47928.172528.126405@localhost.localdomain> On April 6, don-temp28 at isis.cs3-inc.com said: > The problem seems to be that nisplus comes before dns above. > If I add nisplus at the end things still work, > if I put it before dns then they don't. > So perhaps nisplus fails in some way that causes dns to not be > attempted? And what is this nisplus anyhow? Is it supposed to > be installed, configured and running in every linux? If it's not > perhaps that's the problem? nisplus relies on a NIS+ server being present (and configured). If your workstation is looking for NIS+ information from a host that is not providing it, it probably will fail. These days, if you don't know for sure that you need NIS+ in your environment, you probably don't need it. It's actually a potential security risk also. What does the following command show when your system is in the "does not work" configuration: getent services 22 a normal system with glibc and a well-configured /etc/nsswitch.conf should respond something like: [dkg at squeak ~]$ getent services 22 ssh 22/tcp [dkg at squeak ~]$ > You mean I can somehow arrange that > ssh -p 22 isis.cs3-inc.com > and ssh -p 2222 isis.cs3-inc.com > resolve to different IP addresses? How? it's not to different IP addresses, but rather different sockets. from man getaddrinfo (note mention of getservbyname): The getaddrinfo(3) function combines the functionality provided by the getipnodebyname(3), getipnodebyaddr(3), getservbyname(3), and getservbyport(3) functions into a single interface. The thread-safe getaddrinfo(3) function creates one or more socket address structures that can be used by the bind(2) and connect(2) system calls to create a client or a server socket. So getaddrinfo can create full socket addresses (which, for TCP or UDP sockets, would contain port numbers). Passing the string "22" to the service argument to getaddrinfo() will force a lookup via the name service switch (which is configured via /etc/nsswitch.conf). hope this helps, --dkg From don-temp28 at isis.cs3-inc.com Fri Apr 7 11:47:03 2006 From: don-temp28 at isis.cs3-inc.com (Don Cohen) Date: Thu, 6 Apr 2006 18:47:03 -0700 Subject: problem specifying port to ssh In-Reply-To: <17461.47928.172528.126405@localhost.localdomain> References: <20060406213936.55D981A818F@isis.cs3-inc.com> <17461.36432.141543.76919@isis.cs3-inc.com> <17461.37696.942070.989736@isis.cs3-inc.com> <4435A78A.8050307@zip.com.au> <17461.45826.31115.568369@isis.cs3-inc.com> <17461.47928.172528.126405@localhost.localdomain> Message-ID: <17461.50327.64840.254563@isis.cs3-inc.com> Daniel Kahn Gillmor writes: > nisplus relies on a NIS+ server being present (and configured). If > your workstation is looking for NIS+ information from a host that is > not providing it, it probably will fail. In which case a well behaved glibc would go on to use the next method in the list. So I think this is a bug. > What does the following command show when your system is in the "does > not work" configuration: > getent services 22 > a normal system with glibc and a well-configured /etc/nsswitch.conf > should respond something like: > ssh 22/tcp It shows that in either configuration, which is what I'd expect since that's what's in /etc/services, and files comes first. > > You mean I can somehow arrange that > > ssh -p 22 isis.cs3-inc.com > > and ssh -p 2222 isis.cs3-inc.com > > resolve to different IP addresses? How? > it's not to different IP addresses, but rather different sockets. How (if at all) does that affect the network traffic that goes out? > from man getaddrinfo (note mention of getservbyname): > > The getaddrinfo(3) function combines the functionality provided by > the getipnodebyname(3), getipnodebyaddr(3), getservbyname(3), and > getservbyport(3) functions into a single interface. The thread-safe > getaddrinfo(3) function creates one or more socket address structures > that can be used by the bind(2) and connect(2) system calls to create > a client or a server socket. > > So getaddrinfo can create full socket addresses (which, for TCP or UDP > sockets, would contain port numbers). Passing the string "22" to the > service argument to getaddrinfo() will force a lookup via the name > service switch (which is configured via /etc/nsswitch.conf). This still doesn't explain why ssh -p 22 should be any different from ssh without -p at all. I'd expect the same underlying call to one of the functions above, and I would expect the attempt to resolve the host name to not depend on the port at all. From dkg-openssh.com at fifthhorseman.net Fri Apr 7 13:15:10 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 6 Apr 2006 23:15:10 -0400 Subject: problem specifying port to ssh In-Reply-To: <17461.50327.64840.254563@isis.cs3-inc.com> References: <20060406213936.55D981A818F@isis.cs3-inc.com> <17461.36432.141543.76919@isis.cs3-inc.com> <17461.37696.942070.989736@isis.cs3-inc.com> <4435A78A.8050307@zip.com.au> <17461.45826.31115.568369@isis.cs3-inc.com> <17461.47928.172528.126405@localhost.localdomain> <17461.50327.64840.254563@isis.cs3-inc.com> Message-ID: <17461.55614.902655.281470@localhost.localdomain> On April 6, don-temp28 at isis.cs3-inc.com said: > Daniel Kahn Gillmor writes: > > > nisplus relies on a NIS+ server being present (and configured). If > > your workstation is looking for NIS+ information from a host that is > > not providing it, it probably will fail. > In which case a well behaved glibc would go on to use the next method > in the list. So I think this is a bug. i agree: it sounds like this could potentially be a bug in your nisplus nss module, for example. > This still doesn't explain why ssh -p 22 should be any different > from ssh without -p at all. I'd expect the same underlying call > to one of the functions above, and I would expect the attempt to > resolve the host name to not depend on the port at all. huh. this is odd. from what Darren Tucker said: > > > The port number is passed to getaddrinfo() along with the > > > hostname. It would appear that your system can handle hostname > > > alone, but isn't happy with both. i'd expected that if you didn't supply the port, openssh would just call getaddrinfo("isis.cs3-inc.com", NULL, ...) and then set aitop->ai_addr->sin_port to 22 explicitly. but (at least on my debian etch/sid system here) reviewing ssh_connect() (in sshconnect.c [0]) shows that's not the case, and you're right that it does appear to be the same call to getaddrinfo: [dkg at squeak ~]$ ltrace -e getaddrinfo ssh fubar getaddrinfo("fubar", "22", 0xbfe30c00, 0xbfe30c64) = -2 ssh: fubar: Name or service not known +++ exited (status 255) +++ [dkg at squeak ~]$ ltrace -e getaddrinfo ssh -p 22 fubar getaddrinfo("fubar", "22", 0xbfd765f0, 0xbfd76654) = -2 ssh: fubar: Name or service not known +++ exited (status 255) +++ [dkg at squeak ~]$ ssh -V OpenSSH_4.2p1 Debian-8.dkg1, OpenSSL 0.9.8a 11 Oct 2005 [dkg at squeak ~]$ What does your FC4 version of openssh-4.2p1 do with this library call? --dkg [0] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshconnect.c?rev=1.180&content-type=text/x-cvsweb-markup From don-temp28 at isis.cs3-inc.com Fri Apr 7 14:37:27 2006 From: don-temp28 at isis.cs3-inc.com (Don Cohen) Date: Thu, 6 Apr 2006 21:37:27 -0700 Subject: problem specifying port to ssh In-Reply-To: <17461.55614.902655.281470@localhost.localdomain> References: <20060406213936.55D981A818F@isis.cs3-inc.com> <17461.36432.141543.76919@isis.cs3-inc.com> <17461.37696.942070.989736@isis.cs3-inc.com> <4435A78A.8050307@zip.com.au> <17461.45826.31115.568369@isis.cs3-inc.com> <17461.47928.172528.126405@localhost.localdomain> <17461.50327.64840.254563@isis.cs3-inc.com> <17461.55614.902655.281470@localhost.localdomain> Message-ID: <17461.60551.695180.263955@isis.cs3-inc.com> Daniel Kahn Gillmor writes: > [dkg at squeak ~]$ ltrace -e getaddrinfo ssh fubar > getaddrinfo("fubar", "22", 0xbfe30c00, 0xbfe30c64) = -2 > ssh: fubar: Name or service not known > +++ exited (status 255) +++ > [dkg at squeak ~]$ ltrace -e getaddrinfo ssh -p 22 fubar > getaddrinfo("fubar", "22", 0xbfd765f0, 0xbfd76654) = -2 > ssh: fubar: Name or service not known > +++ exited (status 255) +++ > [dkg at squeak ~]$ ssh -V > OpenSSH_4.2p1 Debian-8.dkg1, OpenSSL 0.9.8a 11 Oct 2005 > [dkg at squeak ~]$ > What does your FC4 version of openssh-4.2p1 do with this library call? It seems not to call getaddrinfo at all. Or any of the others described in the earlier message. [root at don-eve tmp]# ltrace -e getaddrinfo ssh -p 22 fubar ssh: fubar: Name or service not known +++ exited (status 255) +++ [root at don-eve tmp]# ltrace -e getaddrinfo ssh -p 22 google.com --- SIGINT (Interrupt) --- +++ killed by SIGINT +++ [root at don-eve tmp]# ltrace -e getaddrinfo ssh -p 22 isis.cs3-inc.com root at isis.cs3-inc.com's password: --- SIGINT (Interrupt) --- From jhumphre at ciena.com Sat Apr 8 02:34:12 2006 From: jhumphre at ciena.com (Humphreys, James) Date: Fri, 7 Apr 2006 12:34:12 -0400 Subject: your mail Message-ID: <0630EE0825D54A429237369546320407013B2669@mdmxm01.ciena.com> > On Thu, 6 Apr 2006, Miller, Damien wrote: > > > > > Does OpenSSH 4.3 support the use of the TLS ciphersuites that are > > supported in OpenSSL? > > If so, is this a compile time option or a run-time option? > Or can sshd > > support both the SSL and TLS ciphersuites at the same time? > > OpenSSH doesn't use SSL or TLS - the SSH protocol defines its > own transport protocol which is a little different. Have a > look at the "Ciphers" and "MACs" options in ssh_config(5) to > see what cryptographic methods are supported. > > -d > My initial question was a bit misleading. I realize that SSH and SSL have different ways of specifying what ciphers and MACs are supported and different ways of negotiating the setup of the transport layer. SSH uses its Algorithm Negotiation packet while SSL uses its Client and Server HELLO messages and its CipherSuite definitions. Comparing the fields in the SSH Algorithm Negotiation message against the definition of a CipherSuite (as used by SSL), you'll see that they specify the same information components. Now, my understanding, which may be flawed, is that SSH and SSL use the same crypto library. SSLv3 support both the SSL and newer TLS CipherSuite which are required for FIPS-140 and DISA certification. This leads to my real question of whether SSH is DISA / FIPS-140 compliant and, if so, how is that achieved. Looking at the SSH Algorithm Negotiation message, it appears that there isn't any field in the message that specifies how the shared symmetric encryption key is generated. Looking at ssh_config(5), I can see where and how the supported ciphers are specified. But there is no place in the negotiation message where the shared key generation mechanism is specified. So if I configure sshd to support, say 3des-cbc, how does the daemon know which mechanism to use to generate the shared symmetric key for the session. And how do the SSH client and server communicate which mechanism they can support so that the two endpoints know if a connection setup is even possible? Jim From dtucker at zip.com.au Sat Apr 8 12:46:08 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 Apr 2006 12:46:08 +1000 Subject: your mail In-Reply-To: <0630EE0825D54A429237369546320407013B2669@mdmxm01.ciena.com> References: <0630EE0825D54A429237369546320407013B2669@mdmxm01.ciena.com> Message-ID: <443723F0.4070401@zip.com.au> Humphreys, James wrote: > Now, my understanding, which may be flawed, is that SSH and SSL > use the same crypto library. No. One SSH implementation (OpenSSH) happens to use the crypto library from an SSL implementation (OpenSSL). There's no requirement for this to be so, and many other SSH implementations either have their own crypto code or use something else. > SSLv3 support both the SSL and > newer TLS CipherSuite which are required for FIPS-140 and DISA > certification. This leads to my real question of whether SSH is > DISA / FIPS-140 compliant and, if so, how is that achieved. I don't know about DISA, but as far as FIPS-140 goes a given SSH implementation might be, but AFAIK OpenSSH isn't. There was apparently some work toward FIPS-140 certification (see the list archives) but I don't know if anything ever came from that. I believe one sticking point would be the use of MD5 for key fingerprints since MD5 isn't permitted by FIPS. Another is that OpenSSH has some of its own crypto code (eg rijndael/aes for older platforms), which I imagine would have to be either disabled or certified. > Looking at the SSH Algorithm Negotiation message, it appears > that there isn't any field in the message that specifies how the > shared symmetric encryption key is generated. Looking at > ssh_config(5), I can see where and how the supported ciphers are > specified. As far as I know, no permitted algorithms are specified by FIPS-140-2 for session key negotiation are permitted at all. > But there is no place in the negotiation message > where the shared key generation mechanism is specified. So if I > configure sshd to support, say 3des-cbc, how does the daemon know > which mechanism to use to generate the shared symmetric key for > the session. In OpenSSH, the shared session key is always negotiated via Diffie-Hellman. The protocol could support others (and in fact RFC4432 specifies one based on RSA), but OpenSSH doesn't. If you run "ssh -vvv yourserver" you will see something like this (all on one line): debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256, diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1, diffie-hellman-group1-sha1 The first two methods use random DH groups from the set in the "moduli" file on the server, using SHA256 or SHA1 hashes respectively. The latter two use fixed DH groups specified in the SSH RFCs (which happen to be a subset of the ones supported by IKE). -- 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 av at simcon-mt.com Sat Apr 8 18:39:59 2006 From: av at simcon-mt.com (Andrei A. Voropaev) Date: Sat, 8 Apr 2006 10:39:59 +0200 Subject: segfaulting on x86_64 for latest version Message-ID: <20060408083959.GA5277@vandal.simcon-mt.de> Hi! I've downloaded yesterday the version openssh-4.3p2. Compiled and installed without problems. No optimization options were used, no PAM. sshd starts also without any problem. But when I try to connect to it, the connection is immidiately closed and I get in the dmesg the following sshd[5246]: segfault at 00002aaaaabbfe40 rip 00002aaaaaab0bf3 rsp 00007fffffef54d0 error 7 Here is the output from ldd libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x00002aaaaabc1000) libutil.so.1 => /lib/libutil.so.1 (0x00002aaaaae01000) libz.so.1 => /lib/libz.so.1 (0x00002aaaaaf05000) libnsl.so.1 => /lib/libnsl.so.1 (0x00002aaaab019000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002aaaab130000) libresolv.so.2 => /lib/libresolv.so.2 (0x00002aaaab265000) libc.so.6 => /lib/libc.so.6 (0x00002aaaab379000) libdl.so.2 => /lib/libdl.so.2 (0x00002aaaab597000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) I'm not subscribed to the list, so please send questions directly to me. Voropaev Andrei From av at simcon-mt.com Sat Apr 8 19:05:45 2006 From: av at simcon-mt.com (Andrei A. Voropaev) Date: Sat, 8 Apr 2006 11:05:45 +0200 Subject: segfaulting on x86_64 for latest version In-Reply-To: <20060408083959.GA5277@vandal.simcon-mt.de> References: <20060408083959.GA5277@vandal.simcon-mt.de> Message-ID: <20060408090545.GB22683@vandal.simcon-mt.de> On Sat, Apr 08, 2006 at 10:39:59AM +0200, Andrei A. Voropaev wrote: [...] > But when I try to connect to it, the connection is immidiately closed > and I get in the dmesg the following > > sshd[5246]: segfault at 00002aaaaabbfe40 rip 00002aaaaaab0bf3 rsp 00007fffffef54d0 error 7 Just wanted to add, that I tried previous version (4.2p1) with exactly the same problem. Finally I've stopped on 3.9p1, which works. Voropaev Andrei From dtucker at zip.com.au Sat Apr 8 20:11:13 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 Apr 2006 20:11:13 +1000 Subject: segfaulting on x86_64 for latest version In-Reply-To: <20060408083959.GA5277@vandal.simcon-mt.de> References: <20060408083959.GA5277@vandal.simcon-mt.de> Message-ID: <44378C41.4020106@zip.com.au> Andrei A. Voropaev wrote: > I've downloaded yesterday the version openssh-4.3p2. Compiled and > installed without problems. No optimization options were used, no PAM. > > sshd starts also without any problem. > > But when I try to connect to it, the connection is immidiately closed > and I get in the dmesg the following > > sshd[5246]: segfault at 00002aaaaabbfe40 rip 00002aaaaaab0bf3 rsp 00007fffffef54d0 error 7 What version of OpenSSL and zlib did you compile with? Could you please run ssh and sshd in debug mode and see where the crash occurs? (eg run "/path/to/sshd -ddd -p 2022" then connect to port 2022 with "ssh -vvv -p 2022 yourserver"). Also, if sshd generates a core dump, can you feed it to gdb and get a backtrace ("gdb /path/to/sshd core" the "bt"). -- 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 tryponraj at gmail.com Mon Apr 10 14:10:32 2006 From: tryponraj at gmail.com (ponraj) Date: Mon, 10 Apr 2006 09:40:32 +0530 Subject: Question on randomization Message-ID: <005301c65c54$b9677050$180110ac@pomco> Hi , I am using OpenSSH4.3p2. One of the fixes in this release says that random seed generation is not necessary for each key generation and initial seed will be served for the re-exec'ed processess. As better random seed will yield better random number generation, how can we achieve true randomization by one time random seed ? Thanks, Ponraj M From dan at D00M.lightwave.net.ru Tue Apr 11 03:56:19 2006 From: dan at D00M.lightwave.net.ru (Dan Yefimov) Date: Mon, 10 Apr 2006 21:56:19 +0400 (MSD) Subject: segfaulting on x86_64 for latest version In-Reply-To: <20060408083959.GA5277@vandal.simcon-mt.de> Message-ID: On Sat, 8 Apr 2006, Andrei A. Voropaev wrote: > Hi! > > I've downloaded yesterday the version openssh-4.3p2. Compiled and > installed without problems. No optimization options were used, no PAM. > > sshd starts also without any problem. > > But when I try to connect to it, the connection is immidiately closed > and I get in the dmesg the following > > sshd[5246]: segfault at 00002aaaaabbfe40 rip 00002aaaaaab0bf3 rsp 00007fffffef54d0 error 7 > > > Here is the output from ldd > > libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x00002aaaaabc1000) > libutil.so.1 => /lib/libutil.so.1 (0x00002aaaaae01000) > libz.so.1 => /lib/libz.so.1 (0x00002aaaaaf05000) > libnsl.so.1 => /lib/libnsl.so.1 (0x00002aaaab019000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002aaaab130000) > libresolv.so.2 => /lib/libresolv.so.2 (0x00002aaaab265000) > libc.so.6 => /lib/libc.so.6 (0x00002aaaab379000) > libdl.so.2 => /lib/libdl.so.2 (0x00002aaaab597000) > /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) > >From ldd output and kernel error line you provided I suspect a bug in your glibc, namely in dynamic loader /lib64/ld-linux-x86-64.so.2. OpenSSH 3.9p1 is fine with it, while later releases somehow provoke that bug. -- Sincerely Your, Dan. From dtucker at zip.com.au Tue Apr 11 08:11:18 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 11 Apr 2006 08:11:18 +1000 Subject: segfaulting on x86_64 for latest version In-Reply-To: References: Message-ID: <443AD806.9060006@zip.com.au> Dan Yefimov wrote: > On Sat, 8 Apr 2006, Andrei A. Voropaev wrote: >> But when I try to connect to it, the connection is immidiately closed >> and I get in the dmesg the following >> >> sshd[5246]: segfault at 00002aaaaabbfe40 rip 00002aaaaaab0bf3 rsp 00007fffffef54d0 error 7 [...] >>From ldd output and kernel error line you provided I suspect a bug in your > glibc, namely in dynamic loader /lib64/ld-linux-x86-64.so.2. OpenSSH 3.9p1 is > fine with it, while later releases somehow provoke that bug. For the record, after some off-list traffic this turned out to be the case: it's another instance of the glibc-namelookup-in-chroot crash. Creating a lib directory inside the chroot (or in the case "lib64" worked around the problem). The underlying bug in glibc has apparently been fixed at some point. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Tue Apr 11 10:52:24 2006 From: djm at mindrot.org (Damien Miller) Date: Tue, 11 Apr 2006 10:52:24 +1000 (EST) Subject: Question on randomization In-Reply-To: <005301c65c54$b9677050$180110ac@pomco> References: <005301c65c54$b9677050$180110ac@pomco> Message-ID: On Mon, 10 Apr 2006, ponraj wrote: > Hi , > > I am using OpenSSH4.3p2. One of the fixes in this release says that random > seed generation is not necessary for each key generation and initial seed > will be served for the re-exec'ed processess. As better random seed will > yield better random number generation, how can we achieve true randomization > by one time random seed ? For systems that lack an OpenSSL that has a internally seeded RNG (either by /dev/random or via PRNGd), we pass a random seed from the per-connection sshd (that is fork()ed after accept()ing a new connection) along with the sshd_config and (maybe) the ephemeral SSH protocol 1 key. This seed is extracted from OpenSSL's random pool on the parent and added to OpenSSL's random pool on the child. Technically it adds zero entropy to the child's pool, but practically it desynchronises the two pools to the point that it would require (at the very minimum) the existence of an effective pre-image attack on OpenSSL's random pool hash function (SHA1 by default). -d From steveshanks at thespeedwarecompany.com Tue Apr 11 14:31:09 2006 From: steveshanks at thespeedwarecompany.com (Steve Shanks) Date: Tue, 11 Apr 2006 00:31:09 -0400 Subject: Problem building openssh-4.3p2 under cygwin and windows XP Message-ID: <20060411043112.57B7D17E609@mail.mindrot.org> I am trying to build openssh-4.3p2 portable source under Cygwin running under Windows XP SP2. I have installed Cygwin 1.5.19-4 along with these significant packages (installed using the cygwin setup program): gcc 3.4.4-1 minires-devel 1.00-1 openssl 0.9.8a-1 openssl-devel 0.9.8a-1 openssl097 0.9.7i-1 tcp_wrappers 7.6-1 zlib 1.2.3-1 I used the instructions in openssh-4.3p2/contrib./cygwin/README which state to do If you want to build from source, the following options to configure are used for the Cygwin binary distribution: --prefix=/usr \ --sysconfdir=/etc \ --libexecdir='${sbindir}' \ --localstatedir=/var \ --datadir='${prefix}/share' \ --mandir='${datadir}/man' \ --infodir='${datadir}/info' \ --with-tcp-wrappers The configure run completes ok (and is logged as such in config.log). But when I try to make the software (command: make with no parameters), then I get the following errors: $ make if test ! -z ""; then \ ./fixprogs ssh_prng_cmds ; \ fi (cd openbsd-compat && make) make[1]: Entering directory `/home/Steve/openssh-4.3p2/openbsd-compat' gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -I. -I.. -I. -I./.. -DHAVE_CONFIG_H -c bsd-arc4random.c In file included from ../includes.h:206, from bsd-arc4random.c:17: ../defines.h:164:4: #error "8 bit int type not found." ../defines.h:176:5: #error "16 bit int type not found." ../defines.h:185:5: #error "32 bit int type not found." ../defines.h:201:5: #error "8 bit int type not found." ../defines.h:213:6: #error "16 bit int type not found." ../defines.h:222:6: #error "32 bit int type not found." ../defines.h:226:1: warning: "__BIT_TYPES_DEFINED__" redefined In file included from /usr/include/sys/types.h:372, from /usr/include/stdio.h:46, from ../includes.h:27, from bsd-arc4random.c:17: The source in defines.h has the following: #ifndef HAVE_INTXX_T # if (SIZEOF_CHAR == 1) typedef char int8_t; # else # error "8 bit int type not found." # endif Which means there is no define HAVE_INTXX_T and no define SIZEOF_CHAR. In the config.log, I can see the following at the end of the file: ---------------------------------------------------------- configure:26966: creating ./config.status ## ---------------------- ## ## Running config.status. ## ## ---------------------- ## This file was extended by OpenSSH config.status Portable, which was generated by GNU Autoconf 2.59. Invocation command line was CONFIG_FILES = CONFIG_HEADERS = CONFIG_LINKS = CONFIG_COMMANDS = $ ./config.status on K13 config.status:714: creating Makefile config.status:714: creating buildpkg.sh config.status:714: creating opensshd.init config.status:714: creating openbsd-compat/Makefile config.status:714: creating scard/Makefile config.status:714: creating ssh_prng_cmds config.status:714: creating survey.sh config.status:818: creating config.h config.status:1336: config.h is unchanged ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=i686-pc-cygwin ac_cv_build_alias=i686-pc-cygwin ac_cv_c_bigendian=no ac_cv_c_compiler_gnu=yes ac_cv_c_inline=inline ac_cv_cc_implements___FUNCTION__=yes ac_cv_cc_implements___func__=yes ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_exeext=.exe ac_cv_file___dev_ptc_=no ac_cv_file___dev_ptmx_=yes ac_cv_file___etc_default_login_=no ac_cv_func___b64_ntop=no ac_cv_func___b64_pton=no ac_cv_func__getlong=no ac_cv_func__getpty=no ac_cv_func__getshort=no ac_cv_func_arc4random=no ac_cv_func_asprintf=yes ac_cv_func_b64_ntop=no ac_cv_func_b64_pton=no ac_cv_func_bcopy=yes ac_cv_func_bindresvport_sa=no ac_cv_func_clock=yes ac_cv_func_closefrom=no ac_cv_func_daemon=yes ac_cv_func_dirfd=yes ac_cv_func_dirname=yes ac_cv_func_endutent=yes ac_cv_func_endutxent=yes ac_cv_func_fchmod=yes ac_cv_func_fchown=yes ac_cv_func_freeaddrinfo=no ac_cv_func_futimes=yes ac_cv_func_gai_strerror=no ac_cv_func_getaddrinfo=no ac_cv_func_getcwd=yes ac_cv_func_getgrouplist=no ac_cv_func_getnameinfo=no ac_cv_func_getopt=yes ac_cv_func_getpagesize=yes ac_cv_func_getpeereid=yes ac_cv_func_getpgrp_void=yes ac_cv_func_getrlimit=yes ac_cv_func_getspnam=no ac_cv_func_gettimeofday=yes ac_cv_func_getttyent=no ac_cv_func_getutent=yes ac_cv_func_getutid=yes ac_cv_func_getutline=yes ac_cv_func_getutxent=yes ac_cv_func_getutxid=yes ac_cv_func_getutxline=yes ac_cv_func_glob=yes ac_cv_func_inet_aton=yes ac_cv_func_inet_ntoa=yes ac_cv_func_inet_ntop=yes ac_cv_func_innetgr=no ac_cv_func_login_getcapbool=no ac_cv_func_logout=yes ac_cv_func_logwtmp=yes ac_cv_func_md5_crypt=no ac_cv_func_memmove=yes ac_cv_func_mkdtemp=yes ac_cv_func_mmap=yes ac_cv_func_ngetaddrinfo=no ac_cv_func_nsleep=no ac_cv_func_ogetaddrinfo=no ac_cv_func_openlog_r=no ac_cv_func_openpty=yes ac_cv_func_prctl=no ac_cv_func_pstat=no ac_cv_func_pututline=yes ac_cv_func_pututxline=yes ac_cv_func_readpassphrase=no ac_cv_func_realpath=yes ac_cv_func_recvmsg=yes ac_cv_func_rresvport_af=no ac_cv_func_sendmsg=yes ac_cv_func_setdtablesize=yes ac_cv_func_setegid=yes ac_cv_func_setenv=yes ac_cv_func_seteuid=yes ac_cv_func_setgroups=yes ac_cv_func_setlogin=no ac_cv_func_setpcred=no ac_cv_func_setproctitle=no ac_cv_func_setregid=yes ac_cv_func_setresgid=no ac_cv_func_setresuid=no ac_cv_func_setreuid=yes ac_cv_func_setrlimit=yes ac_cv_func_setsid=yes ac_cv_func_setsockopt=yes ac_cv_func_setutent=yes ac_cv_func_setutxent=yes ac_cv_func_setvbuf=yes ac_cv_func_sigaction=yes ac_cv_func_sigvec=no ac_cv_func_snprintf=yes ac_cv_func_socketpair=yes ac_cv_func_strcasecmp=yes ac_cv_func_strdup=yes ac_cv_func_strerror=yes ac_cv_func_strftime=yes ac_cv_func_strlcat=yes ac_cv_func_strlcpy=yes ac_cv_func_strmode=no ac_cv_func_strnvis=no ac_cv_func_strsep=yes ac_cv_func_strtoll=yes ac_cv_func_strtonum=no ac_cv_func_strtoul=yes ac_cv_func_sysconf=yes ac_cv_func_tcgetpgrp=yes ac_cv_func_time=yes ac_cv_func_truncate=yes ac_cv_func_unsetenv=yes ac_cv_func_updwtmp=yes ac_cv_func_updwtmpx=no ac_cv_func_utimes=yes ac_cv_func_utmpname=yes ac_cv_func_utmpxname=yes ac_cv_func_vasprintf=yes ac_cv_func_vhangup=yes ac_cv_func_vsnprintf=yes ac_cv_func_waitpid=yes ac_cv_func_yp_match=no ac_cv_have___ss_family_in_struct_ss=no ac_cv_have___va_copy=yes ac_cv_have_accrights_in_msghdr=no ac_cv_have_clock_t=yes ac_cv_have_control_in_msghdr=yes ac_cv_have_decl_LLONG_MAX=yes ac_cv_have_decl__getlong=no ac_cv_have_decl__getshort=no ac_cv_have_decl_getrusage=no ac_cv_have_decl_h_errno=yes ac_cv_have_decl_strsep=yes ac_cv_have_decl_tcsendbreak=yes ac_cv_have_getopt_optreset=yes ac_cv_have_int64_t=yes ac_cv_have_intxx_t=yes ac_cv_have_mode_t=yes ac_cv_have_pid_t=yes ac_cv_have_pw_change_in_struct_passwd=no ac_cv_have_pw_class_in_struct_passwd=no ac_cv_have_pw_expire_in_struct_passwd=no ac_cv_have_sa_family_t=yes ac_cv_have_size_t=yes ac_cv_have_ss_family_in_struct_ss=yes ac_cv_have_ssize_t=yes ac_cv_have_struct_addrinfo=no ac_cv_have_struct_in6_addr=no ac_cv_have_struct_sockaddr_in6=no ac_cv_have_struct_sockaddr_storage=yes ac_cv_have_struct_timeval=yes ac_cv_have_u_char=yes ac_cv_have_u_int=yes ac_cv_have_u_int64_t=yes ac_cv_have_u_intxx_t=yes ac_cv_have_va_copy=yes ac_cv_header_bstring_h=no ac_cv_header_crypt_h=yes ac_cv_header_dirent_h=yes ac_cv_header_endian_h=yes ac_cv_header_features_h=yes ac_cv_header_floatingpoint_h=no ac_cv_header_getopt_h=yes ac_cv_header_glob_h=yes ac_cv_header_ia_h=no ac_cv_header_iaf_h=no ac_cv_header_lastlog_h=yes ac_cv_header_libgen_h=yes ac_cv_header_libutil_h=no ac_cv_header_limits_h=yes ac_cv_header_login_cap_h=no ac_cv_header_login_h=no ac_cv_header_maillock_h=no ac_cv_header_ndir_h=no ac_cv_header_netdb_h=yes ac_cv_header_netgroup_h=no ac_cv_header_pam_pam_appl_h=no ac_cv_header_paths_h=yes ac_cv_header_pty_h=yes ac_cv_header_readpassphrase_h=no ac_cv_header_rpc_types_h=no ac_cv_header_security_pam_appl_h=no ac_cv_header_shadow_h=no ac_cv_header_stddef_h=yes ac_cv_header_stdint_h=yes ac_cv_header_string_h=yes ac_cv_header_strings_h=yes ac_cv_header_sys_audit_h=no ac_cv_header_sys_bitypes_h=no ac_cv_header_sys_bsdtty_h=no ac_cv_header_sys_cdefs_h=yes ac_cv_header_sys_dir_h=no ac_cv_header_sys_mman_h=yes ac_cv_header_sys_ndir_h=no ac_cv_header_sys_prctl_h=no ac_cv_header_sys_pstat_h=no ac_cv_header_sys_ptms_h=no ac_cv_header_sys_select_h=yes ac_cv_header_sys_stat_h=yes ac_cv_header_sys_stream_h=no ac_cv_header_sys_stropts_h=no ac_cv_header_sys_strtio_h=no ac_cv_header_sys_sysmacros_h=yes ac_cv_header_sys_time_h=yes ac_cv_header_sys_timers_h=no ac_cv_header_sys_un_h=yes ac_cv_header_time_h=yes ac_cv_header_tmpdir_h=no ac_cv_header_ttyent_h=no ac_cv_header_unistd_h=yes ac_cv_header_usersec_h=no ac_cv_header_util_h=no ac_cv_header_utime_h=yes ac_cv_header_utmp_h=yes ac_cv_header_utmpx_h=yes ac_cv_header_vis_h=no ac_cv_header_zlib_h=yes ac_cv_host=i686-pc-cygwin ac_cv_host_alias=i686-pc-cygwin ac_cv_lib_crypt_crypt=yes ac_cv_lib_gen_getspnam=no ac_cv_lib_iaf_ia_openinfo=no ac_cv_lib_nsl_yp_match=no ac_cv_lib_z_deflate=yes ac_cv_libc_defines___progname=yes ac_cv_libc_defines_sys_errlist=yes ac_cv_libc_defines_sys_nerr=yes ac_cv_member_HEADER_ad=yes ac_cv_member_struct___res_state_retrans=yes ac_cv_member_struct_stat_st_blksize=yes ac_cv_objext=o ac_cv_path_AR=/usr/bin/ar ac_cv_path_CAT=/usr/bin/cat ac_cv_path_KILL=/usr/bin/kill ac_cv_path_LOGIN_PROGRAM_FALLBACK=/usr/bin/login ac_cv_path_NROFF=/usr/bin/nroff ac_cv_path_PATH_GROUPADD_PROG=groupadd ac_cv_path_PATH_PASSWD_PROG=/usr/bin/passwd ac_cv_path_PATH_USERADD_PROG=useradd ac_cv_path_PROG_ARP=/cygdrive/c/WINDOWS/system32/arp ac_cv_path_PROG_DF=/bin/df ac_cv_path_PROG_IPCS=/bin/ipcs ac_cv_path_PROG_LS=/bin/ls ac_cv_path_PROG_NETSTAT=/cygdrive/c/WINDOWS/system32/netstat ac_cv_path_PROG_PS=/bin/ps ac_cv_path_PROG_TAIL=/bin/tail ac_cv_path_PROG_WHO=/bin/who ac_cv_path_SED=/usr/bin/sed ac_cv_path_SH=/usr/bin/sh ac_cv_path_TEST_MINUS_S_SH=/usr/bin/bash ac_cv_path_install='/usr/bin/install -c' ac_cv_prog_AWK=gawk ac_cv_prog_CPP='gcc -E' ac_cv_prog_MAKE_PACKAGE_SUPPORTED=no ac_cv_prog_ac_ct_CC=gcc ac_cv_prog_ac_ct_RANLIB=ranlib ac_cv_prog_cc_g=yes ac_cv_prog_cc_stdc= ac_cv_prog_egrep='grep -E' ac_cv_search_basename='none required' ac_cv_search_dn_expand='none required' ac_cv_search_getrrsetbyname=no ac_cv_search_login='none required' ac_cv_search_nanosleep='none required' ac_cv_search_res_query=-lresolv ac_cv_sizeof_char=1 ac_cv_sizeof_int=4 ac_cv_sizeof_long_int=4 ac_cv_sizeof_long_long_int=8 ac_cv_sizeof_short_int=2 ac_cv_sys_file_offset_bits=no ac_cv_sys_large_files=no ac_cv_sys_largefile_CC=no ac_cv_type_char=yes ac_cv_type_in_addr_t=yes ac_cv_type_int=yes ac_cv_type_long_double=yes ac_cv_type_long_int=yes ac_cv_type_long_long=yes ac_cv_type_long_long_int=yes ac_cv_type_short_int=yes ac_cv_type_sig_atomic_t=yes ac_cv_type_socklen_t=yes ac_cv_type_struct_timespec=yes ac_cv_type_unsigned_long_long=yes ossh_cv_utmp_h_has_ut_addr=yes ossh_cv_utmp_h_has_ut_addr_v6=no ossh_cv_utmp_h_has_ut_exit=no ossh_cv_utmp_h_has_ut_host=yes ossh_cv_utmp_h_has_ut_id=yes ossh_cv_utmp_h_has_ut_pid=yes ossh_cv_utmp_h_has_ut_time=yes ossh_cv_utmp_h_has_ut_tv=no ossh_cv_utmp_h_has_ut_type=yes ossh_cv_utmpx_h_has_syslen=no ossh_cv_utmpx_h_has_ut_addr=yes ossh_cv_utmpx_h_has_ut_addr_v6=no ossh_cv_utmpx_h_has_ut_host=yes ossh_cv_utmpx_h_has_ut_id=yes ossh_cv_utmpx_h_has_ut_time=yes ossh_cv_utmpx_h_has_ut_tv=yes ossh_cv_utmpx_h_has_ut_type=yes ## ----------------- ## ## Output variables. ## ## ----------------- ## AR='/usr/bin/ar' AWK='gawk' CAT='/usr/bin/cat' CC='gcc' CFLAGS='-g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare ' CPP='gcc -E' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='grep -E' ENT='' EXEEXT='.exe' INSTALL_DATA='${INSTALL} -m 644' INSTALL_PROGRAM='${INSTALL}' INSTALL_SCRIPT='${INSTALL}' INSTALL_SSH_PRNG_CMDS='' INSTALL_SSH_RAND_HELPER='' KILL='/usr/bin/kill' LD='gcc' LDFLAGS='' LIBEDIT='' LIBOBJS='' LIBPAM='' LIBS='-lresolv -lcrypto -lz /usr/lib/textmode.o -lcrypt' LIBWRAP='-lwrap' LOGIN_PROGRAM_FALLBACK='/usr/bin/login' LTLIBOBJS='' MAKE_PACKAGE_SUPPORTED='no' MANTYPE='doc' NROFF='/usr/bin/nroff' OBJEXT='o' OPENSC_CONFIG='no' PACKAGE_BUGREPORT='openssh-unix-dev at mindrot.org' PACKAGE_NAME='OpenSSH' PACKAGE_STRING='OpenSSH Portable' PACKAGE_TARNAME='openssh' PACKAGE_VERSION='Portable' PATH_GROUPADD_PROG='groupadd' PATH_PASSWD_PROG='/usr/bin/passwd' PATH_SEPARATOR=':' PATH_USERADD_PROG='useradd' PERL='' PRIVSEP_PATH='/var/empty' PROG_ARP='/cygdrive/c/WINDOWS/system32/arp' PROG_DF='/bin/df' PROG_IFCONFIG='undef' PROG_IPCS='/bin/ipcs' PROG_JSTAT='undef' PROG_LAST='undef' PROG_LASTLOG='undef' PROG_LS='/bin/ls' PROG_NETSTAT='/cygdrive/c/WINDOWS/system32/netstat' PROG_PS='/bin/ps' PROG_SAR='undef' PROG_TAIL='/bin/tail' PROG_UPTIME='undef' PROG_VMSTAT='undef' PROG_W='undef' PROG_WHO='/bin/who' RANLIB='ranlib' SED='/usr/bin/sed' SH='/usr/bin/sh' SHELL='/bin/sh' SSH_PRIVSEP_USER='sshd' STARTUP_SCRIPT_SHELL='/bin/sh' STRIP_OPT='-s' TEST_MINUS_S_SH='/usr/bin/bash' TEST_SHELL='sh' XAUTH_PATH='undefined' ac_ct_CC='gcc' ac_ct_RANLIB='ranlib' bindir='${exec_prefix}/bin' build='i686-pc-cygwin' build_alias='' build_cpu='i686' build_os='cygwin' build_vendor='pc' datadir='${prefix}/share' exec_prefix='${prefix}' host='i686-pc-cygwin' host_alias='' host_cpu='i686' host_os='cygwin' host_vendor='pc' includedir='${prefix}/include' infodir='${datadir}/info' libdir='${exec_prefix}/lib' libexecdir='${sbindir}' localstatedir='/var' mandir='${datadir}/man' mansubdir='man' oldincludedir='/usr/include' piddir='/var/run' prefix='/usr' program_transform_name='s,x,x,' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='/etc' target_alias='' user_path='/bin:/usr/sbin:/sbin:/usr/bin' xauth_path='' ## ----------- ## ## confdefs.h. ## ## ----------- ## #define DISABLE_FD_PASSING 1 #define DISABLE_SHADOW 1 #define DISABLE_WTMPX 1 #define ENTROPY_TIMEOUT_MSEC 200 #define GETPGRP_VOID 1 #define GLOB_HAS_ALTDIRFUNC 1 #define HAVE_ADDR_IN_UTMP 1 #define HAVE_ADDR_IN_UTMPX 1 #define HAVE_ASPRINTF 1 #define HAVE_BASENAME 1 #define HAVE_BCOPY 1 #define HAVE_CLOCK 1 #define HAVE_CLOCK_T 1 #define HAVE_CONTROL_IN_MSGHDR 1 #define HAVE_CRYPT_H 1 #define HAVE_CYGWIN 1 #define HAVE_DAEMON 1 #define HAVE_DECL_H_ERRNO 1 #define HAVE_DECL__GETLONG 0 #define HAVE_DECL__GETSHORT 0 #define HAVE_DEV_PTMX 1 #define HAVE_DIRENT_H 1 #define HAVE_DIRFD 1 #define HAVE_DIRNAME 1 #define HAVE_ENDIAN_H 1 #define HAVE_ENDUTENT 1 #define HAVE_ENDUTXENT 1 #define HAVE_FCHMOD 1 #define HAVE_FCHOWN 1 #define HAVE_FEATURES_H 1 #define HAVE_FUTIMES 1 #define HAVE_GETCWD 1 #define HAVE_GETOPT 1 #define HAVE_GETOPT_H 1 #define HAVE_GETOPT_OPTRESET 1 #define HAVE_GETPAGESIZE 1 #define HAVE_GETPEEREID 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_HEADER_AD 1 #define HAVE_HOST_IN_UTMP 1 #define HAVE_HOST_IN_UTMPX 1 #define HAVE_ID_IN_UTMP 1 #define HAVE_ID_IN_UTMPX 1 #define HAVE_INET_ATON 1 #define HAVE_INET_NTOA 1 #define HAVE_INET_NTOP 1 #define HAVE_INT64_T 1 #define HAVE_INTXX_T 1 #define HAVE_IN_ADDR_T 1 #define HAVE_LASTLOG_H 1 #define HAVE_LIBGEN_H 1 #define HAVE_LIBZ 1 #define HAVE_LIMITS_H 1 #define HAVE_LOGIN 1 #define HAVE_LOGOUT 1 #define HAVE_LOGWTMP 1 #define HAVE_LONG_DOUBLE 1 #define HAVE_LONG_LONG 1 #define HAVE_MEMMOVE 1 #define HAVE_MKDTEMP 1 #define HAVE_MMAP 1 #define HAVE_MODE_T 1 #define HAVE_NANOSLEEP 1 #define HAVE_NETDB_H 1 #define HAVE_OPENPTY 1 #define HAVE_OPENSSL 1 #define HAVE_PATHS_H 1 #define HAVE_PID_IN_UTMP 1 #define HAVE_PID_T 1 #define HAVE_PROC_PID 1 #define HAVE_PTY_H 1 #define HAVE_PUTUTLINE 1 #define HAVE_PUTUTXLINE 1 #define HAVE_REALPATH 1 #define HAVE_RECVMSG 1 #define HAVE_SA_FAMILY_T 1 #define HAVE_SENDMSG 1 #define HAVE_SETDTABLESIZE 1 #define HAVE_SETEGID 1 #define HAVE_SETENV 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_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_STDINT_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_STRSEP 1 #define HAVE_STRTOLL 1 #define HAVE_STRTOUL 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_SYS_CDEFS_H 1 #define HAVE_SYS_ERRLIST 1 #define HAVE_SYS_MMAN_H 1 #define HAVE_SYS_NERR 1 #define HAVE_SYS_SELECT_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_SYS_SYSMACROS_H 1 #define HAVE_SYS_TIME_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_UNSETENV 1 #define HAVE_UNSIGNED_LONG_LONG 1 #define HAVE_UPDWTMP 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_U_INT64_T 1 #define HAVE_U_INTXX_T 1 #define HAVE_VASPRINTF 1 #define HAVE_VA_COPY 1 #define HAVE_VHANGUP 1 #define HAVE_VSNPRINTF 1 #define HAVE_WAITPID 1 #define HAVE___FUNCTION__ 1 #define HAVE___PROGNAME 1 #define HAVE___VA_COPY 1 #define HAVE___func__ 1 #define IP_TOS_IS_BROKEN 1 #define LIBWRAP 1 #define LOGIN_PROGRAM_FALLBACK "/usr/bin/login" #define NO_IPPORT_RESERVED_CONCEPT 1 #define NO_X11_UNIX_SOCKETS 1 #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 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 SSH_PRIVSEP_USER "sshd" #define USER_PATH "/bin:/usr/sbin:/sbin:/usr/bin" #define USE_PIPES 1 #define _PATH_PASSWD_PROG "/usr/bin/passwd" #define _PATH_SSH_PIDDIR "/var/run" configure: exit 0 ---------------------------------------------------------- I can see the define of HAVE_INTXX_T in this list. I have searched for both HAVE_INTXX_T and SIZEOF_CHAR but the only files they are in are: cygwin/home/Steve/openssh3.4p2/config.h - in a comment cygwin/home/Steve/openssh3.4p2/config.log - as described above cygwin/home/Steve/openssh3.4p2/defines.h - as described above Can anybody give me an idea of what I am doing wrong? Thanks Steve From vinschen at redhat.com Wed Apr 12 20:19:00 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 12 Apr 2006 12:19:00 +0200 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <20060405110327.GC19284@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> <20060405110327.GC19284@calimero.vinschen.de> Message-ID: <20060412101900.GC9135@calimero.vinschen.de> Hi Darren, On Apr 5 13:03, Corinna Vinschen wrote: > On Apr 5 12:36, Darren Tucker wrote: > > To Corinna's question about buffer sizes: I personally would have no > > objection to making it 64k, possibly with a #define for making it > > smaller for folks targeting old/embedded systems and such. I suspect it > > would be a minor performance gain on most platforms. > > > > If a similar bottleneck applies to pipe/socketpairs, it may also be work > > increasing the IO buffer in scp and seeing if that helps your > > performance (the HPN patch bumps it from 2k to 16k, you may want to bump > > it to 64k). > > Thanks for the hint, I'll give it a try next week. I just tried it and it doesn't have any noticable influence, so only the network connection is the bottleneck, apparently. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Wed Apr 12 21:46:32 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 12 Apr 2006 13:46:32 +0200 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <44344361.6090101@psc.edu> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> <44344361.6090101@psc.edu> Message-ID: <20060412114632.GD9135@calimero.vinschen.de> On Apr 5 18:23, Chris Rapier wrote: > Darren Tucker wrote: > > The existing buffer limit is 10MB so unless you have paths with a > > BDP/TCPWINSZ of 10MB or higher (do you?) then I think you'll see your > > throughput go up a little or your CPU and memory utilization go down a > > little. > > I've changed this to 32MB. This should handle up to 3.2Gbps at 80ms RTT > - which is a little low for some applications. However, I think I have a > way to handle this later on. > > > At the moment, you do this in channel.c: > > -limit = MIN(limit, (BUFFER_MAX_LEN - BUFFER_MAX_CHUNK - CHAN_RBUF)); > > +limit = MIN(limit, (BUFFER_MAX_HPN_LEN-BUFFER_MAX_CHUNK-CHAN_RBUF)); > > > > Instead, I suggest leaving the existing line and adding something like: > > limit = MIN(limit, gettcpwinsz()); > > or > > limit = MIN(limit, 2 * gettcpwinsz()); > > I made this change. It only checks multiple times if the option to do > tcp buffer polling is enabled. It stores the channels associated > connections window size in c->tcpwinsz now. > > I also cleaned up some other stuff in channel.c for the sake of clarity > and cleaned up some logic errors in other locations. > > This latest version of the patch can be found at > http://www.psc.edu/networking/projects/hpn-ssh/hpn12v5.diff.gz > Usage notes can be found at > http://www.psc.edu/networking/projects/hpn-ssh/ssh-hpn12.notes > > Let me know if anyone finds anything out vis a vis performance. I didn't > have the time to test it for anything except functionality today. Its > been an annoyingly busy day. I tested your patch and I don't see a difference in relation to the previous hpn version as far as performance is concerned. The performance for the slowest copy: cygwin> scp linux:file . is still slower than without the hpn patch, file 100% 118MB 1.0MB/s 01:58 vs. file 100% 118MB 1.3MB/s 01:31 The curious thing here is that the CPU usage is very low in both cases, it only takes about 2% CPU. But I also have good news for the hpn patch. In my tests last week I forgot to test the hpn patch together with raised buffer sizes in clientloop.c. I raised the buffer sizes in clientloop.c from 8192 to 87380 bytes. As I already noted, the vanilla version of OpenSSH then behaves much better, for instance: file 100% 118MB 5.9MB/s 00:20 However, with 87380 bytes buffers the hpn patch suddenly behaves much better than with 8192 bytes buffers. It is now roughly 80-90% faster than the vanilla version with 87380 bytes buffers: file 100% 118MB 9.9MB/s 00:12 I also noticed that in this configuration the CPU usage climbs to an average of 30%, while without the hpn patch it sticks at 2%. However, I also installed a hpn sshd on my Cygwin box and tried the copy initiated from the other direction: linux> scp file cygwin: The result for the vanilla sshd: file 100% 118MB 9.1MB/s 00:13 The result for sshd with the hpn patch: file 100% 118MB 2.0MB/s 00:59 Looks like another buffer might be in the way now, but I didn't look into this deeper so far. Note that all tests are using a vanilla OpenSSH on the Linux side. I didn't want to add another variable to the test configuration. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dtucker at zip.com.au Wed Apr 12 22:10:37 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 12 Apr 2006 22:10:37 +1000 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <20060412114632.GD9135@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> <44344361.6090101@psc.edu> <20060412114632.GD9135@calimero.vinschen.de> Message-ID: <20060412121037.GA30916@gate.dtucker.net> On Wed, Apr 12, 2006 at 01:46:32PM +0200, Corinna Vinschen wrote: > Looks like another buffer might be in the way now, but I didn't look > into this deeper so far. Attached is a patch I started to play with that outputs the buffer high water mark for each connection. > Note that all tests are using a vanilla OpenSSH on the Linux side. > I didn't want to add another variable to the test configuration. Be aware that some of the hpn changes only kick in if it sees the other end is also hpn. -- 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. -------------- next part -------------- Index: buffer.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/buffer.c,v retrieving revision 1.23 diff -u -p -r1.23 buffer.c --- buffer.c 14 Mar 2005 12:22:26 -0000 1.23 +++ buffer.c 9 Apr 2006 01:22:58 -0000 @@ -18,6 +18,8 @@ RCSID("$OpenBSD: buffer.c,v 1.23 2005/03 #include "buffer.h" #include "log.h" +u_int buffer_hiwater = 4096; + /* Initializes the buffer structure. */ void @@ -87,6 +89,9 @@ buffer_append_space(Buffer *buffer, u_in buffer->end = 0; } restart: + if (buffer->alloc > buffer_hiwater) + buffer_hiwater = buffer->alloc; + /* If there is enough space to store all data, store it now. */ if (buffer->end + len < buffer->alloc) { p = buffer->buf + buffer->end; Index: cleanup.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/cleanup.c,v retrieving revision 1.1 diff -u -p -r1.1 cleanup.c --- cleanup.c 2 Oct 2003 06:12:37 -0000 1.1 +++ cleanup.c 9 Apr 2006 01:00:00 -0000 @@ -22,5 +22,8 @@ RCSID("$OpenBSD: cleanup.c,v 1.1 2003/09 void cleanup_exit(int i) { + extern u_int buffer_hiwater; + + logit("buffer hiwater %u", buffer_hiwater); _exit(i); } Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v retrieving revision 1.312.2.1 diff -u -p -r1.312.2.1 session.c --- session.c 7 Feb 2006 23:18:55 -0000 1.312.2.1 +++ session.c 9 Apr 2006 01:12:03 -0000 @@ -2424,6 +2424,7 @@ void do_cleanup(Authctxt *authctxt) { static int called = 0; + extern u_int buffer_hiwater; debug("do_cleanup"); @@ -2436,6 +2437,9 @@ do_cleanup(Authctxt *authctxt) return; called = 1; + error("%s buffer hiwater %u", + mm_is_monitor() ? "monitor" : "slave", buffer_hiwater); + if (authctxt == NULL) return; #ifdef KRB5 Index: ssh.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ssh.c,v retrieving revision 1.244 diff -u -p -r1.244 ssh.c --- ssh.c 31 Dec 2005 05:33:37 -0000 1.244 +++ ssh.c 9 Apr 2006 01:31:13 -0000 @@ -78,6 +78,7 @@ RCSID("$OpenBSD: ssh.c,v 1.257 2005/12/2 #endif extern char *__progname; +extern u_int buffer_hiwater; /* Flag indicating whether debug mode is on. This can be set on the command line. */ int debug_flag = 0; @@ -759,6 +760,8 @@ again: exit_status = compat20 ? ssh_session2() : ssh_session(); packet_close(); + error("buffer hiwater %u", buffer_hiwater); + if (options.control_path != NULL && control_fd != -1) unlink(options.control_path); From vinschen at redhat.com Thu Apr 13 00:43:38 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 12 Apr 2006 16:43:38 +0200 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <20060412121037.GA30916@gate.dtucker.net> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> <44344361.6090101@psc.edu> <20060412114632.GD9135@calimero.vinschen.de> <20060412121037.GA30916@gate.dtucker.net> Message-ID: <20060412144338.GE9135@calimero.vinschen.de> On Apr 12 22:10, Darren Tucker wrote: > On Wed, Apr 12, 2006 at 01:46:32PM +0200, Corinna Vinschen wrote: > > Looks like another buffer might be in the way now, but I didn't look > > into this deeper so far. > > Attached is a patch I started to play with that outputs the buffer > high water mark for each connection. Results for cygwin> scp linux:file . 1. Vanilla with 8K buffers: file 100% 118MB 1.3MB/s 01:35 buffer hiwater 1105968 2. Vanilla with 85K buffers: file 100% 118MB 5.6MB/s 00:21 buffer hiwater 202176 3. HPN with 8K buffers: file 100% 118MB 1.0MB/s 02:00 buffer hiwater 1069056 4. HPN with 85K buffers: file 100% 118MB 9.9MB/s 00:12 buffer hiwater 1205576 Results for linux> scp file cygwin: 5. Vanilla sshd file 100% 118MB 9.1MB/s 00:13 slave buffer hiwater 1085440 6. HPN sshd file 100% 118MB 2.0MB/s 00:58 slave buffer hiwater 1085440 It's interesting that the buffer in case 4 is reproducibly only filled up to 200K, while in all other cases the buffer is filled up to 1 Meg. Is there anything we can learn from that? > > Note that all tests are using a vanilla OpenSSH on the Linux side. > > I didn't want to add another variable to the test configuration. > > Be aware that some of the hpn changes only kick in if it sees the other > end is also hpn. I am aware of that. The idea is that I have only the Cygwin side under control since that's what I'm maintaining. The generic case is the one in which I don't know anything about the remote side and can't influence it. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From dlochart at gmail.com Thu Apr 13 02:32:34 2006 From: dlochart at gmail.com (Doug Lochart) Date: Wed, 12 Apr 2006 16:32:34 +0000 Subject: openSSH 4.3 p2 rpm help please! Message-ID: <1e71f8880604120932m6e9c3cb6tf53afeee00591652@mail.gmail.com> All, I have a CentOS 4 system I need to update OpenSSH on. Most of my experience has been on slackware and I am new to using yum and packages. I ran yum and it tells me that my current installed version is 3.9 patch level 1. It also said that there are no updates for it. I did a google for it but every link I saw that seemed to point to info about an rpm for 4.3 came up not found. Is there a better yum repository for finding these packages or will I have to build my own? If so How do I do that? Also if I upgrade will I break any other app that might be built with the older version? Is there a yum / rpm option that tells me what other packages/binaries are dependent on the installed version of openssh Thanks Doug -- What profits a man if he gains the whole world yet loses his soul? From hijinks at gmail.com Thu Apr 13 02:44:00 2006 From: hijinks at gmail.com (Mike Zupan) Date: Wed, 12 Apr 2006 12:44:00 -0400 Subject: openSSH 4.3 p2 rpm help please! In-Reply-To: <1e71f8880604120932m6e9c3cb6tf53afeee00591652@mail.gmail.com> References: <1e71f8880604120932m6e9c3cb6tf53afeee00591652@mail.gmail.com> Message-ID: <7227c6c70604120944v7acdd4f8of25767b5f0f05593@mail.gmail.com> remember RH/centos does backpatching.. so while you are running an older version as long as the main version of centos is being supported (which 4 still is) you are ok. http://www.redhat.com/advice/speaks_backport.html On 4/12/06, Doug Lochart wrote: > All, > > I have a CentOS 4 system I need to update OpenSSH on. Most of my > experience has been on slackware and I am new to using yum and > packages. I ran yum and it tells me that my current installed version > is 3.9 patch level 1. It also said that there are no updates for it. > I did a google for it but every link I saw that seemed to point to > info about an rpm for 4.3 came up not found. > > Is there a better yum repository for finding these packages or will I > have to build my own? If so How do I do that? > > Also if I upgrade will I break any other app that might be built with > the older version? Is there a yum / rpm option that tells me what > other packages/binaries are dependent on the installed version of > openssh > > Thanks > > Doug > > > -- > What profits a man if he gains the whole world yet loses his soul? > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- http://www.zcentric.com/wiki My Linux Howto/Tips Wiki From dlochart at gmail.com Thu Apr 13 03:04:38 2006 From: dlochart at gmail.com (Doug Lochart) Date: Wed, 12 Apr 2006 17:04:38 +0000 Subject: openSSH 4.3 p2 rpm help please! Message-ID: <1e71f8880604121004h4e07c6e2m2a78e4e0224f520e@mail.gmail.com> >remember RH/centos does backpatching.. so while you are running an >older version as long as the main version of centos is being supported >(which 4 still is) you are ok. > http://www.redhat.com/advice/speaks_backport.html I found that informative but I am still stuck on what to do. How do I get these security fixes to make my 3.9 equal to 4.3 ??? I am expecting yum or rpm to tell me if there is an update. Since there is no update available should I be assume that the fixes in 4.3 are backported to my 3.9?? Sorry to sound like a dunce but rp etc is totally new to me. I always use slackware and do everything from source. Doug On 4/12/06, Doug Lochart wrote: > All, > > I have a CentOS 4 system I need to update OpenSSH on. Most of my > experience has been on slackware and I am new to using yum and > packages. I ran yum and it tells me that my current installed version > is 3.9 patch level 1. It also said that there are no updates for it. > I did a google for it but every link I saw that seemed to point to > info about an rpm for 4.3 came up not found. > > Is there a better yum repository for finding these packages or will I > have to build my own? If so How do I do that? > > Also if I upgrade will I break any other app that might be built with > the older version? Is there a yum / rpm option that tells me what > other packages/binaries are dependent on the installed version of > openssh > > Thanks > > Doug > > > -- > What profits a man if he gains the whole world yet loses his soul? -- What profits a man if he gains the whole world yet loses his soul? From hijinks at gmail.com Thu Apr 13 03:22:16 2006 From: hijinks at gmail.com (Mike Zupan) Date: Wed, 12 Apr 2006 13:22:16 -0400 Subject: openSSH 4.3 p2 rpm help please! In-Reply-To: <1e71f8880604121004h4e07c6e2m2a78e4e0224f520e@mail.gmail.com> References: <1e71f8880604121004h4e07c6e2m2a78e4e0224f520e@mail.gmail.com> Message-ID: <7227c6c70604121022x45bd0bcs2d760edf99eab5bb@mail.gmail.com> yes that version of 3.9 is fully patched against all bugs and security issues.. the only thing they don't back port is functionality.. so if there is a reason you need 4.3 for a certain function or option that is not in 3.9.. you are SAFE running that version On 4/12/06, Doug Lochart wrote: > >remember RH/centos does backpatching.. so while you are running an > >older version as long as the main version of centos is being supported > >(which 4 still is) you are ok. > > > http://www.redhat.com/advice/speaks_backport.html > > I found that informative but I am still stuck on what to do. How do I > get these security fixes to make my 3.9 equal to 4.3 ??? I am > expecting yum or rpm to tell me if there is an update. Since there is > no update available should I be assume that the fixes in 4.3 are > backported to my 3.9?? > > Sorry to sound like a dunce but rp etc is totally new to me. I always > use slackware and do everything from source. > > Doug > > > > On 4/12/06, Doug Lochart wrote: > > All, > > > > I have a CentOS 4 system I need to update OpenSSH on. Most of my > > experience has been on slackware and I am new to using yum and > > packages. I ran yum and it tells me that my current installed version > > is 3.9 patch level 1. It also said that there are no updates for it. > > I did a google for it but every link I saw that seemed to point to > > info about an rpm for 4.3 came up not found. > > > > Is there a better yum repository for finding these packages or will I > > have to build my own? If so How do I do that? > > > > Also if I upgrade will I break any other app that might be built with > > the older version? Is there a yum / rpm option that tells me what > > other packages/binaries are dependent on the installed version of > > openssh > > > > Thanks > > > > Doug > > > > > > -- > > What profits a man if he gains the whole world yet loses his soul? > > -- > What profits a man if he gains the whole world yet loses his soul? > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- http://www.zcentric.com/wiki My Linux Howto/Tips Wiki From smooge at gmail.com Thu Apr 13 03:24:27 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 12 Apr 2006 11:24:27 -0600 Subject: openSSH 4.3 p2 rpm help please! In-Reply-To: <1e71f8880604121004h4e07c6e2m2a78e4e0224f520e@mail.gmail.com> References: <1e71f8880604121004h4e07c6e2m2a78e4e0224f520e@mail.gmail.com> Message-ID: <80d7e4090604121024y7af6b407ge63c70baaddb0426@mail.gmail.com> On 4/12/06, Doug Lochart wrote: > >remember RH/centos does backpatching.. so while you are running an > >older version as long as the main version of centos is being supported > >(which 4 still is) you are ok. > > > http://www.redhat.com/advice/speaks_backport.html > > I found that informative but I am still stuck on what to do. How do I > get these security fixes to make my 3.9 equal to 4.3 ??? I am > expecting yum or rpm to tell me if there is an update. Since there is > no update available should I be assume that the fixes in 4.3 are > backported to my 3.9?? > > Sorry to sound like a dunce but rp etc is totally new to me. I always > use slackware and do everything from source. > > Doug > > What you normally need to do is look at the relevant Centos/RHEL security errata website and look to see that the CVE's you are wanting are covered (or looking at the src.rpm and see that.) http://rhn.redhat.com/errata/RHSA-2005-550.html http://rhn.redhat.com/errata/RHSA-2005-106.html Or you can just do an rpm -e of the openssh rpms and rebuild the openssh rpms from openssh.. though it may add/remove functionality that your user expected from the old ssh. > > On 4/12/06, Doug Lochart wrote: > > All, > > -- Stephen J Smoogen. CSIRT/Linux System Administrator From petesea at bigfoot.com Thu Apr 13 07:26:08 2006 From: petesea at bigfoot.com (Dan Peterson) Date: Wed, 12 Apr 2006 14:26:08 -0700 (Pacific Daylight Time) Subject: OpenSSH 4.3p2, MIT KfW 3.0 and Cygwin Message-ID: Has anyone successfully built openssh with MIT's KfW (Kerberos for Windows) under Cygwin? Is it even possible? Searching around I found one reference to Nicolas Williams attempting to do this several years ago, but no indication of success and nothing more recent. http://www.cygwin.com/ml/cygwin/2002-01/msg00100.html What about compiling openssh using a native windows compiler? Is that possible? I'm afraid I have NO experience compiling anything using a native windows compiler which is why I'd prefer to use cygwin. But if cygwin isn't possible I'd resort to using something else. The GOAL is a GSSAPI enabled ssh client (preferably with gssapi-keyex support) that uses the nice GUI front-end provided by KfW. Those windows users get too confused if you tell them they have to go to the command prompt and run "kinit" every morning. From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Apr 13 08:00:43 2006 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 13 Apr 2006 00:00:43 +0200 Subject: [schulz@adi.com: 0.9.8a: DSA_generate_parameters & RSA_generate_key not in libcrypto] Message-ID: <20060412220043.GC5708@serv01.aet.tu-cottbus.de> Forwarded to respective mailing lists Regards, Lutz ----- Forwarded message from Thomas Schulz ----- X-Original-To: jaenicke at serv01.aet.tu-cottbus.de X-Original-To: rt at aet.tu-cottbus.de Delivered-To: rt at master.openssl.org Date: Wed, 12 Apr 2006 14:42:27 -0400 (EDT) From: Thomas Schulz To: openssl-bugs at openssl.org Subject: 0.9.8a: DSA_generate_parameters & RSA_generate_key not in libcrypto X-Virus-Scanned: by amavisd 0.1 X-Virus-Scanned: by amavisd 0.1 I am not sure if this is a bug or something that was never defined to work. I tried to build openssh-4.3p2 against openssl-0.9.8a. It died with DSA_generate_parameters and RSA_generate_key as undefined symbols. I tried again using openssl-0.9.7i and openssh-4.3p2 built without any problem. The exact error is as follows: cc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/opt/local/lib -R/opt/local/lib -L/opt/local/lib -R/opt/local/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lrt -lz -lsocket -lnsl Undefined first referenced symbol in file DSA_generate_parameters ./libssh.a(key.o) RSA_generate_key ./libssh.a(key.o) ld: fatal: Symbol referencing errors. No output written to ssh *** Error code 1 Tom schulz Applied Dynamics Intl. schulz at adi.com ----- End forwarded message ----- -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Apr 13 08:00:43 2006 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 13 Apr 2006 00:00:43 +0200 Subject: [schulz@adi.com: 0.9.8a: DSA_generate_parameters & RSA_generate_key not in libcrypto] Message-ID: <20060412220043.GC5708@serv01.aet.tu-cottbus.de> Forwarded to respective mailing lists Regards, Lutz ----- Forwarded message from Thomas Schulz ----- X-Original-To: jaenicke at serv01.aet.tu-cottbus.de X-Original-To: rt at aet.tu-cottbus.de Delivered-To: rt at master.openssl.org Date: Wed, 12 Apr 2006 14:42:27 -0400 (EDT) From: Thomas Schulz To: openssl-bugs at openssl.org Subject: 0.9.8a: DSA_generate_parameters & RSA_generate_key not in libcrypto X-Virus-Scanned: by amavisd 0.1 X-Virus-Scanned: by amavisd 0.1 I am not sure if this is a bug or something that was never defined to work. I tried to build openssh-4.3p2 against openssl-0.9.8a. It died with DSA_generate_parameters and RSA_generate_key as undefined symbols. I tried again using openssl-0.9.7i and openssh-4.3p2 built without any problem. The exact error is as follows: cc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o -L. -Lopenbsd-compat/ -L/opt/local/lib -R/opt/local/lib -L/opt/local/lib -R/opt/local/lib -lssh -lopenbsd-compat -lresolv -lcrypto -lrt -lz -lsocket -lnsl Undefined first referenced symbol in file DSA_generate_parameters ./libssh.a(key.o) RSA_generate_key ./libssh.a(key.o) ld: fatal: Symbol referencing errors. No output written to ssh *** Error code 1 Tom schulz Applied Dynamics Intl. schulz at adi.com ----- End forwarded message ----- -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users at openssl.org Automated List Manager majordomo at openssl.org From djm at mindrot.org Thu Apr 13 09:34:03 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 13 Apr 2006 09:34:03 +1000 (EST) Subject: openSSH 4.3 p2 rpm help please! In-Reply-To: <7227c6c70604121022x45bd0bcs2d760edf99eab5bb@mail.gmail.com> References: <1e71f8880604121004h4e07c6e2m2a78e4e0224f520e@mail.gmail.com> <7227c6c70604121022x45bd0bcs2d760edf99eab5bb@mail.gmail.com> Message-ID: On Wed, 12 Apr 2006, Mike Zupan wrote: > yes that version of 3.9 is fully patched against all bugs and security > issues.. the only thing they don't back port is functionality.. so if I bet that they do not back-port our proactive changes such as signed vs. unsigned integer cleanups which may fix vulnerabilities that we don't know about. Furthermore, some of the new features in more recent version are security-related, such as known_hosts hashing, better password expiry handling, improved logging, delayed compression and better ARC4 cipher modes. So it is a legitimate choice for users to make to use an updated version over a vendor version. As general advice, try to base what you install off your vendor's source packages. You may want to look at applying the vendor-specific patches if they exist, but we don't audit those and so cannot vouch for them. -d From rapier at psc.edu Thu Apr 13 09:36:34 2006 From: rapier at psc.edu (Chris Rapier) Date: Wed, 12 Apr 2006 19:36:34 -0400 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <20060412144338.GE9135@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> <44344361.6090101@psc.edu> <20060412114632.GD9135@calimero.vinschen.de> <20060412121037.GA30916@gate.dtucker.net> <20060412144338.GE9135@calimero.vinschen.de> Message-ID: <443D8F02.6010201@psc.edu> I ran some preliminary performance tests on LAN to LAN connections. Right now it is just OS X 10.4 to OS X 10.4. I'm not seeing any significant performance difference between the various implementations regardless of the combination. Anyway, I'm on vacation until Monday but when I get back I'll try some linux to cygwin tests to see if I can replicate your problem. I'll try some other combinations in the next few weeks as well. Corinna, have you tried using any of the config switches to see fi they have an impact on the performance? Darren, if you have any other suggestions please let me know. I'll also try your patch and see what information I can get out of it. Okay, back to drinking... :) Corinna Vinschen wrote: > On Apr 12 22:10, Darren Tucker wrote: >> On Wed, Apr 12, 2006 at 01:46:32PM +0200, Corinna Vinschen wrote: >>> Looks like another buffer might be in the way now, but I didn't look >>> into this deeper so far. >> Attached is a patch I started to play with that outputs the buffer >> high water mark for each connection. > > Results for > > cygwin> scp linux:file . > > 1. Vanilla with 8K buffers: > > file 100% 118MB 1.3MB/s 01:35 > buffer hiwater 1105968 > > 2. Vanilla with 85K buffers: > > file 100% 118MB 5.6MB/s 00:21 > buffer hiwater 202176 > > 3. HPN with 8K buffers: > > file 100% 118MB 1.0MB/s 02:00 > buffer hiwater 1069056 > > 4. HPN with 85K buffers: > > file 100% 118MB 9.9MB/s 00:12 > buffer hiwater 1205576 > > Results for > > linux> scp file cygwin: > > 5. Vanilla sshd > > file 100% 118MB 9.1MB/s 00:13 > slave buffer hiwater 1085440 > > 6. HPN sshd > > file 100% 118MB 2.0MB/s 00:58 > slave buffer hiwater 1085440 > > It's interesting that the buffer in case 4 is reproducibly only filled > up to 200K, while in all other cases the buffer is filled up to 1 Meg. > Is there anything we can learn from that? > >>> Note that all tests are using a vanilla OpenSSH on the Linux side. >>> I didn't want to add another variable to the test configuration. >> Be aware that some of the hpn changes only kick in if it sees the other >> end is also hpn. > > I am aware of that. The idea is that I have only the Cygwin side under > control since that's what I'm maintaining. The generic case is the one > in which I don't know anything about the remote side and can't influence > it. > > > Corinna > From carson at taltos.org Thu Apr 13 13:44:13 2006 From: carson at taltos.org (Carson Gaspar) Date: Wed, 12 Apr 2006 20:44:13 -0700 Subject: OpenSSH 4.3p2, MIT KfW 3.0 and Cygwin In-Reply-To: References: Message-ID: <57DD51AF4CD87C30E6AFFC55@[192.168.1.2]> --On Wednesday, April 12, 2006 2:26 PM -0700 Dan Peterson wrote: > The GOAL is a GSSAPI enabled ssh client (preferably with gssapi-keyex > support) that uses the nice GUI front-end provided by KfW. Those windows > users get too confused if you tell them they have to go to the command > prompt and run "kinit" every morning. FYI if you use the native SSPI, your tickets are refreshed every time you unlock your screen. Of course SSPI presumes you either use your AD servers as your KDCs for all systems, or that you have a trust relationship between the realms. There are at least 3 SSPI SSH clients I know of: - patched PuTTY (2 different versions exist, but only one allows you specify the host principal, which is required for x-realm logins) - SecureCRT - Kermit 95 I've wanted to try and build OpenSSH using Microsoft's Services for UNIX, and then try and add SSPI support, but I don't have enough free time these days. -- Carson From apb at cequrux.com Thu Apr 13 06:56:24 2006 From: apb at cequrux.com (Alan Barrett) Date: Wed, 12 Apr 2006 22:56:24 +0200 Subject: [PATCH] bug in check_parent_exists() in ssh-agent.c Message-ID: <20060412205623.GG23652@apb-laptoy.apb.alt.za> The check_parent_exists() function in ssh-agent.c does this: if (parent_pid != -1 && kill(parent_pid, 0) < 0) however, the kill can fail with EPERM even if the parent_pid exists. For example, consider this command: ssh-agent sh -c 'ssh-add ; exec sudo sh -i' The original ssh-agent process sets things up so that the "sh -c '...'" process is the parent of a child ssh-agent process; then the "sh -c '...' process execs sudo (which is setuid root), and sudo execs "sh -i" (which is now running as root); so now the "sh -i" process (running as root) is the parent of the "ssh-agent" process (running as the original user). When the ssh-agent child process calls check_parent_exists() after 10 seconds, the kill will fail with EPERM, and the ssh-agent process will exit. The obvious symptom is that "ssh-add -l" executed in the child shell works if you are quick enough, but doesn't work 10 seconds later. Two potential fixes come to mind: A: if (parent_pid != -1 && kill(parent_pid, 0) < 0 && errno == ESRCH) B: if (parent_pid != -1 && getppid() != parent_pid) Fix A assumes that errno == ESRCH means that the process really doesn't exist, and that other errno values mean other things. This assumption would fail in a unix-like OS that, for security reasons, decides not to let processes learn anything about the existence of processes owned by other users. Fix B assumes that, when your parent exits, you get re-parented to pid 1 and the result from getppid() changes. I have tested this and it works for me. I append a patch. --apb (Alan Barrett) Index: ssh-agent.c --- ssh-agent.c +++ ssh-agent.c @@ -964,7 +964,13 @@ { int save_errno = errno; - if (parent_pid != -1 && kill(parent_pid, 0) < 0) { + /* + * Don't just test whether kill(parent_pid,0) is successful, + * because it may fail with EPERM even if the process exists. + * If our parent has exited then getppid() will return (pid_t)1, + * so testing for that should be safe. + */ + if (parent_pid != -1 && getppid() != parent_pid) { /* printf("Parent has died - Authentication agent exiting.\n"); */ cleanup_handler(sig); /* safe */ } From vinschen at redhat.com Fri Apr 14 01:22:09 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 13 Apr 2006 17:22:09 +0200 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <443D8F02.6010201@psc.edu> References: <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> <44344361.6090101@psc.edu> <20060412114632.GD9135@calimero.vinschen.de> <20060412121037.GA30916@gate.dtucker.net> <20060412144338.GE9135@calimero.vinschen.de> <443D8F02.6010201@psc.edu> Message-ID: <20060413152209.GL9135@calimero.vinschen.de> On Apr 12 19:36, Chris Rapier wrote: > I ran some preliminary performance tests on LAN to LAN connections. > Right now it is just OS X 10.4 to OS X 10.4. I'm not seeing any > significant performance difference between the various implementations > regardless of the combination. Anyway, I'm on vacation until Monday but > when I get back I'll try some linux to cygwin tests to see if I can > replicate your problem. I'll try some other combinations in the next few > weeks as well. > > Corinna, have you tried using any of the config switches to see fi they > have an impact on the performance? Uh, no, I didn't. But thanks for the hint, I play a bit with it as time permits. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From senthilkumar_sen at hotpop.com Sat Apr 15 18:34:34 2006 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Sat, 15 Apr 2006 14:04:34 +0530 Subject: OpenSSH fips compliance Message-ID: <41a301c66067$76069a40$220110ac@sekco> Hello All, Im using OpenSSH 4.2p1 statically linked with OpenSSL 0.9.7i. It looks now that a fips certified OpenSSL is now available at http://www.openssl.org/source/OpenSSL-fips-1.0.tar.gz . I like to know of any patches applicable for OpenSSH versions to make it fips compliant. Is there any idea for OpenSSH core team to make OpenSSH as fips compliant? What amount of work it needs at this point? I and some of my colleagues wish to contribute for it. Thanks, Senthil Kumar. From smooge at gmail.com Sun Apr 16 10:38:55 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 15 Apr 2006 18:38:55 -0600 Subject: OpenSSH fips compliance In-Reply-To: <41a301c66067$76069a40$220110ac@sekco> References: <41a301c66067$76069a40$220110ac@sekco> Message-ID: <80d7e4090604151738v45b5b965hf7010126b7e59b62@mail.gmail.com> On 4/15/06, Senthil Kumar wrote: > Hello All, > > Im using OpenSSH 4.2p1 statically linked with OpenSSL 0.9.7i. It looks now > that a fips certified OpenSSL is now available at > http://www.openssl.org/source/OpenSSL-fips-1.0.tar.gz . I like to know of > any patches applicable for OpenSSH versions to make it fips compliant. Is > there any idea for OpenSSH core team to make OpenSSH as fips compliant? What > amount of work it needs at this point? I and some of my colleagues wish to > contribute for it. > Ok.. I am not a member of the SSH team.. I just am dealing with FIPS items currently where I work. Which FIPS are you meaning to be compliant with? There are multiple of them that could potentially cover OpenSSH. Second who is the sponsoring Federal agency for FIPS compliance? From what I can tell.. it would be a bigger point for OpenSSH to have a solid financial floor versus any sort of 'compliance' work. -- Stephen J Smoogen. CSIRT/Linux System Administrator From carenas at sajinet.com.pe Sun Apr 16 14:59:57 2006 From: carenas at sajinet.com.pe (Carlo Marcelo Arenas Belon) Date: Sat, 15 Apr 2006 23:59:57 -0500 Subject: [PATCH] warning: comparison between signed and unsigned in function source@scp.c Message-ID: <20060416045957.GB1008@tapir.sajinet.com.pe> Greetings, Attached patch "fixes" the following warning while compiling with gcc 3.4.5, openssh 4.3p2 in an AMD64 Linux system, which is triggered by the comparison between off_t (signed long) and size_t (unsigned long) as shown : scp.c: In function `source': scp.c:632: warning: comparison between signed and unsigned scp.c:639: warning: comparison between signed and unsigned I am afraid though, that removing this warning is mostly aesthetic as automatic conversions between signed and unsigned long are still being done while calling atomicio or any other of the arithmetic comparisons. Carlo -------------- next part -------------- Index: scp.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/scp.c,v retrieving revision 1.141 diff -u -r1.141 scp.c --- scp.c 1 Apr 2006 05:50:29 -0000 1.141 +++ scp.c 16 Apr 2006 04:31:34 -0000 @@ -548,8 +548,7 @@ struct stat stb; static BUF buffer; BUF *bp; - off_t i, amt, statbytes; - size_t result; + off_t i, amt, statbytes, result; int fd = -1, haderr, indx; char *last, *name, buf[2048]; int len; From georg.schwarz at freenet.de Mon Apr 17 03:49:12 2006 From: georg.schwarz at freenet.de (Georg Schwarz) Date: Sun, 16 Apr 2006 19:49:12 +0200 Subject: openssh 4.3 on IRIX 5.3 Message-ID: <2F177568-ECAC-4FC5-BBEE-09F4B526F9BE@freenet.de> Dear developers, OpenSSH 4.3 (both p1 and p2) has a number of issues on IRIX 5.3 which were not present with 4.2p1: configure thinks that a number of header files are unusable. This is because in order to use them other headers such as sys/types.h must be included as well, and configure's test code does not do so. checking ia.h usability... no checking ia.h presence... yes configure: WARNING: ia.h: present but cannot be compiled configure: WARNING: ia.h: check for missing prerequisite headers? configure: WARNING: ia.h: see the Autoconf documentation configure: WARNING: ia.h: section "Present But Cannot Be Compiled" configure: WARNING: ia.h: proceeding with the preprocessor's result configure: WARNING: ia.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 ia.h... yes checking lastlog.h usability... no checking lastlog.h presence... yes configure: WARNING: lastlog.h: present but cannot be compiled configure: WARNING: lastlog.h: check for missing prerequisite headers? configure: WARNING: lastlog.h: see the Autoconf documentation configure: WARNING: lastlog.h: section "Present But Cannot Be Compiled" configure: WARNING: lastlog.h: proceeding with the preprocessor's result configure: WARNING: lastlog.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 lastlog.h... yes checking net/if.h usability... no checking net/if.h presence... yes configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: see the Autoconf documentation configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: net/if.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 net/if.h... yes checking netinet/in_systm.h usability... no checking netinet/in_systm.h presence... yes configure: WARNING: netinet/in_systm.h: present but cannot be compiled configure: WARNING: netinet/in_systm.h: check for missing prerequisite heade rs? configure: WARNING: netinet/in_systm.h: see the Autoconf documentation configure: WARNING: netinet/in_systm.h: section "Present But Cannot Be Compi led" configure: WARNING: netinet/in_systm.h: proceeding with the preprocessor's resul t configure: WARNING: netinet/in_systm.h: in the future, the compiler will take pr ecedence configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix- dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for netinet/in_systm.h... yes checking sys/dir.h usability... no checking sys/dir.h presence... yes configure: WARNING: sys/dir.h: present but cannot be compiled configure: WARNING: sys/dir.h: check for missing prerequisite headers? configure: WARNING: sys/dir.h: see the Autoconf documentation configure: WARNING: sys/dir.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/dir.h: proceeding with the preprocessor's result configure: WARNING: sys/dir.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 sys/dir.h... yes checking sys/prctl.h usability... no checking sys/prctl.h presence... yes configure: WARNING: sys/prctl.h: present but cannot be compiled configure: WARNING: sys/prctl.h: check for missing prerequisite headers? configure: WARNING: sys/prctl.h: see the Autoconf documentation configure: WARNING: sys/prctl.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/prctl.h: proceeding with the preprocessor's result configure: WARNING: sys/prctl.h: in the future, the compiler will take precedenc e configure: WARNING: ## ------------------------------------------- ## configure: WARNING: ## Report this to openssh-unix- dev at mindrot.org ## configure: WARNING: ## ------------------------------------------- ## checking for sys/prctl.h... yes This can be worked around by setting ac_cv_header_sys_prctl_h=yes ac_cv_header_sys_dir_h=yes ac_cv_header_netinet_in_systm_h=yes ac_cv_header_net_if_h=yes ac_cv_header_lastlog_h=yes ac_cv_header_ia_h=yes Nevertheless this still does not make a difference about the following annoying problem: lorenz 149% ./ssh -v kobe OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 ssh: kobe: no address associated with name the following works: lorenz 150% ./ssh -v 192.168.0.1 OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 debug1: Connecting to 192.168.0.1 [192.168.0.1] port 22. Using 4.3p2 does not make any difference. as do things on the same machine with OpenSSH 4.2p1: lorenz 159% ./ssh -v kobe OpenSSH_4.2p1, OpenSSL 0.9.7i 14 Oct 2005 debug1: Connecting to kobe [192.168.0.1] port 22. There seems to be a problem with DNS resolution with 4.3p1 and p2. Do you have any idea what is going wrong? Can you suggest what I should test or look for? Is there a means to try step by step the changes included from 4.2p1 to 4.3p1? Thanks. Georg -- Georg Schwarz http://home.pages.de/~schwarz/ georg.schwarz at freenet.de +49 178 8545053 From dtucker at zip.com.au Mon Apr 17 11:13:46 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 17 Apr 2006 11:13:46 +1000 Subject: openssh 4.3 on IRIX 5.3 In-Reply-To: <2F177568-ECAC-4FC5-BBEE-09F4B526F9BE@freenet.de> References: <2F177568-ECAC-4FC5-BBEE-09F4B526F9BE@freenet.de> Message-ID: <4442EBCA.6050201@zip.com.au> Georg Schwarz wrote: > Dear developers, > > OpenSSH 4.3 (both p1 and p2) has a number of issues on IRIX 5.3 which > were not present with 4.2p1: > > configure thinks that a number of header files are unusable. This is > because in order to use them other headers such as sys/types.h must > be included as well, and configure's test code does not do so. > > checking ia.h usability... no > checking ia.h presence... yes > configure: WARNING: ia.h: present but cannot be compiled [...] Many of these have been fixed after the 4.3p2 release. Could you please try the latest snapshot and let us know if any still occur? ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ > lorenz 149% ./ssh -v kobe > OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 > ssh: kobe: no address associated with name [...] > There seems to be a problem with DNS resolution with 4.3p1 and p2. > Do you have any idea what is going wrong? Can you suggest what I > should test or look for? > Is there a means to try step by step the changes included from 4.2p1 > to 4.3p1? Thanks. A couple of things to try: 1) manually move "-lresolv" to the end of the LIBS in Makefile. At least one other system (Reliant Unix) exhibits a similar problem and this is the workaround. 2) Define BROKEN_GETADDRINFO in config.h (if it's not already). -- 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 senthilkumar_sen at hotpop.com Mon Apr 17 19:25:14 2006 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Mon, 17 Apr 2006 14:55:14 +0530 Subject: OpenSSH fips compliance References: <41a301c66067$76069a40$220110ac@sekco> <80d7e4090604151738v45b5b965hf7010126b7e59b62@mail.gmail.com> Message-ID: <089a01c66200$f47a36d0$220110ac@sekco> "Stephen John Smoogen" wrote: > > Ok.. I am not a member of the SSH team.. I just am dealing with FIPS > items currently where I work. > > Which FIPS are you meaning to be compliant with? There are multiple of > them that could potentially cover OpenSSH. Second who is the > sponsoring Federal agency for FIPS compliance? From what I can tell.. > it would be a bigger point for OpenSSH to have a solid financial floor > versus any sort of 'compliance' work. Im talking about FIPS 140-2 which is available at http://csrc.nist.gov/cryptval/140-1/140sp/140sp642.pdf. This says that applications (like OpenSSH etc) using fips certified OpenSSL needs to follow some guidelines. Also, the MD5 is not supported in fips and it needs some work on OpenSSH code. I digged up the old archives and came across some patches during June 2004 time frame and not sure about support level for it today. Is there any other recommendations? Thanks, Senthil Kumar. From apb at cequrux.com Mon Apr 17 20:46:03 2006 From: apb at cequrux.com (Alan Barrett) Date: Mon, 17 Apr 2006 12:46:03 +0200 Subject: [PATCH] bug in check_parent_exists() in ssh-agent.c In-Reply-To: <20060412205623.GG23652@apb-laptoy.apb.alt.za> References: <20060412205623.GG23652@apb-laptoy.apb.alt.za> Message-ID: <20060417104603.GC5154@apb-laptoy.apb.alt.za> Does anybody pay attention to bug reports or patches posted here? --apb (Alan Barrett) From georg.schwarz at freenet.de Mon Apr 17 21:43:04 2006 From: georg.schwarz at freenet.de (Georg Schwarz) Date: Mon, 17 Apr 2006 13:43:04 +0200 Subject: openssh 4.3 on IRIX 5.3 In-Reply-To: <4442EBCA.6050201@zip.com.au> References: <2F177568-ECAC-4FC5-BBEE-09F4B526F9BE@freenet.de> <4442EBCA.6050201@zip.com.au> Message-ID: <2D0FEF39-AE79-4ADE-BE19-2A5A5F2EE385@freenet.de> Thanks for your response. Am 17.04.2006 um 03:13 schrieb Darren Tucker: > Many of these have been fixed after the 4.3p2 release. Could you > please try the latest snapshot and let us know if any still occur? as of the 4.3p2 release the following ones are still present: ia.h, sys/dir.h, sys/prctl.h This is still the same with the latest snapshot. If you need further details please let me know. > > ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ > >> lorenz 149% ./ssh -v kobe >> OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 >> ssh: kobe: no address associated with name > [...] >> There seems to be a problem with DNS resolution with 4.3p1 and p2. >> Do you have any idea what is going wrong? Can you suggest what I >> should test or look for? >> Is there a means to try step by step the changes included from >> 4.2p1 to 4.3p1? Thanks. > > A couple of things to try: > > 1) manually move "-lresolv" to the end of the LIBS in Makefile. At > least one other system (Reliant Unix) exhibits a similar problem > and this is the workaround. This library does not seem to exist on IRIX 5.3: Can't locate file for: -lresolv > > 2) Define BROKEN_GETADDRINFO in config.h (if it's not already). it wasn't already, but it did not make any difference either :-( Is there a way I could try old snapshots between 4.2p1 and 4.3p1 to narrow down why name resolution no longer works with 4.3? an additional remark to the current snapshort: in packet.c please remove #include as it is already included through includes.h, and including it twice breaks things on IRIX 5.3 (actually the OS's header files should guard against this, but here it fails to do so) -- Georg Schwarz http://home.pages.de/~schwarz/ georg.schwarz at freenet.de +49 178 8545053 From dtucker at zip.com.au Mon Apr 17 22:14:31 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 17 Apr 2006 22:14:31 +1000 Subject: openssh 4.3 on IRIX 5.3 In-Reply-To: <2D0FEF39-AE79-4ADE-BE19-2A5A5F2EE385@freenet.de> References: <2F177568-ECAC-4FC5-BBEE-09F4B526F9BE@freenet.de> <4442EBCA.6050201@zip.com.au> <2D0FEF39-AE79-4ADE-BE19-2A5A5F2EE385@freenet.de> Message-ID: <444386A7.8070803@zip.com.au> Georg Schwarz wrote: > it wasn't already, but it did not make any difference either :-( > > Is there a way I could try old snapshots between 4.2p1 and 4.3p1 to > narrow down why name resolution no longer works with 4.3? We don't keep really old snapshots but you can pull the old trees by date from anoncvs as long as you have autoconf (v2.59) to rebuild configure. $ export CVS_RSH=ssh $ cvs -d anoncvs at anoncvs.mindrot.org:/cvs co openssh then update for specific dates: cvs up -D '[date]' 4.2p1 was 2005/09/01 and 4.3p1 was 2006/02/01. A binary search should narrow it down. I'll look at the other things in your mail tomorrow. -- 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 stuge-openssh-unix-dev at cdy.org Mon Apr 17 23:27:41 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Mon, 17 Apr 2006 15:27:41 +0200 Subject: [PATCH] bug in check_parent_exists() in ssh-agent.c In-Reply-To: <20060417104603.GC5154@apb-laptoy.apb.alt.za> References: <20060412205623.GG23652@apb-laptoy.apb.alt.za> <20060417104603.GC5154@apb-laptoy.apb.alt.za> Message-ID: <20060417132742.5136.qmail@cdy.org> On Mon, Apr 17, 2006 at 12:46:03PM +0200, Alan Barrett wrote: > Does anybody pay attention to bug reports or patches posted here? Generally speaking, yes, certainly. But reporting them on bugzilla is prefered to make sure they aren't forgotten. //Peter From rapier at psc.edu Tue Apr 18 00:54:57 2006 From: rapier at psc.edu (Chris Rapier) Date: Mon, 17 Apr 2006 10:54:57 -0400 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <20060413152209.GL9135@calimero.vinschen.de> References: <20060404093233.GA16456@calimero.vinschen.de> <4432DC9C.6010103@psc.edu> <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> <44344361.6090101@psc.edu> <20060412114632.GD9135@calimero.vinschen.de> <20060412121037.GA30916@gate.dtucker.net> <20060412144338.GE9135@calimero.vinschen.de> <443D8F02.6010201@psc.edu> <20060413152209.GL9135@calimero.vinschen.de> Message-ID: <4443AC41.6070205@psc.edu> Hi, back from vacation. Try turning off buffer polling and modifying the size of the receive window. This may help a bit. I'll be running some tests over the next day or so to see what I can come up with. Any suggestions or observations you have would be useful to me. Thanks again! Chris Corinna Vinschen wrote: > On Apr 12 19:36, Chris Rapier wrote: >> I ran some preliminary performance tests on LAN to LAN connections. >> Right now it is just OS X 10.4 to OS X 10.4. I'm not seeing any >> significant performance difference between the various implementations >> regardless of the combination. Anyway, I'm on vacation until Monday but >> when I get back I'll try some linux to cygwin tests to see if I can >> replicate your problem. I'll try some other combinations in the next few >> weeks as well. >> >> Corinna, have you tried using any of the config switches to see fi they >> have an impact on the performance? > > Uh, no, I didn't. But thanks for the hint, I play a bit with it as > time permits. > > > Corinna > From dlochart at gmail.com Tue Apr 18 03:33:41 2006 From: dlochart at gmail.com (Doug Lochart) Date: Mon, 17 Apr 2006 17:33:41 +0000 Subject: automating ssh-keygen Message-ID: <1e71f8880604171033u3df5cd5amf25f997ea503f454@mail.gmail.com> I am trying to automate ssh-keygen creating keys without a passphrase. How can I run a script that calls ssh-keygen so that it does NOT require a passphrase? When I was testing on the command line I created a file that contained 2 line feeds and piped it into stdin. I got a message mentioning that ssh-askpass could not be found and it completed. I did not try the keys but I would like to be able to generate them without any error messages. Is this possible? thanks -- What profits a man if he gains the whole world yet loses his soul? From dkg-openssh.com at fifthhorseman.net Tue Apr 18 04:10:31 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 17 Apr 2006 14:10:31 -0400 Subject: automating ssh-keygen In-Reply-To: <1e71f8880604171033u3df5cd5amf25f997ea503f454@mail.gmail.com> References: <1e71f8880604171033u3df5cd5amf25f997ea503f454@mail.gmail.com> Message-ID: <17475.55831.965563.875541@localhost.localdomain> Hi Doug-- On April 17, dlochart at gmail.com said: > I am trying to automate ssh-keygen creating keys without a > passphrase. Modern versions of openssh's ssh-keygen allow you to specify a new passphrase on the command line with the -N argument. So: ssh-keygen -N '' -f ./newkey -t rsa -q would make ./newkey (the passwordless, private key), and ./newkey.pub (the public key). It should return without errors in most normal situations. -q ("quiet") avoids printing the normal status messages generated by ssh-keygen. Please read the man page for ssh-keygen ("man ssh-keygen" or use the web [0]) for more details. hth, --dkg [0] http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen From petesea at bigfoot.com Tue Apr 18 05:00:57 2006 From: petesea at bigfoot.com (Dan Peterson) Date: Mon, 17 Apr 2006 12:00:57 -0700 (Pacific Daylight Time) Subject: OpenSSH 4.3p2, MIT KfW 3.0 and Cygwin In-Reply-To: <57DD51AF4CD87C30E6AFFC55@[192.168.1.2]> References: <57DD51AF4CD87C30E6AFFC55@[192.168.1.2]> Message-ID: On Wed, 12 Apr 2006, Carson Gaspar wrote: > --On Wednesday, April 12, 2006 2:26 PM -0700 Dan Peterson > wrote: > >> The GOAL is a GSSAPI enabled ssh client (preferably with gssapi-keyex >> support) that uses the nice GUI front-end provided by KfW. Those >> windows users get too confused if you tell them they have to go to the >> command prompt and run "kinit" every morning. > > FYI if you use the native SSPI, your tickets are refreshed every time > you unlock your screen. Of course SSPI presumes you either use your AD > servers as your KDCs for all systems, or that you have a trust > relationship between the realms. I'm (mostly) aware of SSPI, but as I understand it, it means the authentication for the entire workstation needs to change. I only want to use ssh with gssapi on a per application basis (CVS/Subversion). Simply put, I don't have enough control over the developers (thousands) to require they change the authentication defaults for their workstation. Nor do I have ANY control over the KDCs or AD servers. From dtucker at zip.com.au Tue Apr 18 10:27:57 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Apr 2006 10:27:57 +1000 Subject: automating ssh-keygen In-Reply-To: <1e71f8880604171033u3df5cd5amf25f997ea503f454@mail.gmail.com> References: <1e71f8880604171033u3df5cd5amf25f997ea503f454@mail.gmail.com> Message-ID: <4444328D.3040304@zip.com.au> Doug Lochart wrote: > I am trying to automate ssh-keygen creating keys without a passphrase. > How can I run a script that calls ssh-keygen so that it does NOT > require a passphrase? When I was testing on the command line I > created a file that contained 2 line feeds and piped it into stdin. I > got a message mentioning that ssh-askpass could not be found and it > completed. That didn't work because ssh-keygen reads its passphrases from its controlling terminal (or ssh-askpass) not stdin. > I did not try the keys but I would like to be able to > generate them without any error messages. Is this possible? $ ssh-keygen -N '' -f foo -- 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 william at 25thandClement.com Tue Apr 18 12:36:02 2006 From: william at 25thandClement.com (William Ahern) Date: Mon, 17 Apr 2006 19:36:02 -0700 Subject: SSH_CHANNEL_UNIX_LISTENER Message-ID: <20060418023602.GA30285@orville.25thandClement.com> I'm creating a patch to support Unix domain socket forwarding. I hadn't intended to initally support specifying remote Unix domain sockets (#ifdef'd that code out in the parse_forward() work), but now that I've gotten as far as channel_setup_fwd_listener() it seems like it makes sense to add the support now, rather than later. Any comments on adding to channels.h the following (w/ accompanying support)? #define SSH_CHANNEL_UNIX_LISTENER 15 #define SSH_CHANNEL_RUNIX_LISTENER 16 I'm guessing that this channel type enumeration is specified in one of the myriad SECSH RFCs. Does the above make sense, or should I really keep my patch to only supporting local Unix domain sockets support for now. - Bill From william at 25thandClement.com Tue Apr 18 12:49:24 2006 From: william at 25thandClement.com (William Ahern) Date: Mon, 17 Apr 2006 19:49:24 -0700 Subject: ControlAllowUsers Message-ID: <20060418024924.GA7526@orville.25thandClement.com> About two months ago I sent out a patch which provided for a list of users allowed to access a master control socket (rather than the current self or root). Did anybody look at it? Was there any interest? Does it need tweaking? I could think of many uses for it, and I hate to see it linger. - Bill From tero.tilus at jyu.fi Tue Apr 18 14:26:34 2006 From: tero.tilus at jyu.fi (Tero Tilus) Date: Tue, 18 Apr 2006 07:26:34 +0300 Subject: Wishlist: addition to FAQ 2.7 Message-ID: <20060418042634.GF10395@jyu.fi> After making quite a few circles around one particular issue (and eventually resolving it) I have a suggestion to make: Append the following to http://www.openssh.org/faq.html#2.7 "NOTE: In order to agent forwarding to work you need to have xauth installed in the remote host. In Debian xauth is in 'xbase-clients' package." And about that "F" in "FAQ". I have confirmed that at least one person other than me has had the same issue. :) -- Tero Tilus ########### http://www.iki.fi/tero.tilus/ http://www.maahinkainen.org/ ## http://www.effi.org/ From dtucker at zip.com.au Tue Apr 18 18:25:45 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Apr 2006 18:25:45 +1000 Subject: Wishlist: addition to FAQ 2.7 In-Reply-To: <20060418042634.GF10395@jyu.fi> References: <20060418042634.GF10395@jyu.fi> Message-ID: <4444A289.90905@zip.com.au> Tero Tilus wrote: > After making quite a few circles around one particular issue (and > eventually resolving it) I have a suggestion to make: > > Append the following to http://www.openssh.org/faq.html#2.7 > > "NOTE: In order to agent forwarding to work you need to have xauth > installed in the remote host. In Debian xauth is in 'xbase-clients' > package." xauth has nothing to do with agent forwarding. I assume you meant X11 forwarding? -- 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 rich at horizon.com Tue Apr 18 19:59:16 2006 From: rich at horizon.com (rich at horizon.com) Date: 18 Apr 2006 05:59:16 -0400 Subject: configure sys/audit.h WARNING Message-ID: <20060418095916.18663.qmail@science.horizon.com> Since the configure script requests... checking sys/audit.h usability... no checking sys/audit.h presence... yes configure: WARNING: sys/audit.h: present but cannot be compiled configure: WARNING: sys/audit.h: check for missing prerequisite headers? configure: WARNING: sys/audit.h: see the Autoconf documentation configure: WARNING: sys/audit.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/audit.h: proceeding with the preprocessor's result configure: WARNING: sys/audit.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 sys/audit.h... yes (This is from openbssh 4.2p1.) Doing a bit of retrocomputing here... SunOS 4.1.4 requires to define the blabel_t typedef before , or you get compile errors. I notice that openbsd-compat/xcrypt.c, where HAVE_GETPWANAM is used, does get this right. Other than that, it appears to be working. The lack of a prototype in scope for the emulated strerror() function causes a lot of warnings over printf formats. Fortunately, sizeof(char *) == sizeof(int), so it ends up working anyway, but you may want to fix that. I did have one problem with strtonum() alreays returning "too small", even if the input value is in range or ridiculously too large. E.g. ssh-keygen -b 99999 prints "Bits has bad value 99999 (too small)". I suspect this is a GCC long long bug; I'm using a truly ancient version of gcc. Changing strtonum() to use "long" rather than "long long" worked around the problem, so don't panic about that. (Via what is probably preprocessor magic, strtoll() returns "long" on this system anyway.) But I did look at the compiler output for strtonum.c, and the beginning is kind of ugly. The struct errval ev[4] could really stand to be declared static. And const. With some alternative hack to preserve errno if there is no error. Anyway, thanks for a great tool! From tero.tilus at jyu.fi Tue Apr 18 21:51:08 2006 From: tero.tilus at jyu.fi (Tero Tilus) Date: Tue, 18 Apr 2006 14:51:08 +0300 Subject: Wishlist: addition to FAQ 2.7 In-Reply-To: <4444A289.90905@zip.com.au> References: <20060418042634.GF10395@jyu.fi> <4444A289.90905@zip.com.au> Message-ID: <20060418115108.GH10395@jyu.fi> 2006-04-18 18:25, Darren Tucker: > I assume you meant X11 forwarding? Yes. Sorry about mixup. -- Tero Tilus ########### http://www.iki.fi/tero.tilus/ http://www.maahinkainen.org/ ## http://www.effi.org/ From dtucker at zip.com.au Tue Apr 18 21:56:51 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 18 Apr 2006 21:56:51 +1000 Subject: Wishlist: addition to FAQ 2.7 In-Reply-To: <20060418115108.GH10395@jyu.fi> References: <20060418042634.GF10395@jyu.fi> <4444A289.90905@zip.com.au> <20060418115108.GH10395@jyu.fi> Message-ID: <4444D403.3000704@zip.com.au> Tero Tilus wrote: > 2006-04-18 18:25, Darren Tucker: >> I assume you meant X11 forwarding? > > Yes. Sorry about mixup. No problem, I was just wondering if Debian had some kind of weird interdependency :-) I have added the following paragraph: "X11 forwarding requires a working xauth(1) binary. On OpenBSD this is in the xbase file set but will probably be different on other platforms. For OpenSSH Portable, xauth must be either found at configure time or specified via XAuthLocation in sshd_config(5) and ssh_config(5)." -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Tue Apr 18 22:23:31 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 18 Apr 2006 14:23:31 +0200 Subject: High Performance SSH/SCP - HPN-SSH when? In-Reply-To: <4443AC41.6070205@psc.edu> References: <44330AAB.1020707@zip.com.au> <4433261B.1020103@psc.edu> <44332D2A.9040805@zip.com.au> <44344361.6090101@psc.edu> <20060412114632.GD9135@calimero.vinschen.de> <20060412121037.GA30916@gate.dtucker.net> <20060412144338.GE9135@calimero.vinschen.de> <443D8F02.6010201@psc.edu> <20060413152209.GL9135@calimero.vinschen.de> <4443AC41.6070205@psc.edu> Message-ID: <20060418122331.GH11759@calimero.vinschen.de> On Apr 17 10:54, Chris Rapier wrote: > Hi, back from vacation. Try turning off buffer polling and modifying the > size of the receive window. This may help a bit. I'll be running some > tests over the next day or so to see what I can come up with. Any > suggestions or observations you have would be useful to me. I'm sorry, I didn't test this further so far. I'm always back to raising the buffer sizes in clientloop.c as the main factor to influence the speed. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From djm at mindrot.org Tue Apr 18 22:47:10 2006 From: djm at mindrot.org (Damien Miller) Date: Tue, 18 Apr 2006 22:47:10 +1000 (EST) Subject: cygwin performance problem In-Reply-To: <20060404093233.GA16456@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> Message-ID: On Tue, 4 Apr 2006, Corinna Vinschen wrote: > Not sure if it's ok to discuss this here. However, we have some > performance problems on Cygwin with the vanilla version of OpenSSH. The > main problem is the size of the read buffers in the client loop, resp. > client_process_net_input/client_process_input. The buffer size is a > fixed 8K. For some reason this degrades performance on Windows > enormously Is it necessary to adjust both these buffers? Or does increasing only the network buffer in client_process_net_input() help? > By raising the aforementioned buffers in clientloop.c from 8192 to, say, > 87380 (default tcp recv buffer size), the latter copy is way faster: Have you tried smaller numbers than 87380? It isn't much effort to crank these buffers up if smaller reads have a performance penalty on Windows, but I'd prefer to make changes based on some measurements. Could you try a range of buffer sizes from 8192 up (doubling perhaps) and see if there is a sweet spot of size vs. performance? > Is it ok to do that? Is there any problem you would expect from raising > the buffer sizes? Is there any reason to keep the buffers at 8K in the > vanilla version or would it be ok to raise the buffers to a somewhat > bigger value like 64K or the aforementioned 87380 bytes? I think raising these sizes is safe: all the file descriptors are in non-blocking state so increasing them will only read more data if it is already available on the kernel side at the expense of some stack space... -d From dkg-openssh.com at fifthhorseman.net Tue Apr 18 23:22:23 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 18 Apr 2006 09:22:23 -0400 Subject: Wishlist: addition to FAQ 2.7 In-Reply-To: <4444D403.3000704@zip.com.au> References: <20060418042634.GF10395@jyu.fi> <4444A289.90905@zip.com.au> <20060418115108.GH10395@jyu.fi> <4444D403.3000704@zip.com.au> Message-ID: <17476.59407.158111.97806@localhost.localdomain> On April 18, dtucker at zip.com.au said: > "X11 forwarding requires a working xauth(1) binary. [...] Not to pick nits, but you may want to say "on the server" here. Thanks for updating the FAQ. It's one of the more useful ones out there. --dkg From dtucker at zip.com.au Wed Apr 19 00:02:02 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 19 Apr 2006 00:02:02 +1000 Subject: Wishlist: addition to FAQ 2.7 In-Reply-To: <17476.59407.158111.97806@localhost.localdomain> References: <20060418042634.GF10395@jyu.fi> <4444A289.90905@zip.com.au> <20060418115108.GH10395@jyu.fi> <4444D403.3000704@zip.com.au> <17476.59407.158111.97806@localhost.localdomain> Message-ID: <20060418140202.GA26463@gate.dtucker.net> On Tue, Apr 18, 2006 at 09:22:23AM -0400, Daniel Kahn Gillmor wrote: > On April 18, dtucker at zip.com.au said: > > > "X11 forwarding requires a working xauth(1) binary. [...] > > Not to pick nits, but you may want to say "on the server" here. No, xauth gets used on both client and server. Try "ssh -vvv -X somehost" and you will see the client running xauth. > Thanks for updating the FAQ. It's one of the more useful ones out > there. You're welcome. -- 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 dkg-openssh.com at fifthhorseman.net Wed Apr 19 00:23:54 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 18 Apr 2006 10:23:54 -0400 Subject: Wishlist: addition to FAQ 2.7 In-Reply-To: <20060418140202.GA26463@gate.dtucker.net> References: <20060418042634.GF10395@jyu.fi> <4444A289.90905@zip.com.au> <20060418115108.GH10395@jyu.fi> <4444D403.3000704@zip.com.au> <17476.59407.158111.97806@localhost.localdomain> <20060418140202.GA26463@gate.dtucker.net> Message-ID: <17476.63098.831371.991321@localhost.localdomain> On April 19, dtucker at zip.com.au said: > No, xauth gets used on both client and server. Try "ssh -vvv -X > somehost" and you will see the client running xauth. ah. right. i think i've never seen someone try to forward X11 to a local X11 workstation that *doesn't* have xauth (though i suppose such machines must exist). But i've certainly seen people beat their head against the wall trying to forward X11 connections from an xauth-less server. Maybe "on both the client and the server" then? For folks who already know how X11 works, this information is probably redundant (and it's certainly implied by the "sshd_config and ssh_config" reference). But this FAQ is for the folks who don't know yet, right? --dkg From vinschen at redhat.com Wed Apr 19 02:11:06 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 18 Apr 2006 18:11:06 +0200 Subject: cygwin performance problem In-Reply-To: References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> Message-ID: <20060418161106.GA25977@calimero.vinschen.de> On Apr 18 22:47, Damien Miller wrote: > On Tue, 4 Apr 2006, Corinna Vinschen wrote: > > Not sure if it's ok to discuss this here. However, we have some > > performance problems on Cygwin with the vanilla version of OpenSSH. The > > main problem is the size of the read buffers in the client loop, resp. > > client_process_net_input/client_process_input. The buffer size is a > > fixed 8K. For some reason this degrades performance on Windows > > enormously > > Is it necessary to adjust both these buffers? Or does increasing only > the network buffer in client_process_net_input() help? Yes, it's apparently enough to change the buffer in client_process_net_input. > > > By raising the aforementioned buffers in clientloop.c from 8192 to, say, > > 87380 (default tcp recv buffer size), the latter copy is way faster: > > Have you tried smaller numbers than 87380? It isn't much effort to > crank these buffers up if smaller reads have a performance penalty > on Windows, but I'd prefer to make changes based on some measurements. > Could you try a range of buffer sizes from 8192 up (doubling perhaps) > and see if there is a sweet spot of size vs. performance? I must admit that I have only tried 65536 and bigger sizes. I made some tests now with smaller buffer sizes, and the results are interesting. There's a performance maximum, which is at buffer sizes between 17408 and 21504 bytes. Every other buffer size below or above these values results in a decrease in performance. Buffersize Throughput Bytes MB/s 8192 1.3 12288 3.5 16384 6.6 17408 9.1 18432 9.1 19456 9.1 20480 9.1 21504 9.1 22528 5.9 24576 5.9 32768 5.9 49152 5.9 65536 5.6 87380 5.6 131072 5.6 524288 5.6 I don't see a reason for the maximum at this 17K to 21K area, but it's definitely not a problem of intermediate buffering in Cygwin. The user buffer is directly used in the call to the underlying Windows sockets call. So, well, maybe setting the buffer size to 20480 would be a useful compromise for all OSes?!? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From rapier at psc.edu Wed Apr 19 02:44:05 2006 From: rapier at psc.edu (Chris Rapier) Date: Tue, 18 Apr 2006 12:44:05 -0400 Subject: cygwin performance problem In-Reply-To: <20060418161106.GA25977@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> Message-ID: <44451755.4050209@psc.edu> Could you tell me a bit more about your network setup including the RTT between the hosts? I'm going to try this under OS X on 100bT and between two linux hosts at 1Gb. The results will mean more if the differences in the network environment are accounted for. Corinna Vinschen wrote: > On Apr 18 22:47, Damien Miller wrote: >> On Tue, 4 Apr 2006, Corinna Vinschen wrote: >>> Not sure if it's ok to discuss this here. However, we have some >>> performance problems on Cygwin with the vanilla version of OpenSSH. The >>> main problem is the size of the read buffers in the client loop, resp. >>> client_process_net_input/client_process_input. The buffer size is a >>> fixed 8K. For some reason this degrades performance on Windows >>> enormously >> Is it necessary to adjust both these buffers? Or does increasing only >> the network buffer in client_process_net_input() help? > > Yes, it's apparently enough to change the buffer in client_process_net_input. >>> By raising the aforementioned buffers in clientloop.c from 8192 to, say, >>> 87380 (default tcp recv buffer size), the latter copy is way faster: >> Have you tried smaller numbers than 87380? It isn't much effort to >> crank these buffers up if smaller reads have a performance penalty >> on Windows, but I'd prefer to make changes based on some measurements. >> Could you try a range of buffer sizes from 8192 up (doubling perhaps) >> and see if there is a sweet spot of size vs. performance? > > I must admit that I have only tried 65536 and bigger sizes. I made some > tests now with smaller buffer sizes, and the results are interesting. > There's a performance maximum, which is at buffer sizes between 17408 > and 21504 bytes. Every other buffer size below or above these values > results in a decrease in performance. > > Buffersize Throughput > Bytes MB/s > > 8192 1.3 > 12288 3.5 > 16384 6.6 > 17408 9.1 > 18432 9.1 > 19456 9.1 > 20480 9.1 > 21504 9.1 > 22528 5.9 > 24576 5.9 > 32768 5.9 > 49152 5.9 > 65536 5.6 > 87380 5.6 > 131072 5.6 > 524288 5.6 > > I don't see a reason for the maximum at this 17K to 21K area, but it's > definitely not a problem of intermediate buffering in Cygwin. The user > buffer is directly used in the call to the underlying Windows sockets > call. > > So, well, maybe setting the buffer size to 20480 would be a useful > compromise for all OSes?!? > > > Corinna > From bsd at unixforge.net Wed Apr 19 04:54:38 2006 From: bsd at unixforge.net (Eli K. Breen) Date: Tue, 18 Apr 2006 11:54:38 -0700 Subject: OpenSSH and Idle Timeouts Message-ID: <444535EE.1030908@unixforge.net> Theo et al., I've looked back through the OpenSSH mailing lists and am stumped as to why there is no IdleTimeout option for OpenSSH. (Normally the omission of a feature as useful as this generates much debate and flame-quashing from the dev. team). Is there some background to this that I'm missing? Here's the scenario, and I'm fully open to any workarounds. We use a combination of OpenBSD(3.7) and FreeBSD(5.x/6.0) machines as various SSH access points to our network. Developers and users, being only human, often end up leaving idle connections open for days/weeks/months at a time. This is both unsightly (from the admin perspective) and generally makes auditing and user activity tracking/tracing much more difficult. In short, I'm looking for a way to expire idle connections across both of these platforms while sticking with OpenSSH because of its excellent security history and close ties to the *BSDs. Are there any plans to add idle timeouts to OpenSSH in future? Does anyone have any proven methods and/or patches for working around this problem? Many thanks, Eli. From pekkas at netcore.fi Wed Apr 19 05:41:34 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 18 Apr 2006 22:41:34 +0300 (EEST) Subject: OpenSSH and Idle Timeouts In-Reply-To: <444535EE.1030908@unixforge.net> References: <444535EE.1030908@unixforge.net> Message-ID: On Tue, 18 Apr 2006, Eli K. Breen wrote: > I've looked back through the OpenSSH mailing lists and am stumped as to > why there is no IdleTimeout option for OpenSSH. (Normally the omission > of a feature as useful as this generates much debate and flame-quashing > from the dev. team). > > Is there some background to this that I'm missing? > > Here's the scenario, and I'm fully open to any workarounds. Maybe you should look at this functionality in th shells you're using.. tcsh: set autologout=x bash: export TMOUT=[x*60] There are ways how these don't get triggered, but maybe sshd shouldn't forcibly terminate the session under those circumstances, no matter the delay. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rapier at psc.edu Wed Apr 19 07:09:17 2006 From: rapier at psc.edu (Chris Rapier) Date: Tue, 18 Apr 2006 17:09:17 -0400 Subject: cygwin performance problem In-Reply-To: <20060418161106.GA25977@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> Message-ID: <4445557D.8070302@psc.edu> > So, well, maybe setting the buffer size to 20480 would be a useful > compromise for all OSes?!? I only looked at 3 buffer sizes. 8k, 20k and 65k. In each case I ran 20 iterations (I should run 100 really). The format for the results is low/high/average/median OS X -> OS X (same subnet) RAM disk to /dev/null, 200MB file, no compression 100bT network, full duplex, rtt 0.293ms 64k - 8.7/10.5/9.9/10.0 20k - 9.5/10.5/10.2/10.0 8k - 8.3/10.5/9.8/10.0 Linux -> OS X (different subnets) disk to /dev/null, 200MB file, no compression 1000bT -> 100bT network, full duplex, rtt 1.2ms 64k - 8.3/10.5/10.1/10.5 20k - 9.1/10.5/10.2/10.5 8k - 9.1/10.5/10.3/10.5 Linux -> Linux (different subnets (and different than the above)) RAM disk to /dev/null, 200MB file, no compression 1000bT network, full duplex, rtt 0.868ms 64k - 12.5/15.4/13.5/13.3 20k - 15.4/18.2/16.6/16.7 8k - 18.2/20.0/19.0/18.2 Okay, so I didn't trust that last round of tests so I re-ran them. 64k - 13.3/18.2/14.46/14.3 20k - 15.4/16.7/15.53/15.4 8k - 18.2/20.0/18.47/18.2 This seemed odd to me so I tried it with another system a bit further away. Unfortunately, to get past the impact of the congestion control buffer on high BDP links I had to use the HPN patch. So that *may* influence the change in clientloop.c somewhat. Linux -> Linux (pittsburgh to colorado) RAM disk to /dev/null, 200MB file, no compression 155mbps network via Internet2/Abilene, rtt 58.8ms 64k - 5.6/12.5/10.56/10.5 20k - 7.7/12.5/10.60/10.5 8k - 11.1/11.8/11.59/11.8 ( 9.5/12.5/10.83/11.1) I reran the 8k sample to make sure the results for that weren't time dependent as the 64k and 20k samples were run around 90 minutes after the 8k sample. The rerun sample is in parentheses. At this point I'm going to guess that there is statistically no or minimal impact on throughput between the different buffer sizes on this network path. So my conclusions are that switching the buffer in client_process_net_input might have, in some conditions with midrange rtts on fast networks, end up having an overall negative impact. I'm not going to speculate as to why at this point. If anyone cares I'll rerun the tests with increase sample sizes, some more buffer sizes, and get the standard deviation. Chris From dtucker at zip.com.au Wed Apr 19 10:42:24 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 19 Apr 2006 10:42:24 +1000 Subject: OpenSSH and Idle Timeouts In-Reply-To: <444535EE.1030908@unixforge.net> References: <444535EE.1030908@unixforge.net> Message-ID: <44458770.9050601@zip.com.au> Eli K. Breen wrote: > Theo et al., > > I've looked back through the OpenSSH mailing lists and am stumped as to > why there is no IdleTimeout option for OpenSSH. (Normally the omission > of a feature as useful as this generates much debate and flame-quashing > from the dev. team). > > Is there some background to this that I'm missing? > > Here's the scenario, and I'm fully open to any workarounds. > > We use a combination of OpenBSD(3.7) and FreeBSD(5.x/6.0) machines as > various SSH access points to our network. Developers and users, being > only human, often end up leaving idle connections open for > days/weeks/months at a time. This is both unsightly (from the admin > perspective) and generally makes auditing and user activity > tracking/tracing much more difficult. In short, I'm looking for a way to > expire idle connections across both of these platforms while sticking > with OpenSSH because of its excellent security history and close ties to > the *BSDs. > > Are there any plans to add idle timeouts to OpenSSH in future? Does > anyone have any proven methods and/or patches for working around this > problem? It depends on what you mean by "idle". If you mean "hasn't exchanged any protocol traffic for a while and might actually be gone" then see ClientAliveInterval and ClientAliveCountMax in sshd_config. If you mean "at the shell but haven't typed anything for a while" then there's no mechanism in sshd for that right now, and it's probably not something that sshd should be doing anyway; ssh connection != shell session (you can have zero, 1 or many shell sessions per ssh connection). There a couple of other options: shell timeout options (as others have pointed out) or there's an "idle daemon" that does this for all login types (the details escape me at the moment). -- 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 william at 25thandClement.com Thu Apr 20 04:59:48 2006 From: william at 25thandClement.com (William Ahern) Date: Wed, 19 Apr 2006 11:59:48 -0700 Subject: tcpip-forward with port 0 and 'want reply' Message-ID: <20060419185948.GA22226@orville.25thandClement.com> RFC 4254 says, in regards to the "tcpip-forward" request message: Section 7.1 ... If a client passes 0 as port number to bind and has 'want reply' as TRUE, then the server allocates the next available unprivileged port number and replies with the following message; otherwise, there is no response-specific data. byte SSH_MSG_REQUEST_SUCCESS uint32 port that was bound on the server However, it doesn't seem like OpenSSH supports this. If you request a port of zero, the code never 1) returns or 2) listens for the allocated port, even though 'want reply' is _always_ TRUE. So I'm left wondering, what happens if you request multiple forwardings w/ port 0 with different hostnames? Seems like there's a silent collision; not sure if it blows up. I'm no longer surprised nobody has added domain socket support yet. FWIW, the route I've take so far is replacing all the host/port pairs with a SocketName structure, and added the streamloceal-forward at openssh.com and forward-streamlocal at openssh.com messages. In the process I've run into trouble w/ ForwardPermissions. I suspect there's a bug in the SSH 2.0 support since it doesn't keep track of listening hostnames, only the port. Again, there's a silent collision and either the permissions are too strict or too loose. - Bill From djm at mindrot.org Thu Apr 20 18:00:54 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 20 Apr 2006 18:00:54 +1000 (EST) Subject: tcpip-forward with port 0 and 'want reply' In-Reply-To: <20060419185948.GA22226@orville.25thandClement.com> References: <20060419185948.GA22226@orville.25thandClement.com> Message-ID: On Wed, 19 Apr 2006, William Ahern wrote: > However, it doesn't seem like OpenSSH supports this. If you request a port > of zero, the code never 1) returns or 2) listens for the allocated port, > even though 'want reply' is _always_ TRUE. No, we don't support this presently. There is a patch in bugzilla but the last time I looked it required a bit more work. > In the process I've run into trouble w/ ForwardPermissions. I suspect > there's a bug in the SSH 2.0 support since it doesn't keep track of > listening hostnames, only the port. Again, there's a silent collision and > either the permissions are too strict or too loose. Yes, permitopen doesn't support specification of a bind_address presently. It should "fail closed" on ambiguous matches though, so why do you say the permissions are too loose? -d From vinschen at redhat.com Thu Apr 20 19:41:29 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 20 Apr 2006 11:41:29 +0200 Subject: cygwin performance problem In-Reply-To: <44451755.4050209@psc.edu> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> <44451755.4050209@psc.edu> Message-ID: <20060420094129.GN11759@calimero.vinschen.de> On Apr 18 12:44, Chris Rapier wrote: > Could you tell me a bit more about your network setup including the RTT > between the hosts? I'm going to try this under OS X on 100bT and between > two linux hosts at 1Gb. The results will mean more if the differences in > the network environment are accounted for. The hosts are on a 1Gb LAN. The RTT is in the 0.2ms area. However, while looking deeper into what's going on, it seems the bad results are somehow based on a strange interaction between ssh and scp, which triggers a performance problem in Cygwin. Writing to the pipe to scp and reading from the pipe in scp seem to take a lot of time. I still haven't understood what's going on, but the really weird thing is this: Not using scp for copying data results in far better performance. For instance (118MB file, client_process_net_input buffer at 8K) cygwin> scp linux:file . takes over 90 seconds. Copying the file using tar over ssh like this: cygwin> ssh linux 'tar cf - file' | tar xf - takes only about 8 seconds. A Linux to Linux copy takes about 7 seconds, with tar just slightly faster than using scp. On Cygwin, changing the buffer size in client_process_net_input() only affects the performance so drastically when using scp, but even in the best case, the performance is rather bad. I got the following average values, using scp and tar with 8K and 20K buffer in client_process_net_input(): secs / MB/s scp,8K tar,8K scp,20K tar,20K Linux->Cygwin 92.0/1.3 8.1/14.6 13.2/8.9 7.2/16.4 Linux->Linux 7.0/16.9 6.4/18.4 7.0/16.9 6.4/18.4 So, changing the buffer size on the input buffer doesn't really speed up the network connection (which is apparently fast enough), it just changes how ssh and scp interact. Since in both cases (scp/tar) the underlying Cygwin is identical, and since in both cases the file is locally copied over a pipe between the two processes (ssh->scp resp. ssh->tar), I'm currently really at a loss why scp is so slow. I tried various buffer sizes in the "sink" function in scp.c, values between 4K and 512K, but this had no influence at all. I have to debug this a lot more, apparently, but... if anybody has a clue why copying over scp could be so much slower than copying over tar, I'd really appreciate it. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From DSzymanski at axit.pl Thu Apr 20 21:57:26 2006 From: DSzymanski at axit.pl (Dawid Szymanski) Date: Thu, 20 Apr 2006 13:57:26 +0200 Subject: SSH and file descriptors Message-ID: <44477726.7040706@axit.pl> Let me start with "I am not sure if problem I describe is really ssh problem" so excuse me in that case. I've needed to make a login shell wrapper for one of users (an example below) to my own script: (shebang with -l or -i does not affect the problem) Real script does not matter, this example is to show you that I cant use error descriptor here;\ When I run this script while being logged on machine I get: user at machine ~ $ /usr/local/bin/myscript_shell > /dev/null ls: /this_does_not_exist: No such file or directory what we can see here is that stderr and stdout are separated... When I run this script over ssh I get: user at machine ~ $ ssh machine /usr/local/bin/myscript_shell > /dev/null Password: ls: /this_does_not_exist: No such file or directory here also stderr and stdout are separated... Now let me change change login shell (in /etc/passwd) for user "user" from "bash" to "myscript_shell"... and login again: user at machine ~ $ ssh machine > /dev/null Password: Connection to machine closed. Hmm, where is my stderr!?;\ to make sure that script is giving the same output.... user at machine ~ $ ssh machine Password: Last login: Thu Apr 20 13:50:36 2006 from machine ls: /this_does_not_exist: No such file or directory -rw-r--r-- 1 root root 2515 Apr 20 10:47 /etc/passwd Connection to machine closed. Is this ssh dependent? Is this wanted behavior? I need to have separated descriptors... as in all examples before login shell change... Any clue? Thx. -- Dawid Szymanski, dszymanski at axit.pl, +48 (71) 3352352 AXIT Polska Sp. z o.o., ul. Ruska 51b, 50-079 Wroclaw, Poland From rapier at psc.edu Fri Apr 21 06:17:49 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 20 Apr 2006 16:17:49 -0400 Subject: cygwin performance problem In-Reply-To: <20060420094129.GN11759@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> <44451755.4050209@psc.edu> <20060420094129.GN11759@calimero.vinschen.de> Message-ID: <4447EC6D.3010805@psc.edu> Corinna Vinschen wrote: > Since in both cases (scp/tar) the underlying Cygwin is identical, and > since in both cases the file is locally copied over a pipe between the > two processes (ssh->scp resp. ssh->tar), I'm currently really at a loss > why scp is so slow. I tried various buffer sizes in the "sink" function > in scp.c, values between 4K and 512K, but this had no influence at all. > I have to debug this a lot more, apparently, but... if anybody has a > clue why copying over scp could be so much slower than copying over tar, > I'd really appreciate it. Do you have any tools under cygwin that could tel you what syscalls are being made during the transfer? If we can find out where its spending so much of its time that might help. Also, regarding the buffer size: I'm not quite sure of which buffer you mean, however the value in if ((bp = allocbuf(&buffer, ofd, 4096)) == NULL) { is, as far as I know, the value which dictates how much is read off the pipe at a time. The *possible* problem here is that the other side of the pipe is using 16k chunks so you have a 4:1 disparity in the read/writes calls on each side of the pipe. If you are using the HPN version I've already change that line to if ((bp = allocbuf(&buffer, ofd, sizeof(buf))) == NULL) { and changed buf to 16k. On the test systems it provided a small improvement in performance (3% or so, not much but on fast connections 3% can be significant). So if you are using the HPN version to test this then try the canonical version. If you are, then I'd try changing that value and seeing what happens. I was planning on running some tests between linux, cygwin, and os x using multiple versions of ssh at, when possible, 3 different RTTs. I was just going to cat a 200MB file via SSH but I think I'll be adding another variable and compare scp as well. Since I'm running 1000 iterations its going to take a while (so 18,000 xfers). But maybe it will shed some light on this. From william at 25thandClement.com Fri Apr 21 06:19:51 2006 From: william at 25thandClement.com (William Ahern) Date: Thu, 20 Apr 2006 13:19:51 -0700 Subject: tcpip-forward with port 0 and 'want reply' In-Reply-To: References: <20060419185948.GA22226@orville.25thandClement.com> Message-ID: <20060420201951.GB3719@orville.25thandClement.com> On Thu, Apr 20, 2006 at 06:00:54PM +1000, Damien Miller wrote: > > In the process I've run into trouble w/ ForwardPermissions. I suspect > > there's a bug in the SSH 2.0 support since it doesn't keep track of > > listening hostnames, only the port. Again, there's a silent collision and > > either the permissions are too strict or too loose. > > Yes, permitopen doesn't support specification of a bind_address > presently. It should "fail closed" on ambiguous matches though, so why > do you say the permissions are too loose? > Well, I wasn't sure. It just looked funny. I didn't inspect it very closely, I just initially #ifdef'd out all the permitopen stuff to narrow the scope (the task was so daunting initially). I'll tackle that to round out the domain socket support. Is there anything in particular I should know or take into consideration0 when adding bind address info to the permitopen handling? From djm at mindrot.org Fri Apr 21 07:47:03 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Apr 2006 07:47:03 +1000 (EST) Subject: cygwin performance problem In-Reply-To: <20060420094129.GN11759@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> <44451755.4050209@psc.edu> <20060420094129.GN11759@calimero.vinschen.de> Message-ID: On Thu, 20 Apr 2006, Corinna Vinschen wrote: > However, while looking deeper into what's going on, it seems the bad > results are somehow based on a strange interaction between ssh and scp, > which triggers a performance problem in Cygwin. Writing to the pipe to > scp and reading from the pipe in scp seem to take a lot of time. Cygwin is set to use pipes instead of socketpairs for communication between scp/sftp and ssh, and between sshd and its subprocesses. Perhaps you could try commenting out the AC_DEFINE(USE_PIPES, 1, [Use PIPES instead of a socketpair()]) line under the cygwin host case value in configure.ac, or just deleting the "#define USE_PIPES" from the generated config.h. If performance improves it might indicate a problem with Cygwin's pipe implementation. -d From tryponraj at gmail.com Fri Apr 21 14:21:28 2006 From: tryponraj at gmail.com (ponraj) Date: Fri, 21 Apr 2006 09:51:28 +0530 Subject: Incorporating X.509 certificate patch into base OpenSSH Message-ID: <00c901c664fb$16a21e10$180110ac@pomco> Hi all, I am using OpenSSH4.3p2. I would like to make use of X.509 certificate support in OpenSSH. I came acroos the patch available at http://roumenpetrov.info/openssh/#features .Could you tell me the impact or any security constraints of incorporating X.509 certificate patch into OpenSSH base source ? -- Ponraj M From Tob_Sch at gmx.de Fri Apr 21 19:16:40 2006 From: Tob_Sch at gmx.de (Tob_Sch at gmx.de) Date: Fri, 21 Apr 2006 11:16:40 +0200 (MEST) Subject: scp of Files > 2GB on HP-UX causes "protocol error: size not delimited" References: <6424.1141215995@www047.gmx.net> Message-ID: <3727.1145611000@www083.gmx.net> Hi, we compiled OpenSSH 4.3p2 / OpenSSL 0.9.8a / zlib 1.2.3 on different platforms. When we copy files > 2GB with "scp" on HP-UX (compiled on HP-UX 11.00 with gcc 3.4.3) on a filesystem with activated largefile-option, we receive following: protocol error: size not delimited This does not happen with "sftp" on HP-UX on the same filesystem. This does not happen with "scp" and "sftp" on any other platform (SunOS, AIX, Linux). Thanks in advance for help. -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail From dtucker at zip.com.au Fri Apr 21 20:05:38 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 21 Apr 2006 20:05:38 +1000 Subject: scp of Files > 2GB on HP-UX causes "protocol error: size not delimited" In-Reply-To: <3727.1145611000@www083.gmx.net> References: <6424.1141215995@www047.gmx.net> <3727.1145611000@www083.gmx.net> Message-ID: <20060421100538.GA16835@gate.dtucker.net> On Fri, Apr 21, 2006 at 11:16:40AM +0200, Tob_Sch at gmx.de wrote: > we compiled OpenSSH 4.3p2 / OpenSSL 0.9.8a / zlib 1.2.3 on different > platforms. > > When we copy files > 2GB with "scp" on HP-UX (compiled on HP-UX 11.00 with > gcc 3.4.3) on a filesystem with activated largefile-option, we receive > following: > > protocol error: size not delimited It's a bug in OpenSSH's snprintf implementation. Description and patch here: http://bugzilla.mindrot.org/show_bug.cgi?id=1173 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Fri Apr 21 20:15:06 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 21 Apr 2006 12:15:06 +0200 Subject: cygwin performance problem In-Reply-To: References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> <44451755.4050209@psc.edu> <20060420094129.GN11759@calimero.vinschen.de> Message-ID: <20060421101506.GD12661@calimero.vinschen.de> On Apr 21 07:47, Damien Miller wrote: > On Thu, 20 Apr 2006, Corinna Vinschen wrote: > > > However, while looking deeper into what's going on, it seems the bad > > results are somehow based on a strange interaction between ssh and scp, > > which triggers a performance problem in Cygwin. Writing to the pipe to > > scp and reading from the pipe in scp seem to take a lot of time. > > Cygwin is set to use pipes instead of socketpairs for communication > between scp/sftp and ssh, and between sshd and its subprocesses. > Perhaps you could try commenting out the > > AC_DEFINE(USE_PIPES, 1, [Use PIPES instead of a socketpair()]) > > line under the cygwin host case value in configure.ac, or just deleting > the "#define USE_PIPES" from the generated config.h. If performance > improves it might indicate a problem with Cygwin's pipe implementation. I did that already, but afaics scp always uses pipes for copying files over ssh, or did I miss something? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From vinschen at redhat.com Fri Apr 21 20:22:33 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 21 Apr 2006 12:22:33 +0200 Subject: cygwin performance problem In-Reply-To: <4447EC6D.3010805@psc.edu> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> <44451755.4050209@psc.edu> <20060420094129.GN11759@calimero.vinschen.de> <4447EC6D.3010805@psc.edu> Message-ID: <20060421102233.GE12661@calimero.vinschen.de> On Apr 20 16:17, Chris Rapier wrote: > Corinna Vinschen wrote: > > > Since in both cases (scp/tar) the underlying Cygwin is identical, and > > since in both cases the file is locally copied over a pipe between the > > two processes (ssh->scp resp. ssh->tar), I'm currently really at a loss > > why scp is so slow. I tried various buffer sizes in the "sink" function > > in scp.c, values between 4K and 512K, but this had no influence at all. > > I have to debug this a lot more, apparently, but... if anybody has a > > clue why copying over scp could be so much slower than copying over tar, > > I'd really appreciate it. > > Do you have any tools under cygwin that could tel you what syscalls are > being made during the transfer? If we can find out where its spending so > much of its time that might help. Yes, and I can see that the most time is spent in select as well as reading and writing on the pipe. I still have to find out why this is, though. > Also, regarding the buffer size: I'm not quite sure of which buffer you > mean, however the value in > > if ((bp = allocbuf(&buffer, ofd, 4096)) == NULL) { Exactly this value. I hacked the code so that the buffer size is a configurable value. But changing this didn't improve the performance in a noticable manner. > Since I'm running 1000 > iterations its going to take a while (so 18,000 xfers). But maybe it > will shed some light on this. Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From mikhail.manuilov at gmail.com Fri Apr 21 20:35:28 2006 From: mikhail.manuilov at gmail.com (Mikhail Manuylov) Date: Fri, 21 Apr 2006 14:35:28 +0400 Subject: Solaris 8 x86 rsa pubkey auth problem Message-ID: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> Hello, I got some weird problem with public key authentication using rsa key pair. Let me first of all explain my setup. 1) I got two Solaris 8 x86 boxes uname -a SunOS 5.8 Generic_117351-24 i86pc i386 i86pc <---> 2) They're running absolutely identical openssh installations I'm using pkgsrc, so I've builded all necessary packages from two days old pkgsrc sources on one of the boxes and installed the same binaries on second OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 3) The only differense in their setup is that 'kdc' is a intel p4 boxm and module is p3 box. I've generated rsa key pair via ssh-keygen, and placed public part of it into /home/root/.ssh/authorized_keys on both computers. The problem: I can't log into any (not only to module) computer running the same version of sshd (and of course user holding the same public key) using 'kdc', pubkey athentication fails and ssh pops password prompt up. Pubkey athentication with that key works flawlessly with any other direction even when 'module' connecting to 'kdc'. How I can help debugging this problem: I've supplied debug output of both ssh and sshd from two cases: 1) 'module' authenticating on 'kdc' ( works ok ) 2) 'kdc' authenticating on 'module' ( pubkey failed ) I've already compiled gdb and openssh with debug info. I've also started two debug sshd yesterday, but due two my not so cool knowledge of openssh sources and maybe schema of forking and privelege separation I still can't reach user_key_allowed function. Thank you for your great work. And thanks for help beforehand. Here's debug output: 1) kdc# ssh -vvv -i ~/.ssh/auditor_rsa_id root at 192.168.10.10 OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 debug1: Reading configuration data /usr/pkg/etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.10.10 [ 192.168.10.10] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/1 debug3: Not a RSA1 key file auditor_id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file auditor_id_rsa type 2 debug1: Remote protocol version 2.0 , remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se ,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se ,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none, zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 115/256 debug2: bits set: 513/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 4 debug1: Host '192.168.10.10' is known and matches the RSA host key. debug1: Found key in /home/root/.ssh/known_hosts:4 debug2: bits set: 516/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: auditor_id_rsa (80b2d48) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: auditor_id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password 2) module# /usr/pkg/sbin/sshd -D -d -d -d -e debug2: load_server_config: filename /usr/pkg/etc/ssh/sshd_config debug2: load_server_config: done config len = 226 debug2: parse_server_config: config /usr/pkg/etc/ssh/sshd_config len 226 debug1: sshd version OpenSSH_4.3p1 debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/pkg/sbin/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-d' debug1: rexec_argv[3]='-d' debug1: rexec_argv[4]='-d' debug1: rexec_argv[5]='-e' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on 192.168.132.15. Server listening on 192.168.132.15 port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on 192.168.10.10. Server listening on 192.168.10.10 port 22. debug1: fd 5 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 10 config len 226 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 10 debug3: recv_rexec_state: entering fd = 5 debug3: ssh_msg_recv entering debug3: recv_rexec_state: done debug2: parse_server_config: config rexec len 226 debug1: sshd version OpenSSH_4.3p1 debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.10.11 port 8759 debug1: Client protocol version 2.0; client software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug3: privsep user:group 100:100 debug1: permanently_set_uid: 100/100 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug2: Network child is on pid 3358 debug3: preauth child monitor started debug3: mm_request_receive entering debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 1024 8192 debug3: mm_request_send entering: type 1 debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: dh_gen_key: priv key bits set: 129/256 debug2: bits set: 524/1024 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: bits set: 495/1024 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_answer_sign: signature 80c7850(271) debug3: mm_request_send entering: type 5 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: mm_request_receive entering debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow debug3: auth_shadow_acctexpired: today 13256 sp_expire -1 days left -13257 debug3: account expiration disabled debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug2: input_userauth_request: setting up authctxt for root debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug3: mm_answer_authpassword: sending result 0 debug3: mm_request_send entering: type 11 Failed none for root from 192.168.10.11 port 8759 ssh2 debug3: mm_request_receive entering debug3: mm_auth_password: user not authenticated Failed none for root from 192.168.10.11 port 8759 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 1 failures 1 debug2: input_userauth_request: try method publickey debug1: test whether pkalg/pkblob are acceptable debug3: mm_key_allowed entering debug3: mm_request_send entering: type 20 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 21 debug3: mm_request_receive entering debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 80c04e8 debug1: temporarily_use_uid: 0/1 (e=0/1) debug1: trying public key file /home/root/.ssh/authorized_keys debug3: secure_filename: checking '/usr/home/root/.ssh' debug3: secure_filename: checking '/usr/home/root' debug3: secure_filename: terminating check at '/usr/home/root' debug3: key_read: type mismatch debug2: user_key_allowed: check options: 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA5SXtHW7fmMWxkvjUKkB3pEygK6MkzOUejT8DCucnLJ2NT/lDdsWUR1Bz+nFmzFrcHEnP1H0+zlTEEEr T1StBaiWmMO1mqD/AXh7XjVylsV+7E9qcQ6OHjfYaNjSffk1hAzLokrXti0qeBbZpz8yAy4LsscxNdX97aDtDB2S9AJYoWSNVsnJJKDGYlQpHL1sK+rfezYOHfeCyBh/Ui07sF2RbPz3k59QFok5VY1EUwvM0 LMjXOAuTl0m7PyouuU3JSr7NRu52nsyNxPLwFvK1wvqX+5dJCIJ8Z9J1peWj4o51ERvKvx7rQSG7N/q10J41IU9koPsi/sr0usLmx3ROsw== root at kgc ' debug2: key_type_from_name: unknown key type 'AAAAB3NzaC1yc2EAAAABIwAAAQEA5SXtHW7fmMWxkvjUKkB3pEygK6MkzOUejT8DCucnLJ2NT/lDdsWUR1Bz+nFmzFrcHEnP1H0+zlTEEErT1St BaiWmMO1mqD/AXh7XjVylsV+7E9qcQ6OHjfYaNjSffk1hAzLokrXti0qeBbZpz8yAy4LsscxNdX97aDtDB2S9AJYoWSNVsnJJKDGYlQpHL1sK+rfezYOHfeCyBh/Ui07sF2RbPz3k59QFok5VY1EUwvM0LMjX OAuTl0m7PyouuU3JSr7NRu52nsyNxPLwFvK1wvqX+5dJCIJ8Z9J1peWj4o51ERvKvx7rQSG7N/q10J41IU9koPsi/sr0usLmx3ROsw==' debug3: key_read: missing keytype debug2: user_key_allowed: advance: 'AAAAB3NzaC1yc2EAAAABIwAAAQEA5SXtHW7fmMWxkvjUKkB3pEygK6MkzOUejT8DCucnLJ2NT/lDdsWUR1Bz+nFmzFrcHEnP1H0+zlTEEErT1StBaiWmMO1mq D/AXh7XjVylsV+7E9qcQ6OHjfYaNjSffk1hAzLokrXti0qeBbZpz8yAy4LsscxNdX97aDtDB2S9AJYoWSNVsnJJKDGYlQpHL1sK+rfezYOHfeCyBh/Ui07sF2RbPz3k59QFok5VY1EUwvM0LMjXOAuTl0m7Py ouuU3JSr7NRu52nsyNxPLwFvK1wvqX+5dJCIJ8Z9J1peWj4o51ERvKvx7rQSG7N/q10J41IU9koPsi/sr0usLmx3ROsw== root at kgc ' debug1: restore_uid: 0/1 debug2: key not found debug1: temporarily_use_uid: 0/1 (e=0/1) debug1: trying public key file /home/root/.ssh/authorized_keys2 debug1: restore_uid: 0/1 debug3: mm_answer_keyallowed: key 80c04e8 is disallowed debug3: mm_request_send entering: type 21 debug3: mm_request_receive entering debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss Failed publickey for root from 192.168.10.11 port 8759 ssh2 debug1: userauth-request for user root service ssh-connection method keyboard-interactive debug1: attempt 2 failures 2 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=root devs= debug1: kbdint_alloc: devices 'skey' debug2: auth2_challenge_start: devices skey debug2: kbdint_next_device: devices debug1: auth2_challenge_start: trying authentication method 'skey' debug3: mm_skey_query: entering debug3: mm_request_send entering: type 16 debug3: mm_request_receive_expect entering: type 17 debug3: mm_request_receive entering debug3: monitor_read: checking request 16 debug3: mm_answer_skeyquery: sending challenge success: 0 debug3: mm_request_send entering: type 17 debug3: mm_request_receive entering debug3: mm_skey_query: no challenge Failed keyboard-interactive for root from 192.168.10.11 port 8759 ssh2 Connection closed by 192.168.10.11 debug1: do_cleanup debug1: do_cleanup 3) module# ssh -vvv -i ~/.ssh/auditor_rsa_id root at 192.168.10.11 OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 debug1: Reading configuration data /usr/pkg/etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.10.11 [192.168.10.11] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/1 debug3: Not a RSA1 key file auditor_id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file auditor_id_rsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se ,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se ,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se ,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se ,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none, zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 143/256 debug2: bits set: 522/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 15 debug1: Host '192.168.10.11' is known and matches the RSA host key. debug1: Found key in /home/root/.ssh/known_hosts:15 debug2: bits set: 483/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: auditor_id_rsa (0) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: auditor_id_rsa debug1: read PEM private key done: type RSA debug3: sign_and_send_pubkey debug2: we sent a publickey packet, wait for reply debug1: Authentication succeeded (publickey). debug2: fd 5 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 0 debug3: tty_make_modes: ospeed 38400 debug3: tty_make_modes: ispeed 38400 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 127 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 0 debug3: tty_make_modes: 7 0 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 11 25 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 16 0 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 1 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 37 0 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 0 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 1 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 52 0 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 1 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 0 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 71 0 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Last login: Tue Apr 18 17:44:32 2006 from 192.168.10.10 4) kdc# /usr/pkg/sbin/sshd -D -d -d -d -e debug2: load_server_config: filename /usr/pkg/etc/ssh/sshd_config debug2: load_server_config: done config len = 247 debug2: parse_server_config: config /usr/pkg/etc/ssh/sshd_config len 247 debug1: sshd version OpenSSH_4.3p1 debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/pkg/sbin/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-d' debug1: rexec_argv[3]='-d' debug1: rexec_argv[4]='-d' debug1: rexec_argv[5]='-e' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on 172.16.2.11. Server listening on 172.16.2.11 port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on 10.1.1.11. Server listening on 10.1.1.11 port 22. debug2: fd 5 setting O_NONBLOCK debug1: Bind to port 22 on 192.168.10.11. Server listening on 192.168.10.11 port 22. debug1: fd 6 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 11 config len 247 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 11 debug3: recv_rexec_state: entering fd = 5 debug3: ssh_msg_recv entering debug3: recv_rexec_state: done debug2: parse_server_config: config rexec len 247 debug1: sshd version OpenSSH_4.3p1 debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /usr/pkg/etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.10.10 port 8302 debug1: Client protocol version 2.0; client software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug3: privsep user:group 22:22 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc, rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: Network child is on pid 16691 debug3: preauth child monitor started debug3: mm_request_receive entering debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 1024 8192 debug3: mm_request_send entering: type 1 debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: dh_gen_key: priv key bits set: 135/256 debug2: bits set: 518/1024 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug2: bits set: 547/1024 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_answer_sign: signature 80c7860(271) debug3: mm_request_send entering: type 5 debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: mm_request_receive entering debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow debug3: auth_shadow_acctexpired: today 13256 sp_expire -1 days left -13257 debug3: account expiration disabled debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: input_userauth_request: setting up authctxt for root debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug3: mm_answer_authpassword: sending result 0 debug3: mm_request_send entering: type 11 debug3: mm_auth_password: user not authenticated Failed none for root from 192.168.10.10 port 8302 ssh2 Failed none for root from 192.168.10.10 port 8302 ssh2 debug3: mm_request_receive entering debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 1 failures 1 debug2: input_userauth_request: try method publickey debug3: mm_key_allowed entering debug3: mm_request_send entering: type 20 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 21 debug3: mm_request_receive entering debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 80c0510 debug1: temporarily_use_uid: 0/1 (e=0/1) debug1: trying public key file /home/root/.ssh/authorized_keys debug3: secure_filename: checking '/home/root/.ssh' debug3: secure_filename: checking '/home/root' debug3: secure_filename: terminating check at '/home/root' debug1: matching key found: file /home/root/.ssh/authorized_keys, line 1 Found matching RSA key: 36:55:cf:41:48:e0:d5:71:f4:34:95:b9:da:72:65:a6 debug1: restore_uid: 0/1 debug3: mm_answer_keyallowed: key 80c0510 is allowed debug3: mm_request_send entering: type 21 debug3: mm_key_verify entering debug3: mm_request_send entering: type 22 debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY debug3: mm_request_receive_expect entering: type 23 debug3: mm_request_receive entering debug3: mm_request_receive entering debug3: monitor_read: checking request 22 debug1: ssh_rsa_verify: signature correct debug3: mm_answer_keyverify: key 80c04b0 signature verified debug3: mm_request_send entering: type 23 debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa Accepted publickey for root from 192.168.10.10 port 8302 ssh2 debug3: mm_send_keystate: Sending new keys: 80be778 80c7a88 debug3: mm_newkeys_to_blob: converting 80be778 debug3: mm_newkeys_to_blob: converting 80c7a88 debug3: mm_send_keystate: New keys have been sent debug3: mm_send_keystate: Sending compression state debug3: mm_request_send entering: type 24 debug3: mm_send_keystate: Finished sending state Accepted publickey for root from 192.168.10.10 port 8302 ssh2 debug1: monitor_child_preauth: root has been authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect entering: type 24 debug3: mm_request_receive entering debug3: mm_newkeys_from_blob: 80c7860(118) debug2: mac_init: found hmac-md5 debug3: mm_get_keystate: Waiting for second key debug3: mm_newkeys_from_blob: 80c7860(118) debug2: mac_init: found hmac-md5 debug3: mm_get_keystate: Getting compression state debug3: mm_get_keystate: Getting Network I/O buffers debug3: mm_share_sync: Share sync debug3: mm_share_sync: Share sync end debug2: set_newkeys: mode 0 debug2: set_newkeys: mode 1 debug1: Entering interactive session for SSH2. debug2: fd 4 setting O_NONBLOCK debug2: fd 5 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/pts/1 debug3: tty_parse_modes: SSH2 n_bytes 266 debug3: tty_parse_modes: ospeed 38400 debug3: tty_parse_modes: ispeed 38400 debug3: tty_parse_modes: 1 3 debug3: tty_parse_modes: 2 28 debug3: tty_parse_modes: 3 127 debug3: tty_parse_modes: 4 21 debug3: tty_parse_modes: 5 4 debug3: tty_parse_modes: 6 0 debug3: tty_parse_modes: 7 0 debug3: tty_parse_modes: 8 17 debug3: tty_parse_modes: 9 19 debug3: tty_parse_modes: 10 26 debug3: tty_parse_modes: 11 25 debug3: tty_parse_modes: 12 18 debug3: tty_parse_modes: 13 23 debug3: tty_parse_modes: 14 22 debug3: tty_parse_modes: 16 0 debug3: tty_parse_modes: 18 15 debug3: tty_parse_modes: 30 1 debug3: tty_parse_modes: 31 0 debug3: tty_parse_modes: 32 0 debug3: tty_parse_modes: 33 0 debug3: tty_parse_modes: 34 0 debug3: tty_parse_modes: 35 0 debug3: tty_parse_modes: 36 1 debug3: tty_parse_modes: 37 0 debug3: tty_parse_modes: 38 1 debug3: tty_parse_modes: 39 0 debug3: tty_parse_modes: 40 0 debug3: tty_parse_modes: 41 1 debug3: tty_parse_modes: 50 1 debug3: tty_parse_modes: 51 1 debug3: tty_parse_modes: 52 0 debug3: tty_parse_modes: 53 1 debug3: tty_parse_modes: 54 1 debug3: tty_parse_modes: 55 1 debug3: tty_parse_modes: 56 0 debug3: tty_parse_modes: 57 0 debug3: tty_parse_modes: 58 0 debug3: tty_parse_modes: 59 1 debug3: tty_parse_modes: 60 1 debug3: tty_parse_modes: 61 1 debug3: tty_parse_modes: 62 0 debug3: tty_parse_modes: 70 1 debug3: tty_parse_modes: 71 0 debug3: tty_parse_modes: 72 1 debug3: tty_parse_modes: 73 0 debug3: tty_parse_modes: 74 0 debug3: tty_parse_modes: 75 0 debug3: tty_parse_modes: 90 1 debug3: tty_parse_modes: 91 1 debug3: tty_parse_modes: 92 0 debug3: tty_parse_modes: 93 0 debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug2: fd 3 setting TCP_NODELAY debug2: fd 7 setting O_NONBLOCK debug3: fd 6 is O_NONBLOCK debug1: Received SIGCHLD. debug1: session_by_pid: pid 16693 debug1: session_exit_message: session 0 channel 0 pid 16693 debug2: channel 0: request exit-status confirm 0 debug1: session_exit_message: release channel 0 debug2: channel 0: write failed debug2: channel 0: close_write debug2: channel 0: output open -> closed debug1: session_pty_cleanup: session 0 release /dev/pts/1 debug2: notify_done: reading debug2: channel 0: read<=0 rfd 7 len 0 debug2: channel 0: read failed debug2: channel 0: close_read debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof debug2: channel 0: input drain -> closed debug2: channel 0: send close debug3: channel 0: will not send data after close debug2: channel 0: rcvd close debug3: channel 0: will not send data after close debug2: channel 0: is dead debug2: channel 0: gc: notify user debug1: session_by_channel: session 0 channel 0 debug1: session_close_by_channel: channel 0 child 0 debug1: session_close: session 0 pid 0 debug2: channel 0: gc: user detached debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: server-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 server-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e -1 c -1 Connection closed by 192.168.10.10 debug1: do_cleanup Closing connection to 192.168.10.10 -- Truly yours, Mikhail Manuilov Reply Forward TMDA daemon This message was created automatically by mail delivery software (TMDA). Your... 1:55 pm (37 minutes ago) Mikhail Manuylov ---------- Forwarded message ---------- From: "Mikhail Manuylov" to me More options 2:21 pm (12 minutes ago) This is the Postfix program at host mail.mindrot.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program (expanded from ): permission denied. Command output: The message that you sent to openssh-unix-dev looks like HTML. HTML mail to openssh-unix-dev is not permitted. Please resend your message as plain text. procmail: Error while writing to "/etc/postfix/htmltrap.sh" Final-Recipient: rfc822; openssh-unix-dev-tmda at mindrot.org Original-Recipient: rfc822; openssh-unix-dev-tmda Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; permission denied. Command output: The message that you sent to openssh-unix-dev looks like HTML. HTML mail to openssh-unix-dev is not permitted. Please resend your message as plain text. procmail: Error while writing to "/etc/postfix/htmltrap.sh" ---------- Forwarded message ---------- From: "Mikhail Manuylov" To: openssh-unix-dev at mindrot.org Date: Fri, 21 Apr 2006 13:55:34 +0400 Subject: Solaris 8 x86 rsa pubkey auth problem Hello, I got some weird problem with public key authentication using rsa key pair. Let me first of all explain my setup. 1) I got two Solaris 8 x86 boxes uname -a SunOS 5.8 Generic_117351-24 i86pc i386 i86pc <---> 2) They're running absolutely identical openssh installations I'm using pkgsrc, so I've builded all necessary packages from two days old pkgsrc sources on one of the boxes and installed the same binaries on second OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 3) The only differense in their setup is that 'kdc' is a intel p4 boxm and module is p3 box. I've generated rsa key pair via ssh-keygen, and placed public part of it into /home/root/.ssh/authorized_keys on both computers. The problem: I can't log into any (not only to module) computer running the same version of sshd (and of course user holding the same public key) using 'kdc', pubkey athentication fails and ssh pops password prompt up. Pubkey athentication with that key works flawlessly with any other direction even when 'module' connecting to 'kdc'. How I can help debugging this problem: I've supplied debug output of both ssh and sshd from two cases: 1) 'module' authenticating on 'kdc' ( works ok ) 2) 'kdc' authenticating on 'module' ( pubkey failed ) I've already compiled gdb and openssh with debug info. I've also started two debug sshd yesterday, but due two my not so cool knowledge of openssh sources and maybe schema of forking and privelege separation I still can't reach user_key_allowed function. Thank you for your great work. And thanks for help beforehand. Here's debug output: 1) kdc# ssh -vvv -i ~/.ssh/auditor_rsa_id root at 192.168.10.10 OpenSSH_4.3p1, OpenSSL 0.9.7i 14 Oct 2005 debug1: Reading configuration data /usr/pkg/etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.10.10 [ 192.168.10.10] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/1 debug3: Not a RSA1 key file auditor_id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file auditor_id_rsa type 2 debug1: Remote protocol version 2.0 , remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none, zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se ,aes12 8-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes -- Truly yours, Mikhail Manuilov From djm at mindrot.org Fri Apr 21 20:38:39 2006 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Apr 2006 20:38:39 +1000 (EST) Subject: cygwin performance problem In-Reply-To: <20060421101506.GD12661@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> <44451755.4050209@psc.edu> <20060420094129.GN11759@calimero.vinschen.de> <20060421101506.GD12661@calimero.vinschen.de> Message-ID: On Fri, 21 Apr 2006, Corinna Vinschen wrote: > I did that already, but afaics scp always uses pipes for copying files > over ssh, or did I miss something? oh, that is probably a bug then :( -d From vinschen at redhat.com Fri Apr 21 20:42:05 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 21 Apr 2006 12:42:05 +0200 Subject: cygwin performance problem In-Reply-To: <20060421101506.GD12661@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> <44451755.4050209@psc.edu> <20060420094129.GN11759@calimero.vinschen.de> <20060421101506.GD12661@calimero.vinschen.de> Message-ID: <20060421104205.GA19664@calimero.vinschen.de> On Apr 21 12:15, Corinna Vinschen wrote: > On Apr 21 07:47, Damien Miller wrote: > > On Thu, 20 Apr 2006, Corinna Vinschen wrote: > > > > > However, while looking deeper into what's going on, it seems the bad > > > results are somehow based on a strange interaction between ssh and scp, > > > which triggers a performance problem in Cygwin. Writing to the pipe to > > > scp and reading from the pipe in scp seem to take a lot of time. > > > > Cygwin is set to use pipes instead of socketpairs for communication > > between scp/sftp and ssh, and between sshd and its subprocesses. > > Perhaps you could try commenting out the > > > > AC_DEFINE(USE_PIPES, 1, [Use PIPES instead of a socketpair()]) > > > > line under the cygwin host case value in configure.ac, or just deleting > > the "#define USE_PIPES" from the generated config.h. If performance > > improves it might indicate a problem with Cygwin's pipe implementation. > > I did that already, but afaics scp always uses pipes for copying files > over ssh, or did I miss something? I mean the initiating scp which forks the local ssh for the remote connection. It always uses the pipe call regardless of the OS. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From stuge-openssh-unix-dev at cdy.org Sat Apr 22 01:13:20 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 21 Apr 2006 17:13:20 +0200 Subject: Solaris 8 x86 rsa pubkey auth problem In-Reply-To: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> References: <7ec6def90604210335s5ad03dc4s811fe4a66a8a32c4@mail.gmail.com> Message-ID: <20060421151320.16640.qmail@cdy.org> On Fri, Apr 21, 2006 at 02:35:28PM +0400, Mikhail Manuylov wrote: > I got some weird problem with public key authentication using rsa > key pair. [..] > I've generated rsa key pair via ssh-keygen, and placed public part of > it into /home/root/.ssh/authorized_keys > on both computers. ..double check this. See below: > 2) module# /usr/pkg/sbin/sshd -D -d -d -d -e [..] > debug1: trying public key file /home/root/.ssh/authorized_keys > debug3: secure_filename: checking '/usr/home/root/.ssh' > debug3: secure_filename: checking '/usr/home/root' > debug3: secure_filename: terminating check at '/usr/home/root' > debug3: key_read: type mismatch > debug2: user_key_allowed: check options: 'ssh-rsa > AAAAB3NzaC1yc2EAAAABIwAAAQEA5SXtHW7fmMWxkvjUKkB3pEygK6MkzOUejT8DCucnLJ2NT/lDdsWUR1Bz+nFmzFrcHEnP1H0+zlTEEEr > T1StBaiWmMO1mqD/AXh7XjVylsV+7E9qcQ6OHjfYaNjSffk1hAzLokrXti0qeBbZpz8yAy4LsscxNdX97aDtDB2S9AJYoWSNVsnJJKDGYlQpHL1sK+rfezYOHfeCyBh/Ui07sF2RbPz3k59QFok5VY1EUwvM0 > LMjXOAuTl0m7PyouuU3JSr7NRu52nsyNxPLwFvK1wvqX+5dJCIJ8Z9J1peWj4o51ERvKvx7rQSG7N/q10J41IU9koPsi/sr0usLmx3ROsw== > root at kgc > ' > debug2: key_type_from_name: unknown key type > 'AAAAB3NzaC1yc2EAAAABIwAAAQEA5SXtHW7fmMWxkvjUKkB3pEygK6MkzOUejT8DCucnLJ2NT/lDdsWUR1Bz+nFmzFrcHEnP1H0+zlTEEErT1St > BaiWmMO1mqD/AXh7XjVylsV+7E9qcQ6OHjfYaNjSffk1hAzLokrXti0qeBbZpz8yAy4LsscxNdX97aDtDB2S9AJYoWSNVsnJJKDGYlQpHL1sK+rfezYOHfeCyBh/Ui07sF2RbPz3k59QFok5VY1EUwvM0LMjX > OAuTl0m7PyouuU3JSr7NRu52nsyNxPLwFvK1wvqX+5dJCIJ8Z9J1peWj4o51ERvKvx7rQSG7N/q10J41IU9koPsi/sr0usLmx3ROsw==' > debug3: key_read: missing keytype > debug2: user_key_allowed: advance: > 'AAAAB3NzaC1yc2EAAAABIwAAAQEA5SXtHW7fmMWxkvjUKkB3pEygK6MkzOUejT8DCucnLJ2NT/lDdsWUR1Bz+nFmzFrcHEnP1H0+zlTEEErT1StBaiWmMO1mq > D/AXh7XjVylsV+7E9qcQ6OHjfYaNjSffk1hAzLokrXti0qeBbZpz8yAy4LsscxNdX97aDtDB2S9AJYoWSNVsnJJKDGYlQpHL1sK+rfezYOHfeCyBh/Ui07sF2RbPz3k59QFok5VY1EUwvM0LMjXOAuTl0m7Py > ouuU3JSr7NRu52nsyNxPLwFvK1wvqX+5dJCIJ8Z9J1peWj4o51ERvKvx7rQSG7N/q10J41IU9koPsi/sr0usLmx3ROsw== > root at kgc > ' > debug1: restore_uid: 0/1 > debug2: key not found > debug1: temporarily_use_uid: 0/1 (e=0/1) > debug1: trying public key file /home/root/.ssh/authorized_keys2 > debug1: restore_uid: 0/1 > debug3: mm_answer_keyallowed: key 80c04e8 is disallowed > debug3: mm_request_send entering: type 21 > debug3: mm_request_receive entering > debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss > Failed publickey for root from 192.168.10.11 port 8759 ssh2 The above shows how sshd fails to parse the public key in authorized_keys properly. > 4) kdc# /usr/pkg/sbin/sshd -D -d -d -d -e [..] > debug1: trying public key file /home/root/.ssh/authorized_keys > debug3: secure_filename: checking '/home/root/.ssh' > debug3: secure_filename: checking '/home/root' > debug3: secure_filename: terminating check at '/home/root' > debug1: matching key found: file /home/root/.ssh/authorized_keys, line 1 > Found matching RSA key: 36:55:cf:41:48:e0:d5:71:f4:34:95:b9:da:72:65:a6 > debug1: restore_uid: 0/1 > debug3: mm_answer_keyallowed: key 80c0510 is allowed > debug3: mm_request_send entering: type 21 > debug3: mm_key_verify entering > debug3: mm_request_send entering: type 22 > debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY > debug3: mm_request_receive_expect entering: type 23 > debug3: mm_request_receive entering > debug3: mm_request_receive entering > debug3: monitor_read: checking request 22 > debug1: ssh_rsa_verify: signature correct > debug3: mm_answer_keyverify: key 80c04b0 signature verified > debug3: mm_request_send entering: type 23 > debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa > Accepted publickey for root from 192.168.10.10 port 8302 ssh2 ..whereas on this system the parsing works, and the client is authenticated. >From the above output, specifically this line: > debug2: user_key_allowed: check options: 'ssh-rsa > AAAAB3NzaC1yc2EAAAABIwAAAQEA5SXtHW7fmMWxkvjUKkB3pEygK6MkzOUejT8DCucnLJ2NT/lDdsWUR1Bz+nFmzFrcHEnP1H0+zlTEEEr > T1StBaiWmMO1mqD/AXh7XjVylsV+7E9qcQ6OHjfYaNjSffk1hAzLokrXti0qeBbZpz8yAy4LsscxNdX97aDtDB2S9AJYoWSNVsnJJKDGYlQpHL1sK+rfezYOHfeCyBh/Ui07sF2RbPz3k59QFok5VY1EUwvM0 > LMjXOAuTl0m7PyouuU3JSr7NRu52nsyNxPLwFvK1wvqX+5dJCIJ8Z9J1peWj4o51ERvKvx7rQSG7N/q10J41IU9koPsi/sr0usLmx3ROsw== > root at kgc > ' I'm guessing that there's extra or malformed whitespace on the line, which makes sshd believe that all of the key is actually options (which are optional, but always appear first on each line, before any whitespace) Check sshd(8) under AUTHORIZED_KEYS FILE FORMAT and verify that your file actually follows the format. If it does have the proper format, there's certainly a bug somewhere. //Peter From aj504 at student.cs.york.ac.uk Sat Apr 22 01:27:07 2006 From: aj504 at student.cs.york.ac.uk (Alan Jenkins) Date: Fri, 21 Apr 2006 15:27:07 +0000 Subject: feature rq: default command In-Reply-To: <1145633162l.30159l.0l@singularity> (from aj504@student.cs.york.ac.uk on Fri Apr 21 16:26:02 2006) References: <1145633162l.30159l.0l@singularity> Message-ID: <1145633227l.30159l.1l@singularity> [not subscribed; please CC me] The OpenSSH client has several configuration options for convenience, allowing aliases to be specified for long hostnames and default usernames for different hosts. I'd like to have a configuration option added to allow a default command to be specified. This would be useful where changing your shell on the remote host is not practical. My main reason for this is in order to use "screen" without having to keep typing it each time I log in. I can write the code but I thought it best to ask for opinions first. I'm not familiar with the codebase, but I would guess it to be a simple copy+paste job due to its similarity to the User configuration option. Thanks, Alan From georg.schwarz at freenet.de Sat Apr 22 05:29:36 2006 From: georg.schwarz at freenet.de (Georg Schwarz) Date: Fri, 21 Apr 2006 21:29:36 +0200 Subject: OpenSSH DNS resolution failure on IRIX 5.3: request to fix Message-ID: Dear developers, as reported earlier, recent versions of OpenSSH (4.3p1, 4.3p2 as well as the current CVS) on IRIX 5.3 exhibit a DNS resolution failure. Even for perfectly valid hostnames they return "no address associated with name". After some digging through the code I found what is causing this strange behaviour. Basically it was introduced with the following change: revision 1.3954 date: 2005/11/05 05:56:52; author: djm; state: Exp; lines: +4 -1 - (djm) [openbsd-compat/getrrsetbyname.c] Sync to latest OpenBSD version, resolving memory leak bz#1111 reported by kremenek AT cs.stanford.edu; ok dtucker@ When I take out the line struct __res_state _res; things work. Also, the problem does not occur when compiling with gcc (I used 3.4.4) instead of the SGI IDO cc. I am not familiar enough with the implementation of the DNS resolution libraries to really judge what is going on. It looks like the global variable _res in openbsd-compat/getrrsetbyname overrides a respective OS-supplied variable when compiling with the SGI IDO cc. I hope that someone else can give a more thorough explanation of what is going wrong. I must admit that I do not understand why _res is defined at all in openbsd-compat/getrrsetbyname.c. It wasn't before 2005/11/05. Now my next question of course is how to fix that problem. Is it acceptable to simple comment out that line with something like this (syntax not really correct)? #if not irix5 or gcc struct __res_state _res; #endif It also seems sufficient to change the line into extern struct __res_state _res; Feedback would be welcome. I'd appreciate if you could CC me on any replies since I am not a member of this mailing list. Georg -- Georg Schwarz http://home.pages.de/~schwarz/ georg.schwarz at freenet.de +49 178 8545053 From stuge-openssh-unix-dev at cdy.org Sat Apr 22 06:08:56 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 21 Apr 2006 22:08:56 +0200 Subject: feature rq: default command In-Reply-To: <1145633227l.30159l.1l@singularity> References: <1145633162l.30159l.0l@singularity> <1145633227l.30159l.1l@singularity> Message-ID: <20060421200856.19700.qmail@cdy.org> On Fri, Apr 21, 2006 at 03:27:07PM +0000, Alan Jenkins wrote: > My main reason for this is in order to use "screen" without having > to keep typing it each time I log in. Couldn't you set that up with a clever .profile? //Peter From aj504 at student.cs.york.ac.uk Sat Apr 22 06:37:44 2006 From: aj504 at student.cs.york.ac.uk (Alan Jenkins) Date: Fri, 21 Apr 2006 20:37:44 +0000 Subject: feature rq: default command In-Reply-To: <1145651779l.3268l.3l@singularity> (from aj504@student.cs.york.ac.uk on Fri Apr 21 21:36:19 2006) References: <1145633162l.30159l.0l@singularity> <1145633227l.30159l.1l@singularity> <20060421200856.19700.qmail@cdy.org> <1145651779l.3268l.3l@singularity> Message-ID: <1145651864l.3268l.4l@singularity> On 21/04/06 21:08:56, Peter Stuge wrote: > On Fri, Apr 21, 2006 at 03:27:07PM +0000, Alan Jenkins wrote: > > My main reason for this is in order to use "screen" without having > > to keep typing it each time I log in. > > Couldn't you set that up with a clever .profile? I thought about that and then forgot it :-). Yes, of course... SSH sets a couple of environment variables I could check for. I suspect a test for a tty wouldn't go amiss either. Thanks Alan From wiskbroom at hotmail.com Sat Apr 22 07:19:44 2006 From: wiskbroom at hotmail.com (Vadim Pushkin) Date: Fri, 21 Apr 2006 21:19:44 +0000 Subject: Need Help Using NIS netgroup - Does It Still Work? Message-ID: Hello; Forgive me for asking on this list, but I've noticed that their has been some recent changes to the code with regards to netgroup.h, and hoping that someone on this list can help, I've already tried the users list. I am having difficulties setting up ssh (ossh4.3p2 with PAM-enabled [DO I NEED IT?] - NIS -Solaris8/Sparc) to authenticate and allow users passwordless entry based solely on a user, or the host that they are on, being on a valid list of netgroup user/and/or/hosts contained in the server hosts .shosts or shosts.equiv. I assume that I am unable to add netgroups within the AllowGroup and/or DenyGroup? Authentication is already setup properly this way for rsh, rsh denies users based on their host and/or user, all from NIS and depending what is contained within /etc/hosts.equiv and/or /.rhosts. What I wish to do is to duplicate this within ossh. I am having alot of trouble finding information on how to get NIS netgroup to work into my sshd_config. Since I am using PAM, should my pam.conf contain some special information for ssh w/PAM? Do I need any special pam modules? I've created an /etc/shosts.equiv and ~.shosts file identical to what is contained within .rhosts and hosts.equiv. My sshd_config contains IgnoreRhosts = no. My environment is pure NIS, no LDAP, at least not for the next year. Many, many thanks in advance, .vp Vadim From gogu at l.route666.net Sun Apr 23 03:02:47 2006 From: gogu at l.route666.net (catamus) Date: Sat, 22 Apr 2006 20:02:47 +0300 (EEST) Subject: bug & patch in ServerAliveInterval (openssh 4.3-p2) Message-ID: Hi openssh-unix-dev subscribers :) I have found that ServerAliveInterval & ServerAliveCountMax have some bug. Basically the ssh-alive check function (that verify the peer is alive) is called only if no data at all gets into ssh (when it should work only for server channel).I am pretty sure developers know about this ..anyway I have tried to fix this issue. Here is the patch: diff -rNu openssh-4.3p2/clientloop.c openssh-4.3p2-alive-fixed/clientloop.c --- openssh-4.3p2/clientloop.c 2005-12-31 07:22:32.000000000 +0200 +++ openssh-4.3p2-alive-fixed/clientloop.c 2006-04-22 19:32:17.000000000 +0300 @@ -456,7 +456,7 @@ client_wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int *maxfdp, u_int *nallocp, int rekeying) { - struct timeval tv, *tvp; + static struct timeval tv, *tvp; int ret; /* Add any selections by the channel mechanism. */ @@ -508,12 +508,16 @@ if (options.server_alive_interval == 0 || !compat20) tvp = NULL; - else { + else if(tv.tv_sec == 0 && tv.tv_usec == 0) { tv.tv_sec = options.server_alive_interval; tv.tv_usec = 0; tvp = &tv; } ret = select((*maxfdp)+1, *readsetp, *writesetp, NULL, tvp); + if(FD_ISSET(connection_out, *readsetp)) { + tv.tv_sec = 0; + tv.tv_usec = 0; + } if (ret < 0) { char buf[100]; From william at 25thandClement.com Sun Apr 23 04:01:20 2006 From: william at 25thandClement.com (William Ahern) Date: Sat, 22 Apr 2006 11:01:20 -0700 Subject: [Patch] Unix Domain Socket Forwarding Message-ID: <20060422180120.GA23577@orville.25thandClement.com> http://25thandclement.com/~william/openssh-4.3p2-streamlocal-20060421.patch The above URL is a complete patch to OpenSSH 4.3p2 to implement unix domain socket forwarding (this supercedes a canceled message I sent last night w/ an inline attachment). Basically, for forward and reverse forwardings anywhere you previously put a port number you can now put a path. The socket path should go between braces (`[' and `]'), and backslash escaping is honored within. Basically, any "port" which uses an escaping mechanism is considered a path instead. That way you can have socket paths like 1234 w/o ambiguity. -L[]:: -L:[] -L[]:[] -R[]:: -R:[] -R[]:[] I've added several new SSH messages: streamlocal-forward at openssh.com forarded-streamlocal at openssh.com cancel-streamlocal-forward at openssh.com direct-streamlocal at openssh.com streamlocal from "AF_LOCAL" and "SOCK_STREAM". Seemed to logically follow from the tcpip messages. Um, included in this patch, for now, is my previous patch which added options to specify a mask and access control lists for control sockets. I'll seperate them out when I port this over to the main OpenSSH source in OpenBSD. So, the following options are honored with this patch: Client: -> old stuff <- ControlBindMask Mask to use when binding a control socket ControlAllowUsers List of users and uids allowed to connect ControlAllowGroups List of groups and gids allows to connect ControlDenyUsers List of users and uids disallowed ControlDenyGroups List of groups and gids disallowed -> new stuff <- StreamLocalBindMask Mask to use when binding a forward socket StreamLocalBindUnlink Attempt an unlink before binding FakeStreamLocalForwards Fake a connection originating from a socket as tcpip. This isn't currently honored, but is the default and only behavior. See channel_post_port_listener(). Server: StreamLocalBindMask See above. StreamLocalBindUnlink See above. All regression tests pass, though I haven't yet added any for the new functionality. Please send suggestions and comments. It would be nice if this were included, or at least had the prospect of inclusion in the future. - Bill From william at 25thandClement.com Sun Apr 23 08:03:16 2006 From: william at 25thandClement.com (William Ahern) Date: Sat, 22 Apr 2006 15:03:16 -0700 Subject: [Patch] Unix Domain Socket Forwarding In-Reply-To: <20060422210757.GA9286@melpomene.jschipper.dynalias.net> References: <20060421041009.GA15746@orville.25thandClement.com> <20060422210757.GA9286@melpomene.jschipper.dynalias.net> Message-ID: <20060422220316.GA17816@orville.25thandClement.com> On Sat, Apr 22, 2006 at 11:07:57PM +0200, Joachim Schipper wrote: > I don't want to be disrespectful or anything - this is a honest > question. But: what's the point? Why would one want to forward UNIX > domain sockets? Fair enough ;) That's the first question I'd ask, too, considering how large the patch is. So, I'll reply to the list as well. > I can see it being useful in some theoretic cases, but almost all > programs can either use internet sockets too (X), or netcat will do just > fine. In some circumstances binding to internet sockets can become unwieldly. If you map a single service to a single port, it's easy. But try mapping a single service from multiple remote machines to multiple ports. How do you choose which ports to use, especially if the remote machines are dynamic? (Don't forget you might have t deal w/ conflicts.) How you do you relay that information to the clients so they know which dynamic port to use to reach particular remote services? Using the filesystem namespace is _much_ cleaner because, well, it's a more powerful _namespace_. TUN doesn't always solve this problem as well as domain sockets. Dare I say it's a less desirable solution altogether when anything less than full network visibility is required. Domain sockets fill the gap between internet addressing and filesystem naming. netcat just doesn't work; it only allows you to open one connection at a time, assuming you're tunneling through a channel. Using it to link a port to a socket doesn't solve the naming issues at all. Originally I wrote this for my job. We have at least two different widely disparate uses for it. But, I intend to use it outside of work for several other things as well (which is why I'll make the effort to suit this patch to everybody's needs, if it indeed might be accepted). Just keep in mind that being able to use the filesystem namespace can make some tasks much, much simpler. Plus, it just makes sense, IMHO. Also, on some platforms (like Linux and maybe all of SysV-land) which obey socket file permissions it gives you free access control (for better or worse; I don't necessarily agree or disagree that socket file permissions should be obeyed). - Bill From crs at sorsby.org Sun Apr 23 12:16:24 2006 From: crs at sorsby.org (Charlie Sorsby) Date: Sat, 22 Apr 2006 20:16:24 -0600 (MDT) Subject: Configuration Warnings OpenSSH 4.3p2 Message-ID: <200604230216.k3N2GOLO034413@sorsby.org> I don't know enough about this to know if these warnings mean that I can't build it or not. Also, since I'm e-mailing anyway, how can I tell what options were compiled into my exiting ssh: My system is freeBSD 4.11. PC% ssh -V OpenSSH_3.5p1 FreeBSD-20030924, SSH protocols 1.5/2.0, OpenSSL 0x0090704f PC% so that I can do the same thing with the newer version. I don't want to build and install the newer version and have things quit working. Thanks. Charlie Saturday, 22 Apr, 2006 -- 20:03:30 MDT checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking build system type... i386-unknown-freebsd4.11 checking host system type... i386-unknown-freebsd4.11 checking whether byte ordering is bigendian... no checking for gawk... gawk checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking for egrep... grep -E checking for ar... /usr/bin/ar checking for cat... /bin/cat checking for kill... /bin/kill checking for perl5... /usr/bin/perl5 checking for sed... /usr/bin/sed checking for ent... no checking for bash... /usr/local/bin/bash checking for ksh... (cached) /usr/local/bin/bash checking for sh... (cached) /usr/local/bin/bash checking for sh... /bin/sh checking for groupadd... groupadd checking for useradd... useradd checking for pkgmk... no checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for _LARGE_FILES value needed for large files... no checking for login... /usr/bin/login checking for passwd... /usr/bin/passwd checking for inline... inline checking whether LLONG_MAX is declared... yes /usr/libexec/ld-elf.so.1: Shared object "libc.so.3" not found, required by "gawk" checking net/if_tap.h usability... no checking net/if_tap.h presence... yes configure: WARNING: net/if_tap.h: present but cannot be compiled configure: WARNING: net/if_tap.h: check for missing prerequisite headers? configure: WARNING: net/if_tap.h: see the Autoconf documentation configure: WARNING: net/if_tap.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if_tap.h: proceeding with the preprocessor's result configure: WARNING: net/if_tap.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 net/if_tap.h... yes checking compiler and flags for sanity... yes checking bstring.h usability... no checking bstring.h presence... no checking for bstring.h... no checking crypt.h usability... no checking crypt.h presence... no checking for crypt.h... no checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking endian.h usability... no checking endian.h presence... no checking for endian.h... no checking features.h usability... no checking features.h presence... no checking for features.h... no checking floatingpoint.h usability... yes checking floatingpoint.h presence... yes checking for floatingpoint.h... yes checking getopt.h usability... no checking getopt.h presence... no checking for getopt.h... no checking glob.h usability... yes checking glob.h presence... yes checking for glob.h... yes checking ia.h usability... no checking ia.h presence... no checking for ia.h... no checking iaf.h usability... no checking iaf.h presence... no checking for iaf.h... no checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking login.h usability... no checking login.h presence... no checking for login.h... no checking login_cap.h usability... no checking login_cap.h presence... yes configure: WARNING: login_cap.h: present but cannot be compiled configure: WARNING: login_cap.h: check for missing prerequisite headers? configure: WARNING: login_cap.h: see the Autoconf documentation configure: WARNING: login_cap.h: section "Present But Cannot Be Compiled" configure: WARNING: login_cap.h: proceeding with the preprocessor's result configure: WARNING: login_cap.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 login_cap.h... yes checking maillock.h usability... no checking maillock.h presence... no checking for maillock.h... no checking ndir.h usability... no checking ndir.h presence... no checking for ndir.h... no checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking netgroup.h usability... no checking netgroup.h presence... no checking for netgroup.h... no checking pam/pam_appl.h usability... no checking pam/pam_appl.h presence... no checking for pam/pam_appl.h... no checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking pty.h usability... no checking pty.h presence... no checking for pty.h... no checking readpassphrase.h usability... yes checking readpassphrase.h presence... yes checking for readpassphrase.h... yes checking rpc/types.h usability... yes checking rpc/types.h presence... yes checking for rpc/types.h... yes checking security/pam_appl.h usability... yes checking security/pam_appl.h presence... yes checking for security/pam_appl.h... yes checking shadow.h usability... no checking shadow.h presence... no checking for shadow.h... no checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking stdint.h usability... no checking stdint.h presence... no checking for stdint.h... no checking string.h usability... yes checking string.h presence... yes checking for string.h... yes checking strings.h usability... yes checking strings.h presence... yes checking for strings.h... yes checking sys/audit.h usability... no checking sys/audit.h presence... no checking for sys/audit.h... no checking sys/bitypes.h usability... no checking sys/bitypes.h presence... no checking for sys/bitypes.h... no checking sys/bsdtty.h usability... no checking sys/bsdtty.h presence... no checking for sys/bsdtty.h... no checking sys/cdefs.h usability... yes checking sys/cdefs.h presence... yes checking for sys/cdefs.h... yes checking sys/dir.h usability... yes checking sys/dir.h presence... yes checking for sys/dir.h... yes checking sys/mman.h usability... no checking sys/mman.h presence... yes configure: WARNING: sys/mman.h: present but cannot be compiled configure: WARNING: sys/mman.h: check for missing prerequisite headers? configure: WARNING: sys/mman.h: see the Autoconf documentation configure: WARNING: sys/mman.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/mman.h: proceeding with the preprocessor's result configure: WARNING: sys/mman.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 sys/mman.h... yes checking sys/ndir.h usability... no checking sys/ndir.h presence... no checking for sys/ndir.h... no checking sys/prctl.h usability... no checking sys/prctl.h presence... no checking for sys/prctl.h... no checking sys/pstat.h usability... no checking sys/pstat.h presence... no checking for sys/pstat.h... no checking sys/select.h usability... no checking sys/select.h presence... yes configure: WARNING: sys/select.h: present but cannot be compiled configure: WARNING: sys/select.h: check for missing prerequisite headers? configure: WARNING: sys/select.h: see the Autoconf documentation configure: WARNING: sys/select.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/select.h: proceeding with the preprocessor's result configure: WARNING: sys/select.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 sys/select.h... yes checking sys/stat.h usability... yes checking sys/stat.h presence... yes checking for sys/stat.h... yes checking sys/stream.h usability... no checking sys/stream.h presence... no checking for sys/stream.h... no checking sys/stropts.h usability... no checking sys/stropts.h presence... no checking for sys/stropts.h... no checking sys/strtio.h usability... no checking sys/strtio.h presence... no checking for sys/strtio.h... no checking sys/sysmacros.h usability... no checking sys/sysmacros.h presence... no checking for sys/sysmacros.h... no checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/timers.h usability... yes checking sys/timers.h presence... yes checking for sys/timers.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking time.h usability... yes checking time.h presence... yes checking for time.h... yes checking tmpdir.h usability... no checking tmpdir.h presence... no checking for tmpdir.h... no checking ttyent.h usability... yes checking ttyent.h presence... yes checking for ttyent.h... yes checking unistd.h usability... yes checking unistd.h presence... yes checking for unistd.h... yes checking usersec.h usability... no checking usersec.h presence... no checking for usersec.h... no checking util.h usability... no checking util.h presence... no checking for util.h... no checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking utmp.h usability... yes checking utmp.h presence... yes checking for utmp.h... yes checking utmpx.h usability... no checking utmpx.h presence... no checking for utmpx.h... no checking vis.h usability... yes checking vis.h presence... yes checking for vis.h... yes checking for lastlog.h... no checking for sys/ptms.h... no checking for yp_match... yes checking for setsockopt... yes checking for dirname... yes checking libgen.h usability... yes checking libgen.h presence... yes checking for libgen.h... yes checking for getspnam... no checking for getspnam in -lgen... no checking for library containing basename... none required checking for deflate in -lz... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for possibly buggy zlib... no checking for strcasecmp... yes checking for utimes... yes checking libutil.h usability... yes checking libutil.h presence... yes checking for libutil.h... yes checking for library containing login... -lutil checking for logout... yes checking for updwtmp... no checking for logwtmp... yes checking for strftime... yes checking for GLOB_ALTDIRFUNC support... yes checking for gl_matchc field in glob_t... no checking whether struct dirent allocates space for d_name... yes checking for /proc/pid/fd directory... no checking for libwrap... yes checking for arc4random... yes checking for asprintf... yes checking for b64_ntop... no checking for __b64_ntop... yes checking for b64_pton... no checking for __b64_pton... yes checking for bcopy... yes checking for bindresvport_sa... yes checking for clock... yes checking for closefrom... no checking for dirfd... no checking for fchmod... yes checking for fchown... yes checking for freeaddrinfo... yes checking for futimes... yes checking for getaddrinfo... yes checking for getcwd... yes checking for getgrouplist... yes checking for getnameinfo... yes checking for getopt... yes checking for getpeereid... yes checking for _getpty... no checking for getrlimit... yes checking for getttyent... yes checking for glob... yes checking for inet_aton... yes checking for inet_ntoa... yes checking for inet_ntop... yes checking for innetgr... yes checking for login_getcapbool... yes checking for md5_crypt... no checking for memmove... yes checking for mkdtemp... yes checking for mmap... yes checking for ngetaddrinfo... no checking for nsleep... no checking for ogetaddrinfo... no checking for openlog_r... no checking for openpty... yes checking for prctl... no checking for pstat... no checking for readpassphrase... yes checking for realpath... yes checking for recvmsg... yes checking for rresvport_af... yes checking for sendmsg... yes checking for setdtablesize... no checking for setegid... yes checking for setenv... yes checking for seteuid... yes checking for setgroups... yes checking for setlogin... yes checking for setpcred... no checking for setproctitle... yes checking for setregid... yes checking for setreuid... yes checking for setrlimit... yes checking for setsid... yes checking for setvbuf... yes checking for sigaction... yes checking for sigvec... yes checking for snprintf... yes checking for socketpair... yes checking for strdup... yes checking for strerror... yes checking for strlcat... yes checking for strlcpy... yes checking for strmode... yes checking for strnvis... no checking for strtonum... no checking for strtoll... yes checking for strtoul... yes checking for sysconf... yes checking for tcgetpgrp... yes checking for truncate... yes checking for unsetenv... yes checking for updwtmpx... no checking for vasprintf... yes checking for vhangup... no checking for vsnprintf... yes checking for waitpid... yes checking for gai_strerror... yes checking for library containing nanosleep... none required checking whether getrusage is declared... no checking whether strsep is declared... yes checking for strsep... yes checking whether tcsendbreak is declared... yes checking whether h_errno is declared... yes checking for setresuid... yes checking if setresuid seems to work... yes checking for setresgid... yes checking if setresgid seems to work... yes checking for gettimeofday... yes checking for time... yes checking for endutent... no checking for getutent... no checking for getutid... no checking for getutline... no checking for pututline... no checking for setutent... no checking for utmpname... no checking for endutxent... no checking for getutxent... no checking for getutxid... no checking for getutxline... no checking for pututxline... no checking for setutxent... no checking for utmpxname... no checking for daemon... yes checking for getpagesize... yes checking whether snprintf correctly terminates long strings... yes checking whether snprintf can declare const char *fmt... yes checking for (overly) strict mkstemp... no checking whether getpgrp requires zero arguments... yes checking OpenSSL header version... 90704f (OpenSSL 0.9.7d 17 Mar 2004) checking OpenSSL library version... 90704f (OpenSSL 0.9.7d 17 Mar 2004) checking whether OpenSSL's headers match the library... yes checking whether OpenSSL has crippled AES support... no checking for crypt in -lcrypt... yes checking for ia_openinfo in -liaf... no checking whether OpenSSL's PRNG is internally seeded... yes checking for ls... /bin/ls checking for netstat... /usr/bin/netstat checking for arp... /usr/sbin/arp checking for ifconfig... /sbin/ifconfig checking for jstat... no checking for ps... /bin/ps checking for sar... no checking for w... /usr/bin/w checking for who... /usr/bin/who checking for last... /usr/bin/last checking for lastlog... no checking for df... /bin/df checking for vmstat... /usr/bin/vmstat checking for uptime... /usr/bin/uptime checking for ipcs... /usr/bin/ipcs checking for tail... /usr/bin/tail checking for long long... yes checking for unsigned long long... yes checking for long double... yes checking for char... yes checking size of char... 1 checking for short int... yes checking size of short int... 2 checking for int... yes checking size of int... 4 checking for long int... yes checking size of long int... 4 checking for long long int... yes checking size of long long int... 8 checking for u_int type... yes checking for intXX_t types... yes checking for int64_t type... yes checking for u_intXX_t types... yes checking for u_int64_t types... yes checking for uintXX_t types in stdint.h... no checking for u_char... yes checking for socklen_t... yes checking for sig_atomic_t... yes checking for in_addr_t... yes checking for size_t... yes checking for ssize_t... yes checking for clock_t... yes checking for sa_family_t... yes checking for pid_t... yes checking for mode_t... yes checking for struct sockaddr_storage... yes checking for struct sockaddr_in6... yes checking for struct in6_addr... yes checking for struct addrinfo... yes checking for struct timeval... yes checking for struct timespec... yes checking for ut_host field in utmp.h... yes checking for ut_host field in utmpx.h... no checking for syslen field in utmpx.h... no checking for ut_pid field in utmp.h... no checking for ut_type field in utmp.h... no checking for ut_type field in utmpx.h... no checking for ut_tv field in utmp.h... no checking for ut_id field in utmp.h... no checking for ut_id field in utmpx.h... no checking for ut_addr field in utmp.h... no checking for ut_addr field in utmpx.h... no checking for ut_addr_v6 field in utmp.h... no checking for ut_addr_v6 field in utmpx.h... no checking for ut_exit field in utmp.h... no checking for ut_time field in utmp.h... yes checking for ut_time field in utmpx.h... no checking for ut_tv field in utmpx.h... no checking for struct stat.st_blksize... yes checking for struct __res_state.retrans... no checking for ss_family field in struct sockaddr_storage... yes checking for __ss_family field in struct sockaddr_storage... no checking for pw_class field in struct passwd... yes checking for pw_expire field in struct passwd... yes checking for pw_change field in struct passwd... yes checking for msg_accrights field in struct msghdr... no checking for msg_control field in struct msghdr... yes checking if libc defines __progname... yes checking whether gcc implements __FUNCTION__... yes checking whether gcc implements __func__... yes checking whether va_copy exists... no checking whether __va_copy exists... no checking whether getopt has optreset support... no checking if libc defines sys_errlist... yes checking if libc defines sys_nerr... yes checking for library containing getrrsetbyname... no checking for library containing res_query... none required checking for library containing dn_expand... none required checking if res_query will link... yes checking for _getshort... yes checking for _getlong... yes checking whether _getshort is declared... no checking whether _getlong is declared... no checking for HEADER.ad... yes checking for xauth... /usr/X11R6/bin/xauth checking for "/dev/ptmx"... no checking for "/dev/ptc"... no checking for nroff... /usr/bin/nroff checking if the systems has expire shadow information... no checking for "/etc/default/login"... no configure: WARNING: Make sure the path to scp is in /etc/login.conf checking if we need to convert IPv4 in IPv6-mapped addresses... no (default) checking if your system defines LASTLOG_FILE... no checking if your system defines _PATH_LASTLOG... yes checking if your system defines UTMP_FILE... no checking if your system defines WTMP_FILE... no checking if your system defines UTMPX_FILE... no checking if your system defines WTMPX_FILE... no configure: creating ./config.status config.status: creating Makefile config.status: creating buildpkg.sh config.status: creating opensshd.init config.status: creating openbsd-compat/Makefile config.status: creating scard/Makefile config.status: creating ssh_prng_cmds config.status: creating survey.sh config.status: creating config.h OpenSSH has been configured with the following options: User binaries: /usr/bin System binaries: /usr/sbin Configuration files: /etc/ssh Askpass program: /usr/libexec/ssh-askpass Manual pages: /usr/man/manX PID file: /var/run Privilege separation chroot path: /var/empty At runtime, sshd will use the path defined in /etc/login.conf Make sure the path to scp is present, otherwise scp will not work Manpage format: doc PAM support: no KerberosV support: no Smartcard support: no S/KEY support: no TCP Wrappers support: yes MD5 password support: yes libedit support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: no BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i386-unknown-freebsd4.11 Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wuninitialized Preprocessor flags: Linker flags: Libraries: -lwrap -lcrypto -lutil -lz -lcrypt -- Charlie Sorsby crs at swcp.com P. O. Box 1225 Edgewood, NM 87015 USA Why HTML in e-mail is evil: http://www.birdhouse.org/etc/evilmail.html and (possibly) how to turn it off: http://www.expita.com/nomime.html From vinschen at redhat.com Sun Apr 23 19:20:30 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 23 Apr 2006 11:20:30 +0200 Subject: cygwin performance problem In-Reply-To: <20060421102233.GE12661@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> <44451755.4050209@psc.edu> <20060420094129.GN11759@calimero.vinschen.de> <4447EC6D.3010805@psc.edu> <20060421102233.GE12661@calimero.vinschen.de> Message-ID: <20060423092030.GB8876@calimero.vinschen.de> On Apr 21 12:22, Corinna Vinschen wrote: > On Apr 20 16:17, Chris Rapier wrote: > > Corinna Vinschen wrote: > > > > > Since in both cases (scp/tar) the underlying Cygwin is identical, and > > > since in both cases the file is locally copied over a pipe between the > > > two processes (ssh->scp resp. ssh->tar), I'm currently really at a loss > > > why scp is so slow. I tried various buffer sizes in the "sink" function > > > in scp.c, values between 4K and 512K, but this had no influence at all. > > > I have to debug this a lot more, apparently, but... if anybody has a > > > clue why copying over scp could be so much slower than copying over tar, > > > I'd really appreciate it. > > > > Do you have any tools under cygwin that could tel you what syscalls are > > being made during the transfer? If we can find out where its spending so > > much of its time that might help. > > Yes, and I can see that the most time is spent in select as well as > reading and writing on the pipe. I still have to find out why this > is, though. I just applied a fix to Cygwin's CVS, so this should be better in the next Cygwin release. For the curious, the culprit was the select implementation for pipes. There's no Windows equivalent for the select function which works on pipes. The only function available to test if data is available on a pipe is a function called "PeekNamedPipe", which is non-blocking. So a select implementation for pipes has to do something along the lines of a busy loop, testing the pipe with PeekNamedPipe until data is available. However, such a loop has the disadvantage to take as much CPU as it can get, so the Cygwin loop used a 10ms sleep per iteration, to keep the CPU usage tolerable. Unfortunately, when sending bulk data, this 10ms sleep is a problem. It's not sure that always the first call to PeekNamedPipe returns with success, so there's a high probability that the loop is at least run twice, which introduces at least one extra sleep per select. My fix changes that by starting the loop with a sleep time set to 0 ms, and incrementing it every second iteration by 1 ms, up to the max value of 10 ms. This still saves CPU time, while giving a good performance for transfering lots of data. With this simple change, scp gets a throughput of ~13 MB/s instead of the former 1.3 MB/s. Changing the buffer size in client_process_net_input is not necessary to get this performance. I'm happy, and I hope Cygwin scp users will be happy, too :-) Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From djm at mindrot.org Sun Apr 23 23:01:33 2006 From: djm at mindrot.org (Damien Miller) Date: Sun, 23 Apr 2006 23:01:33 +1000 (EST) Subject: cygwin performance problem In-Reply-To: <20060423092030.GB8876@calimero.vinschen.de> References: <20060325101007.M7943@ais42.net> <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> <44451755.4050209@psc.edu> <20060420094129.GN11759@calimero.vinschen.de> <4447EC6D.3010805@psc.edu> <20060421102233.GE12661@calimero.vinschen.de> <20060423092030.GB8876@calimero.vinschen.de> Message-ID: On Sun, 23 Apr 2006, Corinna Vinschen wrote: > For the curious, the culprit was the select implementation for pipes. > There's no Windows equivalent for the select function which works on > pipes. The only function available to test if data is available on a > pipe is a function called "PeekNamedPipe", which is non-blocking. > > So a select implementation for pipes has to do something along the lines > of a busy loop, testing the pipe with PeekNamedPipe until data is > available. However, such a loop has the disadvantage to take as much > CPU as it can get, so the Cygwin loop used a 10ms sleep per iteration, > to keep the CPU usage tolerable. In this case, shouldn't cygwin be using socketpair() for interprocess communication everywhere? (assuming that there is a select()-like function available in the Win32 API). This switch can be made by deleting the following line from "*-*-cygwin*)" block: AC_DEFINE(USE_PIPES, 1, [Use PIPES instead of a socketpair()]) To fully use socketpairs, you will need the following patch to scp.c, as it doesn't seem to care right now: Index: scp.c =================================================================== RCS file: /var/cvs/openssh/scp.c,v retrieving revision 1.155 diff -u -p -r1.155 scp.c --- scp.c 23 Apr 2006 02:04:46 -0000 1.155 +++ scp.c 23 Apr 2006 12:58:15 -0000 @@ -181,7 +181,12 @@ do_local_cmd(arglist *a) int do_cmd(char *host, char *remuser, char *cmd, int *fdin, int *fdout) { - int pin[2], pout[2], reserved[2]; + int reserved[2]; +#ifdef USE_PIPES + int pin[2], pout[2]; +#else + int pinout[2]; +#endif if (verbose_mode) fprintf(stderr, @@ -195,11 +200,13 @@ do_cmd(char *host, char *remuser, char * */ pipe(reserved); - /* Create a socket pair for communicating with ssh. */ - if (pipe(pin) < 0) - fatal("pipe: %s", strerror(errno)); - if (pipe(pout) < 0) +#ifdef USE_PIPES + if ((pipe(pin) == -1) || (pipe(pout) == -1)) fatal("pipe: %s", strerror(errno)); +#else /* USE_PIPES */ + if (socketpair(AF_UNIX, SOCK_STREAM, 0, pinout) == -1) + fatal("socketpair: %s", strerror(errno)); +#endif /* USE_PIPES */ /* Free the reserved descriptors. */ close(reserved[0]); @@ -209,12 +216,25 @@ do_cmd(char *host, char *remuser, char * do_cmd_pid = fork(); if (do_cmd_pid == 0) { /* Child. */ +#ifdef USE_PIPES close(pin[1]); close(pout[0]); - dup2(pin[0], 0); - dup2(pout[1], 1); + if ((dup2(pin[0], STDIN_FILENO) == -1) || + (dup2(pout[1], STDOUT_FILENO) == -1)) { + fprintf(stderr, "dup2: %s\n", strerror(errno)); + _exit(1); + } close(pin[0]); close(pout[1]); +#else /* USE_PIPES */ + close(pinout[0]); + if ((dup2(pinout[1], STDIN_FILENO) == -1) || + (dup2(pinout[1], STDOUT_FILENO) == -1)) { + fprintf(stderr, "dup2: %s\n", strerror(errno)); + _exit(1); + } + close(pinout[1]); +#endif /* USE_PIPES */ replacearg(&args, 0, "%s", ssh_program); if (remuser != NULL) @@ -229,10 +249,16 @@ do_cmd(char *host, char *remuser, char * fatal("fork: %s", strerror(errno)); } /* Parent. Close the other side, and return the local side. */ +#ifdef USE_PIPES close(pin[0]); *fdout = pin[1]; close(pout[1]); *fdin = pout[0]; +#else /* USE_PIPES */ + close(pinout[1]); + *fdout = pinout[0]; + *fdin = pinout[0]; +#endif /* USE_PIPES */ signal(SIGTERM, killchild); signal(SIGINT, killchild); signal(SIGHUP, killchild); From gsslist+ssh at anthropohedron.net Sun Apr 23 23:25:24 2006 From: gsslist+ssh at anthropohedron.net (Gregory Seidman) Date: Sun, 23 Apr 2006 09:25:24 -0400 Subject: Mach port forwarding (was Re: [Patch] Unix Domain Socket Forwarding) In-Reply-To: <20060422220316.GA17816@orville.25thandClement.com> References: <20060421041009.GA15746@orville.25thandClement.com> <20060422210757.GA9286@melpomene.jschipper.dynalias.net> <20060422220316.GA17816@orville.25thandClement.com> Message-ID: <20060423132515.GA20793@anthropohedron.net> Okay, this is a long shot and only peripherally related, but I've been hoping to see someone implement Mach port forwarding over ssh. There is really only one significant use case for this, which is the equivalent of X11 forwarding for MacOS X applications. Apps communicate with the WindowServer via a Mach port, and it would be extraordinary if that port could be forwarded over ssh. I'm imagining a situation in which one sits at a MacOS X machine and connects to another one over ssh. Under normal circumstances, the sshd on MacOS X is run outside the user context, thus has no access to the WindowServer Mach port. A modified ssh/sshd pair could bind to the Mach port on the remote host and provide access to the local host's WindowServer. Unfortunately, I am insufficiently familiar with either the OpenSSH codebase or the workings of Mach ports even to say definitively that it is possible. My goal here is to plant the seed of the idea in the hopes that someone will take an interest and implement it. --Greg From vinschen at redhat.com Mon Apr 24 02:42:09 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Sun, 23 Apr 2006 18:42:09 +0200 Subject: cygwin performance problem In-Reply-To: References: <44261AA5.9070407@psc.edu> <20060404093233.GA16456@calimero.vinschen.de> <20060418161106.GA25977@calimero.vinschen.de> <44451755.4050209@psc.edu> <20060420094129.GN11759@calimero.vinschen.de> <4447EC6D.3010805@psc.edu> <20060421102233.GE12661@calimero.vinschen.de> <20060423092030.GB8876@calimero.vinschen.de> Message-ID: <20060423164209.GA11235@calimero.vinschen.de> Hi Damien, On Apr 23 23:01, Damien Miller wrote: > In this case, shouldn't cygwin be using socketpair() for interprocess > communication everywhere? (assuming that there is a select()-like > function available in the Win32 API). This switch can be made by Yes, actually there is a select function, but it's implemented in the Windows socket layer, so it's available exclusively for sockets (and utilized for select on sockets in Cygwin, obviously). > deleting the following line from "*-*-cygwin*)" block: > > AC_DEFINE(USE_PIPES, 1, [Use PIPES instead of a socketpair()]) > > To fully use socketpairs, you will need the following patch to scp.c, > as it doesn't seem to care right now: Thanks for the patch. I tried it, but using socketpairs is slower than using pipes, so, for performance reasons, I'd rather stick with pipes, now that we have found a nice workaround in Cygwin. Way back when we started using USE_PIPES for Cygwin, the reason was actually the performance. Since the select function has changed over the time, I assume the now fixed performance problem didn't exist years ago. As for socketpairs, since Windows has no concept for AF_UNIX/AF_LOCAL sockets, these sockets are implemented as AF_INET sockets under the hood. Using AF_INET sockets locally is 30-40% slower than using pipes on Windows. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From bob at proulx.com Mon Apr 24 03:38:08 2006 From: bob at proulx.com (Bob Proulx) Date: Sun, 23 Apr 2006 11:38:08 -0600 Subject: sshrc not working when using restricted shells on HP-UX In-Reply-To: <44059B5C.5060703@zip.com.au> References: <10782.1138896193@www020.gmx.net> <6424.1141215995@www047.gmx.net> <44059727.2060303@zip.com.au> <44059B5C.5060703@zip.com.au> Message-ID: <20060423173808.GA24840@dementia.proulx.com> Darren Tucker wrote: > Darren Tucker wrote: > > Tob_Sch at gmx.de wrote: > > [about restricted shells] > >> Here's the error message during starting the connection: > >> > >> sh: /bin/sh: The operation is not allowed in a restricted shell. > > > > I would interpret that as one of the commands in the sshrc failing, > > rather than parsing of the file itself failing. What's in sshrc? Does > > putting "set -x" at the top of sshrc provide any enlightenment? > > Looking at the code, it does: > f = popen(_PATH_BSHELL " " _PATH_SSH_SYSTEM_RC, "w"); > > which is effectively running: > > /bin/sh /usr/local/etc/sshrc > > I suspect the difference is that the platforms that work use /bin/sh for > popen() but HP-UX uses the login shell. > ... > The Linux man page says unequivocally that it uses /bin/sh. I can't > conveniently check HP-UX right now. The HP-UX 11.00 popen(3S) documentation says: popen() creates a pipe between the calling program and a command to be executed by the POSIX shell, /usr/bin/sh (see sh-posix(1)). On HP-UX /bin is a symlink to /usr/bin since HP-UX 10.01. So effectively this is also /bin/sh, a POSIX shell, on HP-UX. Bob From djm at mindrot.org Mon Apr 24 11:52:24 2006 From: djm at mindrot.org (Damien Miller) Date: Mon, 24 Apr 2006 11:52:24 +1000 (EST) Subject: test, please ignore Message-ID: Testing upgrade to Mailman 2.1.8. Please ignore. -d From wiskbroom at hotmail.com Wed Apr 26 05:42:39 2006 From: wiskbroom at hotmail.com (Vadim Pushkin) Date: Tue, 25 Apr 2006 19:42:39 +0000 Subject: NIS - netgroup Message-ID: Hello; Sorry for the crosspost/repost, but I am getting desparate here. I am having difficulties setting up ssh (ossh4.3p2 - NIS -Solaris8/Sparc) to authenticate and allow ossh access based on NIS netgroup. So, users and/or host should be from a valid netgroup triple, contained within the ossh servers .rhosts, .shosts, hosts.equiv and/or shosts.equiv. I am having alot of trouble getting NIS netgroup to work with my current sshd_config, and I've tried just about everything... My environment is pure NIS, no LDAP, at least not for the next year. Again, many thanks in advance, .vp From tim at multitalents.net Wed Apr 26 07:37:38 2006 From: tim at multitalents.net (Tim Rice) Date: Tue, 25 Apr 2006 14:37:38 -0700 (PDT) Subject: NIS - netgroup In-Reply-To: References: Message-ID: On Tue, 25 Apr 2006, Vadim Pushkin wrote: > Hello; > > Sorry for the crosspost/repost, but I am getting desparate here. > > I am having difficulties setting up ssh (ossh4.3p2 - NIS -Solaris8/Sparc) to > authenticate and allow ossh access based on NIS netgroup. So, users and/or > host should be from a valid netgroup triple, contained within the ossh > servers .rhosts, .shosts, hosts.equiv and/or shosts.equiv. > > I am having alot of trouble getting NIS netgroup to work with my current > sshd_config, and I've tried just about everything... > > My environment is pure NIS, no LDAP, at least not for the next year. I don't use NIS here, just LDAP. Did you compile openssh with PAM support? Do you have "UsePAM yes" in your sshd_config? > > Again, many thanks in advance, > > .vp -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From dtucker at zip.com.au Thu Apr 27 13:26:45 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 27 Apr 2006 13:26:45 +1000 Subject: OpenSSH DNS resolution failure on IRIX 5.3: request to fix In-Reply-To: References: Message-ID: <445039F5.8020304@zip.com.au> Georg Schwarz wrote: > as reported earlier, recent versions of OpenSSH (4.3p1, 4.3p2 as well > as the current CVS) on IRIX 5.3 exhibit a DNS resolution failure. > Even for perfectly valid hostnames they return "no address associated > with name". [...] > When I take out the line > > struct __res_state _res; > > things work. Also, the problem does not occur when compiling with gcc > (I used 3.4.4) instead of the SGI IDO cc. Thinking about this: is __res_state declared extern in the system headers? -- 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 openssh at roumenpetrov.info Fri Apr 28 04:38:09 2006 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 27 Apr 2006 21:38:09 +0300 Subject: Announce: X.509 certificates support in OpenSSH version 5.4 Message-ID: <44510F91.5030700@roumenpetrov.info> Hi All, The version 5.4 of "X.509 certificates support in OpenSSH" is ready for download. On download page http://roumenpetrov.info.localhost/openssh/download.html#get_-5.4 you can found diffs for OpenSSH versions 4.2p1 and 4.3p2. What's new: * given up support for "x509v3-sign-rsa-sha1" and "x509v3-sign-dss-sha1" The implementation realised in previous version 5.3 is not fully in conformance with "draft-ietf-secsh-x509-02.txt" * correct nid for OCSP responder location All version before 5.4 search for nid "id-pkix-ocsp-service-locator" instead for correct one "id-ad-ocsp" to find location of OCSP responder. * public key permit X.509 certificate for authentication Now the public key listed in authorized keys file permit too a X.509 certificate with public key that match it to be used in "public key authentication". * client option "PubkeyAlgorithms" This new clent option specifies the protocol version 2 algorithms used in "publickey" authentication allowed to sent to the host. * server option "KeyAllowSelfIssued" This new server option specifies whether only public key or certificate blob listed in authorized keys file can allow self-issued(self-signed) X.509 certificate to be used for user authentication. Please visit "http://roumenpetrov.info/openssh/" for more information about "X.509 certificates support in OpenSSH". Regards, Roumen Petrov From parkingtree at yahoo.com Wed Apr 26 09:52:39 2006 From: parkingtree at yahoo.com (J D) Date: Tue, 25 Apr 2006 16:52:39 -0700 (PDT) Subject: Memory Usage with openSSH 4.0 Message-ID: <20060425235239.45447.qmail@web34310.mail.mud.yahoo.com> I have friends running sshd on their emebedded ppc linux systems at two universities. Normally sshd takes about 3M of memory and they have about 16M freemem showed in /proc/meminfo. But occationally (every 1 or 2 weeks) they see free memory goes down really fast and they lose 10M in 1 minute. If they disable sshd by blocking the port access, this does not happen any more. The device is not behind any firewall and sshd version is 4.0. I've done a lot search on the web and have not found any report of similar issues. I was hoping experts on this mailing list can help shed some light on this problem. Thanks. - Adrian From wiskbroom at hotmail.com Thu Apr 27 00:49:36 2006 From: wiskbroom at hotmail.com (Vadim Pushkin) Date: Wed, 26 Apr 2006 14:49:36 +0000 Subject: NIS - netgroup In-Reply-To: Message-ID: Greetings; Yes to both, here are what my config and related system files look like, but I think that I have tried just about every variation possible, not sure about the pam.conf though. Using the scenario below, I am able to sucessfuly login as root from *any* host to serverA. This is true because the remote host is using a valid key that is contained witin serverA's authorized_keys file. So what I am looking to do is to precede netgroups prior to auth by authorized_keys, does this make any sense? Thank you Tim and all! Vadim LDD Output On My SSHD: ----------------------------------- root at serverA#: /tmp=> ldd /usr/local/sbin/sshd libpam.so.1 => /usr/lib/libpam.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libresolv.so.2 => /usr/lib/libresolv.so.2 librt.so.1 => /usr/lib/librt.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libcmd.so.1 => /usr/lib/libcmd.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmp.so.2 => /usr/lib/libmp.so.2 /usr/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1 SSHD_CONFIG On serverA: ------------------------------------ HostKey /etc/ossh/ssh_host_key HostKey /etc/ossh/ssh_host_rsa_key HostKey /etc/ossh/ssh_host_dsa_key PermitRootLogin yes AllowGroups trustedusers ntadmins AuthorizedKeysFile %h/.ssh/authorized_keys IgnoreRhosts no UsePAM yes PrintMotd no PidFile /var/run/sshd.pid Banner /etc/ossh/banner Subsystem sftp /usr/libexec/sftp-server My roots .rhosts and .shosts files (They are the same on serverA): ------------------------------------------------------------------------------------------ - at nontrustedhosts + at trustedhosts Hosts Within The trustedhosts netgroup(verified by doing a ypcat: ------------------------------------------------------------------------------------------ trustedhosts (host1,-,) (host2,-,) (host3,-,) Hosts Within The nontrustedhosts netgroup: --------------------------------------------------------- nontrustedhosts (hostx,-,) (hosty,-,) (hostz,-,) My /etc/pam.conf file, the one thing that I am uncertain of: ---------------------------------------------------------------------------------- login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth required pam_unix_auth.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 dtlogin auth required pam_unix_auth.so.1 sshd auth requisite pam_authtok_get.so.1 sshd auth required pam_dhkeys.so.1 sshd auth sufficient pam_unix_auth.so.1 sshd account required pam_unix_account.so.1 rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_unix_auth.so.1 other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_auth.so.1 login account requisite pam_roles.so.1 login account required pam_projects.so.1 login account required pam_unix_account.so.1 dtlogin account requisite pam_roles.so.1 dtlogin account required pam_projects.so.1 dtlogin account required pam_unix_account.so.1 other account requisite pam_roles.so.1 other account required pam_projects.so.1 other account required pam_unix_account.so.1 other session required pam_unix_session.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 dtsession auth requisite pam_authtok_get.so.1 dtsession auth required pam_dhkeys.so.1 dtsession auth required pam_unix_auth.so.1 ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_unix_auth.so.1 ppp auth required pam_dial_auth.so.1 ppp account requisite pam_roles.so.1 ppp account required pam_projects.so.1 ppp account required pam_unix_account.so.1 ppp session required pam_unix_session.so.1 passwd auth required pam_passwd_auth.so.1 cron account required pam_unix_account.so.1 Perinent portion of /etc/nsswitch.conf: ----------------------------------------------------- netgroup: nis # I've tried also file and files nis (files by copying to local file on serverA) >From: Tim Rice >To: Vadim Pushkin >CC: openssh-unix-dev at mindrot.org >Subject: Re: NIS - netgroup >Date: Tue, 25 Apr 2006 14:37:38 -0700 (PDT) >On Tue, 25 Apr 2006, Vadim Pushkin wrote: > > > Hello; > > > > Sorry for the crosspost/repost, but I am getting desparate here. > > > > I am having difficulties setting up ssh (ossh4.3p2 - NIS >-Solaris8/Sparc) to > > authenticate and allow ossh access based on NIS netgroup. So, users >and/or > > host should be from a valid netgroup triple, contained within the ossh > > servers .rhosts, .shosts, hosts.equiv and/or shosts.equiv. > > > > I am having alot of trouble getting NIS netgroup to work with my current > > sshd_config, and I've tried just about everything... > > > > My environment is pure NIS, no LDAP, at least not for the next year. > >I don't use NIS here, just LDAP. > >Did you compile openssh with PAM support? >Do you have "UsePAM yes" in your sshd_config? > > > > > Again, many thanks in advance, > > > > .vp > >-- >Tim Rice Multitalents (707) 887-1469 >tim at multitalents.net From rapier at psc.edu Thu Apr 27 05:17:12 2006 From: rapier at psc.edu (Chris Rapier) Date: Wed, 26 Apr 2006 15:17:12 -0400 Subject: Prelim results: hpnssh v ssh in local area networks Message-ID: <444FC738.7070803@psc.edu> The results, for anyone interested, can be found here http://www.psc.edu/networking/projects/hpn-ssh/results.html Long story short, there doesn't seem to be any notable difference between the two anymore. I still have a few more test combinations to run (<.5ms rtts and against cygwin) so the conclusions might change but, at this point, I'm no longer seeing any sort of performance hit (as a measure of throughput) for hpnssh in local area networks. Raw data, test script, and stats script available for those interested. thx chris From gawain.bolton at thalesgroup.com Thu Apr 27 17:34:41 2006 From: gawain.bolton at thalesgroup.com (Gawain Bolton) Date: Thu, 27 Apr 2006 09:34:41 +0200 Subject: IdentityFile option escape sequences Message-ID: <44507411.2070003@thalesgroup.com> Hello, I'm using openssh-4.3p2 compiled for sparc-sun-solaris2.8. I'm trying to use the IdentityFile option with the escape sequences for the remote host name (%h) and remote user name (%r) as documented in ssh-config . It seems the escape sequences do not work. I have tried both using the command like option and an ssh-config file and the results are the same - it seems the escape sequences do not get expanded. The example below shows that the option is _seen _by ssh, but the esacpe sequences are not expanded. sftp -v -oPasswordAuthentication=no -oIdentityFile=/var/opt/oss/data/config/ssh/%h_%r_id_dsa temip at bt1sss5t Connecting to bt1sss5t... OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Connecting to bt1sss5t [142.4.151.6] port 22. debug1: Connection established. debug1: identity file %h_%r_id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'bt1sss5t' is known and matches the RSA host key. debug1: Found key in /usr/users/temip/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey *debug1: Trying private key: %h_%r_id_dsa* debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: No more authentication methods to try. Permission denied (publickey,password,keyboard-interactive). Connection closed The private key *%h_%r_id_dsa* not at all what I was expecting. Rather, I was expecting: /var/opt/oss/data/config/ssh/bt1sss5t_temip_id_dsa I apologize in advance if this is a known problem or I am doing something which is known to be a stupid thing neophytes do... In my defense, my searching of the mailing list archives and the web turned up nothing. Cheers, Gawain -------------- next part -------------- A non-text attachment was scrubbed... Name: gawain.bolton.vcf Type: text/x-vcard Size: 201 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20060427/9d456cec/attachment.vcf From dtucker at zip.com.au Fri Apr 28 18:08:57 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 28 Apr 2006 18:08:57 +1000 Subject: IdentityFile option escape sequences In-Reply-To: <44507411.2070003@thalesgroup.com> References: <44507411.2070003@thalesgroup.com> Message-ID: <20060428080857.GA13730@gate.dtucker.net> On Thu, Apr 27, 2006 at 09:34:41AM +0200, Gawain Bolton wrote: > Hello, > > I'm using openssh-4.3p2 compiled for sparc-sun-solaris2.8. I'm trying > to use the IdentityFile option with the escape sequences for the remote > host name (%h) and remote user name (%r) as documented in ssh-config > . > > It seems the escape sequences do not work. I have tried both using the > command like option and an ssh-config file and the results are the same > - it seems the escape sequences do not get expanded. The example below > shows that the option is _seen _by ssh, but the esacpe sequences are not > expanded. You're looking at the man page for the current development version (that's what the "OpenBSD+current" part means) and the feature in question was added after the 4.3p2 release. -- 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 bpsr77 at hotmail.com Sat Apr 29 03:19:45 2006 From: bpsr77 at hotmail.com (olle ollesson) Date: Fri, 28 Apr 2006 19:19:45 +0200 Subject: Disconnecting: Bad packet length Message-ID: Hi, I'm trying to get OpenSSH to work on Solaris 10 wich Sun C 5.8 compiler (SUNWspro 11). I've compiled OpenSSL 0.9.8a without problem and OpenSSH 4.3p2 as well. [user at compilationserver ~/openssh-4.3p2] ./ssh -V OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005 My problem is that I cannot connect to anything. When I try I always get an error [user at compilationserver ~/openssh-4.3p2] ./ssh localhost Disconnecting: Bad packet length 872800259. When run with debug flags the last entries are: debug2: bits set: 520/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent Disconnecting: Bad packet length 2746918454. When compiled on Solaris 9 with Sun C 5.3 (SUNWspro 6) it works. I've searched the mailing archives and found some entres from long time ago with a similar problem. The suggestion then was to test changing zlib. On Solaris 10 the zlib installed is SUNzlib 11.10.0,REV=2005.01.08.05.16 and on Solaris 9 it is 11.9.0,REV=2002.03.02.00.35 . Could it be related to the new zlib in Solaris 10 compared to Solaris 9? Anyone else that has encountered this problem? Any help is greatly apprechiated. Best Regards, Olle _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From bpsr77 at hotmail.com Sat Apr 29 03:47:35 2006 From: bpsr77 at hotmail.com (olle ollesson) Date: Fri, 28 Apr 2006 19:47:35 +0200 Subject: Disconnecting: Bad packet length In-Reply-To: Message-ID: Hi again, Sorry for answering my own mail. Just for the record, I've now downloaded and compiled zlib-1.2.3 and build openssh with the following options ./configure --prefix=/opt/openssh-4.3p2 --with-ssl-dir=/opt/openssl-0.9.8a --with-zlib=/opt/zlib-1.2.3 Unfortunately this didn't help. I still get "Disconnecting: Bad packet length" before the password prompt is shown. Cheers, Olle _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From rapier at psc.edu Sat Apr 29 05:41:56 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 28 Apr 2006 15:41:56 -0400 Subject: hpnssh v ssh performance in local area networks In-Reply-To: <444FC738.7070803@psc.edu> References: <444FC738.7070803@psc.edu> Message-ID: <44527004.8090704@psc.edu> More results using more variables and different combinations of endpoints are available at http://www.psc.edu/networking/projects/hpn-ssh/results.html Basic conclusion is that in local area networks HPNSSH is as fast or, in some situations, faster that the stock version of OpenSSH. I'll be focusing on some of the more interesting results (doing 1000 iterations instead of just 100) and seeing if these conclusions are justified or what, if any, qualifiers are necessary. If anyone would like to try this out for themselves the test script and the analysis script are available at http://www.psc.edu/networking/projects/hpn-ssh/iterate.pl http://www.psc.edu/networking/projects/hpn-ssh/ssh-stats.pl I'd really like to get more data in terms of different OSes, network speeds, latencies and so forth. The most recent beta version of the patch is available at http://www.psc.edu/networking/projects/hpn-ssh/hpn12v5.diff.gz Usage notes can be found here http://www.psc.edu/networking/projects/hpn-ssh/ssh-hpn12.notes Thanks! Chris Rapier From rapier at psc.edu Sat Apr 29 06:03:23 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 28 Apr 2006 16:03:23 -0400 Subject: hpnssh v ssh performance in local area networks In-Reply-To: <44527004.8090704@psc.edu> References: <444FC738.7070803@psc.edu> <44527004.8090704@psc.edu> Message-ID: <4452750B.7000407@psc.edu> Chris Rapier wrote: > If anyone would like to try this out for themselves the test script and > the analysis script are available at > http://www.psc.edu/networking/projects/hpn-ssh/iterate.pl > http://www.psc.edu/networking/projects/hpn-ssh/ssh-stats.pl Due to some security restrictions I wasn't aware of the web server won't serve any page with a .pl extension. :| So the correct locations are http://www.psc.edu/networking/projects/hpn-ssh/iterate.txt http://www.psc.edu/networking/projects/hpn-ssh/ssh-stats.txt and you'll need to rename them as you see fit. Chris From smooge at gmail.com Sat Apr 29 14:20:53 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 28 Apr 2006 22:20:53 -0600 Subject: Memory Usage with openSSH 4.0 In-Reply-To: <20060425235239.45447.qmail@web34310.mail.mud.yahoo.com> References: <20060425235239.45447.qmail@web34310.mail.mud.yahoo.com> Message-ID: <80d7e4090604282120u8170fdch691b330365d920c5@mail.gmail.com> On 4/25/06, J D wrote: > I have friends running sshd on their emebedded ppc > linux systems at two universities. Normally sshd takes > about 3M of memory and they have about 16M freemem > showed in /proc/meminfo. But occationally (every 1 or > 2 weeks) they see free memory goes down really fast > and they lose 10M in 1 minute. If they disable sshd by > blocking the port access, this does not happen any > more. > > The device is not behind any firewall and sshd version > is 4.0. > > I've done a lot search on the web and have not found > any report of similar issues. I was hoping experts on > this mailing list can help shed some light on this > problem. Thanks. > > That is an old version.. so I am not sure much help here.. but there needs to be some info on the type of configuration, also what is the OS, etc. My off-the-wall guess is that the box gets one of the weekly very large dictionary attack during those times and may not be able to log as quickly as it wants to (depending on how the embedded libc is dealing with logging). -- Stephen J Smoogen. CSIRT/Linux System Administrator From nyet at mrv.com Thu Apr 27 14:13:53 2006 From: nyet at mrv.com (Nye Liu) Date: Wed, 26 Apr 2006 21:13:53 -0700 Subject: bug in OpenSSH_4.3p2: pam_open_session() called but not close for root users Message-ID: <20060427041353.GA28467@compile1.chatsunix.int.mrv.com> For root sessions pam_open_session is called, but not pam_close_session. sshd behavior is broken for root logins because if pam session is run from the child, close is never called due to exec: on open since use_privsep is not set, parent calls do_exec_pty(), which does not open session. then, it skips calling do_setusercontext(), so it does not open session. child calls do_setusercontext(), which opens session. on close child will not close sesion, because it exec'd the shell, and the sshd task is gone! parent will not close session, since session was not opened by parent, sshpam_session_open is not set. as root: parent process pid 205: do_exec_pty() uid 0 child process pid 208: do_setusercontext() uid 0 pid 208: radius pam open session (exec shell) parent process pid 208: radius pam close session (skipped!) BROKEN! but it does work for user logins because: on open parent does not call do_exec_pty since use_privsep is set. parent then drops privs via setusercontext, which opens session and sets sshpam_session_open. child calls setusercontext, but that does not open session because uid!=0 on close child will not close session, because it exec'd the shell, and the sshd task is gone. parent will close session, since session was opened by parent, and the sshpam_session_open flag is set. as nonroot: parent process pid 223: do_setusercontext() uid 0 pid 223: radius pam open session child process pid 224: do_setusercontext() uid 104 (exec shell) parent process pid 223: radius pam close session WORKS! One solution is to open session from do_exec_pty() and to NOT reopen session in if sshpam_session_open is set, so that in the case of the user, both the parent AND the child do not open session. Has drawback that open session is being called by parent, not child. root: parent process pid 205: do_exec_pty() uid 0 pid 205: radius pam open session child process pid 208: do_setusercontext() uid 0 pid 208: radius pam open session (skipped!) (exec shell) parent process pid 205: radius pam close session OK! another solution: "fake" set sshpam_session_open. has drawback that if child failed to open session, you'll get a close when the parent exists, but no open. root: parent process pid 205: do_exec_pty() uid 0 pid 205: set sshpam_session_open=1 child process pid 208: do_setusercontext() uid 0 pid 208: radius pam open session (exec shell) parent process pid 205: radius pam close session OK! see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=132681 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=150968 possible patch for first solution: Index: session.c =================================================================== --- session.c (revision 15) +++ session.c (working copy) @@ -394,8 +394,10 @@ session_proctitle(s); #if defined(USE_PAM) - if (options.use_pam && !use_privsep) + if (options.use_pam && !use_privsep) { + do_pam_session(); do_pam_setcred(1); + } #endif /* USE_PAM */ /* Fork the child. */ @@ -531,8 +533,10 @@ #if defined(USE_PAM) if (options.use_pam) { do_pam_set_tty(s->tty); - if (!use_privsep) + if (!use_privsep) { + do_pam_session(); do_pam_setcred(1); + } } #endif Index: auth-pam.c =================================================================== --- auth-pam.c (revision 15) +++ auth-pam.c (working copy) @@ -996,6 +996,8 @@ void do_pam_session(void) { + if(sshpam_session_open) return; + debug3("PAM: opening session"); sshpam_err = pam_set_item(sshpam_handle, PAM_CONV, (const void *)&store_conv); -- Nye Liu nliu at mrv.com (818) 772-6235x248 (818) 772-0576 fax "Who would be stupid enough to quote a fictitious character?" -- Don Quixote