From n3rd at Safe-mail.net Sat Sep 1 01:50:40 2012 From: n3rd at Safe-mail.net (n3rd at Safe-mail.net) Date: Fri, 31 Aug 2012 20:50:40 +0500 Subject: Reload key with more 'strict' options without password Message-ID: Excuse me for lame question.. Imagine you load some private key with ssh-add with no options, so it could be used forever. And after some time you decide to reload it with more 'restrictive' options, like '-t' or '-c'. Why ask password again? If it's the same key (with the same fingerprint).. From djm at mindrot.org Sat Sep 1 07:55:04 2012 From: djm at mindrot.org (Damien Miller) Date: Sat, 1 Sep 2012 07:55:04 +1000 (EST) Subject: Reload key with more 'strict' options without password In-Reply-To: References: Message-ID: On Fri, 31 Aug 2012, n3rd at Safe-mail.net wrote: > Excuse me for lame question.. > > Imagine you load some private key with ssh-add with no options, so it > could be used forever. And after some time you decide to reload it > with more 'restrictive' options, like '-t' or '-c'. Why ask password > again? If it's the same key (with the same fingerprint).. There is no ssh-agent protocol message to express "update this already- loaded key's contraints only". -d From calestyo at scientia.net Sat Sep 1 23:43:06 2012 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sat, 01 Sep 2012 15:43:06 +0200 Subject: Patch to allow glob patterns as authorized keys file names In-Reply-To: References: Message-ID: <1346506986.3386.2.camel@fermat.scientia.net> Hey. Great. Is this going to be merged upstream? Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5450 bytes Desc: not available URL: From Lars.Nordin at SDlabs.se Mon Sep 10 04:54:26 2012 From: Lars.Nordin at SDlabs.se (Lars Nordin) Date: Sun, 09 Sep 2012 20:54:26 +0200 Subject: Patch for ssh-keygen to allow conversion of public key to openssh format Message-ID: <504CE5E2.2040602@SDlabs.se> Hi, I needed to convert a public RSA key to autorized_keys format and found ssh-keygen lacking this feature. I made the option -Q publicfile to allow an conversion like ssh-keygen -Q pubrsa.pem -y The patch is produced using unified diff and made on latest release. If you like it and can make a patch for the man-page also! Regards, /Lars -------------- next part -------------- diff -u openssh-6.1p1/authfile.c openssh-6.1p1-lano/authfile.c --- openssh-6.1p1/authfile.c 2012-02-10 22:19:02.000000000 +0100 +++ openssh-6.1p1-lano/authfile.c 2012-09-08 11:59:08.000000000 +0200 @@ -792,6 +792,58 @@ return 0; } +Key * +key_load_public_pem(char *filename, char **commentp) +{ + FILE *fp = NULL; + EVP_PKEY *pk = NULL; + X509 *x = NULL; + Key *pub = NULL; + char *name = ""; + + fp = fopen(filename, "r"); + if (fp == NULL) { + error("fopen of %s failed: %s", filename, strerror(errno)); + return NULL; + } + x = PEM_read_X509(fp, NULL, NULL, NULL); + if (x == NULL) { + debug3("Not X509 format, try public key format"); + rewind(fp); + pk = PEM_read_PUBKEY(fp, NULL, NULL, NULL); + } else { + pk = X509_get_pubkey(x); + } + if (pk == NULL) { + debug("PEM_read_PUBKEY() file %s failed", filename); + debug3("%s", ERR_error_string(ERR_get_error(), NULL)); + if (x != NULL) + X509_free(x); + return NULL; + } else { + pub = key_new(KEY_UNSPEC); + pub->rsa = RSAPublicKey_dup(EVP_PKEY_get1_RSA(pk)); + pub->type = KEY_RSA; + name = "rsa w/o comment"; +#ifdef DEBUG_PK + RSA_print_fp(stderr, prv->rsa, 8); +#endif + } + + fclose(fp); + + if (pk != NULL) + EVP_PKEY_free(pk); + if (x != NULL) + X509_free(x); + + if (pub != NULL && commentp) + *commentp = xstrdup(name); + debug("read PEM public key done: type %s", + pub ? key_type(pub) : ""); + return pub; +} + /* load public key from ssh v1 private or any pubkey file */ Key * key_load_public(const char *filename, char **commentp) @@ -799,6 +851,11 @@ Key *pub; char file[MAXPATHLEN]; + /* try PEM public */ + pub = key_load_public_pem(filename, commentp); + if (pub != NULL) + return pub; + /* try rsa1 private key */ pub = key_load_public_type(KEY_RSA1, filename, commentp); if (pub != NULL) diff -u openssh-6.1p1/config.status openssh-6.1p1-lano/config.status --- openssh-6.1p1/config.status 2012-09-07 11:01:15.000000000 +0200 +++ openssh-6.1p1-lano/config.status 2012-09-08 11:59:38.000000000 +0200 @@ -445,7 +445,7 @@ This config.status script is free software; the Free Software Foundation gives unlimited permission to copy, distribute and modify it." -ac_pwd='/work/src/openssh-6.1p1' +ac_pwd='/work/src/openssh-6.1p1-lano' srcdir='.' INSTALL='/usr/bin/install -c' AWK='gawk' Common subdirectories: openssh-6.1p1/contrib and openssh-6.1p1-lano/contrib Common subdirectories: openssh-6.1p1/openbsd-compat and openssh-6.1p1-lano/openbsd-compat Common subdirectories: openssh-6.1p1/regress and openssh-6.1p1-lano/regress Common subdirectories: openssh-6.1p1/scard and openssh-6.1p1-lano/scard diff -u openssh-6.1p1/ssh-keygen.c openssh-6.1p1-lano/ssh-keygen.c --- openssh-6.1p1/ssh-keygen.c 2012-07-31 04:20:44.000000000 +0200 +++ openssh-6.1p1-lano/ssh-keygen.c 2012-09-07 09:26:01.000000000 +0200 @@ -141,6 +141,7 @@ } convert_format = FMT_RFC4716; int print_public = 0; int print_generic = 0; +int read_public_only = 0; char *key_type_name = NULL; @@ -240,6 +241,13 @@ char *pass; Key *prv; + if (read_public_only) { + Key *pub; + + pub = key_load_public(filename, NULL); + return pub; + } + prv = key_load_private(filename, "", NULL); if (prv == NULL) { if (identity_passphrase) @@ -705,7 +713,13 @@ perror(identity_file); exit(1); } - prv = load_identity(identity_file); + + if (read_public_only == 1) { + prv = key_load_public(identity_file, NULL); + } else { + prv = load_identity(identity_file); + } + if (prv == NULL) { fprintf(stderr, "load failed\n"); exit(1); @@ -1963,7 +1977,7 @@ } while ((opt = getopt(argc, argv, "AegiqpclBHLhvxXyF:b:f:t:D:I:J:j:K:P:" - "m:N:n:O:C:r:g:R:T:G:M:S:s:a:V:W:z")) != -1) { + "m:N:n:O:C:r:g:R:T:G:M:S:s:a:V:W:zQ:")) != -1) { switch (opt) { case 'A': gen_all_hostkeys = 1; @@ -2129,6 +2143,14 @@ if (BN_hex2bn(&start, optarg) == 0) fatal("Invalid start point."); break; + case 'Q': + if (strlcpy(identity_file, optarg, sizeof(identity_file)) >= + sizeof(identity_file)) + fatal("Identity filename too long"); + have_identity = 1; + print_public = 1; + read_public_only = 1; + break; case 'V': parse_cert_times(optarg); break; From djm at mindrot.org Mon Sep 10 13:36:59 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 10 Sep 2012 13:36:59 +1000 (EST) Subject: Patch for ssh-keygen to allow conversion of public key to openssh format In-Reply-To: <504CE5E2.2040602@SDlabs.se> References: <504CE5E2.2040602@SDlabs.se> Message-ID: On Sun, 9 Sep 2012, Lars Nordin wrote: > Hi, > > I needed to convert a public RSA key to autorized_keys format and found > ssh-keygen lacking this feature. > > I made the option -Q publicfile to allow an conversion like > ssh-keygen -Q pubrsa.pem -y > > The patch is produced using unified diff and made on latest release. I think you can do this already: [djm at fuyu ~]$ openssl genrsa 1024 > /tmp/k.key Generating RSA private key, 1024 bit long modulus ..........................++++++ ............................................++++++ e is 65537 (0x10001) [djm at fuyu ~]$ openssl rsa -pubout < /tmp/k.key > /tmp/k.pub writing RSA key [djm at fuyu ~]$ cat /tmp/k.pub -----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCU7vN7q9f9bHiAYdxvyyGAwGgS LmVxczjf8V+YArEIcAuv8hHR4PkvXS4oWBJyUlNbRxr419NLAVcHmo1Pdnnxqan+ p2HO5n16Syy9eKtJ2/SKYjJlTDh9EdR3Xr2uDYziDcpT30EIhUn9soAX21lILaxo RFmlsTOOnXFwf9PweQIDAQAB -----END PUBLIC KEY----- [djm at fuyu ~]$ ssh-keygen -i -f /tmp/k.pub -m pkcs8 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCU7vN7q9f9bHiAYdxvyyGAwGgSLmVxczjf8V+YArEIcAuv8hHR4PkvXS4oWBJyUlNbRxr419NLAVcHmo1Pdnnxqan+p2HO5n16Syy9eKtJ2/SKYjJlTDh9EdR3Xr2uDYziDcpT30EIhUn9soAX21lILaxoRFmlsTOOnXFwf9PweQ== -d From Lars.Nordin at SDlabs.se Mon Sep 10 15:23:48 2012 From: Lars.Nordin at SDlabs.se (Lars Nordin) Date: Mon, 10 Sep 2012 07:23:48 +0200 Subject: Patch for ssh-keygen to allow conversion of public key to openssh format In-Reply-To: References: <504CE5E2.2040602@SDlabs.se> Message-ID: <504D7964.8020508@SDlabs.se> On 2012-09-10 05:36, Damien Miller wrote: > On Sun, 9 Sep 2012, Lars Nordin wrote: > >> Hi, >> >> I needed to convert a public RSA key to autorized_keys format and found >> ssh-keygen lacking this feature. >> >> I made the option -Q publicfile to allow an conversion like >> ssh-keygen -Q pubrsa.pem -y >> >> The patch is produced using unified diff and made on latest release. > I think you can do this already: > > [djm at fuyu ~]$ openssl genrsa 1024 > /tmp/k.key > Generating RSA private key, 1024 bit long modulus > ..........................++++++ > ............................................++++++ > e is 65537 (0x10001) > [djm at fuyu ~]$ openssl rsa -pubout < /tmp/k.key > /tmp/k.pub > writing RSA key > [djm at fuyu ~]$ cat /tmp/k.pub > -----BEGIN PUBLIC KEY----- > MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCU7vN7q9f9bHiAYdxvyyGAwGgS > LmVxczjf8V+YArEIcAuv8hHR4PkvXS4oWBJyUlNbRxr419NLAVcHmo1Pdnnxqan+ > p2HO5n16Syy9eKtJ2/SKYjJlTDh9EdR3Xr2uDYziDcpT30EIhUn9soAX21lILaxo > RFmlsTOOnXFwf9PweQIDAQAB > -----END PUBLIC KEY----- > [djm at fuyu ~]$ ssh-keygen -i -f /tmp/k.pub -m pkcs8 > ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCU7vN7q9f9bHiAYdxvyyGAwGgSLmVxczjf8V+YArEIcAuv8hHR4PkvXS4oWBJyUlNbRxr419NLAVcHmo1Pdnnxqan+p2HO5n16Syy9eKtJ2/SKYjJlTDh9EdR3Xr2uDYziDcpT30EIhUn9soAX21lILaxoRFmlsTOOnXFwf9PweQ== > > -d > > Damien, My bad, thank you! I wrote the patch for openssh 4.7 with some other changes. In 6.1 I just patched without trying to see if the new options would work (the projekt only needed this changes, so I thought it was easy to send in an patch) Regards /Lars From yuanlei0721 at gmail.com Tue Sep 11 12:21:05 2012 From: yuanlei0721 at gmail.com (yuan lei) Date: Tue, 11 Sep 2012 02:21:05 +0000 (UTC) Subject: Invitation to connect on LinkedIn Message-ID: <543665687.586813.1347330066001.JavaMail.app@ela4-app2310.prod> LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - yuan yuan lei senior software engineer at Autodesk China Confirm that you know yuan lei: https://www.linkedin.com/e/17jf7e-h6ydj8ej-1v/isd/8588866477/uCfn7fI2/?hs=false&tok=1dcTU9G5ndF5o1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/17jf7e-h6ydj8ej-1v/T3eUPsTGk1Fx4GfYY51nUKXAQCzcqTi9U612ZbP-zwu/goo/openssh-unix-dev%40mindrot%2Eorg/20061/I2888424705_1/?hs=false&tok=1LCf5gvUHdF5o1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. From biltong at fastmail.fm Fri Sep 14 00:56:19 2012 From: biltong at fastmail.fm (Biltong) Date: Thu, 13 Sep 2012 16:56:19 +0200 Subject: RFE: EndMatch Message-ID: <1347548179.5508.140661127468433.41AAF7BD@webmail.messagingengine.com> Hi, Currently a Match block can only be ended by another Match block or an end of file. I'd like to suggest adding the keyword "EndMatch" to mark the end of a Match block. This would make tools which modify configuration files not have to worry about the location of a variable being before a Match line. This would also make for much cleaner descriptions of configuration used by tools, such as Augeas called by Puppet. -- Biltong biltong at fastmail.fm -- http://www.fastmail.fm - Same, same, but different... From dtucker at zip.com.au Fri Sep 14 09:46:16 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 14 Sep 2012 09:46:16 +1000 Subject: RFE: EndMatch In-Reply-To: <1347548179.5508.140661127468433.41AAF7BD@webmail.messagingengine.com> References: <1347548179.5508.140661127468433.41AAF7BD@webmail.messagingengine.com> Message-ID: <20120913234616.GA30012@gate.dtucker.net> On Thu, Sep 13, 2012 at 04:56:19PM +0200, Biltong wrote: > Currently a Match block can only be ended by another Match block or an > end of file. > > I'd like to suggest adding the keyword "EndMatch" to mark the end of a > Match block. Rather than adding a new keyword, it would probably be doable by extending Match to understand "Match all", which should have the semantics you want. You could end up with some configs that were pretty hard to understand, though. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Sep 14 10:07:24 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 14 Sep 2012 10:07:24 +1000 Subject: RFE: EndMatch In-Reply-To: <20120913234616.GA30012@gate.dtucker.net> References: <1347548179.5508.140661127468433.41AAF7BD@webmail.messagingengine.com> <20120913234616.GA30012@gate.dtucker.net> Message-ID: <20120914000724.GA9321@gate.dtucker.net> On Fri, Sep 14, 2012 at 09:46:16AM +1000, Darren Tucker wrote: > On Thu, Sep 13, 2012 at 04:56:19PM +0200, Biltong wrote: > > Currently a Match block can only be ended by another Match block or an > > end of file. > > > > I'd like to suggest adding the keyword "EndMatch" to mark the end of a > > Match block. > > Rather than adding a new keyword, it would probably be doable by > extending Match to understand "Match all", which should have the > semantics you want. You could end up with some configs that were pretty > hard to understand, though. Something like this (warning: untested). Index: servconf.c =================================================================== RCS file: /home/dtucker/openssh/cvs/openssh/servconf.c,v retrieving revision 1.226 diff -u -p -r1.226 servconf.c --- servconf.c 31 Jul 2012 02:22:38 -0000 1.226 +++ servconf.c 14 Sep 2012 00:06:49 -0000 @@ -637,7 +637,18 @@ match_cfg_line(char **condition, int lin ci->address ? ci->address : "(null)", ci->laddress ? ci->laddress : "(null)", ci->lport); + if (strcasecmp(cp, "all") == 0) { + debug3("matching due to 'match all'"); + attrib = strdelim(&cp); /* consume token */ + *condition = cp; + return 1; + } + while ((attrib = strdelim(&cp)) && *attrib != '\0') { + if (strcasecmp(attrib, "all") == 0) { + error("'Match all' used with additional criteria."); + return -1; + } if ((arg = strdelim(&cp)) == NULL || *arg == '\0') { error("Missing Match criteria for %s", attrib); return -1; -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Fri Sep 14 11:32:59 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 14 Sep 2012 11:32:59 +1000 Subject: RFE: EndMatch In-Reply-To: <20120914000724.GA9321@gate.dtucker.net> References: <1347548179.5508.140661127468433.41AAF7BD@webmail.messagingengine.com> <20120913234616.GA30012@gate.dtucker.net> <20120914000724.GA9321@gate.dtucker.net> Message-ID: <20120914013259.GA13242@gate.dtucker.net> On Fri, Sep 14, 2012 at 10:07:24AM +1000, Darren Tucker wrote: > On Fri, Sep 14, 2012 at 09:46:16AM +1000, Darren Tucker wrote: > > On Thu, Sep 13, 2012 at 04:56:19PM +0200, Biltong wrote: > > > Currently a Match block can only be ended by another Match block or an > > > end of file. > > > > > > I'd like to suggest adding the keyword "EndMatch" to mark the end of a > > > Match block. > > > > Rather than adding a new keyword, it would probably be doable by > > extending Match to understand "Match all", which should have the > > semantics you want. You could end up with some configs that were pretty > > hard to understand, though. > > Something like this (warning: untested). Actually, on second thought "Match User *" will have the same semantics as my proposed "Match all". -- 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 biltong at fastmail.fm Fri Sep 14 19:18:05 2012 From: biltong at fastmail.fm (Biltong) Date: Fri, 14 Sep 2012 11:18:05 +0200 Subject: RFE: EndMatch In-Reply-To: <20120913234616.GA30012@gate.dtucker.net> References: <1347548179.5508.140661127468433.41AAF7BD@webmail.messagingengine.com> <20120913234616.GA30012@gate.dtucker.net> Message-ID: <1347614285.23240.140661127816109.6F624464@webmail.messagingengine.com> On Fri, Sep 14, 2012, at 01:46 AM, Darren Tucker wrote: > On Thu, Sep 13, 2012 at 04:56:19PM +0200, Biltong wrote: > > Currently a Match block can only be ended by another Match block or an > > end of file. > > > > I'd like to suggest adding the keyword "EndMatch" to mark the end of a > > Match block. > > Rather than adding a new keyword, it would probably be doable by > extending Match to understand "Match all", which should have the > semantics you want. You could end up with some configs that were pretty > hard to understand, though. So would this mean the default config would become part of a Match all block, and that Match blocks become nestable? -- http://www.fastmail.fm - A no graphics, no pop-ups email service From dtucker at zip.com.au Sat Sep 15 17:04:38 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 15 Sep 2012 17:04:38 +1000 Subject: RFE: EndMatch In-Reply-To: <1347614285.23240.140661127816109.6F624464@webmail.messagingengine.com> References: <1347548179.5508.140661127468433.41AAF7BD@webmail.messagingengine.com> <20120913234616.GA30012@gate.dtucker.net> <1347614285.23240.140661127816109.6F624464@webmail.messagingengine.com> Message-ID: <20120915070438.GA21293@gate.dtucker.net> On Fri, Sep 14, 2012 at 11:18:05AM +0200, Biltong wrote: > On Fri, Sep 14, 2012, at 01:46 AM, Darren Tucker wrote: > > On Thu, Sep 13, 2012 at 04:56:19PM +0200, Biltong wrote: > > > Currently a Match block can only be ended by another Match block or an > > > end of file. > > > > > > I'd like to suggest adding the keyword "EndMatch" to mark the end of a > > > Match block. > > > > Rather than adding a new keyword, it would probably be doable by > > extending Match to understand "Match all", which should have the > > semantics you want. You could end up with some configs that were pretty > > hard to understand, though. > > So would this mean the default config would become part of a Match all > block Not exactly. The config is parsed in 2 stages: non-match and match. Anything set in a Match block overrides anything sent in the non-match block. Assuming no earlier Match rule matched it, anything you put in a "Match User *" block will behave almost the same as if it had been part of the config before Match, with the exception that if the same directive is specified once before Match and once in "Match User *" the latter will take precedence. > and that Match blocks become nestable? Match blocks will probably never be nestable. It'd make them less like the ssh(1) Host keywords they were modelled on, probably require some invasive changes to implement and make the configs harder to understand. Anyway, you can do what I was suggesting with "Match User *" right now, so I don't think "Match all" is warranted. -- 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 hugh at mimosa.com Sun Sep 16 08:06:35 2012 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Sat, 15 Sep 2012 18:06:35 -0400 (EDT) Subject: ssh(1) documentation for -L and -R Message-ID: I found that the documentation for -L and -R was hard to understand. So I made some changes to try to make it clearer. I started with Revision 1.328 from http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh.1 Comments welcome. ================ ssh.1.patch ================ --- ssh.1 2012/09/15 16:08:48 1.1 +++ ssh.1 2012/09/15 20:23:35 @@ -51,13 +51,13 @@ .Op Fl F Ar configfile .Op Fl I Ar pkcs11 .Op Fl i Ar identity_file -.Op Fl L Oo Ar bind_address : Oc Ns Ar port : Ns Ar host : Ns Ar hostport +.Op Fl L Oo Ar bind_address : Oc Ns Ar localport : Ns Ar remoteaddr : Ns Ar remoteport .Op Fl l Ar login_name .Op Fl m Ar mac_spec .Op Fl O Ar ctl_cmd .Op Fl o Ar option .Op Fl p Ar port -.Op Fl R Oo Ar bind_address : Oc Ns Ar port : Ns Ar host : Ns Ar hostport +.Op Fl R Oo Ar bind_address : Oc Ns Ar remoteport : Ns Ar localaddr : Ns Ar localport .Op Fl S Ar ctl_path .Op Fl W Ar host : Ns Ar port .Op Fl w Ar local_tun Ns Op : Ns Ar remote_tun @@ -296,26 +296,37 @@ .It Fl L Xo .Sm off .Oo Ar bind_address : Oc -.Ar port : host : hostport +.Ar localport : remoteaddr : remoteport .Sm on .Xc -Specifies that the given port on the local (client) host is to be -forwarded to the given host and port on the remote side. +Specifies that the given TCP port +.Ar localport +on the local (client) host is to be +forwarded to the given +.Ar remoteaddr +and +.Ar remoteport +on the remote side. This works by allocating a socket to listen to -.Ar port +.Ar localport on the local side, optionally bound to the specified .Ar bind_address . Whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to -.Ar host +.Ar remoteaddr port -.Ar hostport +.Ar remoteport from the remote machine. +.Ar remoteaddr +is resolved on the remote machine. Port forwardings can also be specified in the configuration file. IPv6 addresses can be specified by enclosing the address in square brackets. -Only the superuser can forward privileged ports. -By default, the local port is bound in accordance with the +Only the superuser can forward a privileged +.Ar localport . +By default, the +.Ar localport +is bound in accordance with the .Cm GatewayPorts setting. However, an explicit @@ -488,23 +499,31 @@ .It Fl R Xo .Sm off .Oo Ar bind_address : Oc -.Ar port : host : hostport +.Ar remoteport : localaddr : localport .Sm on .Xc -Specifies that the given port on the remote (server) host is to be -forwarded to the given host and port on the local side. +Specifies that the given TCP port +.Ar remoteport +on the remote (server) host is to be +forwarded to the given +.Ar localaddr +and +.Ar localport +on the local side. This works by allocating a socket to listen to -.Ar port +.Ar remoteport on the remote side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to -.Ar host +.Ar localaddr port -.Ar hostport +.Ar localport from the local machine. .Pp Port forwardings can also be specified in the configuration file. -Privileged ports can be forwarded only when +A privileged +.Ar remoteport + can be forwarded only when logging in as root on the remote machine. IPv6 addresses can be specified by enclosing the address in square brackets. .Pp @@ -525,7 +544,7 @@ .Xr sshd_config 5 ) . .Pp If the -.Ar port +.Ar remoteport argument is .Ql 0 , the listen port will be dynamically allocated on the server and reported @@ -972,12 +991,12 @@ .Dq #users , nickname .Dq pinky , -using port 1234. +using port 1234/TCP. It doesn't matter which port is used, as long as it's greater than 1023 (remember, only root can open sockets on privileged ports) and doesn't conflict with any ports already in use. -The connection is forwarded to port 6667 on the remote server, +The connection is forwarded to port 6667/TCP on the remote server, since that's the standard port for IRC services. .Pp The ================ end ================ From peter at stuge.se Sun Sep 16 22:54:26 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 16 Sep 2012 14:54:26 +0200 Subject: any hope for bug 1663 or similar function? In-Reply-To: References: <20120221135650.GA74606@bewilderbeast.blackhelicopters.org> Message-ID: <20120916125426.11975.qmail@stuge.se> Filipe Fernandes wrote: > Hello All, > > I have the same problem with 150+ boxes all running OpenSSH. Although > we don't use the patch, and have to write services which modify the > authorized_keys file on all boxes. > > OpenSSH 6.1 looks like it's up for review, but as far as I can tell, > there's been no mention of the patch. > > Is there a timeline for something like this, or is it simply because > the patch is not worthy of inclusion? I think it's obvious from Damien's reply that there is strong desire to include functionality in OpenSSH which solves the problem. The general direction is also quite obvious from what he writes. Instead of talking nonsense about a timeline you should just send a perfect patch which does what Damien wants to do. It is really *that* easy. //Peter From alex at alex.org.uk Mon Sep 17 00:17:34 2012 From: alex at alex.org.uk (Alex Bligh) Date: Sun, 16 Sep 2012 15:17:34 +0100 Subject: any hope for bug 1663 or similar function? In-Reply-To: <20120916125426.11975.qmail@stuge.se> References: <20120221135650.GA74606@bewilderbeast.blackhelicopters.org> <20120916125426.11975.qmail@stuge.se> Message-ID: --On 16 September 2012 14:54:26 +0200 Peter Stuge wrote: > I think it's obvious from Damien's reply that there is strong desire > to include functionality in OpenSSH which solves the problem. The > general direction is also quite obvious from what he writes. > > Instead of talking nonsense about a timeline you should just send a > perfect patch which does what Damien wants to do. To be fair, there is a patch attached to that bug (attachment 1895 and comment 13), which I believe has not actually been reviewed yet, which doesn't fiddle with LDAP, and fixes (I think) all of Damien's concerns raised in the first comment. Bug at: https://bugzilla.mindrot.org/show_bug.cgi?id=1663 Patch at: https://bugzilla.mindrot.org/attachment.cgi?id=1896&action=diff (note: I contributed to neither the patch nor the bug). -- Alex Bligh From djm at mindrot.org Mon Sep 17 02:52:08 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Sep 2012 02:52:08 +1000 (EST) Subject: any hope for bug 1663 or similar function? In-Reply-To: References: <20120221135650.GA74606@bewilderbeast.blackhelicopters.org> <20120916125426.11975.qmail@stuge.se> Message-ID: On Sun, 16 Sep 2012, Alex Bligh wrote: > To be fair, there is a patch attached to that bug (attachment 1895 > and comment 13), which I believe has not actually been reviewed yet, > which doesn't fiddle with LDAP, and fixes (I think) all of Damien's > concerns raised in the first comment. I'm sorry it is taking so long, I had hoped to look at it earlier in the year but Real Life left me with little time to work on it. I will hopefully get a chance to look at it at the OpenBSD network hackathon that starts tomorrow. -d From calestyo at scientia.net Mon Sep 17 04:01:39 2012 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Sun, 16 Sep 2012 20:01:39 +0200 Subject: any hope for bug 1663 or similar function? In-Reply-To: References: <20120221135650.GA74606@bewilderbeast.blackhelicopters.org> <20120916125426.11975.qmail@stuge.se> Message-ID: <1347818499.3722.159.camel@fermat.scientia.net> On Mon, 2012-09-17 at 02:52 +1000, Damien Miller wrote: > I'm sorry it is taking so long, I had hoped to look at it earlier in > the year but Real Life left me with little time to work on it. I will > hopefully get a chance to look at it at the OpenBSD network hackathon > that starts tomorrow. In case you get bored after taking care on #1663,... my I advertise for #1926 and #1953 ?! ;) Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5450 bytes Desc: not available URL: From alex at alex.org.uk Mon Sep 17 04:14:41 2012 From: alex at alex.org.uk (Alex Bligh) Date: Sun, 16 Sep 2012 19:14:41 +0100 Subject: any hope for bug 1663 or similar function? In-Reply-To: References: <20120221135650.GA74606@bewilderbeast.blackhelicopters.org> <20120916125426.11975.qmail@stuge.se> Message-ID: --On 17 September 2012 02:52:08 +1000 Damien Miller wrote: >> To be fair, there is a patch attached to that bug (attachment 1895 >> and comment 13), which I believe has not actually been reviewed yet, >> which doesn't fiddle with LDAP, and fixes (I think) all of Damien's >> concerns raised in the first comment. > > I'm sorry it is taking so long, I had hoped to look at it earlier in > the year but Real Life left me with little time to work on it. I will > hopefully get a chance to look at it at the OpenBSD network hackathon > that starts tomorrow. It wasn't a nag (honestly!) - just pointing out there was already an unreviewed patch there so suggesting $OP created one was perhaps incorrect. Have fun at the hackathon. -- Alex Bligh From bert.wesarg at googlemail.com Mon Sep 17 06:23:36 2012 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Sun, 16 Sep 2012 22:23:36 +0200 Subject: ssh(1) documentation for -L and -R In-Reply-To: References: Message-ID: Hi, On Sun, Sep 16, 2012 at 12:06 AM, D. Hugh Redelmeier wrote: > I found that the documentation for -L and -R was hard to understand. > So I made some changes to try to make it clearer. I started with Revision > 1.328 from http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh.1 > > Comments welcome. I think the 'remote' in here > --L port:host:hostport > +-L localport:remoteaddr:remoteport and the 'local' in here > --R port:host:hostport > +-R remoteport:localaddr:localport is now totally misleading. It suggest that the host:port has anything to do with the corresponding side, which is not. Read this again: Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side. It states clearly, that the connection is made from the remote side to host:port. And now it reads: Specifies that the given TCP port localport on the local (client) host is to be forwarded to the given remoteaddr and remoteport on the remote side. But now, why do I need to specify 'remoteaddr', if it makes a connection to the 'remote side', because 'remoteaddr' and 'remote side' is equal, isn't it? One possible improvement, could be to use targethost:targetport for both, -L and -R. Using 'localport' in -L and 'remoteport' in -R does sounds like an improvement to me. Bert From djm at mindrot.org Mon Sep 17 07:23:42 2012 From: djm at mindrot.org (Damien Miller) Date: Mon, 17 Sep 2012 07:23:42 +1000 (EST) Subject: any hope for bug 1663 or similar function? In-Reply-To: References: <20120221135650.GA74606@bewilderbeast.blackhelicopters.org> <20120916125426.11975.qmail@stuge.se> Message-ID: On Sun, 16 Sep 2012, Alex Bligh wrote: > > > --On 17 September 2012 02:52:08 +1000 Damien Miller wrote: > > > > To be fair, there is a patch attached to that bug (attachment 1895 > > > and comment 13), which I believe has not actually been reviewed yet, > > > which doesn't fiddle with LDAP, and fixes (I think) all of Damien's > > > concerns raised in the first comment. > > > > I'm sorry it is taking so long, I had hoped to look at it earlier in > > the year but Real Life left me with little time to work on it. I will > > hopefully get a chance to look at it at the OpenBSD network hackathon > > that starts tomorrow. > > It wasn't a nag (honestly!) - just pointing out there was already an > unreviewed patch there so suggesting $OP created one was perhaps > incorrect. I've looked at the patch but haven't decided on the approach. To me the bug question is which UID to use for the helper program. I don't want to create yet another option to choose which user to run it under... My apologies for not commenting on the bug sooner. -d From peter at stuge.se Mon Sep 17 16:09:32 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 17 Sep 2012 08:09:32 +0200 Subject: ssh(1) documentation for -L and -R In-Reply-To: References: Message-ID: <20120917060932.29771.qmail@stuge.se> Bert Wesarg wrote: > totally misleading. It suggest that the host:port has anything > to do with the corresponding side, which is not. The destination in both -L and -R is only ever used on the respective side. host in -L is resolved locally, host in -R is resolved remotely. I guess this is what the patch wants to clarify. //Peter From bert.wesarg at googlemail.com Mon Sep 17 17:06:22 2012 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Mon, 17 Sep 2012 09:06:22 +0200 Subject: ssh(1) documentation for -L and -R In-Reply-To: <20120917060932.29771.qmail@stuge.se> References: <20120917060932.29771.qmail@stuge.se> Message-ID: On Mon, Sep 17, 2012 at 8:09 AM, Peter Stuge wrote: > Bert Wesarg wrote: >> totally misleading. It suggest that the host:port has anything >> to do with the corresponding side, which is not. > > The destination in both -L and -R is only ever used on the respective > side. host in -L is resolved locally, host in -R is resolved remotely. But its exactly the other way around, isn't it? Ie. in -L port:host:hostport, the host is resolved on the remote side. And the patch added exactly this to the documentation. > > I guess this is what the patch wants to clarify. I hoped I understood the intention of the patch, but the proposed new namings are misleading. And I think adding 'remote' to the host name in -L does not makes it clearer that it will be resolved on the remote size. Bert > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From peter at stuge.se Mon Sep 17 18:48:22 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 17 Sep 2012 10:48:22 +0200 Subject: ssh(1) documentation for -L and -R In-Reply-To: References: <20120917060932.29771.qmail@stuge.se> Message-ID: <20120917084822.10610.qmail@stuge.se> Bert Wesarg wrote: > >> totally misleading. It suggest that the host:port has anything > >> to do with the corresponding side, which is not. > > > > The destination in both -L and -R is only ever used on the respective > > side. host in -L is resolved locally, host in -R is resolved remotely. > > But its exactly the other way around, isn't it? Ie. in -L > port:host:hostport, the host is resolved on the remote side. Yes, sorry, you are right of course. Too early in the morning for me. > And the patch added exactly this to the documentation. Right, maybe changing only the wording and not the parameter names is a good middle road? > I think adding 'remote' to the host name in -L does not makes it > clearer that it will be resolved on the remote size. I agree with that. I think it's better to keep it called host and use prose to explain how it works. //Peter From hugh at mimosa.com Wed Sep 19 13:01:15 2012 From: hugh at mimosa.com (D. Hugh Redelmeier) Date: Tue, 18 Sep 2012 23:01:15 -0400 (EDT) Subject: ssh(1) documentation for -L and -R In-Reply-To: <20120917084822.10610.qmail@stuge.se> References: <20120917060932.29771.qmail@stuge.se> <20120917084822.10610.qmail@stuge.se> Message-ID: [Please excuse my awkward reply. I'm not used to replying on a mailing list that I'm not subscribed to.] Thanks very much for looking at my suggestions. I had avoided using SSH tunnels because I found the description opaque. But this last week, I broke down and decided I really needed to use them. Once I'd figured them out, they were easy, and I thought I could improve ssh(1)'s description. Why should you listen to me? Because I'm sort of new at this and don't come in already understanding what the documentation says: fresh eyes. Why you should not listen to me? I'm not an SSH guru. So: my short email was a "solution" but you should perhaps listen to my problems and come up with better solutions. | From: bert.wesarg at googlemail.com (Bert Wesarg) | | On Sun, Sep 16, 2012 at 12:06 AM, D. Hugh Redelmeier wrote: | > I found that the documentation for -L and -R was hard to understand. | > So I made some changes to try to make it clearer. I started with Revision | > 1.328 from http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh.1 | > | > Comments welcome. | | I think the 'remote' in here | | > --L port:host:hostport | > +-L localport:remoteaddr:remoteport | | and the 'local' in here | | > --R port:host:hostport | > +-R remoteport:localaddr:localport | | is now totally misleading. It suggest that the host:port has anything | to do with the corresponding side, which is not. I don't understand what you are saying. What is host:port? I don't see that literally anywhere. | Read this again: | | Specifies that the given port on the local (client) host is to be | forwarded to the given host and port on the remote side. "given port" ought to be "given _port_" to link it to the synopsis. "given host and port" ought to be "given _host_ and _hostport_" for the same reason. Otherwise the reader cannot easily know what is being referenced. The word "given" is rather weak and confusing (even so, I kept it out of conservatism). | It states clearly, that the connection is made from the remote side to | host:port. And now it reads: | | Specifies that the given TCP port localport on the local (client) | host is to be | forwarded to the given remoteaddr and remoteport on the remote side. Please: the underscores/italics matter in linking the prose to the synopsis. | But now, why do I need to specify 'remoteaddr', if it makes a | connection to the 'remote side', because 'remoteaddr' and 'remote | side' is equal, isn't it? You are right that the terse terminology is still somewhat ambiguous. I meant "address on the remote side", not "address of the remote side". If the prose does not make that clear, that is a weakness that I did not introduce. Would you prefer _portonremote_ or _port_on_remote_ to _remoteport_? | One possible improvement, could be to use targethost:targetport for | both, -L and -R. I think that "target" is a fine word. What I was trying to do was make the visual representation (synopsis) communicate a very important feature: the host and port are from the "point of view" of the remote system. Of course it is important to have it in the text, but the diagram is what people look at to remember the structure. So it must have the important conceptual information (and still be compact). So what is the important stuff that I missed when I first read ssh(1)? - The only mention that port forwarding only applied to TCP was a passing reference in the last sentence of the first paragraph, far from the description of -L and -R. [So I sprinkled "TCP" once in the description of -L and once in the description of -R] - in my testing, I wanted the remotehost (my term) to be 127.0.0.1. I thought that saying "localhost" would be better than either leaving it blank or using 127.0.0.1. But on my local machine I needed to use "localhost4" to be unambiguous. This was a disaster because the remote machine (which resolved remotehost) had never heard of localhost4, tried to resolve it, failed, and generated a totally useless/misleading/unclear diagnostic on my (local) end: channel 3: open failed: administratively prohibited: open failed I went off on a wild-goose chase thinking the problem was that the remoteport was privileged (it was privileged, but that's not a problem). The best fix would be a better diagnostic, but I didn't have the time to dive into the code to figure out how to do that (for all I know, it might take a protocol change!). Instead, I thought that clarifying where it gets resolved would at least help and be very appropriate for a manpage. - I was surprised to find that the local packet could be IPv6 and the packet on the other side of the tunnel could be IPv4. At least that seemed to be the case. I didn't do enough testing to be sure but if so, the full generality of this neat feature should be documented. Because I wasn't sure, I didn't document it. - the -L synopsis was: -L [bind_address:]port:host:hostport In the prose, the "_port_" value was referenced in "the given port on the local (client) host", "port on the local side", "this port", "local port", and "listening port", and "the port". Surely these should be "_port_" to link each reference more clearly to the synopsis and each other. Also in the prose, "port on the remote side", and "host port _hostport_" refer to _hostport_. + Surely all ports are on hosts, so "_hostport_" isn't a very good name. I thought "_remoteport_" would be more descriptive. It is a small leap to change "port" to "localport". + it more clearly distinguishes it from "hostport" + the synopsis communicates more topological information + the generality of "port" is narrowed appropriately. - in that same synopsis, "host" is also a too-general word: there are potentially several hosts involved: the client host, the server host, the host from which the original packet originated (it might not be the client), and the "target" host where the packet goes from the server. All these hosts might not be distinct, but they could be. What is good nomenclature for these hosts? Perhaps we don't need to name all of them. I used local and remote for the SSH client and SSH server machines, following the existing pattern. Certainly the bare word "host" is too ambiguous for good exposition. Perhaps "target" is good for the ultimate target of the packets. Some of this is on thin ice since TCP connections are bidirectional. - "bind_address" is a bit odd. I don't have an immediate suggestion for improvement. "localhost"? Oops: that's a well-known-name that isn't general enough. That's why I used "localaddr" in -R instead of "localhost" so symmetry drove the decision to use "remoteaddr" in -L. PERHAPS -L's "bind_address" could be renamed "localaddr" and -R's "bind_address" could be renamed "remoteaddr" | Using 'localport' in -L and 'remoteport' in -R does sounds like an | improvement to me. Good! | From: peter at stuge.se (Peter Stuge) | Bert Wesarg wrote: | > totally misleading. It suggest that the host:port has anything | > to do with the corresponding side, which is not. | | The destination in both -L and -R is only ever used on the respective | side. host in -L is resolved locally, host in -R is resolved remotely. Quite true (when reversed) and important and possibly not obvious (I didn't get it at first). | I guess this is what the patch wants to clarify. It is part of what I was trying to clarify. | From: bert.wesarg at googlemail.com (Bert Wesarg) | | On Mon, Sep 17, 2012 at 8:09 AM, Peter Stuge wrote: | > I guess this is what the patch wants to clarify. | | I hoped I understood the intention of the patch, but the proposed new | namings are misleading. And I think adding 'remote' to the host name | in -L does not makes it clearer that it will be resolved on the remote | size. I agree: that wasn't my main purpose in the naming. It was to point out that the remoteaddr and remoteport were interpreted and used on the remote site, with all the corresponding implications. Similarly, localport | From: peter at stuge.se (Peter Stuge) | Bert Wesarg wrote: | Right, maybe changing only the wording and not the parameter names is | a good middle road? I still think that some improvement to the synopsis naming is possible. I'm not adamant about my choices. | > I think adding 'remote' to the host name in -L does not makes it | > clearer that it will be resolved on the remote size. | | I agree with that. I think it's better to keep it called host and use | prose to explain how it works. As argued above, resolution is not the only issue. And "host" is way too ambiguous given that up to four hosts are involved. From THaller at sefcu.com Fri Sep 21 01:42:36 2012 From: THaller at sefcu.com (Ty Haller) Date: Thu, 20 Sep 2012 11:42:36 -0400 Subject: AIX 5.8p1? Message-ID: <00F7B9EB9E2A714388C163A5DF51B341140E46946D@sefexchmh.sefcu.com> Good Morning, We just performed some security scanning on one of our AIX systems and these vulnerabilities was returned: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4755 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5000 We are currently running: 5.8.0.6101 The latest on IBMs Website is 5.8p1 (5.8.0.6202), does this address the above vulnerabilities? I'm having trouble locating change logs between these two versions. IBMs readme for 5.8p1 does not mention these CVEs. Thanks, Ty Haller | Lead Administrator - System Services | SEFCU | thaller at sefcu.com 700 Patroon Creek Blvd. Albany, NY 12206 | Phone: 518-464-5210 | Fax: 518-464-5209 This message may contain confidential information and is intended for the sole purpose of communication with the addressee. Dissemination or publication in any format is strictly prohibited. If you have received this communication in error please notify SEFCU immediately. Help save a tree. Please print this e-mail only if it is truly necessary. Thank you. From THaller at sefcu.com Fri Sep 21 02:20:15 2012 From: THaller at sefcu.com (Ty Haller) Date: Thu, 20 Sep 2012 12:20:15 -0400 Subject: AIX 5.8p1? In-Reply-To: <00F7B9EB9E2A714388C163A5DF51B341140E46946D@sefexchmh.sefcu.com> References: <00F7B9EB9E2A714388C163A5DF51B341140E46946D@sefexchmh.sefcu.com> Message-ID: <00F7B9EB9E2A714388C163A5DF51B341140E469470@sefexchmh.sefcu.com> I just realized that I sent the message as HTML, and that is frowned upon. Here is the non-html. Thanks, Ty Haller SEFCU Lead Administrator - System Services thaller at sefcu.com From: Ty Haller Sent: Thursday, September 20, 2012 11:43 AM To: 'openssh-unix-dev at mindrot.org' Subject: AIX 5.8p1? Good Morning, We just performed some security scanning on one of our AIX systems and these vulnerabilities was returned: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4755 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-5000 We are currently running: 5.8.0.6101 The latest on IBMs Website is 5.8p1 (5.8.0.6202), does this address the above vulnerabilities? I'm having trouble locating change logs between these two versions. IBMs readme for 5.8p1 does not mention these CVEs. https://www6.software.ibm.com/sdfdl/2v2/regs2/sihourn/openssh/Xa.2/Xb.YpX6IhcfCLTVpsjWMhdhZIbI9rXXMpck6RkO-ayBjQ/Xc.openssh/Readme_5.8.0.6102.txt/Xd./Xf.LPr.AAvi/Xg.6692599/Xi.aixbp/XY.regsrvs/XZ.4gNj28KKlrh5yUcStvOhzTVtLmI/Readme_5.8.0.6102.txt Thanks, Ty Haller | Lead Administrator - System Services | SEFCU | thaller at sefcu.com 700 Patroon Creek Blvd. Albany, NY 12206 | Phone: 518-464-5210 | Fax: 518-464-5209 This message may contain confidential information and is intended for the sole purpose of communication with the addressee. Dissemination or publication in any format is strictly prohibited. If you have received this communication in error please notify SEFCU immediately. Help save a tree. Please print this e-mail only if it is truly necessary. Thank you. From dtucker at zip.com.au Fri Sep 21 11:53:25 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 21 Sep 2012 11:53:25 +1000 Subject: AIX 5.8p1? In-Reply-To: <00F7B9EB9E2A714388C163A5DF51B341140E469470@sefexchmh.sefcu.com> References: <00F7B9EB9E2A714388C163A5DF51B341140E46946D@sefexchmh.sefcu.com> <00F7B9EB9E2A714388C163A5DF51B341140E469470@sefexchmh.sefcu.com> Message-ID: <20120921015325.GA5976@gate.dtucker.net> On Thu, Sep 20, 2012 at 12:20:15PM -0400, Ty Haller wrote: [...] > The latest on IBMs Website is 5.8p1 (5.8.0.6202), does this address the > above vulnerabilities? I'm having trouble locating change logs between > these two versions. If you want to know what's in IBM's binary packages then you really need to ask IBM. They used to publish some sources at http://openssh-aix.sourceforge.net/ but the versions there are a couple of years old (and may or may not correspond to what they shipped). -- 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 THaller at sefcu.com Fri Sep 21 13:14:16 2012 From: THaller at sefcu.com (Ty Haller) Date: Thu, 20 Sep 2012 23:14:16 -0400 Subject: AIX 5.8p1? In-Reply-To: <20120921015325.GA5976@gate.dtucker.net> References: <00F7B9EB9E2A714388C163A5DF51B341140E46946D@sefexchmh.sefcu.com> <00F7B9EB9E2A714388C163A5DF51B341140E469470@sefexchmh.sefcu.com> <20120921015325.GA5976@gate.dtucker.net> Message-ID: I will contact them. However it seems that IBM just publishes binaries built from the regular OpenSSH sources. They list their latest version as being built with OpenSSH 5.8p1. My question is does version 5.8p1 address the mentioned vulnerabilities? I would expect those kinds of fixes to come straight from OpenSSH. Thanks, Ty Haller SEFCU Lead Administrator System Services THaller at sefcu.com (518)-464-5210 700 Patroon Creek Blvd. Albany, NY 12206 On Sep 20, 2012, at 9:53 PM, "Darren Tucker" > wrote: 5.8p1 This message may contain confidential information and is intended for the sole purpose of communication with the addressee. Dissemination or publication in any format is strictly prohibited. If you have received this communication in error please notify SEFCU immediately. Help save a tree. Please print this e-mail only if it is truly necessary. Thank you. From dtucker at zip.com.au Fri Sep 21 14:22:17 2012 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 21 Sep 2012 14:22:17 +1000 Subject: AIX 5.8p1? In-Reply-To: References: <00F7B9EB9E2A714388C163A5DF51B341140E46946D@sefexchmh.sefcu.com> <00F7B9EB9E2A714388C163A5DF51B341140E469470@sefexchmh.sefcu.com> <20120921015325.GA5976@gate.dtucker.net> Message-ID: <20120921042217.GA8201@gate.dtucker.net> On Thu, Sep 20, 2012 at 11:14:16PM -0400, Ty Haller wrote: > I will contact them. > > However it seems that IBM just publishes binaries built from the regular > OpenSSH sources. I can't speak to what they currently do, however in the past they did modify the code. > They list their latest version as being built with OpenSSH 5.8p1. My > question is does version 5.8p1 address the mentioned vulnerabilities? For the stock 5.8p1, no. The fix for CVE-2011-5000 first appeared in 5.9p1 http://anoncvs.mindrot.org/index.cgi/openssh/gss-serv.c?r1=1.24&r2=1.25 CVE-2010-4755 only lets a client DoS itself: http://lists.mindrot.org/pipermail/openssh-unix-dev/2011-March/029429.html > I would expect those kinds of fixes to come straight from OpenSSH. Vendors often backport security fixes without bumping the major version. -- 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 seth at juniper.net Fri Sep 21 15:07:55 2012 From: seth at juniper.net (Seth Ross) Date: Thu, 20 Sep 2012 22:07:55 -0700 Subject: AIX 5.8p1? In-Reply-To: <20120921042217.GA8201@gate.dtucker.net> Message-ID: On 9/20/12 9:22 PM, "Darren Tucker" wrote: >Vendors often backport security fixes without bumping the major version. True. ~S. From kevin.brott at gmail.com Sun Sep 23 02:32:29 2012 From: kevin.brott at gmail.com (Kevin Brott) Date: Sat, 22 Sep 2012 09:32:29 -0700 Subject: AIX 5.8p1? In-Reply-To: <20120921042217.GA8201@gate.dtucker.net> References: <00F7B9EB9E2A714388C163A5DF51B341140E46946D@sefexchmh.sefcu.com> <00F7B9EB9E2A714388C163A5DF51B341140E469470@sefexchmh.sefcu.com> <20120921015325.GA5976@gate.dtucker.net> <20120921042217.GA8201@gate.dtucker.net> Message-ID: <505DE81D.7050200@gmail.com> On 2012-09-20 21:22, Darren Tucker wrote: > On Thu, Sep 20, 2012 at 11:14:16PM -0400, Ty Haller wrote: >> I will contact them. >> >> However it seems that IBM just publishes binaries built from the regular >> OpenSSH sources. > I can't speak to what they currently do, however in the past they did > modify the code. IBM routinely "waits for releases to become stable", so they're typically at least a couple revs behind at any given time. You'd think they'd apply any available patches at build time, but I've seen no evidence of it at this end after their three 5.0p1 releases. The one 5.8 bundle they've released behaves like a stock 5.8p1 build (so far - haven't done a full vuln test on it, just finished doing all the 6.1 builds). Vendor slow release cycles, and the question of back-ported patches are the major reasons I've been building update packages from source for internal distribution at work - to try and stay ahead of corporate "vulnerability scanners" that determine system vulnerabilities purely on the basis of a version string at connect. Red Hat are you listening? >> They list their latest version as being built with OpenSSH 5.8p1. My >> question is does version 5.8p1 address the mentioned vulnerabilities? > For the stock 5.8p1, no. > > The fix for CVE-2011-5000 first appeared in 5.9p1 > http://anoncvs.mindrot.org/index.cgi/openssh/gss-serv.c?r1=1.24&r2=1.25 > > CVE-2010-4755 only lets a client DoS itself: > http://lists.mindrot.org/pipermail/openssh-unix-dev/2011-March/029429.html The IBM release of 5.8 appears to be vulnerable to both of these (assuming I tested and understood the results correctly). If IBM's histrorical release cycles are used as a gauge (anywhere from 6-10 months after every other source releases; e.g. 5.0, 5.2, 5.4, 5.6, 5.8) - the next SSH bundle will be 6.0, and won't probably release any sooner than the end of this year. I'd say it's either time to build from source, or get IBM to commit to a relase date (HA!) if you're looking to address a security audit finding. >> I would expect those kinds of fixes to come straight from OpenSSH. > Vendors often backport security fixes without bumping the major version. > Red Hat is notorious for this, IBM has historically been pretty good about their SSH/SSL bundles - the versioning of those patckages matches consistantly with the documented binary heaviours. From balu9463 at gmail.com Tue Sep 25 21:12:38 2012 From: balu9463 at gmail.com (balu chandra) Date: Tue, 25 Sep 2012 16:42:38 +0530 Subject: OpenSSH banner doesnot display multibyte characters like korean Message-ID: Hello, The banner message displayed on the screen contain octal values instead of korean chars. Prior to ssh 5.1 the banner message would display the charaters properly. I understand that starting from 5.1 the message is passed through strnvis() function. I looked into documentation on strnvis and found that it does not support multibyte chars and doesnt work well with international chars. Could you please share any workaround to display international chars like korean in banner message. I also found little information inthe changelog on why strnvis() was introduced in input_userauth_banner. Is it added to address any security vulnerability. Any information on this is appreciated. Regards, Bala From maillist-openssh at barfooze.de Fri Sep 28 22:26:50 2012 From: maillist-openssh at barfooze.de (John Spencer) Date: Fri, 28 Sep 2012 14:26:50 +0200 Subject: incorrect configure test for "whether snprintf correctly terminates long strings" Message-ID: <5065978A.40700@barfooze.de> checking whether snprintf correctly terminates long strings... no configure: WARNING: ****** Your snprintf() function is broken, complain to your vendor configure:10176: checking whether snprintf correctly terminates long strings conftest.c:181:2: error: implicit declaration of function 'exit' the test (and others) use exit without including this is a list of other such errors (misdetection of features due to sloppy tests depending on implicit declarations to succeed): configure:8862: checking whether struct dirent allocates space for d_name conftest.c:88:2: error: implicit declaration of function 'exit' configure:9899: checking if setresuid seems to work conftest.c:164:2: error: implicit declaration of function 'setresuid' configure:9954: checking if setresgid seems to work conftest.c:166:2: error: implicit declaration of function 'setresgid' configure:10345: checking for (overly) strict mkstemp conftest.c:187:2: error: implicit declaration of function 'unlink' configure:13142: checking for struct timespec configure:13142: result: yes configure:13194: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-com$ conftest.c:226:1: warning: return type defaults to 'int' conftest.c: In function 'main': conftest.c:237:2: warning: format '%lld' expects type 'long long int', but argument 4 has type 'long int' conftest.c:239:3: error: implicit declaration of function 'exit' conftest.c:239:3: warning: incompatible implicit declaration of built-in function 'exit' configure:15597: checking Discovering system mail directory conftest.c:265:3: error: implicit declaration of function 'exit' configure:15959: checking for "/etc/default/login" conftest.c:274:3: error: implicit declaration of function 'exit' From seb.ssh at koocotte.org Sun Sep 30 06:24:43 2012 From: seb.ssh at koocotte.org (Sebastien Koechlin) Date: Sat, 29 Sep 2012 22:24:43 +0200 Subject: Restrict extranet connection to a group Message-ID: <20120929202443.GJ6197@koocotte.org> Hello, I have a question about sshd and I'm unable to find an answer, I checked the man page, the FAQ, the archives of the mailing list without success. I'm in a small organization with a single server (Stable Linux Debian). It's connected to two networks: local-network and internet. >From the local network, everybody is allowed to do SSH (sftp in fact) but I want to restrict SSH connection coming from Internet to a group of users (this group is named ssh, users within this group should be the only ones allowed to connect from Internet). I tried to deny any login method to users not on the local network and not in the ssh group by writing into /etc/ssh/sshd_config the following section: Match Address !192.168.0.0/16 Group !ssh KbdInteractiveAuthentication no KerberosAuthentication no PasswordAuthentication no PubkeyAuthentication no RSAAuthentication no But it does not work: I can login with password using a user not in the ssh group. I am doing it wrong? Why it doesn't work as expected? Is it possible? Thanks, -- Sebastien Koechlin From peter at stuge.se Sun Sep 30 07:25:44 2012 From: peter at stuge.se (Peter Stuge) Date: Sat, 29 Sep 2012 23:25:44 +0200 Subject: Restrict extranet connection to a group In-Reply-To: <20120929202443.GJ6197@koocotte.org> References: <20120929202443.GJ6197@koocotte.org> Message-ID: <20120929212544.21733.qmail@stuge.se> Sebastien Koechlin wrote: > Why it doesn't work as expected? I don't think sshd can know the groups until after authentication. Hence, group matching happens after authentication, at which point it doesn't matter that you forbid some authentication types. Doing it the other way around doesn't help. But I would recommend that you reverse the logic in sshd_config anyway. Global config everything disallowed. Match local network allow pubkey auth. I don't allow password or challenge+response (kbdint). Then try matching on the users, rather than group, and allow pubkey auth in that match block too. //Peter