From jhawk at MIT.EDU Sat Jun 1 00:58:56 2013 From: jhawk at MIT.EDU (John Hawkinson) Date: Fri, 31 May 2013 10:58:56 -0400 Subject: Patch to discourage unencrypted key generation In-Reply-To: <5B00EEF4-A27B-4D1B-B7F0-C1F2524E32AF@gmail.com> References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> <20130530171546.GC24674@ringworld.MIT.EDU> <5B00EEF4-A27B-4D1B-B7F0-C1F2524E32AF@gmail.com> Message-ID: <20130531145856.GU24674@ringworld.MIT.EDU> Nico Kadel-Garcia wrote on Fri, 31 May 2013 at 09:40:31 -0400 in <5B00EEF4-A27B-4D1B-B7F0-C1F2524E32AF at gmail.com>: > Generating host keys, which are normally passphrase free and done by > root. That can be written into the init script, where such keys are > usually generated, and complex test cases avoided. This just isn't compelling. It is BAD PRACTICE to have root behave differently from other users. It should only be used in extreme cases. (I asked the question, kind of hoping there was some stronger justification). It promotes confusion when software behaves differently when run under different UIDs. It also does nothing to repair the bad habits some users may have while running as root (oh boy). And there are legit needs to generate keypairs as non-root users. Non-root users should be able to generate keypairs without human interaction, too, if root users do. They also have automation requirements. Please drop the root check and make it a simple command-line check. --jhawk at mit.edu John Hawkinson From alex at alex.org.uk Sat Jun 1 01:41:53 2013 From: alex at alex.org.uk (Alex Bligh) Date: Fri, 31 May 2013 16:41:53 +0100 Subject: Patch to discourage unencrypted key generation In-Reply-To: <20130531145856.GU24674@ringworld.MIT.EDU> References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> <20130530171546.GC24674@ringworld.MIT.EDU> <5B00EEF4-A27B-4D1B-B7F0-C1F2524E32AF@gmail.com> <20130531145856.GU24674@ringworld.MIT.EDU> Message-ID: <25BCBFD2-791A-4B1E-9182-A87FD75B8BAD@alex.org.uk> On 31 May 2013, at 15:58, John Hawkinson wrote: > Please drop the root check and make it a simple command-line check. Would isatty(0) be reasonable to determine whether prompting should be used? -- Alex Bligh From jhawk at MIT.EDU Sat Jun 1 01:46:59 2013 From: jhawk at MIT.EDU (John Hawkinson) Date: Fri, 31 May 2013 11:46:59 -0400 Subject: Patch to discourage unencrypted key generation In-Reply-To: <25BCBFD2-791A-4B1E-9182-A87FD75B8BAD@alex.org.uk> References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> <20130530171546.GC24674@ringworld.MIT.EDU> <5B00EEF4-A27B-4D1B-B7F0-C1F2524E32AF@gmail.com> <20130531145856.GU24674@ringworld.MIT.EDU> <25BCBFD2-791A-4B1E-9182-A87FD75B8BAD@alex.org.uk> Message-ID: <20130531154659.GV24674@ringworld.MIT.EDU> Alex Bligh wrote on Fri, 31 May 2013 at 16:41:53 +0100 in <25BCBFD2-791A-4B1E-9182-A87FD75B8BAD at alex.org.uk>: > Would isatty(0) be reasonable to determine whether prompting should be used? I don't think so. This just makes it hard to debug scripts and hard to write them. This kind of "trickery" causes more trouble than it solves. --jhawk at mit.edu John Hawkinson From alex at alex.org.uk Sat Jun 1 02:23:36 2013 From: alex at alex.org.uk (Alex Bligh) Date: Fri, 31 May 2013 17:23:36 +0100 Subject: Patch to discourage unencrypted key generation In-Reply-To: <20130531154659.GV24674@ringworld.MIT.EDU> References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> <20130530171546.GC24674@ringworld.MIT.EDU> <5B00EEF4-A27B-4D1B-B7F0-C1F2524E32AF@gmail.com> <20130531145856.GU24674@ringworld.MIT.EDU> <25BCBFD2-791A-4B1E-9182-A87FD75B8BAD@alex.org.uk> <20130531154659.GV24674@ringworld.MIT.EDU> Message-ID: On 31 May 2013, at 16:46, John Hawkinson wrote: > Alex Bligh wrote on Fri, 31 May 2013 > at 16:41:53 +0100 in <25BCBFD2-791A-4B1E-9182-A87FD75B8BAD at alex.org.uk>: > >> Would isatty(0) be reasonable to determine whether prompting should be used? > > I don't think so. This just makes it hard to debug scripts and hard to > write them. > > This kind of "trickery" causes more trouble than it solves. To be honest I am doubtful about the value of doing anything other than modifying the manpage. However, having written such scripts before, I can't see why anyone writing a script would be using piping stuff to prompts, when you can pass -N "" as a parameter and get no prompt. -- Alex Bligh From jhawk at MIT.EDU Sat Jun 1 02:35:55 2013 From: jhawk at MIT.EDU (John Hawkinson) Date: Fri, 31 May 2013 12:35:55 -0400 Subject: Patch to discourage unencrypted key generation In-Reply-To: References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> <20130530171546.GC24674@ringworld.MIT.EDU> <5B00EEF4-A27B-4D1B-B7F0-C1F2524E32AF@gmail.com> <20130531145856.GU24674@ringworld.MIT.EDU> <25BCBFD2-791A-4B1E-9182-A87FD75B8BAD@alex.org.uk> <20130531154659.GV24674@ringworld.MIT.EDU> Message-ID: <20130531163555.GW24674@ringworld.MIT.EDU> Alex Bligh wrote on Fri, 31 May 2013 at 17:23:36 +0100 in : > However, having written such scripts before, I can't see why anyone writing > a script would be using piping stuff to prompts, when you can pass -N "" > as a parameter and get no prompt. Ten I misunderstood the proposal. If -N "" gives no prompt, then there shouldn't be a prompt at all, and the message should simply tell you to run with -N "" instead of offering two disparate paths to the same end. --jhawk at mit.edu John Hawkinson From alex at alex.org.uk Sat Jun 1 08:45:03 2013 From: alex at alex.org.uk (Alex Bligh) Date: Fri, 31 May 2013 23:45:03 +0100 Subject: Patch to discourage unencrypted key generation In-Reply-To: <20130531163555.GW24674@ringworld.MIT.EDU> References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> <20130530171546.GC24674@ringworld.MIT.EDU> <5B00EEF4-A27B-4D1B-B7F0-C1F2524E32AF@gmail.com> <20130531145856.GU24674@ringworld.MIT.EDU> <25BCBFD2-791A-4B1E-9182-A87FD75B8BAD@alex.org.uk> <20130531154659.GV24674@ringworld.MIT.EDU> <20130531163555.GW24674@ringworld.MIT.EDU> Message-ID: <85797F01-140E-42F1-B827-E89327429E5C@alex.org.uk> On 31 May 2013, at 17:35, John Hawkinson wrote: > > Ten I misunderstood the proposal. > > If -N "" gives no prompt, then there shouldn't be a prompt at all, and the > message should simply tell you to run with -N "" instead of offering two > disparate paths to the same end. AIUI the original patch asked the user to enter the string "I know" if they were prompted for the passphrase (twice), and the result was the empty string. I am dubious as to the value of that, as, I think are you. However, the patch was subject to the criticism that it would break scripts. My point is that this particular piece of criticism is unfair, as any sane script writer would not do echo -e "\n\n" | ssh-keygen ... but would do ssh-keygen -N "" ... in which case the 'user' would never be prompted at all, and the script author would avoid having to do echo -e "\n\nI know\n" | ssh-keygen IE as far as I can tell, the patch does not alter the code path for any sensible script users. I suggested isatty(0) to dilute its impact a little further just in case a non-sensible script user was doing the above in order to maintain back compatibility. My favourite dilution would merely be to print a warning if a null string was received from the prompts (not through -N ""). -- Alex Bligh From pavelivolkov at gmail.com Wed Jun 5 00:46:49 2013 From: pavelivolkov at gmail.com (Pavel Volkov) Date: Tue, 4 Jun 2013 18:46:49 +0400 Subject: [PATCH] add restricted mode to sftp-server Message-ID: Hello. These patches add a new mode of operation for the sftp server. It is located between the ordinary, unrestricted mode and read-only mode. It allows you to add files to the server, but only if these files do not exist on the server before. Changes to existing files - are prohibited. Please review them, maybe these patches will be useful not only to me. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-restrict-sftp-server.c Type: text/x-csrc Size: 3330 bytes Desc: not available URL: From scott_n at xypro.com Wed Jun 5 03:08:39 2013 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 4 Jun 2013 10:08:39 -0700 Subject: PTY allocation? Message-ID: <78DD71C304F38B41885A242996B96F73044495EE@xyservd.XYPRO-23.LOCAL> I'm running a 5.0p1 derivative SSH server (that for various reasons I can not upgrade), on a host system that does not support PTYs. Attempts to connect to that sshd via sftp are failing due to an inability to allocate a pty. I can't really see a reason that an sftp session requires a pty. Is this addressed in later versions? Should I patch my system to avoid even trying to allocate a pty for an sftp session? Thanks --- Scott Neugroschl From pavelivolkov at gmail.com Wed Jun 5 04:03:48 2013 From: pavelivolkov at gmail.com (Pavel Volkov) Date: Tue, 4 Jun 2013 22:03:48 +0400 Subject: [PATCH] add restricted mode to sftp-server In-Reply-To: References: Message-ID: Hi again. Attachment is lost in the mailing list. I'm sorry. I will repeat them again in the body. --- sftp-server.8.orig 2013-06-04 13:32:44.000000000 +0400 +++ sftp-server.8 2013-06-04 18:08:32.000000000 +0400 @@ -99,6 +99,13 @@ into a read-only mode. Attempts to open files for writing, as well as other operations that change the state of the filesystem, will be denied. +.It Fl r +Places this instance of +.Nm +into a restricted mode. +Attempts to open files for writing, as well as other operations that change +the state of the filesystem, will be denied if files already exist. +Allows to resume via 'put' command for such program as winscp or filezilla, or other. .It Fl u Ar umask Sets an explicit .Xr umask 2 --- sftp-server.c.orig 2013-01-04 23:26:38.000000000 +0400 +++ sftp-server.c 2013-06-04 12:22:35.000000000 +0400 @@ -64,6 +64,9 @@ /* Disable writes */ int readonly; +/* Disable change if file exist */ +int nochange=0; + /* portable attributes, etc. */ typedef struct Stat Stat; @@ -533,6 +536,28 @@ buffer_free(&msg); } +static int +fnochange(const char *name) +{ + const char *filepart = ".filepart"; + char bname[PATH_MAX], *pbname; + struct stat st; + + if(nochange) { /* nochange = 1 */ + pbname=stpncpy(bname,name,sizeof(bname)-1); + bname[sizeof(bname)-1]='\0'; + debug3("fnochange 1: bname=%s, length bname=%d", bname, strlen(bname)); + if(strlen(name)>strlen(filepart)) { + pbname-=strlen(filepart); + debug3("fnochange 2: pbname=%s, length pbname=%d", pbname, strlen(pbname)); + if(bcmp(pbname,filepart,strlen(filepart))==0) *pbname='\0'; + } + debug3("fnochange 3: bname=%s, length bname=%d", bname, strlen(bname)); + if(lstat(bname,&st)!=-1) return 1; + } + return 0; +} + static void process_open(void) { @@ -550,7 +575,7 @@ mode = (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) ? a->perm : 0666; logit("open \"%s\" flags %s mode 0%o", name, string_from_portable(pflags), mode); - if (readonly && + if ((readonly || (fnochange(name) && (flags != O_WRONLY))) && ((flags & O_ACCMODE) == O_WRONLY || (flags & O_ACCMODE) == O_RDWR)) status = SSH2_FX_PERMISSION_DENIED; else { @@ -762,7 +787,7 @@ name = get_string(NULL); a = get_attrib(); debug("request %u: setstat name \"%s\"", id, name); - if (readonly) { + if (readonly || fnochange(name)) { status = SSH2_FX_PERMISSION_DENIED; a->flags = 0; } @@ -954,7 +979,7 @@ name = get_string(NULL); debug3("request %u: remove", id); logit("remove name \"%s\"", name); - if (readonly) + if (readonly || fnochange(name)) status = SSH2_FX_PERMISSION_DENIED; else { ret = unlink(name); @@ -1000,7 +1025,7 @@ name = get_string(NULL); debug3("request %u: rmdir", id); logit("rmdir name \"%s\"", name); - if (readonly) + if (readonly || fnochange(name)) status = SSH2_FX_PERMISSION_DENIED; else { ret = rmdir(name); @@ -1050,7 +1075,7 @@ debug3("request %u: rename", id); logit("rename old \"%s\" new \"%s\"", oldpath, newpath); status = SSH2_FX_FAILURE; - if (readonly) + if (readonly || fnochange(oldpath)) status = SSH2_FX_PERMISSION_DENIED; else if (lstat(oldpath, &sb) == -1) status = errno_to_portable(errno); @@ -1150,7 +1175,7 @@ newpath = get_string(NULL); debug3("request %u: posix-rename", id); logit("posix-rename old \"%s\" new \"%s\"", oldpath, newpath); - if (readonly) + if (readonly || fnochange(oldpath)) status = SSH2_FX_PERMISSION_DENIED; else { ret = rename(oldpath, newpath); @@ -1362,7 +1387,7 @@ extern char *__progname; fprintf(stderr, - "usage: %s [-ehR] [-d start_directory] [-f log_facility] " + "usage: %s [-ehRr] [-d start_directory] [-f log_facility] " "[-l log_level]\n\t[-u umask]\n", __progname); exit(1); @@ -1385,8 +1410,11 @@ pw = pwcopy(user_pw); - while (!skipargs && (ch = getopt(argc, argv, "d:f:l:u:cehR")) != -1) { + while (!skipargs && (ch = getopt(argc, argv, "d:f:l:u:cehRr")) != -1) { switch (ch) { + case 'r': + nochange = 1; + break; case 'R': readonly = 1; break; On Tue, Jun 4, 2013 at 6:46 PM, Pavel Volkov wrote: > Hello. > These patches add a new mode of operation for the sftp server. > It is located between the ordinary, unrestricted mode and read-only mode. > It allows you to add files to the server, but only if these files do > not exist on the server before. > Changes to existing files - are prohibited. > Please review them, maybe these patches will be useful not only to me. > Thank you. From dtucker at zip.com.au Wed Jun 5 04:13:48 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 4 Jun 2013 14:13:48 -0400 Subject: PTY allocation? In-Reply-To: <78DD71C304F38B41885A242996B96F73044495EE@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F73044495EE@xyservd.XYPRO-23.LOCAL> Message-ID: On Tue, Jun 4, 2013 at 1:08 PM, Scott Neugroschl wrote: > Attempts to connect to that sshd via sftp are failing due to an > inability to allocate a pty. I can't really see a reason that an sftp > session requires a pty. me either. > Is this addressed in later versions? Requesting a tty is a function of the client, not the server. > Should I patch my system to avoid even trying to allocate a pty for an sftp session? maybe. which client software are you using? OpenSSH has the RequestTTY option, but it looks like the default of "auto" doesn't request one with sftp sessions. -- 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 scott_n at xypro.com Wed Jun 5 06:23:00 2013 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 4 Jun 2013 13:23:00 -0700 Subject: PTY allocation? In-Reply-To: References: <78DD71C304F38B41885A242996B96F73044495EE@xyservd.XYPRO-23.LOCAL> Message-ID: <78DD71C304F38B41885A242996B96F7304449648@xyservd.XYPRO-23.LOCAL> It wound up being a brain-dead client that was asking for a terminal on an SFTP session. I'm still thinking about looking at the subsystem, and skipping the terminal allocation for SFTP. > -----Original Message----- > From: dtucker at dtucker.net [mailto:dtucker at dtucker.net] On Behalf Of > Darren Tucker > Sent: Tuesday, June 04, 2013 11:14 AM > To: Scott Neugroschl > Cc: openssh-unix-dev at mindrot.org > Subject: Re: PTY allocation? > > On Tue, Jun 4, 2013 at 1:08 PM, Scott Neugroschl > wrote: > > Attempts to connect to that sshd via sftp are failing due to an > > inability to allocate a pty. I can't really see a reason that an > sftp > > session requires a pty. > > me either. > > > Is this addressed in later versions? > > Requesting a tty is a function of the client, not the server. > > > Should I patch my system to avoid even trying to allocate a pty for > an sftp session? > > maybe. which client software are you using? OpenSSH has the > RequestTTY option, but it looks like the default of "auto" doesn't > request one with sftp sessions. > > -- > 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 mdb at juniper.net Wed Jun 5 16:44:56 2013 From: mdb at juniper.net (Mark D. Baushke) Date: Tue, 4 Jun 2013 23:44:56 -0700 Subject: [Bug 2115] Support for DSA p=2048 q=256/224 bit keys In-Reply-To: References: Message-ID: <89496.1370414696@eng-mail01.juniper.net> > --- Comment #2 from Cipher --- > Thanks Damien. > > Yes we were creating the keys using openssl and also using > ssh-keygen(After removing 1024 bit limit gate in the code). > One of our third party applications support only DSA keys, so we cant > use ECDSA. FIPS 140-2/3 requires 2048 with q=224/256. So how difficult > it will be and how much sense will it make to change ssh-dss to use 32 > byte seg parts? NIST SP 800-131A also mandates you would need to use SHA2-256 instead of SHA-1 for public key signature verification to meet FIPS 140-2/3 requirements. Given ssh-dss in RFC 4253 specifies ssh-dss format as | ssh-dss REQUIRED sign Raw DSS Key | ... | Signing and verifying using this key format is done according to the | Digital Signature Standard [FIPS-186-2] using the SHA-1 hash | [FIPS-180-2]. | | The resulting signature is encoded as follows: | | string "ssh-dss" | string dss_signature_blob | | The value for 'dss_signature_blob' is encoded as a string containing | r, followed by s (which are 160-bit integers, without lengths or | padding, unsigned, and in network byte order). It is the 160-bit SHA-1 hash that is your real problem. The openssh-unix-dev list has a suggestion for adding ssh-rsa-sha256 and ssh-dss-sha256 I believe this has been filed as Bug 2109 by Geoff Lowe. I therefore suggest that Bug 2115 is not a sufficient representation of your issue and that you would also need to see Bug 2109 addressed as well. -- Mark From daniel.neuberger at gmail.com Fri Jun 7 23:25:51 2013 From: daniel.neuberger at gmail.com (Daniel Neuberger) Date: Fri, 07 Jun 2013 09:25:51 -0400 Subject: pam_tally2 reset problems with many simultaneous connections Message-ID: All, (Sorry if this is a repost, I tried without being a subscriber and saw nothing after a day, so I'm trying again after subscribing). I think this is a problem with how sshd uses PAM. Basic scenario: - sshd is configured to use PAM with pam_tally2 - Multiple clients try connecting within a small time frame - Some of the clients fail to authenticate The problem is that the tally is incremented for every authentication, but isn't necessarily reset for successful authentications before another client tries to authenticate. So it goes something like this: - Client A authenticates successfully, but doesn't yet reset the tally - Client B tries to authenticate, but gets locked out for 10 seconds - Client C tries to authenticate, but gets locked out for 10 seconds - Client D tries to authenticate, but then the account is locked entirely - Client A finally resets the tally in the account phase - Client B tries again and authenticates successfully So, if a server is under load with many sftp connections, you'll see lots of logs even though everything eventually succeeds. I'm on RHEL 5.5 with openssh-server-4.3p2-41.el5 and pam-0.99.6.2-6.el5_4.1. I'm using pam_tally2 in the auth and account phases: #%PAM-1.0 ... auth requisite pam_tally2.so deny=3 lock_time=10 unlock_time=900 ... account required pam_tally2.so ... I'm guessing the problem is that sshd doesn't call pam_setcred correctly as stated in the pam_tally2 man page: "Account phase resets attempts counter if the user is not magic root. This phase can be used optionally for services which don't call pam_setcred(3) correctly or if the reset should be done regardless of the failure of the account phase of other modules." We had a similar problem with vsftpd once and solved it by not using pam_tally2, but I don't really want to do that for sshd. Has anyone else run into this problem before or have any suggestions for solving it? I searched google, the mailing list, and the bug list and couldn't find anything. Thanks. - Daniel From john.m.olsson at ericsson.com Sat Jun 8 06:19:52 2013 From: john.m.olsson at ericsson.com (John Olsson M) Date: Fri, 7 Jun 2013 20:19:52 +0000 Subject: Time zone for chrooted internal-sftp? In-Reply-To: References: <56C5269167653F4EB997E85F8CBB3299140014@ESESSMB301.ericsson.se> <56C5269167653F4EB997E85F8CBB32991680BE@ESESSMB301.ericsson.se>, Message-ID: <56C5269167653F4EB997E85F8CBB32991B1405@ESESSMB301.ericsson.se> Hi, Sorry again for a *very* late response. We have not yet verified the suggested patch due to that I simply forgot forwarding it to those who builds the system. :( I'll do that straight away and let you know the result as soon as I have it. /John ________________________________________ From: Damien Miller [djm at mindrot.org] Sent: Tuesday, 16 April 2013 13:37 To: John Olsson M Cc: openssh-unix-dev at mindrot.org Subject: RE: Time zone for chrooted internal-sftp? it worked? On Tue, 16 Apr 2013, John Olsson M wrote: > Sorry for not replying earlier. :( > > Thank you! > > /John > > -----Original Message----- > From: Damien Miller [mailto:djm at mindrot.org] > Sent: den 20 mars 2013 18:57 > To: John Olsson M > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Time zone for chrooted internal-sftp? > > On Wed, 13 Mar 2013, John Olsson M wrote: > > > Hi, > > > > A question regarding chroot, internal-sftp, and time zones: Is it > > possible to get the time stamps presented by the chrooted > > internal-sftp to always be aligned with the system global time zone > > setting? > > > > What is the reason this not done by default, that is couldn't the > > chrooted internal-sftp inherit the time zone information from the SSH > > daemon? > > I'd expect that it would, but maybe something gets reset after fork(). > You might want to try this patch to see if it makes any difference. > > Index: session.c > =================================================================== > RCS file: /var/cvs/openssh/session.c,v > retrieving revision 1.416 > diff -u -p -r1.416 session.c > --- session.c 15 Mar 2013 00:22:37 -0000 1.416 > +++ session.c 20 Mar 2013 17:55:21 -0000 > @@ -58,6 +58,7 @@ > #include > #include > #include > +#include > #include > > #include "openbsd-compat/sys-queue.h" > @@ -1461,6 +1462,7 @@ safely_chroot(const char *path, uid_t ui > > } > > + tzset(); > if (chdir(path) == -1) > fatal("Unable to chdir to chroot path \"%s\": " > "%s", path, strerror(errno)); > Index: sshd.c > =================================================================== > RCS file: /var/cvs/openssh/sshd.c,v > retrieving revision 1.420 > diff -u -p -r1.420 sshd.c > --- sshd.c 12 Feb 2013 00:04:48 -0000 1.420 > +++ sshd.c 20 Mar 2013 17:55:41 -0000 > @@ -607,6 +607,7 @@ privsep_preauth_child(void) > arc4random_stir(); > arc4random_buf(rnd, sizeof(rnd)); > RAND_seed(rnd, sizeof(rnd)); > + tzset(); > > /* Demote the private keys to public keys. */ > demote_sensitive_data(); > From johannes.ernst at gmail.com Sat Jun 8 10:02:40 2013 From: johannes.ernst at gmail.com (Johannes Ernst) Date: Fri, 7 Jun 2013 17:02:40 -0700 Subject: "Virtual hosts" for ssh Message-ID: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> It'd be very cool if ssh supported something like Apache "virtual hosts". This would make it much more viable to host multiple installs of git on the same server, for example. More details: On the remote server, ssh already sets some environment variables: > printenv | grep SSH SSH_CLIENT=192.168.1.18 50945 22 SSH_TTY=/dev/pts/1 SSH_CONNECTION=192.168.1.18 50945 192.168.1.1 22 What about adding another, say SSH_SERVER_HOST=host1 Assuming that /etc/hosts 192.168.1.1 host1 host2 then ssh user at host1 and ssh user at host2 would lead to a shell on the same host with the same user, but SSH_SERVER_HOST would be different, and that would allow the creation of a script that, for example, could find the correct git repository given the virtual hostname. This is currently not possible because the script only has IP addresses. Presumably that would not be too hard to do? Cheers, Johannes. From peter at stuge.se Sat Jun 8 10:59:44 2013 From: peter at stuge.se (Peter Stuge) Date: Sat, 8 Jun 2013 02:59:44 +0200 Subject: "Virtual hosts" for ssh In-Reply-To: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> Message-ID: <20130608005944.8277.qmail@stuge.se> Johannes Ernst wrote: > very cool if ssh supported something like Apache "virtual hosts" That makes not much sense, but you could of course consider jails/containers/etc. > host multiple installs of git on the same server You can use real user accounts and POSIX ACLs: # git init --shared "${repodir}" && find "${repodir}" -type d -execdir \ setfacl -m u::rwx,g::rwx,o::r-x,d:u::rwx,d:g::rwx,d:m::rwx,d:o::r-x '{}' + ..or use something like gitolite in order to avoid learning about ACLs. //Peter From johannes.ernst at gmail.com Sat Jun 8 12:42:59 2013 From: johannes.ernst at gmail.com (Johannes Ernst) Date: Fri, 7 Jun 2013 19:42:59 -0700 Subject: "Virtual hosts" for ssh In-Reply-To: <20130608005944.8277.qmail@stuge.se> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <20130608005944.8277.qmail@stuge.se> Message-ID: On Jun 7, 2013, at 17:59, Peter Stuge wrote: > Johannes Ernst wrote: >> very cool if ssh supported something like Apache "virtual hosts" > > That makes not much sense, Elaborate? > but you could of course consider > jails/containers/etc. I don't see how this would work other than by assigning different IP addresses to the same server or at least using different ports. What am I missing? Perhaps I wasn't as clear about the use case as I thought I was: I'd like to be able to use the same user (say "git") on multiple git repositories on the same host, distinguished only by the hostname, but reaching different logical accounts with different credentials. Just like http://host1/blog and http://host2/blog can point to different installs of Wordpress on the same server (both of which have a user "admin" through the web interface that have nothing to do with each other), I'd like git commits by the same user for different virtual hostnames on the same server to have different credentials, and reach different repositories. Think mass hosting of git installs (or gitolite, or gitorious, or ...) on the same host just like virtual HTTP hosting at your typical Wordpress host. > host multiple installs of git on the same server > > You can use real user accounts and POSIX ACLs: > > # git init --shared "${repodir}" && find "${repodir}" -type d -execdir \ > setfacl -m u::rwx,g::rwx,o::r-x,d:u::rwx,d:g::rwx,d:m::rwx,d:o::r-x '{}' + > > ..or use something like gitolite in order to avoid learning about ACLs. I think this is an issue unrelated to my problem / suggestion. > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From pavelivolkov at gmail.com Sat Jun 8 14:57:59 2013 From: pavelivolkov at gmail.com (Pavel Volkov) Date: Sat, 8 Jun 2013 08:57:59 +0400 Subject: "Virtual hosts" for ssh In-Reply-To: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> Message-ID: Hello. You may be used 'Match' condition block, 'sshd_config(5)'. It allows you to distinguish between a compound of: User, Group, Host, LocalAddress, LocalPort, and Address criteria. May be with 'ChrootDirectory'. Or, if you trust your clients, you may use 'AcceptEnv'. To passed over ssh your environment variable. On Sat, Jun 8, 2013 at 4:02 AM, Johannes Ernst wrote: > It'd be very cool if ssh supported something like Apache "virtual hosts". This would make it much more viable to host multiple installs of git on the same server, for example. > > More details: > > On the remote server, ssh already sets some environment variables: > >> printenv | grep SSH > SSH_CLIENT=192.168.1.18 50945 22 > SSH_TTY=/dev/pts/1 > SSH_CONNECTION=192.168.1.18 50945 192.168.1.1 22 > > What about adding another, say > SSH_SERVER_HOST=host1 > > Assuming that /etc/hosts > 192.168.1.1 host1 host2 > then > ssh user at host1 > and > ssh user at host2 > would lead to a shell on the same host with the same user, but SSH_SERVER_HOST would be different, and that would allow the creation of a script that, for example, could find the correct git repository given the virtual hostname. This is currently not possible because the script only has IP addresses. > > Presumably that would not be too hard to do? > > Cheers, > > > Johannes. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Sat Jun 8 17:43:18 2013 From: djm at mindrot.org (Damien Miller) Date: Sat, 8 Jun 2013 17:43:18 +1000 (EST) Subject: "Virtual hosts" for ssh In-Reply-To: References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> Message-ID: On Sat, 8 Jun 2013, Pavel Volkov wrote: > Hello. > You may be used 'Match' condition block, 'sshd_config(5)'. It allows > you to distinguish between a compound of: User, Group, Host, > LocalAddress, LocalPort, and Address criteria. May be with > 'ChrootDirectory'. Right - and ForceCommand. -d From medsalim.bouhlel at enis.rnu.tn Sat Jun 8 16:51:13 2013 From: medsalim.bouhlel at enis.rnu.tn (SETIT 2014) Date: Sat, 8 Jun 2013 08:51:13 +0200 Subject: Call for Papers to SETIT 2014. 24-28 March 2014 Malaysia Message-ID: <45284129146466433915@SETIT-PC> Merci pour la transmission de cet appel ?? tous ceux et celles qui pourraient y ??tre int??ress??s Conf??rence Internationale HMI 2013 Nous avons le plaisir de vous annoncer que l'unit?? de recherche SETIT et son partenaire l'ASDF viennent de conclure un accord. Cet accord pr??voit l'octroi d'une bourse d'un montant de 150$ et l'h??bergement gratuit (5 nuit??es) ?? tous les participants* de la Conf??rence Internationale (Human-Machine Interaction HMI 2013). Cette conf??rence aura lieu du 25 au 27 Mars 2013 ?? chennai-INDE. Les doctorants et enseignants b??n??ficeront selon cet accord des tarifs suivants: frais de participation frais normaux frais sponsoris??s Participant niveau mast??re (maximum) 175$ 25$ Participant avec communication longue 250$ 100$ Participant sans communication 175$ 25$ Participant avec communication sous forme d'un poster 180$ 30$ Participant avec communication courte 180$ 30$ Si vous souhaiterez participer et b??n??ficier de cet appui financier, veuillez remplir le formulaire suivant : http://www.setit.rnu.tn/financial_hmi.html. Si vous souhaiterez soumettre un poster, veuillez visiter le lien suivant : http://www.setit.rnu.tn/poster_hmi.html (Les th??matiques de soumission ?? la session poster ne se limite pas aux domaines de l'IHM). Si vous souhaiterez soumettre un papier r??gulier, veuillez visiter le lien suivant : http://www.hmi2013.in/pprsubmission.html Pour plus amples informations, veuillez consulter: www.setit.rnu.tn/Hmi2013.html. Si vous souhaiterez consulter la liste des participants ayant d??j?? obtenus l'accord pour le support financier : http://www.setit.rnu.tn/hmi2013/conflist.html . (Cette liste sera actualis??e chaque lundi).. *********************************************************** Mohamed Salim BOUHLEL & KOKULA KRISHNA HARI K. Pr??sidents HMI 2013 hmi2013 at hmi2013.in *********************************************************** * Tous les participants des pays en voie de d??vellopement (Tunisiens y compris). Cordialement Mohamed Salim BOUHLEL Co-pr??sident, SETIT 2013 et HMI 2013 Directeur de l'Unit?? de recherche: Sciences Et Technologies de l'Image et des T??l??communications SETIT (Universit?? de Sfax) GSM +216 20 20 00 05 ===================================================================== Pour se d??sinscrire de notre liste, veuillez r??pondre par un message contenant le mot unsubscribe ===================================================================== From dan at doxpara.com Sat Jun 8 18:34:34 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 8 Jun 2013 01:34:34 -0700 Subject: "Virtual hosts" for ssh In-Reply-To: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> Message-ID: <9F8F9D3C-E287-4060-A536-BD31FD063A07@doxpara.com> Actually this isn't a bad idea. Seems like it's at the right layer, doesn't require protocol rework, and exists in a namespace OpenSSH can reasonably claim to own. Only the client needs patching to upgrade the entire server space! Looks like a useful feature to have on by default, with pretty deep historical evidence that sharing perceived DNS name is operationally valuable. Not seeing a security impact; some concern about subsystems/sftp, but no need to block on that. I like it! I'll write a patch if nobody else will. Sent from my iPhone On Jun 7, 2013, at 5:02 PM, Johannes Ernst wrote: > It'd be very cool if ssh supported something like Apache "virtual hosts". This would make it much more viable to host multiple installs of git on the same server, for example. > > More details: > > On the remote server, ssh already sets some environment variables: > >> printenv | grep SSH > SSH_CLIENT=192.168.1.18 50945 22 > SSH_TTY=/dev/pts/1 > SSH_CONNECTION=192.168.1.18 50945 192.168.1.1 22 > > What about adding another, say > SSH_SERVER_HOST=host1 > > Assuming that /etc/hosts > 192.168.1.1 host1 host2 > then > ssh user at host1 > and > ssh user at host2 > would lead to a shell on the same host with the same user, but SSH_SERVER_HOST would be different, and that would allow the creation of a script that, for example, could find the correct git repository given the virtual hostname. This is currently not possible because the script only has IP addresses. > > Presumably that would not be too hard to do? > > Cheers, > > > Johannes. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From alex at alex.org.uk Sat Jun 8 19:08:44 2013 From: alex at alex.org.uk (Alex Bligh) Date: Sat, 8 Jun 2013 10:08:44 +0100 Subject: "Virtual hosts" for ssh In-Reply-To: <9F8F9D3C-E287-4060-A536-BD31FD063A07@doxpara.com> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <9F8F9D3C-E287-4060-A536-BD31FD063A07@doxpara.com> Message-ID: <04E47C6D-D7E9-455A-A250-4B25D56F05F6@alex.org.uk> Dan, On 8 Jun 2013, at 09:34, Dan Kaminsky wrote: > Actually this isn't a bad idea. Seems like it's at the right layer, doesn't require protocol rework, and exists in a namespace OpenSSH can reasonably claim to own. Only the client needs patching to upgrade the entire server space! Looks like a useful feature to have on by default, with pretty deep historical evidence that sharing perceived DNS name is operationally valuable. Not seeing a security impact; some concern about subsystems/sftp, but no need to block on that. +1. However, for maximum utility I think you are going to want to upgrade the server too, so whatever the 'virtual host' name is can be be subject to Match style logic, appear as %[something] etc. Ideally you would want it to to select different authorized_keys files, etc. etc. but that would obviously be too late in the day. Also unless the server sanitises this (which they won't if unpatched) server side users of the environment variable will need to be aware that a malicious client could set this maliciously, and catch the foolish who start in scripts without checking, assuming it's always a hostname or IP. IE it doesn't work like apache where the vhost has already been validated. -- Alex Bligh From dan at doxpara.com Sat Jun 8 19:13:40 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 8 Jun 2013 02:13:40 -0700 Subject: "Virtual hosts" for ssh In-Reply-To: <04E47C6D-D7E9-455A-A250-4B25D56F05F6@alex.org.uk> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <9F8F9D3C-E287-4060-A536-BD31FD063A07@doxpara.com> <04E47C6D-D7E9-455A-A250-4B25D56F05F6@alex.org.uk> Message-ID: Host can always be malicious (believe me, I'm working on some attacks in this space right now). In this case, we're security equivalent to an environment variable we can generally set anyway. The entire authorized keys system is kind of crufty. What I like about this request is that it's client only, it's immediately useful, and it points in a useful direction. It's also hilariously simple. On Saturday, June 8, 2013, Alex Bligh wrote: > Dan, > > On 8 Jun 2013, at 09:34, Dan Kaminsky wrote: > > > Actually this isn't a bad idea. Seems like it's at the right layer, > doesn't require protocol rework, and exists in a namespace OpenSSH can > reasonably claim to own. Only the client needs patching to upgrade the > entire server space! Looks like a useful feature to have on by default, > with pretty deep historical evidence that sharing perceived DNS name is > operationally valuable. Not seeing a security impact; some concern about > subsystems/sftp, but no need to block on that. > > +1. > > However, for maximum utility I think you are going to want > to upgrade the server too, so whatever the 'virtual host' > name is can be be subject to Match style logic, appear > as %[something] etc. Ideally you would want it to > to select different authorized_keys files, etc. etc. > but that would obviously be too late in the day. > > Also unless the server sanitises this (which they won't > if unpatched) server side users of the environment > variable will need to be aware that a malicious > client could set this maliciously, and catch the foolish > who start in scripts without checking, assuming > it's always a hostname or IP. IE it doesn't work > like apache where the vhost has already been > validated. > > -- > Alex Bligh > > > > > From alex at alex.org.uk Sat Jun 8 21:25:33 2013 From: alex at alex.org.uk (Alex Bligh) Date: Sat, 8 Jun 2013 12:25:33 +0100 Subject: "Virtual hosts" for ssh In-Reply-To: References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <9F8F9D3C-E287-4060-A536-BD31FD063A07@doxpara.com> <04E47C6D-D7E9-455A-A250-4B25D56F05F6@alex.org.uk> Message-ID: <801A1803-ECB8-402B-89E0-3CE48316E451@alex.org.uk> On 8 Jun 2013, at 10:13, Dan Kaminsky wrote: > Host can always be malicious (believe me, I'm working on some attacks in this space right now). In this case, we're security equivalent to an environment variable we can generally set anyway. Sure. I just meant a note in the manpage saying something along the lines of 'this variable is not validated by the server and contains exactly what is passed by the client; hence caution should be used when processing it server side'. > The entire authorized keys system is kind of crufty. I couldn't possibly comment :-; If, however, I was inventing an ssh 'virtual server', the first thing I'd want is for different authorized keys etc. per virtual server. This would mean exchanging the 'virtual host' required prior to authentication (and probably prior to key exchange). As far as I can tell from the spec, this would require bumping either protoversion or similar. Far more intrusive. -- Alex Bligh From nkadel at gmail.com Sun Jun 9 00:58:06 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 8 Jun 2013 10:58:06 -0400 Subject: "Virtual hosts" for ssh In-Reply-To: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> Message-ID: On Fri, Jun 7, 2013 at 8:02 PM, Johannes Ernst wrote: > It'd be very cool if ssh supported something like Apache "virtual hosts". This would make it much more viable to host multiple installs of git on the same server, for example. You've stepped into one of my fun areas, mixing technologies to attain a desired result, especially SSH and source control. As long as you can gracefully use a different IP address for each environment, it's workable. If you do it hostname based, you can get in deep confusion with all the different valid versions of the same hostname, such as WWW.eXaMplE.CoM versus www.example.com versus www (with a local domain set of example.com), and trying to match them all. That's an old problem with "VirtualHosts" from web servers, as well. Alternatively, don't use the "same user" for different projects on the same server. Use a different git shared username for each project environment. Since your git environments are normally defined by the home directory of the actual shared git username, this may be much faster and easier to set up and require no root managed manipulation of your sshd_config. Nico Kadel-Garcia > More details: > > On the remote server, ssh already sets some environment variables: > >> printenv | grep SSH > SSH_CLIENT=192.168.1.18 50945 22 > SSH_TTY=/dev/pts/1 > SSH_CONNECTION=192.168.1.18 50945 192.168.1.1 22 > > What about adding another, say > SSH_SERVER_HOST=host1 > > Assuming that /etc/hosts > 192.168.1.1 host1 host2 > then > ssh user at host1 > and > ssh user at host2 > would lead to a shell on the same host with the same user, but SSH_SERVER_HOST would be different, and that would allow the creation of a script that, for example, could find the correct git repository given the virtual hostname. This is currently not possible because the script only has IP addresses. > > Presumably that would not be too hard to do? > > Cheers, > > > Johannes. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dan at doxpara.com Sun Jun 9 01:14:27 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Sat, 8 Jun 2013 08:14:27 -0700 Subject: "Virtual hosts" for ssh In-Reply-To: References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> Message-ID: <04630225-54E7-4349-957D-9762BD98A99E@doxpara.com> Sent from my iPhone On Jun 8, 2013, at 7:58 AM, Nico Kadel-Garcia wrote: > On Fri, Jun 7, 2013 at 8:02 PM, Johannes Ernst wrote: >> It'd be very cool if ssh supported something like Apache "virtual hosts". This would make it much more viable to host multiple installs of git on the same server, for example. > > You've stepped into one of my fun areas, mixing technologies to attain > a desired result, especially SSH and source control. > > As long as you can gracefully use a different IP address for each > environment, it's workable. Because nothing says graceful or workable like large scale IP management. > If you do it hostname based, you can get > in deep confusion with all the different valid versions of the same > hostname, such as WWW.eXaMplE.CoM versus www.example.com versus www > (with a local domain set of example.com), and trying to match them > all. That's an old problem with "VirtualHosts" from web servers, as > well. Yes, it's an old, pretty much entirely solved problem. It's also not *our* problem; with this environment trick, it's the consuming shell's thing to deal with. Arguably we could canonicalize the DNS name. > > Alternatively, don't use the "same user" for different projects on the > same server. Use a different git shared username for each project > environment. Since your git environments are normally defined by the > home directory of the actual shared git username, this may be much > faster and easier to set up and require no root managed manipulation > of your sshd_config. That's one way to do it, but overloading username instead of host has its own pile of issues. > > Nico Kadel-Garcia > >> More details: >> >> On the remote server, ssh already sets some environment variables: >> >>> printenv | grep SSH >> SSH_CLIENT=192.168.1.18 50945 22 >> SSH_TTY=/dev/pts/1 >> SSH_CONNECTION=192.168.1.18 50945 192.168.1.1 22 >> >> What about adding another, say >> SSH_SERVER_HOST=host1 >> >> Assuming that /etc/hosts >> 192.168.1.1 host1 host2 >> then >> ssh user at host1 >> and >> ssh user at host2 >> would lead to a shell on the same host with the same user, but SSH_SERVER_HOST would be different, and that would allow the creation of a script that, for example, could find the correct git repository given the virtual hostname. This is currently not possible because the script only has IP addresses. >> >> Presumably that would not be too hard to do? >> >> Cheers, >> >> >> Johannes. >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From nkadel at gmail.com Sun Jun 9 04:27:50 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 8 Jun 2013 14:27:50 -0400 Subject: "Virtual hosts" for ssh In-Reply-To: <04630225-54E7-4349-957D-9762BD98A99E@doxpara.com> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <04630225-54E7-4349-957D-9762BD98A99E@doxpara.com> Message-ID: On Jun 8, 2013, at 11:14, Dan Kaminsky wrote: > > > Sent from my iPhone > > On Jun 8, 2013, at 7:58 AM, Nico Kadel-Garcia wrote: > >> On Fri, Jun 7, 2013 at 8:02 PM, Johannes Ernst wrote: >>> It'd be very cool if ssh supported something like Apache "virtual hosts". This would make it much more viable to host multiple installs of git on the same server, for example. >> >> You've stepped into one of my fun areas, mixing technologies to attain >> a desired result, especially SSH and source control. >> >> As long as you can gracefully use a different IP address for each >> environment, it's workable. > > Because nothing says graceful or workable like large scale IP management. Indeed, it does scale stably and well for small projects. For large sets of projects, such as several hundred, IPv6 becomes critical to support this approach. Doesn't work well behind NAT or proxies without a lot if extra work. >> If you do it hostname based, you can get >> in deep confusion with all the different valid versions of the same >> hostname, such as WWW.eXaMplE.CoM versus www.example.com versus www >> (with a local domain set of example.com), and trying to match them >> all. That's an old problem with "VirtualHosts" from web servers, as >> well. > > Yes, it's an old, pretty much entirely solved problem. It's also not *our* problem; with this environment trick, it's the consuming shell's thing to deal with. Yes, and it's very often done wrong. UTF8 hostnames, anyone? > Arguably we could canonicalize the DNS name. I'd advocate that. >> >> Alternatively, don't use the "same user" for different projects on the >> same server. Use a different git shared username for each project >> environment. Since your git environments are normally defined by the >> home directory of the actual shared git username, this may be much >> faster and easier to set up and require no root managed manipulation >> of your sshd_config. > > That's one way to do it, but overloading username instead of host has its own pile of issues. True, but it scales to thousands if projects and keeps source control configurations away from DNS or network resource management. From johannes.ernst at gmail.com Sun Jun 9 08:08:00 2013 From: johannes.ernst at gmail.com (Johannes Ernst) Date: Sat, 8 Jun 2013 15:08:00 -0700 Subject: Addition to the use case Was: Re: "Virtual hosts" for ssh In-Reply-To: References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <04630225-54E7-4349-957D-9762BD98A99E@doxpara.com> Message-ID: <06F287E3-C5A3-4387-96D7-DF0D7752813C@gmail.com> This one argues that the workaround of simply assigning different user accounts to different git installs has other problems which could be avoided with "virtual hosting" as proposed. Assume I set up 3 gits on server1 and 3 gits on server2. To keep the repositories separate, I create separate users: users git1, git2, git3 on server1 (with host name aliases host1, host2 and host3, each of which has a git instance) users git1, git2, git3 on server2 (with host name aliases host3, host4 and host5, each of which has a git instance) Now, for some reason two of the repositories on server1 get really popular, so I need to move one of it to server2. All of a sudden, there's a conflict: user git2 from server1 is not and should not be the same as user git2 on server2. So I'd have to rename one of them, and all of my users need to change their client-side setup. The act of moving a site from one server to another is not transparent to clients, and that's not good in my book. Virtual hosting, Apache-style, would avoid that. Cheers, Johannes From carson at taltos.org Sun Jun 9 10:02:17 2013 From: carson at taltos.org (Carson Gaspar) Date: Sat, 08 Jun 2013 17:02:17 -0700 Subject: Addition to the use case Was: Re: "Virtual hosts" for ssh In-Reply-To: <06F287E3-C5A3-4387-96D7-DF0D7752813C@gmail.com> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <04630225-54E7-4349-957D-9762BD98A99E@doxpara.com> <06F287E3-C5A3-4387-96D7-DF0D7752813C@gmail.com> Message-ID: <51B3C609.8070304@taltos.org> On 6/8/13 3:08 PM, Johannes Ernst wrote: > Assume I set up 3 gits on server1 and 3 gits on server2. To keep the > repositories separate, I create separate users: users git1, git2, > git3 on server1 (with host name aliases host1, host2 and host3, each > of which has a git instance) users git1, git2, git3 on server2 (with > host name aliases host3, host4 and host5, each of which has a git > instance) > > Now, for some reason two of the repositories on server1 get really > popular, so I need to move one of it to server2. All of a sudden, > there's a conflict: user git2 from server1 is not and should not be > the same as user git2 on server2. So I'd have to rename one of them, > and all of my users need to change their client-side setup. The setup you describe is just badly designed, so of course it doesn't work well. Set up a CNAME per account (which the VH proposal already requires), and make the account names globally unique. You can now migrate between servers to your heart's content without the users having to change a thing. -- Carson From johannes.ernst at gmail.com Sun Jun 9 12:50:48 2013 From: johannes.ernst at gmail.com (Johannes Ernst) Date: Sat, 8 Jun 2013 19:50:48 -0700 Subject: Addition to the use case Was: Re: "Virtual hosts" for ssh In-Reply-To: <51B3C609.8070304@taltos.org> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <04630225-54E7-4349-957D-9762BD98A99E@doxpara.com> <06F287E3-C5A3-4387-96D7-DF0D7752813C@gmail.com> <51B3C609.8070304@taltos.org> Message-ID: On Jun 8, 2013, at 17:02, Carson Gaspar wrote: > On 6/8/13 3:08 PM, Johannes Ernst wrote: >> Assume I set up 3 gits on server1 and 3 gits on server2. To keep the >> repositories separate, I create separate users: users git1, git2, >> git3 on server1 (with host name aliases host1, host2 and host3, each >> of which has a git instance) users git1, git2, git3 on server2 (with >> host name aliases host3, host4 and host5, each of which has a git >> instance) >> >> Now, for some reason two of the repositories on server1 get really >> popular, so I need to move one of it to server2. All of a sudden, >> there's a conflict: user git2 from server1 is not and should not be >> the same as user git2 on server2. So I'd have to rename one of them, >> and all of my users need to change their client-side setup. > > The setup you describe is just badly designed, so of course it doesn't work well. Set up a CNAME per account (which the VH proposal already requires), and make the account names globally unique. You can now migrate between servers to your heart's content without the users having to change a thing. Imagine that all of an ISP's customers that run Wordpress needed to take their admin user names from a common namespace, e.g. you would be admin4567. That would not really be what you'd want as a customer, but that is what you are proposing just for ssh. Now imagine that I'm moving my Wordpress install from one ISP to another; all of a sudden I might have to change admin account names, I wouldn't want to do that ... and in case of git, it's a lot harder to do. Cheers, Johannes. From rongqing.li at windriver.com Sun Jun 9 18:41:32 2013 From: rongqing.li at windriver.com (rongqing.li at windriver.com) Date: Sun, 9 Jun 2013 16:41:32 +0800 Subject: [PATCH] fix mac_computer Message-ID: <1370767292-17643-1-git-send-email-rongqing.li@windriver.com> The mac_compute() function in openssh calls umac_final() to prepend a tag to a buffer. Umac_final() calls pdf_gen_xor() on the tag as its final operation, and as implemented, pdf_gen_xor() assumes an appropriate alignment for 64-bit operations on its buffer. However, the buffer is declared in mac_compute() as a static u_char array, and the linker doesn't guarantee 64-bit alignment for such arrays. On ARM v7 NEON platforms with gcc, 64-bit values must be 64-bit aligned, and the unaligned buffer declaration caused alignment faults when executing certain openssh tests. Force the buffer in mac_compute() to be 64-bit aligned. Signed-off-by: Donn Seeley Signed-off-by: Roy Li --- mac.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/mac.c +++ b/mac.c @@ -132,12 +132,14 @@ mac_init(Mac *mac) u_char * mac_compute(Mac *mac, u_int32_t seqno, u_char *data, int datalen) { - static u_char m[EVP_MAX_MD_SIZE]; + static u_int64_t m_buf[(EVP_MAX_MD_SIZE + sizeof (u_int64_t) - 1) + / sizeof (u_int64_t)]; + u_char *m = (u_char *)m_buf; u_char b[4], nonce[8]; - if (mac->mac_len > sizeof(m)) + if (mac->mac_len > EVP_MAX_MD_SIZE) fatal("mac_compute: mac too long %u %lu", - mac->mac_len, (u_long)sizeof(m)); + mac->mac_len, (u_long)EVP_MAX_MD_SIZE); switch (mac->type) { case SSH_EVP: From mouring at eviladmin.org Sun Jun 9 22:52:31 2013 From: mouring at eviladmin.org (Ben Lindstrom) Date: Sun, 9 Jun 2013 07:52:31 -0500 Subject: Addition to the use case Was: Re: "Virtual hosts" for ssh In-Reply-To: References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <04630225-54E7-4349-957D-9762BD98A99E@doxpara.com> <06F287E3-C5A3-4387-96D7-DF0D7752813C@gmail.com> <51B3C609.8070304@taltos.org> Message-ID: On Jun 8, 2013, at 9:50 PM, Johannes Ernst wrote: > > On Jun 8, 2013, at 17:02, Carson Gaspar wrote: > >> On 6/8/13 3:08 PM, Johannes Ernst wrote: >>> Assume I set up 3 gits on server1 and 3 gits on server2. To keep the >>> repositories separate, I create separate users: users git1, git2, >>> git3 on server1 (with host name aliases host1, host2 and host3, each >>> of which has a git instance) users git1, git2, git3 on server2 (with >>> host name aliases host3, host4 and host5, each of which has a git >>> instance) >>> >>> Now, for some reason two of the repositories on server1 get really >>> popular, so I need to move one of it to server2. All of a sudden, >>> there's a conflict: user git2 from server1 is not and should not be >>> the same as user git2 on server2. So I'd have to rename one of them, >>> and all of my users need to change their client-side setup. They also have to change the host which their git is going to. Thus still requiring them to make a chance. So if it is username or servername. The user is still changing their client-side setup. Causing it to be a bad design. >> >> The setup you describe is just badly designed, so of course it doesn't work well. Set up a CNAME per account (which the VH proposal already requires), and make the account names globally unique. You can now migrate between servers to your heart's content without the users having to change a thing. > > Imagine that all of an ISP's customers that run Wordpress needed to take their admin user names from a common namespace, e.g. you would be admin4567. That would not really be what you'd want as a customer, but that is what you are proposing just for ssh. > > Now imagine that I'm moving my Wordpress install from one ISP to another; all of a sudden I might have to change admin account names, I wouldn't want to do that ... and in case of git, it's a lot harder to do. Imagine if all the Wordpress instances were to share the same database so all accounts need to be unique across every instance on the server. This is more akin to sshd. Since it doesn't work that way your example is bogus. - Ben From dtucker at zip.com.au Mon Jun 10 02:47:46 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 9 Jun 2013 12:47:46 -0400 Subject: [PATCH] fix mac_computer In-Reply-To: <1370767292-17643-1-git-send-email-rongqing.li@windriver.com> References: <1370767292-17643-1-git-send-email-rongqing.li@windriver.com> Message-ID: On Sun, Jun 9, 2013 at 4:41 AM, wrote: > Force the buffer in mac_compute() to be 64-bit aligned. Thanks, but a slightly different fix has already been applied over in bug#2101: https://bugzilla.mindrot.org/show_bug.cgi?id=2101 http://anoncvs.mindrot.org/index.cgi/openssh/mac.c?r1=1.27&r2=1.28 -- 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 keisial at gmail.com Mon Jun 10 02:56:41 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 09 Jun 2013 18:56:41 +0200 Subject: "Virtual hosts" for ssh In-Reply-To: References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <04630225-54E7-4349-957D-9762BD98A99E@doxpara.com> Message-ID: <51B4B3C9.7060309@gmail.com> On 08/06/13 20:27, Nico Kadel-Garcia wrote: >> Arguably we could canonicalize the DNS name. > I'd advocate that. And restrict it to [a-z][a-z0-9.-]* please :) From nkadel at gmail.com Mon Jun 10 03:12:22 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sun, 9 Jun 2013 13:12:22 -0400 Subject: "Virtual hosts" for ssh In-Reply-To: <51B4B3C9.7060309@gmail.com> References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <04630225-54E7-4349-957D-9762BD98A99E@doxpara.com> <51B4B3C9.7060309@gmail.com> Message-ID: On Sun, Jun 9, 2013 at 12:56 PM, ?ngel Gonz?lez wrote: > On 08/06/13 20:27, Nico Kadel-Garcia wrote: >>> >>> Arguably we could canonicalize the DNS name. >> >> I'd advocate that. > > And restrict it to [a-z][a-z0-9.-]* please :) I'd personally love to se DNS go back to RFC 035 and use 7-bit ASCII characters, limited as you describe. Unfortunately, RFC 3490 blew that out of the water with the internationalization of domain names. Canonicalizing domain names got a *lot* harder with that RFC. From keisial at gmail.com Mon Jun 10 03:56:19 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 09 Jun 2013 19:56:19 +0200 Subject: "Virtual hosts" for ssh In-Reply-To: References: <452AAF93-9297-4E85-BB06-1B7C2D6F8B0F@gmail.com> <04630225-54E7-4349-957D-9762BD98A99E@doxpara.com> <51B4B3C9.7060309@gmail.com> Message-ID: <51B4C1C3.5040302@gmail.com> On 09/06/13 19:12, Nico Kadel-Garcia wrote: > On Sun, Jun 9, 2013 at 12:56 PM, ?ngel Gonz?lez wrote: >> And restrict it to [a-z][a-z0-9.-]* please :) > I'd personally love to se DNS go back to RFC 035 and use 7-bit ASCII > characters, limited as you describe. Unfortunately, RFC 3490 blew that > out of the water with the internationalization of domain names. > Canonicalizing domain names got a *lot* harder with that RFC. I was expecting the client to provide the domain in punycode form. :) Restricting to what is used by the underlying dns seemed logical, although my main interest was doing in the server the cleanup so that it doesn't end up with control characters, .., backticks, slashes et al. so that for instance the following naive script would be safe: #!/bin/sh set -e cd $SSH_SERVER_HOST tar -c . From Jason at zx2c4.com Mon Jun 10 04:20:00 2013 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sun, 9 Jun 2013 20:20:00 +0200 Subject: pass fingerprint to authorizedkeyscommand Message-ID: Hi guys, It might be nice if AuthorizedKeysCommand would receive the fingerprint of the offered key as an argument, so that programs like gitolite could implement more refined key-based identity lookup that offers better performance than AuthorizedKeysFile's linear scan. The following patch is untested but is the basic idea: diff -ru openssh-6.2p1/auth2-pubkey.c openssh-6.2p1-modified/auth2-pubkey.c --- openssh-6.2p1/auth2-pubkey.c 2013-02-15 00:28:56.000000000 +0100 +++ openssh-6.2p1-modified/auth2-pubkey.c 2013-06-09 20:07:15.039975210 +0200 @@ -554,7 +554,8 @@ } execl(options.authorized_keys_command, - options.authorized_keys_command, user_pw->pw_name, NULL); + options.authorized_keys_command, user_pw->pw_name, + key_fingerprint(key, SSH_FP_MD5, SSH_FP_HEX), NULL); error("AuthorizedKeysCommand %s exec failed: %s", options.authorized_keys_command, strerror(errno)); Does this sound interesting? Thanks, Jason From dkg at fifthhorseman.net Mon Jun 10 06:27:51 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 09 Jun 2013 16:27:51 -0400 Subject: pass fingerprint to authorizedkeyscommand In-Reply-To: References: Message-ID: <51B4E547.6040104@fifthhorseman.net> On 06/09/2013 02:20 PM, Jason A. Donenfeld wrote: > It might be nice if AuthorizedKeysCommand would receive the fingerprint of > the offered key as an argument, so that programs like gitolite could > implement more refined key-based identity lookup that offers better > performance than AuthorizedKeysFile's linear scan. I like this proposal. A similar suggestions came up on January 14th of this year, in the thread started by Katsumoto San, Subject: "AuthorizedKeysCommand": http://marc.info/?t=135817865200002&r=1&w=2 If the goal is to pass information about the key, i'd rather that the information passed was the entire key, not just the fingerprint. Maybe your patch could put the full key in some canonical form as the next parameter instead of just the fpr? One nice thing about your proposed patch is that existing AuthorizedKeysCommand implementations will still work, but newer implementations can take advantage of the second parameter (if present) to minimize the work they need to do. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From daniel210x at gmail.com Mon Jun 10 21:02:13 2013 From: daniel210x at gmail.com (Daniel Cousens) Date: Mon, 10 Jun 2013 21:02:13 +1000 Subject: SSHD relative pathing problem Message-ID: Hi :) I hope this isn't just a problem in my understanding, but anyway. I am using `OpenSSH_6.2, OpenSSL 1.0.1e 11 Feb 2013` on an Arch Linux system, and I got caught out on this error for several days, and I'm not sure if its a bug for you guys or what. Anyway, what I noticed, was that when I specifyied a custom HostKey in the host file or by relative path, that is: `sshd -Dd -f myconfig` or `sshd -Dd -h myhostkey` where myconfig is just: ```myconfig HostKey myhostkey ``` It would load the key correctly, no complaints, but when attempted to connect to the server via `ssh 127.0.0.1` (or by any other means), it would immediately have an `ssh_exchange_identification: read: Connection reset by peer` error; and sshd would exit. Changing either of the above lines to: `sshd -Dd -f /home/foo/bar/myconfig` or `sshd -Dd -h /home/foo/bar/myhostkey` Resolved this issue, resulting in regular sshd behaviour. As I said, this may actually be a problem further downstream (that is, the Arch packagers), but I figured I'd ask here first. If that is the case, I'm sorry for taking up your time. Kind Regards, Daniel Cousens From daniel210x at gmail.com Mon Jun 10 21:27:29 2013 From: daniel210x at gmail.com (Daniel Cousens) Date: Mon, 10 Jun 2013 21:27:29 +1000 Subject: Please confirm your message In-Reply-To: References: <1370862161.22465.TMDA@natsu.mindrot.org> Message-ID: Hi (again), Not sure if it is too late now, so I apologize in advance, but I just had someone on IRC (finally) advise me of the following bug report: https://bugzilla.mindrot.org/show_bug.cgi?id=1290 Which is exactly my problem (which I just reported to you via email). It took me too long to figure out since there were no problems reported by sshd (-ddddddd) up until it received an actual connection. The loading sequence for sshd had reported key loading and config loading as all completing successfully. Maybe just some kind of warning could help to show this is indeed what is happening would be awesome. Ah well. Kind Regards, On Mon, Jun 10, 2013 at 9:03 PM, Daniel Cousens wrote: > > > On Mon, Jun 10, 2013 at 9:02 PM, TMDA daemon wrote: > >> This message was created automatically by mail delivery software (TMDA). >> >> Your message attached below is being held because the address >> has not been verified. >> >> To release your message for delivery, please send an empty message >> to the following address, or use your mailer's "Reply" feature. >> >> tmda+confirm+1370862161.22465.6cc559 at mindrot.org >> >> This confirmation verifies that your message is legitimate and not >> junk-mail. You should only have to confirm your address once. >> >> If you do not respond to this confirmation request within 14 days, >> your message will not be delivered. >> >> >> ---------- Forwarded message ---------- >> From: Daniel Cousens >> To: openssh-unix-dev at mindrot.org >> Cc: >> Date: Mon, 10 Jun 2013 21:02:13 +1000 >> Subject: SSHD relative pathing problem >> Hi :) >> >> I hope this isn't just a problem in my understanding, but anyway. >> >> I am using `OpenSSH_6.2, OpenSSL 1.0.1e 11 Feb 2013` on an Arch Linux >> system, and I got caught out on this error for several days, and I'm not >> sure if its a bug for you guys or what. >> >> Anyway, what I noticed, was that when I specifyied a custom HostKey in >> the host file or by relative path, that is: >> >> `sshd -Dd -f myconfig` >> or >> `sshd -Dd -h myhostkey` >> >> where myconfig is just: >> ```myconfig >> HostKey myhostkey >> ``` >> >> It would load the key correctly, no complaints, but when attempted to >> connect to the server via `ssh 127.0.0.1` (or by any other means), it would >> immediately have an `ssh_exchange_identification: read: Connection reset by >> peer` error; and sshd would exit. >> Changing either of the above lines to: >> >> `sshd -Dd -f /home/foo/bar/myconfig` >> or >> `sshd -Dd -h /home/foo/bar/myhostkey` >> >> Resolved this issue, resulting in regular sshd behaviour. >> >> As I said, this may actually be a problem further downstream (that is, >> the Arch packagers), but I figured I'd ask here first. If that is the case, >> I'm sorry for taking up your time. >> >> Kind Regards, >> >> Daniel Cousens >> > > From esr at thyrsus.com Tue Jun 18 15:13:55 2013 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jun 2013 01:13:55 -0400 (EDT) Subject: Problems in slogin.1, sshd_config.5, ssh_config.5 Message-ID: <20130618051355.5F8A9417B7@snark.thyrsus.com> This is automatically generated email about markup problems in a man page for which you appear to be responsible. If you are not the right person or list, please tell me so I can correct my database. See http://catb.org/~esr/doclifter/bugs.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the modification date of any manual page. You may wish to do that by hand. I apologize if this message seems spammy or impersonal. The volume of markup bugs I am tracking is over five hundred - there is no real alternative to generating bugmail from a database and template. -- Eric S. Raymond -------------- next part -------------- Problems with sshd_config.5: My records indicate that you have accepted this patch, so this is just a reminder. Invalid Sx reference - not a section on this page. --- sshd_config.5-unpatched 2013-05-25 14:55:59.688356241 -0400 +++ sshd_config.5 2013-05-25 14:55:59.344356247 -0400 @@ -144,9 +144,7 @@ and finally .Cm AllowGroups . .Pp -See -.Sx PATTERNS -in +See PATTERNS in .Xr ssh_config 5 for more information on patterns. .It Cm AllowTcpForwarding @@ -173,16 +171,13 @@ and finally .Cm AllowGroups . .Pp -See -.Sx PATTERNS -in +See PATTERNS in .Xr ssh_config 5 for more information on patterns. .It Cm AuthorizedKeysFile Specifies the file that contains the public keys that can be used for user authentication. -The format is described in the -.Sx AUTHORIZED_KEYS FILE FORMAT +The format is described in the AUTHORIZED_KEYS FILE FORMAT section of .Xr sshd 8 . .Cm AuthorizedKeysFile @@ -206,9 +201,7 @@ this file lists names, one of which must appear in the certificate for it to be accepted for authentication. Names are listed one per line preceded by key options (as described -in -.Sx AUTHORIZED_KEYS FILE FORMAT -in +under AUTHORIZED_KEYS FILE FORMAT in .Xr sshd 8 ) . Empty lines and comments starting with .Ql # @@ -387,9 +380,7 @@ and finally .Cm AllowGroups . .Pp -See -.Sx PATTERNS -in +See PATTERNS in .Xr ssh_config 5 for more information on patterns. .It Cm DenyUsers @@ -408,9 +399,7 @@ and finally .Cm AllowGroups . .Pp -See -.Sx PATTERNS -in +See PATTERNS in .Xr ssh_config 5 for more information on patterns. .It Cm ForceCommand @@ -741,8 +730,7 @@ .Cm Address . The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the -.Sx PATTERNS -section of +PATTERNS section of .Xr ssh_config 5 . .Pp The patterns in an @@ -1094,8 +1082,7 @@ Note that certificates that lack a list of principals will not be permitted for authentication using .Cm TrustedUserCAKeys . -For more details on certificates, see the -.Sx CERTIFICATES +For more details on certificates, see the CERTIFICATES section in .Xr ssh-keygen 1 . .It Cm UseDNS -------------- next part -------------- Problems with ssh_config.5: My records indicate that you have accepted this patch, so this is just a reminder. Invalid Sx reference - not a section on this page. --- ssh_config.5-unpatched 2013-05-25 14:56:05.228356137 -0400 +++ ssh_config.5 2013-05-25 14:56:04.832356145 -0400 @@ -490,9 +490,7 @@ option is also enabled. .It Cm ForwardX11Timeout Specify a timeout for untrusted X11 forwarding -using the format described in the -.Sx TIME FORMATS -section of +using the format described in the TIME FORMATS section of .Xr sshd_config 5 . X11 connections received by .Xr ssh 1 @@ -1296,9 +1294,7 @@ .Dq no . Note that this option applies to protocol version 2 only. .Pp -See also -.Sx VERIFYING HOST KEYS -in +See also VERIFYING HOST KEYS in .Xr ssh 1 . .It Cm VisualHostKey If this flag is set to -------------- next part -------------- Problems with slogin.1: (Identical patches should apply to: ssh.1) My records indicate that you have accepted this patch, so this is just a reminder. Invalid Sx reference - not a section on this page. --- slogin.1-unpatched 2013-05-25 15:25:02.736323644 -0400 +++ slogin.1 2013-05-25 15:25:02.228323653 -0400 @@ -733,7 +733,7 @@ Protocol 1 is restricted to using only RSA keys, but protocol 2 may use any. The -.Sx HISTORY +.Em HISTORY section of .Xr ssl 8 (on non-OpenBSD systems, see @@ -795,7 +795,7 @@ This has the advantage that a single trusted certification authority can be used in place of many public/private keys. See the -.Sx CERTIFICATES +.Em CERTIFICATES section of .Xr ssh-keygen 1 for more information. From glance at acc.umu.se Tue Jun 18 20:33:16 2013 From: glance at acc.umu.se (Anton Lundin) Date: Tue, 18 Jun 2013 12:33:16 +0200 Subject: Matching username in ssh_config Message-ID: <20130618103316.GA15004@acc.umu.se> Hi all openssh devs out there. I have quite a few Host-stanzas in my .ssh/config to keep track of all the different settings and credentials needed to access all different hosts I connect to. Now I have ran in to a problem where I need to switch settings based on what user I'm trying to login to a host as. A simple case is: ssh -i rootkey root at host123 vs. ssh -i userkey username at host123 Up until now I have just used a stanza like Host host123 User username IdentityFile userkey But it would be awesome of it was possible to add before that, eg fist match as all other blocks, a stanza looking like: Host root at host123 IdentityFile rootkey So when I type: "ssh host123" it resolves to equivalent of "ssh -i userkey username at host123" And when i type: "ssh root at host123" it would resolve to "ssh -i rootkey root at host123" Does this sound reasonable to the rest of you? //Anton Ps. Please keep me on Cc, I'm not subscribed to the list. -- Anton Lundin +46702-161604 From flavien-ssh at lebarbe.net Wed Jun 19 06:55:33 2013 From: flavien-ssh at lebarbe.net (Flavien) Date: Tue, 18 Jun 2013 22:55:33 +0200 Subject: Matching username in ssh_config In-Reply-To: <20130618103316.GA15004@acc.umu.se> References: <20130618103316.GA15004@acc.umu.se> Message-ID: <20130618205533.GA32400@srv3.flavien.org> Hi, Why not just do : Host rhost123 User root IdentityFile rootkey Host uhost123 User user IdentityFile userkey Why not just do : Flavien. Anton Lundin ecrivait : > Hi all openssh devs out there. > > I have quite a few Host-stanzas in my .ssh/config to keep track of all the > different settings and credentials needed to access all different hosts I > connect to. > > Now I have ran in to a problem where I need to switch settings based on what > user I'm trying to login to a host as. A simple case is: > > ssh -i rootkey root at host123 > vs. > ssh -i userkey username at host123 > > Up until now I have just used a stanza like > > Host host123 > User username > IdentityFile userkey > > But it would be awesome of it was possible to add before that, eg fist > match as all other blocks, a stanza looking like: > > Host root at host123 > IdentityFile rootkey > > > So when I type: > "ssh host123" it resolves to equivalent of "ssh -i userkey username at host123" > And when i type: > "ssh root at host123" it would resolve to "ssh -i rootkey root at host123" > > > Does this sound reasonable to the rest of you? > > //Anton > > Ps. > Please keep me on Cc, I'm not subscribed to the list. > > -- > Anton Lundin +46702-161604 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- From imorgan at nas.nasa.gov Wed Jun 19 07:35:02 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 18 Jun 2013 14:35:02 -0700 Subject: Matching username in ssh_config In-Reply-To: <20130618103316.GA15004@acc.umu.se> References: <20130618103316.GA15004@acc.umu.se> Message-ID: <20130618213502.GE540@linux124.nas.nasa.gov> On Tue, Jun 18, 2013 at 05:33:16 -0500, Anton Lundin wrote: > Hi all openssh devs out there. > > I have quite a few Host-stanzas in my .ssh/config to keep track of all the > different settings and credentials needed to access all different hosts I > connect to. > > Now I have ran in to a problem where I need to switch settings based on what > user I'm trying to login to a host as. A simple case is: > > ssh -i rootkey root at host123 > vs. > ssh -i userkey username at host123 > > Up until now I have just used a stanza like > > Host host123 > User username > IdentityFile userkey > > But it would be awesome of it was possible to add before that, eg fist > match as all other blocks, a stanza looking like: > > Host root at host123 > IdentityFile rootkey > > > So when I type: > "ssh host123" it resolves to equivalent of "ssh -i userkey username at host123" > And when i type: > "ssh root at host123" it would resolve to "ssh -i rootkey root at host123" > > > Does this sound reasonable to the rest of you? > > //Anton > > Ps. > Please keep me on Cc, I'm not subscribed to the list. > What about using %r when you specify IdentityFile? -- Iain Morgan From djm at mindrot.org Wed Jun 19 10:50:16 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 19 Jun 2013 10:50:16 +1000 (EST) Subject: Matching username in ssh_config In-Reply-To: <20130618103316.GA15004@acc.umu.se> References: <20130618103316.GA15004@acc.umu.se> Message-ID: On Tue, 18 Jun 2013, Anton Lundin wrote: > But it would be awesome of it was possible to add before that, eg fist > match as all other blocks, a stanza looking like: > > Host root at host123 > IdentityFile rootkey I floated the idea recently with Darren of introducing Match for ssh_config: Match user djm host evil.com IdentityFile foo I'll try to implement this for 6.3 if I get time and nobody beats me to it. It's pretty easy if anyone wants to have a go at it - most of the infrastructure already exists for the "Host" directive. -d From esr at thyrsus.com Wed Jun 19 11:07:23 2013 From: esr at thyrsus.com (esr at thyrsus.com) Date: Tue, 18 Jun 2013 21:07:23 -0400 (EDT) Subject: Problems in ssh-keygen.1 Message-ID: <20130619010723.084DA414C7@snark.thyrsus.com> This is automatically generated email about markup problems in a man page for which you appear to be responsible. If you are not the right person or list, please tell me so I can correct my database. See http://catb.org/~esr/doclifter/bugs.html for details on how and why these patches were generated. Feel free to email me with any questions. Note: These patches do not change the modification date of any manual page. You may wish to do that by hand. I apologize if this message seems spammy or impersonal. The volume of markup bugs I am tracking is over five hundred - there is no real alternative to generating bugmail from a database and template. -- Eric S. Raymond -------------- next part -------------- Problems with ssh-keygen.1: Invalid Sx reference - not a section on this page. --- ssh-keygen.1-unpatched 2013-05-25 15:24:47.868323922 -0400 +++ ssh-keygen.1 2013-05-25 15:24:47.508323929 -0400 @@ -466,7 +466,7 @@ The start time may be specified as a date in YYYYMMDD format, a time in YYYYMMDDHHMMSS format or a relative time (to the current time) consisting of a minus sign followed by a relative time in the format described in the -.Sx TIME FORMATS +.Em TIME FORMATS section of .Xr sshd_config 5 . The end time may be specified as a YYYYMMDD date, a YYYYMMDDHHMMSS time or From glance at acc.umu.se Wed Jun 19 17:24:46 2013 From: glance at acc.umu.se (Anton Lundin) Date: Wed, 19 Jun 2013 09:24:46 +0200 Subject: Matching username in ssh_config In-Reply-To: <20130618205533.GA32400@srv3.flavien.org> References: <20130618103316.GA15004@acc.umu.se> <20130618205533.GA32400@srv3.flavien.org> Message-ID: <20130619072446.GC15004@acc.umu.se> On 18 June, 2013 - Flavien wrote: > Hi, > > > Why not just do : > > Host rhost123 > User root > IdentityFile rootkey > > Host uhost123 > User user > IdentityFile userkey > Why not just do : This is a workaround the problem, but i don't really like it because it requires you to change the command your writing, not just omitting parameters. //Anton > Anton Lundin ecrivait : > > Hi all openssh devs out there. > > > > I have quite a few Host-stanzas in my .ssh/config to keep track of all the > > different settings and credentials needed to access all different hosts I > > connect to. > > > > Now I have ran in to a problem where I need to switch settings based on what > > user I'm trying to login to a host as. A simple case is: > > > > ssh -i rootkey root at host123 > > vs. > > ssh -i userkey username at host123 > > > > Up until now I have just used a stanza like > > > > Host host123 > > User username > > IdentityFile userkey > > > > But it would be awesome of it was possible to add before that, eg fist > > match as all other blocks, a stanza looking like: > > > > Host root at host123 > > IdentityFile rootkey > > > > > > So when I type: > > "ssh host123" it resolves to equivalent of "ssh -i userkey username at host123" > > And when i type: > > "ssh root at host123" it would resolve to "ssh -i rootkey root at host123" > > > > > > Does this sound reasonable to the rest of you? > > > > //Anton > > > > Ps. > > Please keep me on Cc, I'm not subscribed to the list. > > > > -- > > Anton Lundin +46702-161604 > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- -- Anton Lundin +46702-161604 From glance at acc.umu.se Wed Jun 19 17:33:15 2013 From: glance at acc.umu.se (Anton Lundin) Date: Wed, 19 Jun 2013 09:33:15 +0200 Subject: Matching username in ssh_config In-Reply-To: <20130618213502.GE540@linux124.nas.nasa.gov> References: <20130618103316.GA15004@acc.umu.se> <20130618213502.GE540@linux124.nas.nasa.gov> Message-ID: <20130619073315.GD15004@acc.umu.se> On 18 June, 2013 - Iain Morgan wrote: > On Tue, Jun 18, 2013 at 05:33:16 -0500, Anton Lundin wrote: > > Hi all openssh devs out there. > > > > I have quite a few Host-stanzas in my .ssh/config to keep track of all the > > different settings and credentials needed to access all different hosts I > > connect to. > > > > Now I have ran in to a problem where I need to switch settings based on what > > user I'm trying to login to a host as. A simple case is: > > > > ssh -i rootkey root at host123 > > vs. > > ssh -i userkey username at host123 > > > > Up until now I have just used a stanza like > > > > Host host123 > > User username > > IdentityFile userkey > > > > But it would be awesome of it was possible to add before that, eg fist > > match as all other blocks, a stanza looking like: > > > > Host root at host123 > > IdentityFile rootkey > > > > > > So when I type: > > "ssh host123" it resolves to equivalent of "ssh -i userkey username at host123" > > And when i type: > > "ssh root at host123" it would resolve to "ssh -i rootkey root at host123" > > > > > > Does this sound reasonable to the rest of you? > > > > //Anton > > > > Ps. > > Please keep me on Cc, I'm not subscribed to the list. > > > > What about using %r when you specify IdentityFile? This is a good solution, but it requires that you layout your IdentityFile's in some sane fashion and not just as you create them and be done with it. I also use Simon Wilkinson's gssapi-patches and now when krb5-libraries start to have support for multi-principal credential-caches the GSSAPIClientIdentity option is just awesome. Then i would be nifty to do something like: Host root at host123 GSSAPIClientIdentity username/root at REALM Host host123 User username GSSAPIClientIdentity username at REALM //Anton -- Anton Lundin +46702-161604 From glance at acc.umu.se Wed Jun 19 17:45:39 2013 From: glance at acc.umu.se (Anton Lundin) Date: Wed, 19 Jun 2013 09:45:39 +0200 Subject: Matching username in ssh_config In-Reply-To: References: <20130618103316.GA15004@acc.umu.se> Message-ID: <20130619074539.GE15004@acc.umu.se> On 19 June, 2013 - Damien Miller wrote: > On Tue, 18 Jun 2013, Anton Lundin wrote: > > > But it would be awesome of it was possible to add before that, eg fist > > match as all other blocks, a stanza looking like: > > > > Host root at host123 > > IdentityFile rootkey > > I floated the idea recently with Darren of introducing Match for ssh_config: > > Match user djm host evil.com > IdentityFile foo > > I'll try to implement this for 6.3 if I get time and nobody beats me to it. > It's pretty easy if anyone wants to have a go at it - most of the > infrastructure already exists for the "Host" directive. This is probably better than my suggestion, to actually unify how matches and blocks are done between ssh and sshd and reuse that code. The only downside that i see is that old clients will look at the new config format and say: "Bad configuration option: Match" //Anton -- Anton Lundin +46702-161604 From mwlucas at michaelwlucas.com Thu Jun 20 00:10:28 2013 From: mwlucas at michaelwlucas.com (Michael W. Lucas) Date: Wed, 19 Jun 2013 10:10:28 -0400 Subject: AuthorizedKeysCommand idea Message-ID: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> Hi, I've been kicking this idea around, and the problem with it escapes me. I'm looking for someone to tell me why this is a bad idea. The new OpenSSH includes the AuthorizedKeysCommand, which was mostly added to let people use a command to look up user keys in LDAP. LDAP key lookup have some limitations -- specifically, the common openssh-lpk_openldap schema won't let you add restrictions at the front of the key. This didn't matter so much when the LPK patch was such a pain, but now that OpenSSH can actually do this out of the box I'd like to use it. So: What about using a SQLite database, copied to all machines, and a simple sqlite lookup for AuthorizedKeysCommand? If a user can't log into the local machine, because PAM or no local account or whatever, the presence of the key shouldn't matter. For key adds/changes/deletions, I just push the new sqlite DB to all my machines. This seems easy. Too easy. What am I missing? Thanks, ==ml -- Michael W. Lucas - mwlucas at michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e coupon code "ILUVMICHAEL" gets you 30% off & helps me. From mwlucas at michaelwlucas.com Thu Jun 20 00:26:28 2013 From: mwlucas at michaelwlucas.com (Michael W. Lucas) Date: Wed, 19 Jun 2013 10:26:28 -0400 Subject: AuthorizedKeysCommand idea In-Reply-To: <51C1BF9F.4040109@gmail.com> References: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> <51C1BF9F.4040109@gmail.com> Message-ID: <20130619142628.GB61730@bewilderbeast.blackhelicopters.org> On Wed, Jun 19, 2013 at 04:26:39PM +0200, ?ngel Gonz?lez wrote: > On 19/06/13 16:10, Michael W. Lucas wrote: > > So: > > > > What about using a SQLite database, copied to all machines, and a > > simple sqlite lookup for AuthorizedKeysCommand? > > > > If a user can't log into the local machine, because PAM or no local > > account or whatever, the presence of the key shouldn't matter. > > > > For key adds/changes/deletions, I just push the new sqlite DB to all > > my machines. > > > > This seems easy. Too easy. What am I missing? > > > > Thanks, > > ==ml > That should work. What makes you think that it wouldn't? Because after two decades of systems administration, I've seen too many people say "Oh, I'll just do this" without being aware of all the implications. It seems that if it was that simple, someone would have done it already... ==ml -- Michael W. Lucas - mwlucas at michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e coupon code "ILUVMICHAEL" gets you 30% off & helps me. From keisial at gmail.com Thu Jun 20 00:26:39 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 19 Jun 2013 16:26:39 +0200 Subject: AuthorizedKeysCommand idea In-Reply-To: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> References: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> Message-ID: <51C1BF9F.4040109@gmail.com> On 19/06/13 16:10, Michael W. Lucas wrote: > So: > > What about using a SQLite database, copied to all machines, and a > simple sqlite lookup for AuthorizedKeysCommand? > > If a user can't log into the local machine, because PAM or no local > account or whatever, the presence of the key shouldn't matter. > > For key adds/changes/deletions, I just push the new sqlite DB to all > my machines. > > This seems easy. Too easy. What am I missing? > > Thanks, > ==ml That should work. What makes you think that it wouldn't? From lists at spuddy.org Thu Jun 20 01:06:03 2013 From: lists at spuddy.org (Stephen Harris) Date: Wed, 19 Jun 2013 11:06:03 -0400 Subject: AuthorizedKeysCommand idea In-Reply-To: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> References: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> Message-ID: <20130619150602.GA7914@mercury.spuddy.org> On Wed, Jun 19, 2013 at 10:10:28AM -0400, Michael W. Lucas wrote: > LDAP key lookup have some limitations -- specifically, the common > openssh-lpk_openldap schema won't let you add restrictions at the > front of the key. This didn't matter so much when the LPK patch was > such a pain, but now that OpenSSH can actually do this out of the box > I'd like to use it. Why use this schema, if it doesn't do what you want? With the latest version of OpenSSH you can pick your own ldapsearch command and so do any schema you like. You could even have the keys attached to the same dn as the existing account object, if you wanted. > This seems easy. Too easy. What am I missing? Scalability, atomicity. Local databases do work (see seos/eTrust AC/Control Minder/name-of-the-day) but a "push" model has performance issues. A notification based pull model scales better. Handling the edge cases (server down; slow to respond; etc) is where the fun starts in your model :-) -- rgds Stephen From mouring at eviladmin.org Thu Jun 20 01:02:48 2013 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 19 Jun 2013 10:02:48 -0500 Subject: AuthorizedKeysCommand idea In-Reply-To: <20130619142628.GB61730@bewilderbeast.blackhelicopters.org> References: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> <51C1BF9F.4040109@gmail.com> <20130619142628.GB61730@bewilderbeast.blackhelicopters.org> Message-ID: On Jun 19, 2013, at 9:26 AM, Michael W. Lucas wrote: > On Wed, Jun 19, 2013 at 04:26:39PM +0200, ?ngel Gonz?lez wrote: >> On 19/06/13 16:10, Michael W. Lucas wrote: >>> So: >>> >>> What about using a SQLite database, copied to all machines, and a >>> simple sqlite lookup for AuthorizedKeysCommand? >>> >>> If a user can't log into the local machine, because PAM or no local >>> account or whatever, the presence of the key shouldn't matter. >>> >>> For key adds/changes/deletions, I just push the new sqlite DB to all >>> my machines. >>> >>> This seems easy. Too easy. What am I missing? >>> >>> Thanks, >>> ==ml >> That should work. What makes you think that it wouldn't? > > Because after two decades of systems administration, I've seen too > many people say "Oh, I'll just do this" without being aware of all the > implications. > > It seems that if it was that simple, someone would have done it > already... Sounds like something that would be nicely paired with puppet, chef, or cfengine. So it is managed. Mind you this is what I would called an old school NIS solution. =) (remember back when a "ypmake" actually rcp files to client machines from the master? =) It comes with all annoying sync issues of the old school NIS solution as well as other issues (bad rhost files, badly maintained client lists, machine down during the push, etc). It may be better from a security point of view to centralize that SQLite database, and use an existing protocols like https:// to talk to a CGI server to acquire the information. Then lock it down via IP or secret tokens or whatnot. It removes the "my machine was down" issue which could leave it out of sync (at worse leave keys around that you thought were gone). - Ben From sfrost at snowman.net Thu Jun 20 01:19:28 2013 From: sfrost at snowman.net (Stephen Frost) Date: Wed, 19 Jun 2013 11:19:28 -0400 Subject: AuthorizedKeysCommand idea In-Reply-To: References: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> <51C1BF9F.4040109@gmail.com> <20130619142628.GB61730@bewilderbeast.blackhelicopters.org> Message-ID: <20130619151928.GU23363@tamriel.snowman.net> * Ben Lindstrom (mouring at eviladmin.org) wrote: > Sounds like something that would be nicely paired with puppet, chef, or cfengine. So > it is managed. +1 ; Managing the sqlite (or whatever) file that's pushed out to the clients using a CM system will address the 'box was down during your push' issue because they periodically check in. > It may be better from a security point of view to centralize that SQLite database, and use > an existing protocols like https:// to talk to a CGI server to acquire the information. You'd cache it though, of course..? Otherwise... > Then lock > it down via IP or secret tokens or whatnot. It removes the "my machine was down" issue > which could leave it out of sync (at worse leave keys around that you thought were gone). If the 'my machine was down' is the CGI server, things get annoying. It's possible to build an HA setup to address that, but seems like overkill to me. Having a file that's distributed to all the hosts through puppet works well, imv; it's certainly what we do for individual accounts currently. Having a single file instead of a file per user might be an interesting idea, but what happens if the file is corrupted or unavailable..? Seems worse than simply having an actual authorized_keys file for each user, at least then you're limiting the hurt to one account. Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From phil.pennock at globnix.org Thu Jun 20 04:35:03 2013 From: phil.pennock at globnix.org (Phil Pennock) Date: Wed, 19 Jun 2013 14:35:03 -0400 Subject: AuthorizedKeysCommand idea In-Reply-To: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> References: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> Message-ID: <20130619183503.GA78247@redoubt.spodhuis.org> On 2013-06-19 at 10:10 -0400, Michael W. Lucas wrote: > What about using a SQLite database, copied to all machines, and a > simple sqlite lookup for AuthorizedKeysCommand? > > If a user can't log into the local machine, because PAM or no local > account or whatever, the presence of the key shouldn't matter. > > For key adds/changes/deletions, I just push the new sqlite DB to all > my machines. > > This seems easy. Too easy. What am I missing? It's easier than that: you don't need an SQLite DB or AuthorizedKeysCommand support. Once you already have all of the infrastructure to control which keys exist for which users, you can manage a directory with files named for the user and N keys per file. Then you can deploy that with puppet/chef/rsync/whatever. In sshd_config you just set: AuthorizedKeysFile /opt/mycompany/etc/sshkeys/%u This works, and has worked, for years, minimizes complexity at login time, makes audit easy and generally is something I've seen used, or have set up, in many places for at least a decade (with patches to pre-openssh sshd, originally). -Phil From no_spam_98 at yahoo.com Thu Jun 20 08:44:24 2013 From: no_spam_98 at yahoo.com (no_spam_98 at yahoo.com) Date: Wed, 19 Jun 2013 15:44:24 -0700 (PDT) Subject: OpenSSH and RFC 5114 Message-ID: <1371681864.27665.YahooMailNeo@web140601.mail.bf1.yahoo.com> I apologize up-front if this is the wrong list for this question. Can OpenSSH be made to work with the MODP Groups in RFC 5114? ?The RFC itself makes a comment in section 3.4 that mentions that RFC 4419 extended the original SSH model to allow Diffie-Hellman parameters to be transmitted as part of the key exchange messages, but I'm not clear how that works with OpenSSH's moduli file. Do I add the MODP Groups from 5114 into the moduli file? What "type" do I use? How do I know that sshd will choose to use them? ?Do I remove the other entries in the file? Thanks. From djm at mindrot.org Thu Jun 20 11:47:14 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 20 Jun 2013 11:47:14 +1000 (EST) Subject: OpenSSH and RFC 5114 In-Reply-To: <1371681864.27665.YahooMailNeo@web140601.mail.bf1.yahoo.com> References: <1371681864.27665.YahooMailNeo@web140601.mail.bf1.yahoo.com> Message-ID: On Wed, 19 Jun 2013, no_spam_98 at yahoo.com wrote: > I apologize up-front if this is the wrong list for this question. > > Can OpenSSH be made to work with the MODP Groups in RFC 5114? The RFC > itself makes a comment in section 3.4 that mentions that RFC 4419 > extended the original SSH model to allow Diffie-Hellman parameters to > be transmitted as part of the key exchange messages, but I'm not clear > how that works with OpenSSH's moduli file. > > Do I add the MODP Groups from 5114 into the moduli file? Here's an example line for "2048-bit MODP Group with 256-bit Prime Order Subgroup" that will hopefully explain it: 20130620000000 2 6 100 2047 3FB32C9B73134D0B2E77506660EDBD484CA7B18F21EF205407F4793A1A0BA12510DBC15077BE463FFF4FED4AAC0BB555BE3A6C1B0C6B47B1BC3773BF7E8C6F62901228F8C28CBB18A55AE31341000A650196F931C77A57F2DDF463E5E9EC144B777DE62AAAB8A8628AC376D282D6ED3864E67982428EBC831D14348F6F2F9193B5045AF2767164E1DFC967C1FB3F2E55A4BD1BFFE83B9C80D052B985D182EA0ADB2A3B7313D3FE14C8484B1E052588B9B7D2BBD2DF016199ECD06E1557CD0915B3353BBB64E0EC377FD028370DF92B52C7891428CDC67EB6184B523D1DB246C32F63078490F00EF8D647D148D47954515E2327CFEF98C582664B4C0F6CC41659 87A8E61DB4B6663CFFBBD19C651959998CEEF608660DD0F25D2CEED4435E3B00E00DF8F1D61957D4FAF7DF4561B2AA3016C3D91134096FAA3BF4296D830E9A7C209E0C6497517ABD5A8A9D306BCF67ED91F9E6725B4758C022E0B1EF4275BF7B6C5BFC11D45F9088B941F54EB1E59BB8BC39A0BF12307F5C4FDB70C581B23F76B63ACAE1CAA6B7902D52526735488A0EF13C6D9A51BFA4AB3AD8347796524D8EF6A167B5A41825D967E144E5140564251CCACB83E6B486F6B3CA3F7971506026C0B857F689962856DED4010ABD0BE621C3A3960A54E710C375F26375D7014103A4B54330C198AF126116D2276E11715F693877FAD7EF09CADB094AE91E1A1597 > How do I know that sshd will choose to use them? Do I remove the other >entries in the file? Yes, that's the only way to force it. -d From kawaljeet.malviya at gmail.com Thu Jun 20 12:28:17 2013 From: kawaljeet.malviya at gmail.com (kawaljeet kaur) Date: Thu, 20 Jun 2013 07:58:17 +0530 Subject: Issue with Pseudo terminal allocation with Openssh6.1p1 Message-ID: Hi Openssh users , I am working on a client server application that involves extensive client server interaction in a single ssh session. The application is also required to capture all the Read , Write and Error Filehandles to work on them separately as per the requirements of the application. The ssh session had been using the flag '-T' to disable the message 'Pseudo-terminal will not be allocated because stdin is not a terminal' until ssh of Openssh 5.4p1. However, ssh versions higher than this ( esp 6.1 ) is seen to be just displaying the same message 'Pseudo-terminal will not be allocated because stdin is not a terminal' and hanging forever . If executing in debug mode , it is seen to be hung at : soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh -T -v -v 10.5.68.68 "/tmp/test.sh " . . debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/soetest1/.ssh/identity ((nil)) debug2: key: /home/soetest1/.ssh/id_rsa (0x8429828) debug2: key: /home/soetest1/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: publickey debug1: Trying private key: /home/soetest1/.ssh/identity debug1: Offering RSA public key: /home/soetest1/.ssh/id_rsa debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp 17:b7:01:1e:39:29:f5:14:e6:67:1e:ab:ce:9c:10:11 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). Authenticated to 10.5.68.68 ([10.5.68.68]:22). debug1: Requesting no-more-sessions at openssh.com debug1: Entering interactive session. ^CKilled by signal 2. [soetest1 at CSCRHEL62LGG32v ~]$ However , if we dont use '-T' flag or use '-t' flag , the application still displays the same message 'Pseudo-terminal will not be allocated because stdin is not a terminal' but is seen to go through and complete successfully, with all versions of openssh. I have tried the below few command line runs to explain myself , but i am not sure whether they are appropriate to the situation or not: * Example 1 - non-interactive * Test script on remote host: ---------------------------------------- [root at CSCRHEL6LGGV ~]# cat /tmp/test3.sh echo 'hello ssh' [root at CSCRHEL6LGGV ~]# Script execution on test host : ------------------------------------------- [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_5.4p1/bin/ssh -T 10.5.68.68 "/tmp/test3.sh" 0>/tmp/errs2 hello ssh [soetest1 at CSCRHEL62LGG32v ~]$ cat /tmp/errs2 [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_5.4p1/bin/ssh -T 10.5.68.68 "/tmp/test3.sh" hello ssh [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_5.4p1/bin/ssh -t 10.5.68.68 "/tmp/test3.sh" hello ssh Connection to 10.5.68.68 closed. [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_5.4p1/bin/ssh -t 10.5.68.68 "/tmp/test3.sh" 0>/tmp/errs2 Pseudo-terminal will not be allocated because stdin is not a terminal. hello ssh [soetest1 at CSCRHEL62LGG32v ~]$ cat /tmp/errs2 [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh -t 10.5.68.68 "/tmp/test3.sh" 0>/tmp/errs2 Pseudo-terminal will not be allocated because stdin is not a terminal. hello ssh [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh -t 10.5.68.68 "/tmp/test3.sh" hello ssh Connection to 10.5.68.68 closed. [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh -T 10.5.68.68 "/tmp/test3.sh" ^CKilled by signal 2. [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh -T 10.5.68.68 "/tmp/test3.sh" 0>/tmp/errs2 ^CKilled by signal 2. [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh 10.5.68.68 "/tmp/test3.sh" hello ssh * Example 2 - interactive * Test script on remote host: --------------------------------------- [root at CSCRHEL6LGGV ~]# cat /tmp/test.sh read -p "enter name:" name; echo "your name is $name" [root at CSCRHEL6LGGV ~]# Script execution on test host : ------------------------------------------- [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_5.4p1/bin/ssh 10.5.68.68 "/tmp/test.sh" ^CKilled by signal 2. [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_5.4p1/bin/ssh -t 10.5.68.68 "/tmp/test.sh" enter name:test your name is test Connection to 10.5.68.68 closed. [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_5.4p1/bin/ssh -t 10.5.68.68 "/tmp/test.sh" 0>/tmp/errs2 Pseudo-terminal will not be allocated because stdin is not a terminal. your name is [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_5.4p1/bin/ssh -T 10.5.68.68 "/tmp/test.sh" 0>/tmp/errs2 your name is [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_5.4p1/bin/ssh -T 10.5.68.68 "/tmp/test.sh" ^CKilled by signal 2. [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh -T 10.5.68.68 "/tmp/test.sh" 0>/tmp/errs2 ^CKilled by signal 2. [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh -t 10.5.68.68 "/tmp/test.sh" enter name:hello your name is hello Connection to 10.5.68.68 closed. [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh -t 10.5.68.68 "/tmp/test.sh" 0>/tmp/errs2 Pseudo-terminal will not be allocated because stdin is not a terminal. your name is [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh 10.5.68.68 "/tmp/test.sh" 0>/tmp/errs2 your name is [soetest1 at CSCRHEL62LGG32v ~]$ ./ssh_6.1p1/bin/ssh 10.5.68.68 "/tmp/test.sh" ^CKilled by signal 2. Please help. Regards Kawaljeet From igor at mir2.org Fri Jun 21 07:52:22 2013 From: igor at mir2.org (Igor Bukanov) Date: Thu, 20 Jun 2013 23:52:22 +0200 Subject: ProxyCommand that returns a socket Message-ID: Hello, My usage of ProxyCommand just calls the nc utility with various parameters. That in turn after the initial setup just copies copies the data from the network socket to stdin/stdout. This useless coping can be avoided if ssh has an option to receive the socket from the proxy command. I suppose it can improve network error reporting as ssh would talk directly to the network socket rather than a proxy, right? From djm at mindrot.org Fri Jun 21 10:01:21 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Jun 2013 10:01:21 +1000 (EST) Subject: ProxyCommand that returns a socket In-Reply-To: References: Message-ID: On Thu, 20 Jun 2013, Igor Bukanov wrote: > Hello, > > My usage of ProxyCommand just calls the nc utility with various > parameters. That in turn after the initial setup just copies copies > the data from the network socket to stdin/stdout. This useless coping > can be avoided if ssh has an option to receive the socket from the > proxy command. I suppose it can improve network error reporting as ssh > would talk directly to the network socket rather than a proxy, right? I have a patch that adds a ProxyUseFdpass that might do what you want. When ProxyUseFdpass=yes, the ProxyCommand is expected to pass back a connected socket and exit. ssh will then use this socket directly. This is somewhat more optional for cases where the proxy is only needed at the beginning of the connection. Index: readconf.c =================================================================== RCS file: /var/cvs/openssh/readconf.c,v retrieving revision 1.184 diff -u -p -r1.184 readconf.c --- readconf.c 5 Jun 2013 22:22:47 -0000 1.184 +++ readconf.c 21 Jun 2013 00:00:29 -0000 @@ -137,7 +137,7 @@ typedef enum { oHashKnownHosts, oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand, oVisualHostKey, oUseRoaming, oZeroKnowledgePasswordAuthentication, - oKexAlgorithms, oIPQoS, oRequestTTY, oIgnoreUnknown, + oKexAlgorithms, oIPQoS, oRequestTTY, oIgnoreUnknown, oProxyUseFdpass, oIgnoredUnknownOption, oDeprecated, oUnsupported } OpCodes; @@ -249,6 +249,7 @@ static struct { { "kexalgorithms", oKexAlgorithms }, { "ipqos", oIPQoS }, { "requesttty", oRequestTTY }, + { "proxyusefdpass", oProxyUseFdpass }, { "ignoreunknown", oIgnoreUnknown }, { NULL, oBadOption } @@ -1074,6 +1075,10 @@ parse_int: charptr = &options->ignored_unknown; goto parse_string; + case oProxyUseFdpass: + intptr = &options->proxy_use_fdpass; + goto parse_flag; + case oDeprecated: debug("%s line %d: Deprecated option \"%s\"", filename, linenum, keyword); @@ -1235,6 +1240,7 @@ initialize_options(Options * options) options->ip_qos_interactive = -1; options->ip_qos_bulk = -1; options->request_tty = -1; + options->proxy_use_fdpass = -1; options->ignored_unknown = NULL; } @@ -1387,6 +1393,8 @@ fill_default_options(Options * options) options->ip_qos_bulk = IPTOS_THROUGHPUT; if (options->request_tty == -1) options->request_tty = REQUEST_TTY_AUTO; + if (options->proxy_use_fdpass == -1) + options->proxy_use_fdpass = 0; /* options->local_command should not be set by default */ /* options->proxy_command should not be set by default */ /* options->user will be set in the main program if appropriate */ Index: readconf.h =================================================================== RCS file: /var/cvs/openssh/readconf.h,v retrieving revision 1.87 diff -u -p -r1.87 readconf.h --- readconf.h 16 May 2013 10:30:03 -0000 1.87 +++ readconf.h 21 Jun 2013 00:00:29 -0000 @@ -138,6 +138,8 @@ typedef struct { int request_tty; + int proxy_use_fdpass; + char *ignored_unknown; /* Pattern list of unknown tokens to ignore */ } Options; Index: ssh_config.5 =================================================================== RCS file: /var/cvs/openssh/ssh_config.5,v retrieving revision 1.164 diff -u -p -r1.164 ssh_config.5 --- ssh_config.5 16 May 2013 10:30:32 -0000 1.164 +++ ssh_config.5 21 Jun 2013 00:00:29 -0000 @@ -931,6 +931,14 @@ For example, the following directive wou .Bd -literal -offset 3n ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p .Ed +.It Cm ProxyUseFdpass +Specifies that the a +.Cm ProxyCommand +will pass a connected file descriptor back to +.Nm ssh +instead of continuing to execute and pass data. +The default is +.Dq no . .It Cm PubkeyAuthentication Specifies whether to try public key authentication. The argument to this keyword must be Index: sshconnect.c =================================================================== RCS file: /var/cvs/openssh/sshconnect.c,v retrieving revision 1.211 diff -u -p -r1.211 sshconnect.c --- sshconnect.c 1 Jun 2013 21:31:19 -0000 1.211 +++ sshconnect.c 21 Jun 2013 00:00:29 -0000 @@ -59,6 +59,7 @@ #include "misc.h" #include "dns.h" #include "roaming.h" +#include "monitor_fdpass.h" #include "ssh2.h" #include "version.h" @@ -78,16 +79,113 @@ extern uid_t original_effective_uid; static int show_other_keys(struct hostkeys *, Key *); static void warn_changed_key(Key *); +/* Expand a proxy command */ +static char * +expand_proxy_command(const char *proxy_command, const char *user, + const char *host, int port) +{ + char *tmp, *ret, strport[NI_MAXSERV]; + + snprintf(strport, sizeof strport, "%hu", port); + xasprintf(&tmp, "exec %s", proxy_command); + ret = percent_expand(tmp, "h", host, "p", strport, + "r", options.user, (char *)NULL); + free(tmp); + return ret; +} + +/* + * Connect to the given ssh server using a proxy command that passes a + * a connected fd back to us. + */ +static int +ssh_proxy_fdpass_connect(const char *host, u_short port, + const char *proxy_command) +{ + char *command_string; + int sp[2], sock; + pid_t pid; + char *shell; + + if ((shell = getenv("SHELL")) == NULL) + shell = _PATH_BSHELL; + + if (socketpair(AF_UNIX, SOCK_STREAM, 0, sp) < 0) + fatal("Could not create socketpair to communicate with " + "proxy dialer: %.100s", strerror(errno)); + + command_string = expand_proxy_command(proxy_command, options.user, + host, port); + debug("Executing proxy dialer command: %.500s", command_string); + + /* Fork and execute the proxy command. */ + if ((pid = fork()) == 0) { + char *argv[10]; + + /* Child. Permanently give up superuser privileges. */ + permanently_drop_suid(original_real_uid); + + close(sp[1]); + /* Redirect stdin and stdout. */ + if (sp[0] != 0) { + if (dup2(sp[0], 0) < 0) + perror("dup2 stdin"); + } + if (sp[0] != 1) { + if (dup2(sp[0], 1) < 0) + perror("dup2 stdout"); + } + if (sp[0] >= 2) + close(sp[0]); + + /* + * Stderr is left as it is so that error messages get + * printed on the user's terminal. + */ + argv[0] = shell; + argv[1] = "-c"; + argv[2] = command_string; + argv[3] = NULL; + + /* + * Execute the proxy command. + * Note that we gave up any extra privileges above. + */ + execv(argv[0], argv); + perror(argv[0]); + exit(1); + } + /* Parent. */ + if (pid < 0) + fatal("fork failed: %.100s", strerror(errno)); + close(sp[0]); + free(command_string); + + if ((sock = mm_receive_fd(sp[1])) == -1) + fatal("proxy dialer did not pass back a connection"); + + while (waitpid(pid, NULL, 0) == -1) + if (errno != EINTR) + fatal("Couldn't wait for child: %s", strerror(errno)); + + /* Set the connection file descriptors. */ + packet_set_connection(sock, sock); + packet_set_timeout(options.server_alive_interval, + options.server_alive_count_max); + + return 0; +} + /* * Connect to the given ssh server using a proxy command. */ static int ssh_proxy_connect(const char *host, u_short port, const char *proxy_command) { - char *command_string, *tmp; + char *command_string; int pin[2], pout[2]; pid_t pid; - char *shell, strport[NI_MAXSERV]; + char *shell; if (!strcmp(proxy_command, "-")) { packet_set_connection(STDIN_FILENO, STDOUT_FILENO); @@ -96,29 +194,19 @@ ssh_proxy_connect(const char *host, u_sh return 0; } + if (options.proxy_use_fdpass) + return ssh_proxy_fdpass_connect(host, port, proxy_command); + if ((shell = getenv("SHELL")) == NULL || *shell == '\0') shell = _PATH_BSHELL; - /* Convert the port number into a string. */ - snprintf(strport, sizeof strport, "%hu", port); - - /* - * Build the final command string in the buffer by making the - * appropriate substitutions to the given proxy command. - * - * Use "exec" to avoid "sh -c" processes on some platforms - * (e.g. Solaris) - */ - xasprintf(&tmp, "exec %s", proxy_command); - command_string = percent_expand(tmp, "h", host, "p", strport, - "r", options.user, (char *)NULL); - free(tmp); - /* Create pipes for communicating with the proxy. */ if (pipe(pin) < 0 || pipe(pout) < 0) fatal("Could not create pipes to communicate with the proxy: %.100s", strerror(errno)); + command_string = expand_proxy_command(proxy_command, options.user, + host, port); debug("Executing proxy command: %.500s", command_string); /* Fork and execute the proxy command. */ From mwlucas at michaelwlucas.com Fri Jun 21 10:19:18 2013 From: mwlucas at michaelwlucas.com (Michael W. Lucas) Date: Thu, 20 Jun 2013 20:19:18 -0400 Subject: AuthorizedKeysCommand idea In-Reply-To: <20130619183503.GA78247@redoubt.spodhuis.org> References: <20130619141028.GA61643@bewilderbeast.blackhelicopters.org> <20130619183503.GA78247@redoubt.spodhuis.org> Message-ID: <20130621001918.GA68627@bewilderbeast.blackhelicopters.org> On Wed, Jun 19, 2013 at 02:35:03PM -0400, Phil Pennock wrote: > This works, and has worked, for years, minimizes complexity at login > time, makes audit easy and generally is something I've seen used, or > have set up, in many places for at least a decade (with patches to > pre-openssh sshd, originally). Well, yes, that's easier still. Never mind. It seems the best use for AuthorizedKeysCommand is to get keys from a location outside the local machine. ==ml -- Michael W. Lucas - mwlucas at michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Absolute OpenBSD 2/e - http://www.nostarch.com/openbsd2e coupon code "ILUVMICHAEL" gets you 30% off & helps me. From igor at mir2.org Fri Jun 21 15:55:43 2013 From: igor at mir2.org (Igor Bukanov) Date: Fri, 21 Jun 2013 07:55:43 +0200 Subject: ProxyCommand that returns a socket In-Reply-To: References: Message-ID: Thanks, I think this is exactly what I was looking for! On 21 June 2013 02:01, Damien Miller wrote: > On Thu, 20 Jun 2013, Igor Bukanov wrote: > >> Hello, >> >> My usage of ProxyCommand just calls the nc utility with various >> parameters. That in turn after the initial setup just copies copies >> the data from the network socket to stdin/stdout. This useless coping >> can be avoided if ssh has an option to receive the socket from the >> proxy command. I suppose it can improve network error reporting as ssh >> would talk directly to the network socket rather than a proxy, right? > > I have a patch that adds a ProxyUseFdpass that might do what you want. > > When ProxyUseFdpass=yes, the ProxyCommand is expected to pass back a > connected socket and exit. ssh will then use this socket directly. > > This is somewhat more optional for cases where the proxy is only > needed at the beginning of the connection. > > Index: readconf.c > =================================================================== > RCS file: /var/cvs/openssh/readconf.c,v > retrieving revision 1.184 > diff -u -p -r1.184 readconf.c > --- readconf.c 5 Jun 2013 22:22:47 -0000 1.184 > +++ readconf.c 21 Jun 2013 00:00:29 -0000 > @@ -137,7 +137,7 @@ typedef enum { > oHashKnownHosts, > oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand, > oVisualHostKey, oUseRoaming, oZeroKnowledgePasswordAuthentication, > - oKexAlgorithms, oIPQoS, oRequestTTY, oIgnoreUnknown, > + oKexAlgorithms, oIPQoS, oRequestTTY, oIgnoreUnknown, oProxyUseFdpass, > oIgnoredUnknownOption, oDeprecated, oUnsupported > } OpCodes; > > @@ -249,6 +249,7 @@ static struct { > { "kexalgorithms", oKexAlgorithms }, > { "ipqos", oIPQoS }, > { "requesttty", oRequestTTY }, > + { "proxyusefdpass", oProxyUseFdpass }, > { "ignoreunknown", oIgnoreUnknown }, > > { NULL, oBadOption } > @@ -1074,6 +1075,10 @@ parse_int: > charptr = &options->ignored_unknown; > goto parse_string; > > + case oProxyUseFdpass: > + intptr = &options->proxy_use_fdpass; > + goto parse_flag; > + > case oDeprecated: > debug("%s line %d: Deprecated option \"%s\"", > filename, linenum, keyword); > @@ -1235,6 +1240,7 @@ initialize_options(Options * options) > options->ip_qos_interactive = -1; > options->ip_qos_bulk = -1; > options->request_tty = -1; > + options->proxy_use_fdpass = -1; > options->ignored_unknown = NULL; > } > > @@ -1387,6 +1393,8 @@ fill_default_options(Options * options) > options->ip_qos_bulk = IPTOS_THROUGHPUT; > if (options->request_tty == -1) > options->request_tty = REQUEST_TTY_AUTO; > + if (options->proxy_use_fdpass == -1) > + options->proxy_use_fdpass = 0; > /* options->local_command should not be set by default */ > /* options->proxy_command should not be set by default */ > /* options->user will be set in the main program if appropriate */ > Index: readconf.h > =================================================================== > RCS file: /var/cvs/openssh/readconf.h,v > retrieving revision 1.87 > diff -u -p -r1.87 readconf.h > --- readconf.h 16 May 2013 10:30:03 -0000 1.87 > +++ readconf.h 21 Jun 2013 00:00:29 -0000 > @@ -138,6 +138,8 @@ typedef struct { > > int request_tty; > > + int proxy_use_fdpass; > + > char *ignored_unknown; /* Pattern list of unknown tokens to ignore */ > } Options; > > Index: ssh_config.5 > =================================================================== > RCS file: /var/cvs/openssh/ssh_config.5,v > retrieving revision 1.164 > diff -u -p -r1.164 ssh_config.5 > --- ssh_config.5 16 May 2013 10:30:32 -0000 1.164 > +++ ssh_config.5 21 Jun 2013 00:00:29 -0000 > @@ -931,6 +931,14 @@ For example, the following directive wou > .Bd -literal -offset 3n > ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p > .Ed > +.It Cm ProxyUseFdpass > +Specifies that the a > +.Cm ProxyCommand > +will pass a connected file descriptor back to > +.Nm ssh > +instead of continuing to execute and pass data. > +The default is > +.Dq no . > .It Cm PubkeyAuthentication > Specifies whether to try public key authentication. > The argument to this keyword must be > Index: sshconnect.c > =================================================================== > RCS file: /var/cvs/openssh/sshconnect.c,v > retrieving revision 1.211 > diff -u -p -r1.211 sshconnect.c > --- sshconnect.c 1 Jun 2013 21:31:19 -0000 1.211 > +++ sshconnect.c 21 Jun 2013 00:00:29 -0000 > @@ -59,6 +59,7 @@ > #include "misc.h" > #include "dns.h" > #include "roaming.h" > +#include "monitor_fdpass.h" > #include "ssh2.h" > #include "version.h" > > @@ -78,16 +79,113 @@ extern uid_t original_effective_uid; > static int show_other_keys(struct hostkeys *, Key *); > static void warn_changed_key(Key *); > > +/* Expand a proxy command */ > +static char * > +expand_proxy_command(const char *proxy_command, const char *user, > + const char *host, int port) > +{ > + char *tmp, *ret, strport[NI_MAXSERV]; > + > + snprintf(strport, sizeof strport, "%hu", port); > + xasprintf(&tmp, "exec %s", proxy_command); > + ret = percent_expand(tmp, "h", host, "p", strport, > + "r", options.user, (char *)NULL); > + free(tmp); > + return ret; > +} > + > +/* > + * Connect to the given ssh server using a proxy command that passes a > + * a connected fd back to us. > + */ > +static int > +ssh_proxy_fdpass_connect(const char *host, u_short port, > + const char *proxy_command) > +{ > + char *command_string; > + int sp[2], sock; > + pid_t pid; > + char *shell; > + > + if ((shell = getenv("SHELL")) == NULL) > + shell = _PATH_BSHELL; > + > + if (socketpair(AF_UNIX, SOCK_STREAM, 0, sp) < 0) > + fatal("Could not create socketpair to communicate with " > + "proxy dialer: %.100s", strerror(errno)); > + > + command_string = expand_proxy_command(proxy_command, options.user, > + host, port); > + debug("Executing proxy dialer command: %.500s", command_string); > + > + /* Fork and execute the proxy command. */ > + if ((pid = fork()) == 0) { > + char *argv[10]; > + > + /* Child. Permanently give up superuser privileges. */ > + permanently_drop_suid(original_real_uid); > + > + close(sp[1]); > + /* Redirect stdin and stdout. */ > + if (sp[0] != 0) { > + if (dup2(sp[0], 0) < 0) > + perror("dup2 stdin"); > + } > + if (sp[0] != 1) { > + if (dup2(sp[0], 1) < 0) > + perror("dup2 stdout"); > + } > + if (sp[0] >= 2) > + close(sp[0]); > + > + /* > + * Stderr is left as it is so that error messages get > + * printed on the user's terminal. > + */ > + argv[0] = shell; > + argv[1] = "-c"; > + argv[2] = command_string; > + argv[3] = NULL; > + > + /* > + * Execute the proxy command. > + * Note that we gave up any extra privileges above. > + */ > + execv(argv[0], argv); > + perror(argv[0]); > + exit(1); > + } > + /* Parent. */ > + if (pid < 0) > + fatal("fork failed: %.100s", strerror(errno)); > + close(sp[0]); > + free(command_string); > + > + if ((sock = mm_receive_fd(sp[1])) == -1) > + fatal("proxy dialer did not pass back a connection"); > + > + while (waitpid(pid, NULL, 0) == -1) > + if (errno != EINTR) > + fatal("Couldn't wait for child: %s", strerror(errno)); > + > + /* Set the connection file descriptors. */ > + packet_set_connection(sock, sock); > + packet_set_timeout(options.server_alive_interval, > + options.server_alive_count_max); > + > + return 0; > +} > + > /* > * Connect to the given ssh server using a proxy command. > */ > static int > ssh_proxy_connect(const char *host, u_short port, const char *proxy_command) > { > - char *command_string, *tmp; > + char *command_string; > int pin[2], pout[2]; > pid_t pid; > - char *shell, strport[NI_MAXSERV]; > + char *shell; > > if (!strcmp(proxy_command, "-")) { > packet_set_connection(STDIN_FILENO, STDOUT_FILENO); > @@ -96,29 +194,19 @@ ssh_proxy_connect(const char *host, u_sh > return 0; > } > > + if (options.proxy_use_fdpass) > + return ssh_proxy_fdpass_connect(host, port, proxy_command); > + > if ((shell = getenv("SHELL")) == NULL || *shell == '\0') > shell = _PATH_BSHELL; > > - /* Convert the port number into a string. */ > - snprintf(strport, sizeof strport, "%hu", port); > - > - /* > - * Build the final command string in the buffer by making the > - * appropriate substitutions to the given proxy command. > - * > - * Use "exec" to avoid "sh -c" processes on some platforms > - * (e.g. Solaris) > - */ > - xasprintf(&tmp, "exec %s", proxy_command); > - command_string = percent_expand(tmp, "h", host, "p", strport, > - "r", options.user, (char *)NULL); > - free(tmp); > - > /* Create pipes for communicating with the proxy. */ > if (pipe(pin) < 0 || pipe(pout) < 0) > fatal("Could not create pipes to communicate with the proxy: %.100s", > strerror(errno)); > > + command_string = expand_proxy_command(proxy_command, options.user, > + host, port); > debug("Executing proxy command: %.500s", command_string); > > /* Fork and execute the proxy command. */ From zev at bewilderbeest.net Tue Jun 25 15:06:07 2013 From: zev at bewilderbeest.net (Zev Weiss) Date: Mon, 24 Jun 2013 22:06:07 -0700 Subject: RFC: encrypted hostkeys patch Message-ID: <20130625050606.GA21458@hatter.bewilderbeest.net> Hi, About a year and a half ago I brought up the topic of encrypted hostkeys and posted a patch (http://marc.info/?l=openssh-unix-dev&m=132774431906364&w=2), and while the general reaction seemed receptive to the idea, a few problems were pointed out with the implementation (UI issues, ssh-keysign breakage). I've finally had some spare time in which to get back to this, and I've written a new patch which has the daemon talking to an ssh-agent for private key operations, as suggested in the previous conversation -- the current version of the patch can be found below. It's not complete (doesn't address ssh-keysign, for one thing), but I was hoping for some feedback on it so far -- reasonable-looking in terms of general approach? I had initially implemented a somewhat simpler version with the privsep child talking directly to the agent, but then figured that exposing the agent socket directly to the network-facing process might not be such a good idea security-wise (in contrast to the much more restricted protocol of the privsep monitor), so I rearranged things so that only the monitor has the agent connection. This version also (somewhat unnecessarily) bundles public keys into the sensitive_data struct, but I didn't really see a more appropriate place to stash those. And, assuming things look OK thus far, I'm considering how best to handle the ssh-keysign problem. Since it's executed by a user's ssh client, it won't have the server's SSH_AUTH_SOCK environment variable, so finding the socket to connect to is slightly tricky -- any problems with changing it to a (configurable) static, globally-known path? Assuming not, then there's the question of *where* that would be configured -- sshd would need to know it, but ssh-keysign reads ssh_config, not sshd_config; requiring the user to configure the same path in both seems undesirable, as does having either one loading the other's config file. I guess making it compile-time configurable would sort of work, but also doesn't seem like a great solution. Any thoughts or suggestions on this? Having a static, configurable socket path does seem nice otherwise, so sshd could just spawn its own agent passing "-a $SOCKETPATH" if it encounters an encrypted hostkey on startup, rather than, say, relying on an init script to launch ssh-agent and export the SSH_AUTH_SOCK variable to sshd (though I suppose there's really nothing stopping it from doing that anyway without a static socket path). Thoughts/comments welcome. Thanks, Zev Weiss diff --git a/auth.h b/auth.h index a406e13..d91f845 100644 --- a/auth.h +++ b/auth.h @@ -197,6 +197,7 @@ check_key_in_hostfiles(struct passwd *, Key *, const char *, /* hostkey handling */ Key *get_hostkey_by_index(int); +Key *get_hostkey_public_by_index(int); Key *get_hostkey_public_by_type(int); Key *get_hostkey_private_by_type(int); int get_hostkey_index(Key *); diff --git a/kex.h b/kex.h index 680264a..b77a2c2 100644 --- a/kex.h +++ b/kex.h @@ -139,6 +139,7 @@ struct Kex { Key *(*load_host_public_key)(int); Key *(*load_host_private_key)(int); int (*host_key_index)(Key *); + void (*sign)(Key *, Key *, u_char **, u_int *, u_char *, u_int); void (*kex[KEX_MAX])(Kex *); }; diff --git a/kexdhs.c b/kexdhs.c index 1512863..f6d43f2 100644 --- a/kexdhs.c +++ b/kexdhs.c @@ -80,9 +80,6 @@ kexdh_server(Kex *kex) if (server_host_public == NULL) fatal("Unsupported hostkey type %d", kex->hostkey_type); server_host_private = kex->load_host_private_key(kex->hostkey_type); - if (server_host_private == NULL) - fatal("Missing private key for hostkey type %d", - kex->hostkey_type); /* key, cert */ if ((dh_client_pub = BN_new()) == NULL) @@ -144,9 +141,8 @@ kexdh_server(Kex *kex) } /* sign H */ - if (PRIVSEP(key_sign(server_host_private, &signature, &slen, hash, - hashlen)) < 0) - fatal("kexdh_server: key_sign failed"); + kex->sign(server_host_private, server_host_public, &signature, &slen, + hash, hashlen); /* destroy_sensitive_data(); */ diff --git a/kexecdhs.c b/kexecdhs.c index c42dcf4..eec5fb6 100644 --- a/kexecdhs.c +++ b/kexecdhs.c @@ -78,9 +78,6 @@ kexecdh_server(Kex *kex) if (server_host_public == NULL) fatal("Unsupported hostkey type %d", kex->hostkey_type); server_host_private = kex->load_host_private_key(kex->hostkey_type); - if (server_host_private == NULL) - fatal("Missing private key for hostkey type %d", - kex->hostkey_type); debug("expecting SSH2_MSG_KEX_ECDH_INIT"); packet_read_expect(SSH2_MSG_KEX_ECDH_INIT); @@ -139,9 +136,8 @@ kexecdh_server(Kex *kex) } /* sign H */ - if (PRIVSEP(key_sign(server_host_private, &signature, &slen, - hash, hashlen)) < 0) - fatal("kexdh_server: key_sign failed"); + kex->sign(server_host_private, server_host_public, &signature, &slen, + hash, hashlen); /* destroy_sensitive_data(); */ diff --git a/kexgexs.c b/kexgexs.c index a543dda..3ef7710 100644 --- a/kexgexs.c +++ b/kexgexs.c @@ -68,10 +68,6 @@ kexgex_server(Kex *kex) if (server_host_public == NULL) fatal("Unsupported hostkey type %d", kex->hostkey_type); server_host_private = kex->load_host_private_key(kex->hostkey_type); - if (server_host_private == NULL) - fatal("Missing private key for hostkey type %d", - kex->hostkey_type); - type = packet_read(); switch (type) { @@ -187,9 +183,8 @@ kexgex_server(Kex *kex) } /* sign H */ - if (PRIVSEP(key_sign(server_host_private, &signature, &slen, hash, - hashlen)) < 0) - fatal("kexgex_server: key_sign failed"); + kex->sign(server_host_private, server_host_public, &signature, &slen, + hash, hashlen); /* destroy_sensitive_data(); */ diff --git a/monitor.c b/monitor.c index 7286126..8f289b5 100644 --- a/monitor.c +++ b/monitor.c @@ -97,6 +97,7 @@ #include "ssh2.h" #include "jpake.h" #include "roaming.h" +#include "authfd.h" #ifdef GSSAPI static Gssctxt *gsscontext = NULL; @@ -686,6 +687,8 @@ mm_answer_moduli(int sock, Buffer *m) return (0); } +extern AuthenticationConnection *auth_conn; + int mm_answer_sign(int sock, Buffer *m) { @@ -714,10 +717,16 @@ mm_answer_sign(int sock, Buffer *m) memcpy(session_id2, p, session_id2_len); } - if ((key = get_hostkey_by_index(keyid)) == NULL) + if ((key = get_hostkey_by_index(keyid)) != NULL) { + if (key_sign(key, &signature, &siglen, p, datlen) < 0) + fatal("%s: key_sign failed", __func__); + } else if ((key = get_hostkey_public_by_index(keyid)) != NULL && + auth_conn != NULL) { + if (ssh_agent_sign(auth_conn, key, &signature, &siglen, p, + datlen) < 0) + fatal("%s: ssh_agent_sign failed", __func__); + } else fatal("%s: no hostkey from index %d", __func__, keyid); - if (key_sign(key, &signature, &siglen, p, datlen) < 0) - fatal("%s: key_sign failed", __func__); debug3("%s: signature %p(%u)", __func__, signature, siglen); diff --git a/sshd.c b/sshd.c index 1306a62..a4a788b 100644 --- a/sshd.c +++ b/sshd.c @@ -106,6 +106,7 @@ #include "canohost.h" #include "hostfile.h" #include "auth.h" +#include "authfd.h" #include "misc.h" #include "msg.h" #include "dispatch.h" @@ -194,6 +195,9 @@ char *server_version_string = NULL; /* for rekeying XXX fixme */ Kex *xxx_kex; +/* Daemon's agent connection */ +AuthenticationConnection *auth_conn = NULL; + /* * Any really sensitive data in the application is contained in this * structure. The idea is that this structure could be locked into memory so @@ -206,6 +210,7 @@ struct { Key *server_key; /* ephemeral server key */ Key *ssh1_host_key; /* ssh1 host key */ Key **host_keys; /* all private host keys */ + Key **host_pubkeys; /* all public host keys */ Key **host_certificates; /* all public host certificates */ int have_ssh1_key; int have_ssh2_key; @@ -652,11 +657,18 @@ privsep_preauth(Authctxt *authctxt) } else if (pid != 0) { debug2("Network child is on pid %ld", (long)pid); + auth_conn = ssh_get_authentication_connection(); + pmonitor->m_pid = pid; if (box != NULL) ssh_sandbox_parent_preauth(box, pid); monitor_child_preauth(authctxt, pmonitor); + if (auth_conn) { + ssh_close_authentication_connection(auth_conn); + auth_conn = NULL; + } + /* Sync memory */ monitor_sync(pmonitor); @@ -704,10 +716,11 @@ privsep_postauth(Authctxt *authctxt) u_int32_t rnd[256]; #ifdef DISABLE_FD_PASSING - if (1) { + if (1) #else - if (authctxt->pw->pw_uid == 0 || options.use_login) { + if (authctxt->pw->pw_uid == 0 || options.use_login) #endif + { /* File descriptor passing is broken or root login */ use_privsep = 0; goto skip; @@ -767,6 +780,8 @@ list_hostkey_types(void) for (i = 0; i < options.num_host_key_files; i++) { key = sensitive_data.host_keys[i]; if (key == NULL) + key = sensitive_data.host_pubkeys[i]; + if (key == NULL) continue; switch (key->type) { case KEY_RSA: @@ -819,6 +834,8 @@ get_hostkey_by_type(int type, int need_private) break; default: key = sensitive_data.host_keys[i]; + if (key == NULL && !need_private) + key = sensitive_data.host_pubkeys[i]; break; } if (key != NULL && key->type == type) @@ -848,6 +865,14 @@ get_hostkey_by_index(int ind) return (sensitive_data.host_keys[ind]); } +Key * +get_hostkey_public_by_index(int ind) +{ + if (ind < 0 || ind >= options.num_host_key_files) + return (NULL); + return (sensitive_data.host_pubkeys[ind]); +} + int get_hostkey_index(Key *key) { @@ -860,6 +885,8 @@ get_hostkey_index(Key *key) } else { if (key == sensitive_data.host_keys[i]) return (i); + if (key == sensitive_data.host_pubkeys[i]) + return (i); } } return (-1); @@ -1344,6 +1371,9 @@ main(int ac, char **av) u_int64_t ibytes, obytes; mode_t new_umask; Key *key; + Key *pubkey; + char *pubkey_comment; + int have_agent, keytype; Authctxt *authctxt; struct connection_info *connection_info = get_connection_info(0, 0); @@ -1623,22 +1653,40 @@ main(int ac, char **av) } endpwent(); - /* load private host keys */ + /* load host keys */ sensitive_data.host_keys = xcalloc(options.num_host_key_files, sizeof(Key *)); - for (i = 0; i < options.num_host_key_files; i++) + sensitive_data.host_pubkeys = xcalloc(options.num_host_key_files, + sizeof(Key *)); + for (i = 0; i < options.num_host_key_files; i++) { sensitive_data.host_keys[i] = NULL; + sensitive_data.host_pubkeys[i] = NULL; + } + + have_agent = ssh_agent_present(); for (i = 0; i < options.num_host_key_files; i++) { key = key_load_private(options.host_key_files[i], "", NULL); + pubkey = key_load_public(options.host_key_files[i], + &pubkey_comment); sensitive_data.host_keys[i] = key; - if (key == NULL) { + sensitive_data.host_pubkeys[i] = pubkey; + + if (key == NULL && pubkey != NULL && pubkey->type != KEY_RSA1 && + have_agent) { + debug("will rely on agent for hostkey %s", + options.host_key_files[i]); + keytype = pubkey->type; + } else if (key == NULL) { error("Could not load host key: %s", options.host_key_files[i]); sensitive_data.host_keys[i] = NULL; + sensitive_data.host_pubkeys[i] = NULL; continue; - } - switch (key->type) { + } else + keytype = key->type; + + switch (keytype) { case KEY_RSA1: sensitive_data.ssh1_host_key = key; sensitive_data.have_ssh1_key = 1; @@ -1649,8 +1697,8 @@ main(int ac, char **av) sensitive_data.have_ssh2_key = 1; break; } - debug("private host key: #%d type %d %s", i, key->type, - key_type(key)); + debug("private host key: #%d type %d %s", i, keytype, + key_type(key ? key : pubkey)); } if ((options.protocol & SSH_PROTO_1) && !sensitive_data.have_ssh1_key) { logit("Disabling protocol version 1. Could not load host key"); @@ -2020,15 +2068,21 @@ main(int ac, char **av) buffer_init(&loginmsg); auth_debug_reset(); - if (use_privsep) + if (use_privsep) { if (privsep_preauth(authctxt) == 1) goto authenticated; + } else if (compat20) + auth_conn = ssh_get_authentication_connection(); /* perform the key exchange */ /* authenticate user and start session */ if (compat20) { do_ssh2_kex(); do_authentication2(authctxt); + if (!use_privsep && auth_conn) { + ssh_close_authentication_connection(auth_conn); + auth_conn = NULL; + } } else { do_ssh1_kex(); do_authentication(authctxt); @@ -2336,6 +2390,23 @@ do_ssh1_kex(void) packet_write_wait(); } +static void +kex_server_sign(Key *privkey, Key *pubkey, u_char **signature, u_int *slen, + u_char *data, u_int dlen) +{ + if (privkey) { + if (PRIVSEP(key_sign(privkey, signature, slen, data, dlen) < 0)) + fatal("%s: key_sign failed", __func__); + } else if (use_privsep) { + if (mm_key_sign(pubkey, signature, slen, data, dlen) < 0) + fatal("%s: pubkey_sign failed", __func__); + } else { + if (ssh_agent_sign(auth_conn, pubkey, signature, slen, data, + dlen)) + fatal("%s: ssh_agent_sign failed", __func__); + } +} + /* * SSH2 key exchange: diffie-hellman-group1-sha1 */ @@ -2386,6 +2457,7 @@ do_ssh2_kex(void) kex->load_host_public_key=&get_hostkey_public_by_type; kex->load_host_private_key=&get_hostkey_private_by_type; kex->host_key_index=&get_hostkey_index; + kex->sign = kex_server_sign; xxx_kex = kex; From djm at mindrot.org Tue Jun 25 21:29:19 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 25 Jun 2013 21:29:19 +1000 (EST) Subject: RFC: encrypted hostkeys patch In-Reply-To: <20130625050606.GA21458@hatter.bewilderbeest.net> References: <20130625050606.GA21458@hatter.bewilderbeest.net> Message-ID: On Mon, 24 Jun 2013, Zev Weiss wrote: > Hi, > > About a year and a half ago I brought up the topic of encrypted hostkeys > and posted a patch > (http://marc.info/?l=openssh-unix-dev&m=132774431906364&w=2), and while the > general reaction seemed receptive to the idea, a few problems were pointed > out with the implementation (UI issues, ssh-keysign breakage). > > I've finally had some spare time in which to get back to this, and I've > written a new patch which has the daemon talking to an ssh-agent for > private key operations, as suggested in the previous conversation -- the > current version of the patch can be found below. Wow - thanks! This was on my list of things to do and I'm very glad that you beat me to it. Could I ask you to create a bug at https://bugzilla.mindrot.org/ and attach your patch and the below comments there so we can track and review them? > And, assuming things look OK thus far, I'm considering how best to handle > the ssh-keysign problem. Since it's executed by a user's ssh client, it > won't have the server's SSH_AUTH_SOCK environment variable, so finding the > socket to connect to is slightly tricky -- any problems with changing it to > a (configurable) static, globally-known path? Assuming not, then there's > the question of *where* that would be configured -- sshd would need to know > it, but ssh-keysign reads ssh_config, not sshd_config; requiring the user > to configure the same path in both seems undesirable, as does having either > one loading the other's config file. I guess making it compile-time > configurable would sort of work, but also doesn't seem like a great > solution. Any thoughts or suggestions on this? Having a static, > configurable socket path does seem nice otherwise, so sshd could just spawn > its own agent passing "-a $SOCKETPATH" if it encounters an encrypted > hostkey on startup, rather than, say, relying on an init script to launch > ssh-agent and export the SSH_AUTH_SOCK variable to sshd (though I suppose > there's really nothing stopping it from doing that anyway without a static > socket path). I think it is down to adding another ssh_config option to configure a well- known agent socket for ssh-keysign or making ssh-keysign read sshd_config too. The latter might be desirable, since then it could detect which keys are actually in use. That being said, making it read ssh_config would be more flexible if people ran multiple ssh instances on their hosts. Maybe there is some third option that hasn't occurred to me... -d From zev at bewilderbeest.net Wed Jun 26 13:18:10 2013 From: zev at bewilderbeest.net (Zev Weiss) Date: Tue, 25 Jun 2013 20:18:10 -0700 Subject: RFC: encrypted hostkeys patch In-Reply-To: References: <20130625050606.GA21458@hatter.bewilderbeest.net> Message-ID: <20130626031806.GB21458@hatter.bewilderbeest.net> On Tue, Jun 25, 2013 at 09:29:19PM +1000, Damien Miller wrote: > On Mon, 24 Jun 2013, Zev Weiss wrote: > > > Hi, > > > > About a year and a half ago I brought up the topic of encrypted hostkeys > > and posted a patch > > (http://marc.info/?l=openssh-unix-dev&m=132774431906364&w=2), and while the > > general reaction seemed receptive to the idea, a few problems were pointed > > out with the implementation (UI issues, ssh-keysign breakage). > > > > I've finally had some spare time in which to get back to this, and I've > > written a new patch which has the daemon talking to an ssh-agent for > > private key operations, as suggested in the previous conversation -- the > > current version of the patch can be found below. > > Wow - thanks! This was on my list of things to do and I'm very glad > that you beat me to it. > > Could I ask you to create a bug at https://bugzilla.mindrot.org/ and > attach your patch and the below comments there so we can track and review > them? > Sure -- I've resurrected the existing bugzilla entry from my earlier attempt: https://bugzilla.mindrot.org/show_bug.cgi?id=1974 (I'll add further stuff there, unless an entirely new entry is actually preferable.) Zev From mfriedl at gmail.com Thu Jun 27 04:57:59 2013 From: mfriedl at gmail.com (Markus Friedl) Date: Wed, 26 Jun 2013 20:57:59 +0200 Subject: RFC: encrypted hostkeys patch In-Reply-To: <20130626031806.GB21458@hatter.bewilderbeest.net> References: <20130625050606.GA21458@hatter.bewilderbeest.net> <20130626031806.GB21458@hatter.bewilderbeest.net> Message-ID: <537FFF54-8EE7-495F-9D29-CB490E253CFE@gmail.com> nice! I might have a look at this next week. Am 26.06.2013 um 05:18 schrieb Zev Weiss : > On Tue, Jun 25, 2013 at 09:29:19PM +1000, Damien Miller wrote: >> On Mon, 24 Jun 2013, Zev Weiss wrote: >> >>> Hi, >>> >>> About a year and a half ago I brought up the topic of encrypted hostkeys >>> and posted a patch >>> (http://marc.info/?l=openssh-unix-dev&m=132774431906364&w=2), and while the >>> general reaction seemed receptive to the idea, a few problems were pointed >>> out with the implementation (UI issues, ssh-keysign breakage). >>> >>> I've finally had some spare time in which to get back to this, and I've >>> written a new patch which has the daemon talking to an ssh-agent for >>> private key operations, as suggested in the previous conversation -- the >>> current version of the patch can be found below. >> >> Wow - thanks! This was on my list of things to do and I'm very glad >> that you beat me to it. >> >> Could I ask you to create a bug at https://bugzilla.mindrot.org/ and >> attach your patch and the below comments there so we can track and review >> them? >> > > Sure -- I've resurrected the existing bugzilla entry from my earlier > attempt: https://bugzilla.mindrot.org/show_bug.cgi?id=1974 > > (I'll add further stuff there, unless an entirely new entry is actually > preferable.) > > Zev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Thu Jun 27 11:47:04 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 27 Jun 2013 11:47:04 +1000 (EST) Subject: RFC: encrypted hostkeys patch In-Reply-To: <20130626031806.GB21458@hatter.bewilderbeest.net> References: <20130625050606.GA21458@hatter.bewilderbeest.net> <20130626031806.GB21458@hatter.bewilderbeest.net> Message-ID: On Tue, 25 Jun 2013, Zev Weiss wrote: > Sure -- I've resurrected the existing bugzilla entry from my earlier > attempt: https://bugzilla.mindrot.org/show_bug.cgi?id=1974 Thanks - I'd forgotten that you already had a bug open for this. Making host keys available via the agent also solves another recent feature request: host keys held in a PKCS#11 token. -d From lkppo at free.fr Fri Jun 28 10:26:41 2013 From: lkppo at free.fr (=?utf-8?B?U3TDqXBoYW5l?= Aulery) Date: Fri, 28 Jun 2013 02:26:41 +0200 Subject: Fix a typo in sshd.8 Message-ID: <20130628002641.GA3717@free.fr> Hello, Attached is a patch for a typo in the manpage sshd.8. Regards, -- St?phane Aulery -------------- next part -------------- A non-text attachment was scrubbed... Name: typo_sshd.8.patch Type: text/x-diff Size: 542 bytes Desc: not available URL: