search for: envstring

Hi, I worked with puppet (< 0.25) back in 2008/2009. We were able to deploy 200 servers from scratch and manage them. It worked fine. I''m now with a new customer and I''m pushing Puppet (and I''m also back to puppet on a side project). We''re considering Puppet 2.6 to manage RHEL/CentOS 5 or 6 hosts. I''m "upgrading myself" to Puppet

...ions.h --- 3_0_2p1.1/auth-options.h Wed, 21 Nov 2001 10:38:46 -0500 +++ 3_0_2p1_w_named_keys.1(w)/auth-options.h Thu, 24 Jan 2002 10:52:24 -0500 @@ -16,6 +16,8 @@ #ifndef AUTH_OPTIONS_H #define AUTH_OPTIONS_H +#include "key.h" + /* Linked list of custom environment strings */ struct envstring { struct envstring *next; @@ -31,6 +33,8 @@ extern struct envstring *custom_environment; int auth_parse_options(struct passwd *, char *, char *, u_long); +void auth_set_key_env(Key *k); void auth_clear_options(void); + #endif Index: 3_0_2p1.1/auth-options.c --- 3_0_2p1.1/auth-options.c We...

[Mod: Sent to linux-security instead of linux alert -- alex] Dave G. <daveg@ESCAPE.COM> wrote: > /* vixie crontab buffer overflow for RedHat Linux > * > * I dont think too many people know that redhat uses vixie crontab. > * I didn''t find this, just exploited it. The vulnerability involves an unguarded sscanf call in env.c. Enlarging the buffer to the largest

.../k/21_auth-optio 1.1 644) +++ 2_9_p2_w_named_keys.2/auth-options.h Tue, 03 Jul 2001 13:57:30 -0400 willian (OpenSSH/k/21_auth-optio 1.1.1.1 644) @@ -16,6 +16,8 @@ #ifndef AUTH_OPTIONS_H #define AUTH_OPTIONS_H +#include "key.h" + /* Linked list of custom environment strings */ struct envstring { struct envstring *next; @@ -37,6 +39,9 @@ int auth_parse_options(struct passwd *pw, char *options, char *file, u_long linenum); + +void +auth_set_key_env(Key *k); /* reset options flags */ void auth_clear_options(void); Index: 2_9_p2.1/auth-options.c --- 2_9_p2.1/auth-options.c Thu,...

...ions.c Sun Mar 18 16:13:47 2001 +++ openssh-2.9p2_forceshell/auth-options.c Wed Oct 3 09:57:24 2001 @@ -29,6 +29,8 @@ /* "command=" option. */ char *forced_command = NULL; +/* "shell=" option. */ +char *forced_shell = NULL; /* "environment=" options. */ struct envstring *custom_environment = NULL; @@ -98,6 +100,35 @@ packet_send_debug("Pty allocation disabled."); no_pty_flag = 1; opts += strlen(cp); + goto next_option; + } + cp = "shell=\""; + if (strncasecmp(opts, cp, strlen(cp)) == 0) { + opts += strlen(cp); + forced...

Hi. To compartmentalize things a bit (e.g., to help limit the damage should one of my machines be hacked and my private RSA keys stolen) I use different RSA key pairs on my different client machines. So it occurs to me that it would be nice if ssh could log which key was used when logging in to a particular account that has more than one entry in .ssh/authorized_keys. Right now it simply says

On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl> wrote: > On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Hi Paweł, > > > > Thanks for continuing this discussion. > > > > I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”.

Hi Paweł, Thanks for continuing this discussion. I like the simplicity of your suggestion. My only concern involves the ambiguity of what is meant by “environment”. Presently there are functions in the llvm::Triple class to access the environment as an enumeration of a fixed set of values. It seems that some non-enumerated values are already in use, but introducing possible combinations of

...5 +++ auth-options.c 24 Jul 2002 16:55:25 -0000 @@ -133,7 +133,8 @@ goto next_option; } cp = "environment=\""; - if (strncasecmp(opts, cp, strlen(cp)) == 0) { + if (options.permit_user_env && + strncasecmp(opts, cp, strlen(cp)) == 0) { char *s; struct envstring *new_envstring; --- session.c 22 Jul 2002 11:03:06 -0000 1.145 +++ session.c 24 Jul 2002 16:55:27 -0000 @@ -899,7 +899,7 @@ auth_sock_name); /* read $HOME/.ssh/environment. */ - if (!options.use_login) { + if (options.permit_user_env && !options.use_login) { snprintf(buf, si...

On Fri, Aug 17, 2012 at 12:16 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Hi Paweł,**** > > ** ** > > Thanks for continuing this discussion.**** > > ** ** > > I like the simplicity of your suggestion. My only concern involves the > ambiguity of what is meant by “environment”. Presently there are functions > in the llvm::Triple class to access

ping From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Tuesday, August 28, 2012 11:10 AM To: Jim Grosbach; Pawel Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu) Subject: Re: [LLVMdev] RFC: MCJIT enhancements Has anything more happened with this? -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent:

Has anything more happened with this? -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Friday, August 17, 2012 7:51 AM To: Paweł Bylica; Chris Lattner Cc: llvmdev at cs.uiuc.edu (LLVMdev at cs.uiuc.edu); Kaylor, Andrew Subject: Re: [LLVMdev] RFC: MCJIT enhancements On Aug 17, 2012, at 2:50 AM, Paweł Bylica <pawel.bylica at ibs.org.pl<mailto:pawel.bylica at ibs.org.pl>>

...-2.1.0p2/session.c Wed May 24 12:56:12 2000 @@ -96,6 +96,7 @@ /* RSA authentication "command=" option. */ char *forced_command = NULL; +char *original_command = NULL; /* original command from protocol. */ /* LEE */ /* RSA authentication "environment=" options. */ struct envstring *custom_environment = NULL; @@ -343,6 +344,7 @@ packet_integrity_check(plen, 0, type); } if (forced_command != NULL) { + original_command = command; command = forced_command; debug("Forced command '%.500s'", forced_command); } @@ -911,6 +913,8 @@ c...

Chris, are you OK with the below changes to the Triple? -Jim On Sep 4, 2012, at 5:21 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > ping > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew > Sent: Tuesday, August 28, 2012 11:10 AM > To: Jim Grosbach; Pawel Bylica; Chris Lattner > Cc: llvmdev

On Sep 4, 2012, at 5:23 PM, Jim Grosbach <grosbach at apple.com> wrote: > Chris, are you OK with the below changes to the Triple? If at all possible, I'd like to keep the triple changes separate (separate patch series and separate discussion) from the other MCJIT changes. How dependent are the MCJIT improvements on the Triple changes? As you've noticed, Triple is not a

Attached is a patch which adds a log= directive to authorized_keys. The text in the log="text" directive is appended to the log line, so you can easily tell which key is matched. For instance the line: log="hello world!",no-agent-forwarding,command="/bin/true",no-pty, no-user-rc,no-X11-forwarding,permitopen="127.0.0.1:7" ssh-rsa AAAAB3Nza....xcgaK9xXoU=

On Wed, Jul 25, 2012 at 12:24 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > > -------------------------------**** > > ELF Support on Windows**** > > -------------------------------**** > > **** > > There are various reasons that it would be nice to be able to support > generation of ELF objects on Windows through the MCJIT interface, one of >

The other MCJIT improvements aren’t dependent on the triple changes at all. The reason that this came up in the context of MCJIT is that the quickest way to get MCJIT support on Windows is to enable the generation of ELF object images on Windows. We previously proposed a minimal approach of just adding “ELF” to the recognized triple environment strings. This is the way that MachO generation is

...th-options.c 29 Jan 2003 20:39:19 -0000 1.7 @@ -133,7 +135,7 @@ goto next_option; } cp = "environment=\""; - if (options.permit_user_env && + if (!auth_restricted(RESTRICT_ENV, pw) && strncasecmp(opts, cp, strlen(cp)) == 0) { char *s; struct envstring *new_envstring; @@ -217,8 +219,6 @@ } cp = "permitopen=\""; if (strncasecmp(opts, cp, strlen(cp)) == 0) { - char host[256], sport[6]; - u_short port; char *patterns = xmalloc(strlen(opts) + 1); opts += strlen(cp); @@ -243,8 +243,7 @@ } patterns[i] = 0;...

If I am trying to build OpenSSH 6.6 with Kerberos GSSAPI support, do I still need to get Simon Wilkinson's patches? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |