OpenSSH standard

[Jeroen van Meeuwen]

Hi there,

A few thoughts on the OpenSSH standard in development right now;

I'm thinking about including the following topics:

- OpenSSH Server Configuration Standard (partly done)
  - host keys
  - access control (AllowUsers, AllowGroups, etc)
  - ssh gateway in DMZ setup
  - auditing (pam_abl, denyhosts, insert-your-favorite here)

- OpenSSH Client Configuration Standard
  - host client configuration (/etc/ssh/ssh_config)
  - ssh-agent
  - XForwarding
  - tunneling principles
  - ssh-agent forwarding

This though is all a bit over my head; I've done most, but not all, and 
I'm not in a position to think of a standard on all of these topics. 
Hence this mail; is there anyone in our little group right now that can 
think of anything I need to pay some special attention to?

Kind regards,

Jeroen van Meeuwen
-kanarip

[Stephen John Smoogen]

On Fri, Jul 11, 2008 at 12:06 AM, Jeroen van Meeuwen
<kanarip(a)kanarip.com&gt; wrote:
>  Hi there,
>
>  A few thoughts on the OpenSSH standard in development right now;
>
>  I'm thinking about including the following topics:
>
>  - OpenSSH Server Configuration Standard (partly done)
>   - host keys
>   - access control (AllowUsers, AllowGroups, etc)
>   - ssh gateway in DMZ setup
>   - auditing (pam_abl, denyhosts, insert-your-favorite here)
>
>  - OpenSSH Client Configuration Standard
>   - host client configuration (/etc/ssh/ssh_config)
>   - ssh-agent
>   - XForwarding
>   - tunneling principles
>   - ssh-agent forwarding
>  
Kerberos is one of the things I found worked really well. getting it
configured was a bit of a pain (especially when the cool kerberos bits
werent in openbsd proper).

One of the items that we usually had to do was deploy the same version
of openssh on all our boxes so I would have to compile sshd for
2.1,3,4, etc to make sure that the version was the same and that they
all had the same 'extra' patches in the case of our cluster builds.

Having ssh 'proxy' systems was also interesting. We had to have
control of outgoing connections from some networks (you actually may
not want your financial system computers to have ssh channels where
someone is tunneling out the financials.). That is more into the
security policy items. [And the silly things people will do to get
work done at home when they were told to never take it out the
company.]


>  This though is all a bit over my head; I've done most, but not
> all, and
>  I'm not in a position to think of a standard on all of these topics.
>  Hence this mail; is there anyone in our little group right now that can
>  think of anything I need to pay some special attention to?
>
>  Kind regards,
>
>  Jeroen van Meeuwen
>  -kanarip
>
>  _______________________________________________
>  csi-devel mailing list
>  csi-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/csi-devel
>  


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Mike McGrath]

On Fri, 11 Jul 2008, Stephen John Smoogen wrote:

>  On Fri, Jul 11, 2008 at 12:06 AM, Jeroen van Meeuwen
>  <kanarip(a)kanarip.com&gt; wrote:
>  > Hi there,
>  >
>  > A few thoughts on the OpenSSH standard in development right now;
>  >
>  > I'm thinking about including the following topics:
>  >
>  > - OpenSSH Server Configuration Standard (partly done)
>  >  - host keys
>  >  - access control (AllowUsers, AllowGroups, etc)
>  >  - ssh gateway in DMZ setup
>  >  - auditing (pam_abl, denyhosts, insert-your-favorite here)
>  >
>  > - OpenSSH Client Configuration Standard
>  >  - host client configuration (/etc/ssh/ssh_config)
>  >  - ssh-agent
>  >  - XForwarding
>  >  - tunneling principles
>  >  - ssh-agent forwarding
>  >
>
>  Kerberos is one of the things I found worked really well. getting it
>  configured was a bit of a pain (especially when the cool kerberos bits
>  werent in openbsd proper).
>  
I debated whether or not to include auth bits in the standard or not and
for now have left it off.  I was hoping to make the standard that would
work with multiple auth mechanisms.

>  One of the items that we usually had to do was deploy the same
> version
>  of openssh on all our boxes so I would have to compile sshd for
>  2.1,3,4, etc to make sure that the version was the same and that they
>  all had the same 'extra' patches in the case of our cluster builds.
>
>  Having ssh 'proxy' systems was also interesting. We had to have
>  control of outgoing connections from some networks (you actually may
>  not want your financial system computers to have ssh channels where
>  someone is tunneling out the financials.). That is more into the
>  security policy items. [And the silly things people will do to get
>  work done at home when they were told to never take it out the
>  company.]
>  
Yeah, right now what I've written in the OpenSSH standard is a base
layout.  I do have some other questions like whether or not its proper to
track all known host keys.  I've never been in an environment that has
done it but that seems like the 'right' way to do it.

	-Mike

[Jeroen van Meeuwen]

Mike McGrath wrote:
> > Kerberos is one of the things I found worked really well. getting
> it
> > configured was a bit of a pain (especially when the cool kerberos bits
> > werent in openbsd proper).
> >
>  
>  I debated whether or not to include auth bits in the standard or not and
>  for now have left it off.  I was hoping to make the standard that would
>  work with multiple auth mechanisms.
>   
I don't think actual authentication configuration is suitable for the 
OpenSSH standard. We might link to a security, SSO or general 
Authentication configuration standard instead - to point out that we 
have it and have thought about it... only to show the specific related 
OpenSSH in the HOWTO part on one of the documents - if there is ever 
going to be one for both such document.

Darn I hate speculating... ;-)

> > One of the items that we usually had to do was deploy the same
> version
> > of openssh on all our boxes so I would have to compile sshd for
> > 2.1,3,4, etc to make sure that the version was the same and that they
> > all had the same 'extra' patches in the case of our cluster builds.
> >
> > Having ssh 'proxy' systems was also interesting. We had to have
> > control of outgoing connections from some networks (you actually may
> > not want your financial system computers to have ssh channels where
> > someone is tunneling out the financials.). That is more into the
> > security policy items. [And the silly things people will do to get
> > work done at home when they were told to never take it out the
> > company.]
> >
>  
>  Yeah, right now what I've written in the OpenSSH standard is a base
>  layout.  I do have some other questions like whether or not its proper to
>  track all known host keys.  I've never been in an environment that has
>  done it but that seems like the 'right' way to do it.
>   
There's arguments in favor of tracking these host bits, and there's 
arguments against it... (I think) Generally it depends on the type of 
environment you're in and whether these things form some type of problem 
for you when they change.

What you'd want to do on a running system however, is ensure they are 
consistent (again, I think). I also think you would want to prevent them 
from changing if there's a billion users in trouble with 
~/.ssh/known_hosts having the wrong fingerprint. Some machines use them 
as a form of authentication (in which case again you wouldn't want them 
to change -not even after a re-installation).

Again, these are just some thoughts and will help us define the standard ;-)

Kind regards,

Jeroen van Meeuwen
-kanarip

[Stephen John Smoogen]

On Sat, Jul 12, 2008 at 10:12 AM, Jeroen van Meeuwen
<kanarip(a)kanarip.com&gt; wrote:
>  Mike McGrath wrote:
> >> Kerberos is one of the things I found worked really well. getting it
> >> configured was a bit of a pain (especially when the cool kerberos bits
> >> werent in openbsd proper).
> >>
> >
> > I debated whether or not to include auth bits in the standard or not and
> > for now have left it off.  I was hoping to make the standard that would
> > work with multiple auth mechanisms.
> >
>
>  I don't think actual authentication configuration is suitable for the
>  OpenSSH standard. We might link to a security, SSO or general
>  Authentication configuration standard instead - to point out that we
>  have it and have thought about it... only to show the specific related
>  OpenSSH in the HOWTO part on one of the documents - if there is ever
>  going to be one for both such document.
>
>  Darn I hate speculating... ;-)
>  
Thinking about it in the weekend, i have to agree. i guess we need the
equivalent of basic configuration and addendums that are linked to
other parts. if you set up a 'ipa' system you need to have these
changes done, etc etc.

> >> One of the items that we usually had to do was deploy the
> same version
> >> of openssh on all our boxes so I would have to compile sshd for
> >> 2.1,3,4, etc to make sure that the version was the same and that they
> >> all had the same 'extra' patches in the case of our cluster builds.
> >>
> >> Having ssh 'proxy' systems was also interesting. We had to have
> >> control of outgoing connections from some networks (you actually may
> >> not want your financial system computers to have ssh channels where
> >> someone is tunneling out the financials.). That is more into the
> >> security policy items. [And the silly things people will do to get
> >> work done at home when they were told to never take it out the
> >> company.]
> >>
> >
> > Yeah, right now what I've written in the OpenSSH standard is a base
> > layout.  I do have some other questions like whether or not its proper to
> > track all known host keys.  I've never been in an environment that has
> > done it but that seems like the 'right' way to do it.
> >
>
>  There's arguments in favor of tracking these host bits, and there's
>  arguments against it... (I think) Generally it depends on the type of
>  environment you're in and whether these things form some type of problem
>  for you when they change.
>
>  What you'd want to do on a running system however, is ensure they are
>  consistent (again, I think). I also think you would want to prevent them
>  from changing if there's a billion users in trouble with
>  ~/.ssh/known_hosts having the wrong fingerprint. Some machines use them
>  as a form of authentication (in which case again you wouldn't want them
>  to change -not even after a re-installation).
>
>  Again, these are just some thoughts and will help us define the standard ;-)
>
>  Kind regards,
>
>  Jeroen van Meeuwen
>  -kanarip
>  _______________________________________________
>  csi-devel mailing list
>  csi-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/csi-devel
>  


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"