Re: Security question and using scp

[Larry Ploetz]

On 1/22/09 4:38 PM, John Summerfield wrote:

Larry Ploetz wrote:

Scott Rohling _/*DID NOT*/_ wrote:


If I must configure bind, maybe I need a text editor. If I can use a
text editor maybe I can edit /etc/sudoers

I said that


That's what sudoedit (not visudoers!) is for.


The point is that I can actually use any editor I like, so long as I get
it right. I have actually used at least one of ed, ex and sed, I edit it
in my kickstart %post section.



I may very well be missing the point entirely, but am trying to point 
out that if anyone needs to be able to edit system (or other users') 
configuration files, but should not become root to do so (so they can't 
use shell escapes to run any command as root), sudoedit securely makes a 
copy of the file(s) the sudo user is allowed to edit into /tmp, runs the 
sudo user's editor-of-choice as the sudo user with no escalated 
privileges, checks to see if any changes were made and if so, securely 
copies the file back to the correct place -- no exposure WRT file 
maintenance (of course, if you allow someone to sudoedit /etc/passwd, 
/etc/shadow or /etc/sudoers you've got a Gaping Hole©, but that's not 
sudoedit's fault, that's yours). Assuming sudo is properly configured to 
allow the sudo user to run sudoedit, on the file(s) that user is 
specifically allowed to edit (e.g., bind configuration).

--

  
*

Larry Ploetz
Systems Administrator
Carnegie Institution of Washington
Department of Plant Biology
The Arabidopsis Information Resource
650 325 1521 x 296 la...@tairgroup.org *

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Rob van der Heij]

On Fri, Jan 23, 2009 at 1:43 AM, John Summerfield
 wrote:

>> With sudo you get the privileged commands in the system logging and it
>> is much easier to understand what happened and who is to blame.
>
> As I've pointed out before, unless you're really careful it's easily
> circumvented, and sometimes allowing someone to do one thing (eg manage
> linux user accounts) may allow them more privilege than they should have
> (eg create a privileged account and misuse it).

Oh sure. I don't give much for the granularity that you can introduce
to do per-command authorization with sudo for some people. We used it
as big hammer with syslog. And when someone felt the desire to invoke
a script of his own under sudo (and thus hide everything that happens
inside) he would be taken outside for some education. Clearly "sudo su
-" would be a very obvious one to frown upon. Just because you should
leave trails for your coworkers.

Rob

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Adam Thornton]

On Jan 22, 2009, at 6:38 PM, John Summerfield wrote:


Larry Ploetz wrote:

Scott Rohling wrote:


If I must configure bind, maybe I need a text editor. If I can use a
text editor maybe I can edit /etc/sudoers

I said that


That's what sudoedit (not visudoers!) is for.


The point is that I can actually use any editor I like, so long as I
get
it right. I have actually used at least one of ed, ex and sed, I
edit it
in my kickstart %post section.


Well, yeah, but you should do that by setting your EDITOR environment
variable and running visudo (or, I guess, sudoedit), which, despite
the name, does respect the value of $EDITOR.  It also does all the
appropriate locking and atomic updating to ensure that the file is
safely editing, which just smacking a text editor onto /etc/sudoers
doesn't.

Adam

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[John Summerfield]

Rob van der Heij wrote:

On Thu, Jan 22, 2009 at 7:03 PM, Mark Post  wrote:


Second, as John Summerfield has pointed out, by default no indication of what 
public/private key pair was used for authentication is logged.  To get _that_ 
to happen, and to be able to correlate who signed in, then the default of 
LogLevel INFO needs to be changed to LogLevel VERBOSE.  Once that is done, you 
get syslog entries such as


True. We actually made a modification to sshd to display the comments
field from the key that was matched. But as I pointed out earlier in
this thread, we avoided using the root account entirely (except for
extreme emergencies).

But this approach still has most of the problems of shared userids.
When two people have both logged in as root with their own cryptic key
pair, you will be mostly puzzled which of them did the things that
turned out to be a problem (because the PID of the shell is not part
of most auditing).

With sudo you get the privileged commands in the system logging and it
is much easier to understand what happened and who is to blame.


As I've pointed out before, unless you're really careful it's easily
circumvented, and sometimes allowing someone to do one thing (eg manage
linux user accounts) may allow them more privilege than they should have
(eg create a privileged account and misuse it).

--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[John Summerfield]

Larry Ploetz wrote:

Scott Rohling wrote:


If I must configure bind, maybe I need a text editor. If I can use a
text editor maybe I can edit /etc/sudoers

I said that


That's what sudoedit (not visudoers!) is for.


The point is that I can actually use any editor I like, so long as I get
it right. I have actually used at least one of ed, ex and sed, I edit it
in my kickstart %post section.

--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Mark Post]

>>> On 1/22/2009 at  3:31 PM, Rob van der Heij  wrote: 
-snip-
> But this approach still has most of the problems of shared userids.
> When two people have both logged in as root with their own cryptic key
> pair, you will be mostly puzzled which of them did the things that
> turned out to be a problem (because the PID of the shell is not part
> of most auditing).
> 
> With sudo you get the privileged commands in the system logging and it
> is much easier to understand what happened and who is to blame.

Agreed.  Just pointing out some gaps in what was being tossed back and forth.


Mark

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Rob van der Heij]

On Thu, Jan 22, 2009 at 7:03 PM, Mark Post  wrote:

> Second, as John Summerfield has pointed out, by default no indication of what 
> public/private key pair was used for authentication is logged.  To get _that_ 
> to happen, and to be able to correlate who signed in, then the default of 
> LogLevel INFO needs to be changed to LogLevel VERBOSE.  Once that is done, 
> you get syslog entries such as

True. We actually made a modification to sshd to display the comments
field from the key that was matched. But as I pointed out earlier in
this thread, we avoided using the root account entirely (except for
extreme emergencies).

But this approach still has most of the problems of shared userids.
When two people have both logged in as root with their own cryptic key
pair, you will be mostly puzzled which of them did the things that
turned out to be a problem (because the PID of the shell is not part
of most auditing).

With sudo you get the privileged commands in the system logging and it
is much easier to understand what happened and who is to blame.

Rob

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Scott Rohling]

For the record - I didn't write that ;-)

On Thu, Jan 22, 2009 at 1:18 PM, Larry Ploetz  wrote:

> Scott Rohling wrote:
>
>>
>> If I must configure bind, maybe I need a text editor. If I can use a
>> text editor maybe I can edit /etc/sudoers
>>
>
> That's what sudoedit (not visudoers!) is for.
>
> - Larry
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Larry Ploetz]

Scott Rohling wrote:


If I must configure bind, maybe I need a text editor. If I can use a
text editor maybe I can edit /etc/sudoers


That's what sudoedit (not visudoers!) is for.

- Larry

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Mark Post]

>>> On 1/22/2009 at 12:26 PM, Alan Altmark  wrote: 
-snip-
> As the file containing the public keys is not
> encrypted, you have no idea who might be in possession of it.

The whole idea of a public key is that it _is_ public.  Anyone can be in 
possession of it, and I don't care.  If they're foolish enough to stick that 
key into a ~/.ssh/authorized_keys file, that doesn't do _me_ any harm, but I 
might do _them_ some harm by logging in and messing around with their system.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Mark Post]

>>> On 1/22/2009 at 12:26 PM, Alan Altmark  wrote: 
> On Thursday, 01/22/2009 at 11:06 EST, John Summerfield
>  wrote:
> 
>> Auditors like to think they know who did things. If I connect to your
>> system using ssh, how do you know it's me? All you know is that someone
>> connected using a public key you've approved.
> 
> Because you (should) have 'PubKeyAuthentication YES' on each server you
> will access.  That will cause a signature to be generated using your
> matching private key, which is only on your home system(s).  That, in
> turn, requires you to enter the password you used during ssh-keygen.

Two notes...  PubkeyAuthentication simply _allows_ (or denies) people to log in 
via public key authentication.  It doesn't turn that authentication on or off 
while still allowing people to log in via those keys.  The default is "yes."

Second, as John Summerfield has pointed out, by default no indication of what 
public/private key pair was used for authentication is logged.  To get _that_ 
to happen, and to be able to correlate who signed in, then the default of 
LogLevel INFO needs to be changed to LogLevel VERBOSE.  Once that is done, you 
get syslog entries such as
Jan 22 12:54:41 git390 sshd[24776]: Found matching DSA key: 
20:fd:b3:0f:e3:9f:fa:e7:7c:d9:14:a4:7b:aa:dc:78
Jan 22 12:54:42 git390 sshd[24776]: Accepted publickey for root from 
xxx.xxx.xxx.xxx port 22663 ssh2

I don't know what all else might get generated in the logs for other events by 
setting LogLevel VERBOSE, but in this particular instance, not much.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Adam Thornton]

On Jan 22, 2009, at 10:49 AM, Jack Woehr wrote:



The normal practice is the Unix world is to disallow ssh logins to
root ...
root users must log in under a user account and su or sudo to root.


I'd be leery of saying that is necessarily "normal practice."

There's a lot of variation in the Unix world.

For instance, a lot of machines I've seen don't do this precisely
because there are no user accounts.  Just system accounts used to run
various services.  Granted, in those cases, it would probably be
better to add a support account everywhere, allow ssh to a support
account and force support to sudo, but in this day and age, you really
can't count on "user accounts" anymore, since almost all interaction
with systems is via network-exposed services rather than an actual
login shell.

Adam

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[John Summerfield]

Alan Altmark wrote:

On Thursday, 01/22/2009 at 11:06 EST, John Summerfield
 wrote:


Auditors like to think they know who did things. If I connect to your
system using ssh, how do you know it's me? All you know is that someone
connected using a public key you've approved.


Because you (should) have 'PubKeyAuthentication YES' on each server you

yes


will access.  That will cause a signature to be generated using your
matching private key, which is only on your home system(s).  That, in
turn, requires you to enter the password you used during ssh-keygen.


yes
Mine's null, but never mind.

To avoid having to enter your private-key-encrypting password each time
you ssh to a host, you use ssh-agent (maybe with something like keychain)
so that you only enter your password once per local login session.  You
can also cause in-memory keys are purged after 'n' minutes.  Hint: Don't
use the same password for each keygen and don't use the same password as
your login password, though the latter isn't too much of a problem since
you change your own password at defined intervals.

If you don't authenticate a user's public key, then its value is
significantly reduced.  As the file containing the public keys is not
encrypted, you have no idea who might be in possession of it.


Now just what identifies who logged in here just now?
02:28:26 r...@mail.office.lan ~ # tail /var/log/auth.log| grep ssh
Jan 23 02:28:01 mail sshd[4533]: Accepted publickey for root from
192.168.9.131 port 54877 ssh2
Jan 23 02:28:01 mail sshd[4535]: (pam_unix) session opened for user root
by root(uid=0)
02:30:33 r...@mail.office.lan ~ # grep -i pub /etc/ssh/sshd_config
PubkeyAuthentication yes
02:30:38 r...@mail.office.lan ~ #

The system in question's running Debian, but I don't think that makes a
difference.


--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Alan Altmark]

On Thursday, 01/22/2009 at 11:06 EST, John Summerfield
 wrote:

> Auditors like to think they know who did things. If I connect to your
> system using ssh, how do you know it's me? All you know is that someone
> connected using a public key you've approved.

Because you (should) have 'PubKeyAuthentication YES' on each server you
will access.  That will cause a signature to be generated using your
matching private key, which is only on your home system(s).  That, in
turn, requires you to enter the password you used during ssh-keygen.

To avoid having to enter your private-key-encrypting password each time
you ssh to a host, you use ssh-agent (maybe with something like keychain)
so that you only enter your password once per local login session.  You
can also cause in-memory keys are purged after 'n' minutes.  Hint: Don't
use the same password for each keygen and don't use the same password as
your login password, though the latter isn't too much of a problem since
you change your own password at defined intervals.

If you don't authenticate a user's public key, then its value is
significantly reduced.  As the file containing the public keys is not
encrypted, you have no idea who might be in possession of it.

Alan Altmark
z/VM Development
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[John Summerfield]

Rob van der Heij wrote:

On Mon, Jan 19, 2009 at 11:35 PM, Alan Altmark  wrote:


:-)  I agree that it is messy.  That's the "reducation" (I meant
"reduction") I was talking about things that map uids to usernames.
They get confused.  Anything that tests for a username of 'root' is broken
already!


That reverse mapping is happening everywhere in Linux. Should we take
"useradd" being unwilling to do so as an omen? Sure, it's just text so
hand-edit the passwd and shadow files (yes, we can).

So do we conclude that using multiple accounts with UID 0 is not a
good idea and certainly does not achieve what you wanted? On the
subject of UID: security gets a lot easier when you can have unique
name and UID across all your servers (that's where a central LDAP
helps a lot).


I created a user fred, with uid=0.

It allowed me to read system log files (it's all I tried). I saw fred
was recorded as having logged in.

Nothing I did was logged.

If I was maliciously inclined, I could have used logger to record a few
bogus messages about Mike, Rob, Adam and a few others logging in, then
logging out. When my more serious misdeeds were discovered later,
there'd be plenty of suspects, and maybe I would not be amongst their
number!




--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Scott Rohling]

>
>
>>> Are your support users prevented from this command?
>>> sudo /bin/bash
>>>
>>
> Are they?
>
>
Can't really say since what I described was implemented long ago and may not
even be used now..
But - no they weren't - neither were they prevented from 'su -' or the other
hundreds of ways you might get access to a shell.   The support id could not
be logged into directly - you could only su to it..  which does give some
indication of 'who' in the logs .. but admittedly could be a messy audit
trail.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Jack Woehr]

John Summerfield wrote:


If you have a dozen public keys in there, how do you know whose key was
used, and that was done?

I quite like the idea of locking root's account


The normal practice is the Unix world is to disallow ssh logins to root ...
root users must log in under a user account and su or sudo to root.

--
Jack J. Woehr# I run for public office from time to time. It's like
http://www.well.com/~jax # working out at the gym, you sweat a lot, don't get
http://www.softwoehr.com # anywhere, and you fall asleep easily afterwards.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[John Summerfield]

Scott Rohling wrote:

I suppose the difference is sudo -- with sudo you have an audit trail of who
issued what.



Sure. Whoever's using the support account at the time.


You can limit what the user can do in /etc/sudoers.   You could make support
only able to issue certain commands..  or you can try excluding commands if
you think you can cover them all.  (I'd argue the only 'safe' way is to
specify what the user can issue - specifying what they 'cannot' issue could
be an endless game).


If I must configure bind, maybe I need a text editor. If I can use a
text editor maybe I can edit /etc/sudoers

People make mistakes, it's in our nature. When it happens, it's probably
not helpful to know (by evidence) who did it. Blaming someone does not
undo the problem and it does not make anyone happier.

What you need to understand is how it happened, and then maybe you need
to change procedures to ensure it doesn't recur, and you need to train
people in the new procedures.

Making sure people can't do bad things, and if they do then catching
them, that's another problem.



Scott

On Thu, Jan 22, 2009 at 9:19 AM, John Summerfield <
deb...@herakles.homelinux.org> wrote:


Scott Rohling wrote:


We implemented this within IBM:

-  created userid 'support' on all Linux guests - made it a 'no login'
user
-  Put support in sudoers to allow commands with NOPASSWD on all guests
-  Distributed the 'authorized_keys' to /home/support/.ssh with  the
support
user's public key on the central system.


so in effect you have dozens (hundreds) of users all called "support."

I use the account name "summer" for most machines I use, but I (almost)
always create new keys on each one, and distribute them where needed.


You haven't explained to my understanding how your account "support"
differs from "root" in controlling what users might do willfully. I can
see it might prevent some accidents.

Are your support users prevented from this command?
sudo /bin/bash


Are they?


--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[John Summerfield]

Rob van der Heij wrote:

On Mon, Jan 19, 2009 at 5:52 AM, Alan Altmark  wrote:


It isn't about passwords, per se.  Rather, many (most?) sites prohibit
remote login of root *by any means*.


The sad thing about such directives is that they live much longer than
the person who initially dictated them (and still might know the
motivation behind this). Once such rules are established, you can't
easily change them anymore.
The two-step approach for root login has nothing to do with
encryption. When you have a plain old telnet session, the root
password that you type still travels over the wire to the system.
The motivation behind the two-step approach is a poor man's approach
to separate authentication and access control. When someone leaves the
department he may still remember the root password, but if you take
away his local account so that knowledge is less useful to him. But
when the root password is commonly known, then the added value of it
is minimal.


_THAT_ is a major flaw in how RHEL is administered. My wife, who has
CentOS 5 on her desktop gets notified of available software updates.

I am not giving her root's password, she has no idea of how to care for
and feed penguins. It would be much better if the sysadmin (me) was
either informed by her system sending me email, or even just left to me
(her's isn't the only CentOS5 system here).

Red Hat expects every administrator to know root's password.


I think "sudo" asking for the root password is in the same range of


That is how SUSE configures sudo, but it's not its default modus
operandi. By default, it asks for the users' own.

SUSE expects every administrator to know root's password.


useless rituals that create the illusion of security. And when you
logged on to the system, asking again for your password is of little
value (more likely to be picked up by the user watching over your


If I give you a program that does evil if run as root, and if there is
no dialogue with you (asking for a password) before it's run, what
prevents it? We're back with the Windows 95 security model.


shoulder). When you're concerned about sessions remaining unsecured
open too long, then address that (by locking the workstation). I don't


Assuming you've kept your password properly secret, requesting your password
1. Ensures you know Something Important is about to happen
2. You approve it.


have high expectations of per-command access granularity implemented
in sudo. But I do appreciate it for the auditing. When you use LDAP to
associate users with groups, it is very easy to handle access control
for sudo as well.

When dealing with folks who need to work in emergency situations
(doctors, system programmers), attempts to limit their access often
creates a lot of discussion (and for a good reason). Those are no
routine tasks and you can't predict all steps needed. In those cases,
I believe strongly in fairly open access for approved staff, combined
with auditing (and justification afterwards). The auditing is also
helpful to diagnose problems and learn from the steps followed to
resolve the problem. System programmers using their access to tamper
with the auditing should be handled with care.

Rob (amateur security weeny)


On a typical Linux PC, might take me as long as five minutes to get past
root's password.

BIOS and/or bootloader passwords make it more difficult, I have to take
the disk out and install it in another machine.

Encryption would probably stop me, but if I'm your sysadmin you cannot
encrypt any filesystems I might need to access, unless someone else is
on hand when needed.

Which all goes to say a system that's good enough to keep the bad
(local) people out's also going to make legitimate work very difficult.


--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Scott Rohling]

I suppose the difference is sudo -- with sudo you have an audit trail of who
issued what.

You can limit what the user can do in /etc/sudoers.   You could make support
only able to issue certain commands..  or you can try excluding commands if
you think you can cover them all.  (I'd argue the only 'safe' way is to
specify what the user can issue - specifying what they 'cannot' issue could
be an endless game).

Scott

On Thu, Jan 22, 2009 at 9:19 AM, John Summerfield <
deb...@herakles.homelinux.org> wrote:

> Scott Rohling wrote:
>
>> We implemented this within IBM:
>>
>> -  created userid 'support' on all Linux guests - made it a 'no login'
>> user
>> -  Put support in sudoers to allow commands with NOPASSWD on all guests
>> -  Distributed the 'authorized_keys' to /home/support/.ssh with  the
>> support
>> user's public key on the central system.
>>
>
> so in effect you have dozens (hundreds) of users all called "support."
>
> I use the account name "summer" for most machines I use, but I (almost)
> always create new keys on each one, and distribute them where needed.
>
>
> You haven't explained to my understanding how your account "support"
> differs from "root" in controlling what users might do willfully. I can
> see it might prevent some accidents.
>
> Are your support users prevented from this command?
> sudo /bin/bash
>
>
>
> --
>
> Cheers
> John
>
> -- spambait
> 1...@coco.merseine.nu  z1...@coco.merseine.nu
> -- Advice
> http://webfoot.com/advice/email.top.php
> http://www.catb.org/~esr/faqs/smart-questions.html
> http://support.microsoft.com/kb/555375
>
> You cannot reply off-list:-)
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[John Summerfield]

Scott Rohling wrote:

Auditors like to think they know who did things. If I connect to your
system using ssh, how do you know it's me? All you know is that someone
connected using a public key you've approved.



That 'someone' who connected has the private key that pairs with the public
key...  that's supposed to be the indicator that it is you.


01:20:21 r...@mail.office.lan ~ # wc -l .ssh/authorized_keys*
   9 .ssh/authorized_keys
   9 .ssh/authorized_keys2
  18 total
01:20:33 r...@mail.office.lan ~ #

I don't recall that anything logs who's logged in as root. Here's what
my system logged just now:


Jan 23 01:20:19 mail sshd[3619]: Accepted publickey for root from
192.168.9.131 port 41855 ssh2
Jan 23 01:20:20 mail sshd[3625]: (pam_unix) session opened for user root
by root(uid=0)



--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[John Summerfield]

Scott Rohling wrote:

We implemented this within IBM:

-  created userid 'support' on all Linux guests - made it a 'no login' user
-  Put support in sudoers to allow commands with NOPASSWD on all guests
-  Distributed the 'authorized_keys' to /home/support/.ssh with  the support
user's public key on the central system.


so in effect you have dozens (hundreds) of users all called "support."

I use the account name "summer" for most machines I use, but I (almost)
always create new keys on each one, and distribute them where needed.


You haven't explained to my understanding how your account "support"
differs from "root" in controlling what users might do willfully. I can
see it might prevent some accidents.

Are your support users prevented from this command?
sudo /bin/bash



--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Scott Rohling]

>
> Auditors like to think they know who did things. If I connect to your
> system using ssh, how do you know it's me? All you know is that someone
> connected using a public key you've approved.
>
>
That 'someone' who connected has the private key that pairs with the public
key...  that's supposed to be the indicator that it is you.

Scott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[John Summerfield]

CHAPLIN, JAMES (CTR) wrote:

Tom Kern from DOE called me with a good solution, using pubkeys and in
the sshd_conf file, set PermitRootLogin to without-password. Did a
google search on " PermitRootLogin  without-password" and got allot of
hits, trying to set up a test right now (phone keeps ringing with other
peoples problem;-0). But this is looking like the best solution. Will
update soon, thanks for the suggestions.

Thanks Tom for pointing me in the right direction.


If you have a dozen public keys in there, how do you know whose key was
used, and that was done?

I quite like the idea of locking root's account, and explaining to the
auditor the door's locked and we've thrown away the key, the point being
there is _no_ password that will allow root to logon.

--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[John Summerfield]

Michael MacIsaac wrote:

Marcy,


Same rule here  (if only some of these vendors (cough ibm/tivoli

cough) would comprehend... )
I'm trying to comprehend, and will also try to bubble the message upwards
in my small sphere of influence.

So let me ask this to the list - what are the rules regarding key-based
authentication?  Is this approach not authorized even though no root (or
any other) passwords goes over the wire?  Or is it just the rule that the
/root/.ssh/authorized_keys file never exist?

If there is no key-based authentication for root allowed, can there be for
non-root users (not sure how much this will help).


Auditors like to think they know who did things. If I connect to your
system using ssh, how do you know it's me? All you know is that someone
connected using a public key you've approved.



One thing I'm looking for is a way that a central Linux system can pull
important data (/etc/fstab /etc/zipl.conf,
/etc/sysconfig/network/ifcfg-qeth-*), and run certain commands remotely on
other Linux systems without the need for someone sitting typing a password
many times.


Most of that stuff is (generally) available to all - the only exceptions
I can think of are secrets such as wireless keys. sshd might have
secrets too.



Systems management tasks need to be automated to scale the number of
servers a single admin can care for, but security rules in certain shops
seem to be preventing that.  There must be some intelligent compromise
(and it's probably involves sudo)


_I_ don't think sudo is as bullet-proof as people think. Certainly, it
needs care to set up to control everything and I've never tried to do that.

Three quick examples.

I can run anything. That meas I can run a shell directly, and so avoid
most of sudo's logging. Sure, you can ask me later, but if I was
deliberately doing something bad I also sanitised logs.

I can't do much, but I can create new user accounts. I create a new
account with uid=0. Now I can do anything I like, and the logs won't
help you either.

I can install software. I can install some backdoor, maybe unpackaged so
rpm doesn't report it.

I'm sure selinux can help here.


Thanks.

"Mike MacIsaac"(845) 433-7061



Oh, decades again, on OS user programs could use WTO to write messages
on the operator console(s). Eventually, someone worked out that
unauthorised (we're talking APF here) should not be able to write
messages indistinguishable from system messages (maybe using WTOR to get
passwords), and from then those messages were prefixed by a plus.

On Linux, writing to syslog a few messages alleging you, Mike MacIsaac,
used the command "/sbin/fdasd /dev/dasda" might cause you some
employment difficulties and/or cause you to disbelieve other messages.






--

Cheers
John

-- spambait
1...@coco.merseine.nu  z1...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Alan Altmark]

On Tuesday, 01/20/2009 at 04:12 EST, Rob van der Heij 
wrote:

> So do we conclude that using multiple accounts with UID 0 is not a
> good idea and certainly does not achieve what you wanted? On the
> subject of UID: security gets a lot easier when you can have unique
> name and UID across all your servers (that's where a central LDAP
> helps a lot).

I concede the point to you, Sir Rob.  The administrative complications
outweigh the benefit.

Alan Altmark
z/VM Development
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[David Boyes]

On 1/20/09 4:08 AM, "Rob van der Heij"  wrote:


> So do we conclude that using multiple accounts with UID 0 is not a
> good idea and certainly does not achieve what you wanted? On the
> subject of UID: security gets a lot easier when you can have unique
> name and UID across all your servers (that's where a central LDAP
> helps a lot).

Just an observation:

Multiple userids with the same UID will confuse NFS something awful (and
keep in mind that there is special-case code in NFS to handle uid 0 in
different ways).

While it bypasses one problem, it creates many, many more. Managing sudo
rules with LDAP is a much better solution.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Rob van der Heij]

On Mon, Jan 19, 2009 at 11:35 PM, Alan Altmark  wrote:

> :-)  I agree that it is messy.  That's the "reducation" (I meant
> "reduction") I was talking about things that map uids to usernames.
> They get confused.  Anything that tests for a username of 'root' is broken
> already!

That reverse mapping is happening everywhere in Linux. Should we take
"useradd" being unwilling to do so as an omen? Sure, it's just text so
hand-edit the passwd and shadow files (yes, we can).

So do we conclude that using multiple accounts with UID 0 is not a
good idea and certainly does not achieve what you wanted? On the
subject of UID: security gets a lot easier when you can have unique
name and UID across all your servers (that's where a central LDAP
helps a lot).

PS If you really want, you could look into MultiAdmin to do what you
tried.No idea how mature that is.

Rob - amateur security weeny

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Alan Altmark]

On Monday, 01/19/2009 at 05:06 EST, Rob van der Heij 
wrote:
> I have heard that suggestion before, and it appears to come from those
> who never tried it. I recall that several things get messy when you
> don't maintain a 1-to-1 mapping of names and uid 0. IIRC the reverse
> mapping goes through the nscd cache and the result will change color
> depending on who is looking. The most scary one is seeing yourself as
> the owner of the file although you never created it. It also breaks
> stuff that tests for root, and &deity knows what.

:-)  I agree that it is messy.  That's the "reducation" (I meant
"reduction") I was talking about things that map uids to usernames.
They get confused.  Anything that tests for a username of 'root' is broken
already!

Alan Altmark
z/VM Development
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Adam Thornton]

On Jan 19, 2009, at 4:05 PM, Rob van der Heij wrote:


I have heard that suggestion before, and it appears to come from those
who never tried it. I recall that several things get messy when you
don't maintain a 1-to-1 mapping of names and uid 0. IIRC the reverse
mapping goes through the nscd cache and the result will change color
depending on who is looking. The most scary one is seeing yourself as
the owner of the file although you never created it. It also breaks
stuff that tests for root, and &deity knows what.


Well, one obvious lesson here is: "Don't ever use nscd because it is
malicious and evil and sucks and lurks under your chair at the movies
and steals your popcorn and gets it all slimy."  Oooh, we hates it.
We hates it forever.  I remember hearing that in some LDAP
environments, nscd really *does* help, but it's caused me much more
harm than it's ever done good.  YMMV.

I have never tried giving out multiple uid 0 users, and the idea makes
me twitchy.  But on the other hand, on many occasions I've had a
second uid 0 user, named "toor", who had a SANE login shell.

I have seen horrifically written software that checks to see if it's
being run by "root" rather than by uid 0.  But then, I've seen things
you people wouldn't believe.  Attack ships on fire off the shoulder of
Orion.  C-beams glittering in the dark near the Tannhauser gate.

Um.

It's really, really not Friday yet, is it?

Adam

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Rob van der Heij]

On Mon, Jan 19, 2009 at 4:23 PM, Alan Altmark  wrote:
>
> There is trust and there is Trust (the latter includes a measure of
> "personal integrity").  For those whom you Trust, root access is
> permitted, but do it by giving them all uid 0, not by sharing passwords.
> Since each user has a different pid, the audit trail can be more closely
> examined to see who did what.  (Watch out for a reducation program that
> gives you a username when you have shared uids.)

I have heard that suggestion before, and it appears to come from those
who never tried it. I recall that several things get messy when you
don't maintain a 1-to-1 mapping of names and uid 0. IIRC the reverse
mapping goes through the nscd cache and the result will change color
depending on who is looking. The most scary one is seeing yourself as
the owner of the file although you never created it. It also breaks
stuff that tests for root, and &deity knows what.

We were perfectly able to manage Linux systems and not use the root
account. Just sudo. As close to logonby and PROP as you can get. If
nothing else, it was good to end discussions when someone brought his
manager to convince us that he needed the root password: there is no
root password.

Most things go easy via sudo, and if you have more complicated things
you can invoke the shell with the -c option to issue one command (that
is being logged clearly). So the audit trail showed who issued what
command. It's not as good as a console log of a VM user that also
shows the output (but then you take care to keep things "visible" for
those that need to follow your steps and not issue commands from
XEDIT).

Rob

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Alan Cox]

> In a previous life I worked at a University that omitted sidewalks from
> a large campus expansion.  Sidewalks were added later, on the most
> "well-worn trails"..  :-)

The masses don't always get it right. A warning story to go with that
one. Locally a planned path ran along a ridge of ground. Everyone took
the shortcut so the council gave in and moved the path.

Now the people who originally built it were smart people. The people who
took the shortcut were optimising for their usual case only. Every time
there was heavy rain the new path became a canal.

Lesson: Even if you believe the people wearing the trails are behaving
rationally the sum of individual optimum choices is not usually the right
answer.

And boy oh boy is that so often true for security...

Alan

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[David Boyes]

On 1/19/09 10:59 AM, "Alan Altmark"  wrote:

> On Monday, 01/19/2009 at 10:47 EST, "Chase, John" 
> wrote:
>> In a previous life I worked at a University that omitted sidewalks from
>> a large campus expansion.  Sidewalks were added later, on the most
>> "well-worn trails"..  :-)
>
> Ahhh.  The Light of Reason peeks through the overcast skies of our
> Existence!

More like temporary (in)sanity. Those individuals responsible have probably
been corrected and demoted.

-db

(who hasn't had any coffee yet today. *grr*)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Alan Altmark]

On Monday, 01/19/2009 at 10:47 EST, "Chase, John" 
wrote:
> In a previous life I worked at a University that omitted sidewalks from
> a large campus expansion.  Sidewalks were added later, on the most
> "well-worn trails"..  :-)

Ahhh.  The Light of Reason peeks through the overcast skies of our
Existence!

Alan Altmark
z/VM Development
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Chase, John]

> -Original Message-
> From: Linux on 390 Port On Behalf Of Alan Altmark
> 
> [ snip ]
> 
> . . .  By making it
> difficult to Do The Common Sense Thing, people start looking for
> shortcuts.  (Ever look at a college campus?  The sidewalks are
ignored.
> But where are the lights placed for safety?  Near the sidewalks)

In a previous life I worked at a University that omitted sidewalks from
a large campus expansion.  Sidewalks were added later, on the most
"well-worn trails"..  :-)

   -jc-

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Alan Altmark]

On Monday, 01/19/2009 at 04:03 EST, Rob van der Heij 
wrote:

> > It isn't about passwords, per se.  Rather, many (most?) sites prohibit
> > remote login of root *by any means*.
>
> The sad thing about such directives is that they live much longer than
> the person who initially dictated them (and still might know the
> motivation behind this). Once such rules are established, you can't
> easily change them anymore.

This is the subtle trap that organizations fall into.  By making it
difficult to Do The Common Sense Thing, people start looking for
shortcuts.  (Ever look at a college campus?  The sidewalks are ignored.
But where are the lights placed for safety?  Near the sidewalks)

> The two-step approach for root login has nothing to do with
> encryption. When you have a plain old telnet session, the root
> password that you type still travels over the wire to the system.
> The motivation behind the two-step approach is a poor man's approach
> to separate authentication and access control. When someone leaves the
> department he may still remember the root password, but if you take
> away his local account so that knowledge is less useful to him. But
> when the root password is commonly known, then the added value of it
> is minimal.

Shared passwords of ANY sort destroy accountability.  If you want your
audit trail to tell a compelling story, make sure every person or
process/program logs in with their own id.

> I think "sudo" asking for the root password is in the same range of
> useless rituals that create the illusion of security. And when you
> logged on to the system, asking again for your password is of little
> value (more likely to be picked up by the user watching over your
> shoulder). When you're concerned about sessions remaining unsecured
> open too long, then address that (by locking the workstation). I don't
> have high expectations of per-command access granularity implemented
> in sudo. But I do appreciate it for the auditing. When you use LDAP to
> associate users with groups, it is very easy to handle access control
> for sudo as well.

If an intermediary is asking for root's password, then you haven't
accomplished anything by using sudo.  In fact, security is WORSE because
of the pacifying effect of sudo.

> When dealing with folks who need to work in emergency situations
> (doctors, system programmers), attempts to limit their access often
> creates a lot of discussion (and for a good reason). Those are no
> routine tasks and you can't predict all steps needed. In those cases,
> I believe strongly in fairly open access for approved staff, combined
> with auditing (and justification afterwards). The auditing is also
> helpful to diagnose problems and learn from the steps followed to
> resolve the problem. System programmers using their access to tamper
> with the auditing should be handled with care.

There is trust and there is Trust (the latter includes a measure of
"personal integrity").  For those whom you Trust, root access is
permitted, but do it by giving them all uid 0, not by sharing passwords.
Since each user has a different pid, the audit trail can be more closely
examined to see who did what.  (Watch out for a reducation program that
gives you a username when you have shared uids.)

Alan Altmark
z/VM Development
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Rob van der Heij]

On Mon, Jan 19, 2009 at 5:52 AM, Alan Altmark  wrote:

> It isn't about passwords, per se.  Rather, many (most?) sites prohibit
> remote login of root *by any means*.

The sad thing about such directives is that they live much longer than
the person who initially dictated them (and still might know the
motivation behind this). Once such rules are established, you can't
easily change them anymore.
The two-step approach for root login has nothing to do with
encryption. When you have a plain old telnet session, the root
password that you type still travels over the wire to the system.
The motivation behind the two-step approach is a poor man's approach
to separate authentication and access control. When someone leaves the
department he may still remember the root password, but if you take
away his local account so that knowledge is less useful to him. But
when the root password is commonly known, then the added value of it
is minimal.

I think "sudo" asking for the root password is in the same range of
useless rituals that create the illusion of security. And when you
logged on to the system, asking again for your password is of little
value (more likely to be picked up by the user watching over your
shoulder). When you're concerned about sessions remaining unsecured
open too long, then address that (by locking the workstation). I don't
have high expectations of per-command access granularity implemented
in sudo. But I do appreciate it for the auditing. When you use LDAP to
associate users with groups, it is very easy to handle access control
for sudo as well.

When dealing with folks who need to work in emergency situations
(doctors, system programmers), attempts to limit their access often
creates a lot of discussion (and for a good reason). Those are no
routine tasks and you can't predict all steps needed. In those cases,
I believe strongly in fairly open access for approved staff, combined
with auditing (and justification afterwards). The auditing is also
helpful to diagnose problems and learn from the steps followed to
resolve the problem. System programmers using their access to tamper
with the auditing should be handled with care.

Rob (amateur security weeny)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Ronald van der Laan]

James,

I normally use a combination of ssh, sudo and tar to copy files with root
authorization from one system to the other:

cd  ${sourcedir}
sudo  tar  -cp  ${files}  |  ssh  ${targetsys}  sudo  tar  -C  ${targetdir}
-xpv

Ronald van der Laan

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Alan Altmark]

On Sunday, 01/18/2009 at 07:51 EST, Michael
MacIsaac/Poughkeepsie/i...@ibmus wrote:

> So let me ask this to the list - what are the rules regarding key-based
> authentication?  Is this approach not authorized even though no root (or
> any other) passwords goes over the wire?  Or is it just the rule that
the
> /root/.ssh/authorized_keys file never exist?

It isn't about passwords, per se.  Rather, many (most?) sites prohibit
remote login of root *by any means*.

> If there is no key-based authentication for root allowed, can there be
for
> non-root users (not sure how much this will help).
>
> One thing I'm looking for is a way that a central Linux system can pull
> important data (/etc/fstab /etc/zipl.conf,
> /etc/sysconfig/network/ifcfg-qeth-*), and run certain commands remotely
on
> other Linux systems without the need for someone sitting typing a
password
> many times.
>
> Systems management tasks need to be automated to scale the number of
> servers a single admin can care for, but security rules in certain shops
> seem to be preventing that.  There must be some intelligent compromise
> (and it's probably involves sudo)

A system management task needs to have a clearly defined role and access
rights.
- What system files is it reading?
- What system files is it writing?
- What privileged commands/APIs does it need?

Yes, it probably involves sudo.  Your app gets the same privs as a remote
admin would get and has to do thing the same way the remote admin would do
them.

Alan Altmark
z/VM Development
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Michael MacIsaac]

Marcy,

> Same rule here  (if only some of these vendors (cough ibm/tivoli
cough) would comprehend... )
I'm trying to comprehend, and will also try to bubble the message upwards
in my small sphere of influence.

So let me ask this to the list - what are the rules regarding key-based
authentication?  Is this approach not authorized even though no root (or
any other) passwords goes over the wire?  Or is it just the rule that the
/root/.ssh/authorized_keys file never exist?

If there is no key-based authentication for root allowed, can there be for
non-root users (not sure how much this will help).

One thing I'm looking for is a way that a central Linux system can pull
important data (/etc/fstab /etc/zipl.conf,
/etc/sysconfig/network/ifcfg-qeth-*), and run certain commands remotely on
other Linux systems without the need for someone sitting typing a password
many times.

Systems management tasks need to be automated to scale the number of
servers a single admin can care for, but security rules in certain shops
seem to be preventing that.  There must be some intelligent compromise
(and it's probably involves sudo)

Thanks.

"Mike MacIsaac"(845) 433-7061

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Rob van der Heij]

On Sun, Jan 18, 2009 at 11:22 PM, Scott Rohling  wrote:

> We implemented this within IBM:

> -  Distributed the 'authorized_keys' to /home/support/.ssh with  the support
> user's public key on the central system.

This is the questionable part of the process I think. Your security
guidelines also require the user to take action when his private key
would be compromised (by generating a new key pair). When you have put
his public key on various servers, the user may not have such control
anymore.
A more attractive option IMHO is to have sshd obtain the public keys
from an LDAP database. When you have both access lists and public keys
there, it makes managing system access much easier.

Rob

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Scott Rohling]

We implemented this within IBM:

-  created userid 'support' on all Linux guests - made it a 'no login' user
-  Put support in sudoers to allow commands with NOPASSWD on all guests
-  Distributed the 'authorized_keys' to /home/support/.ssh with  the support
user's public key on the central system.
- Used 'support' to run various various scripts, tools, etc via ssh to
collect Linux files and data across all servers.  Also used to 'push' files
to the Linux servers (scripts, /etc/sudoers, etc) - and change passwords,
etc.
- Created an 'intelligent' ssh tool which could talk to servers based on
different criteria (names, ips, groups, customers, etc) - all run from
'support' on the central server.

I'm not sure whether the above violates any security rules - it would depend
on the security policies in place..

Scott Rohling

On Sun, Jan 18, 2009 at 2:58 PM, Michael MacIsaac wrote:

> ... sent this this AM - not sure where it went ... resending ...
>
> Marcy,
>
> > Same rule here  (if only some of these vendors (cough ibm/tivoli
> cough) would comprehend... )
> I'm trying to comprehend, and will also try to bubble the message upwards
> in my small sphere of influence.
>
> So let me ask this to the list - what are the rules regarding key-based
> authentication?  Is this approach not authorized even though no root (or
> any other) passwords goes over the wire?  Or is it just the rule that the
> /root/.ssh/authorized_keys file never exist?
>
> If there is no key-based authentication for root allowed, can there be for
> non-root users (not sure how much this will help).
>
> One thing I'm looking for is a way that a central Linux system can pull
> important data (/etc/fstab /etc/zipl.conf,
> /etc/sysconfig/network/ifcfg-qeth-*), and run certain commands remotely on
> other Linux systems without the need for someone sitting typing a password
> many times.
>
> Systems management tasks need to be automated to scale the number of
> servers a single admin can care for, but security rules in certain shops
> seem to be preventing that.  There must be some intelligent compromise
> (and it's probably involves sudo)
>
> Thanks.
>
> "Mike MacIsaac"(845) 433-7061
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Michael MacIsaac]

... sent this this AM - not sure where it went ... resending ...

Marcy,

> Same rule here  (if only some of these vendors (cough ibm/tivoli
cough) would comprehend... )
I'm trying to comprehend, and will also try to bubble the message upwards
in my small sphere of influence.

So let me ask this to the list - what are the rules regarding key-based
authentication?  Is this approach not authorized even though no root (or
any other) passwords goes over the wire?  Or is it just the rule that the
/root/.ssh/authorized_keys file never exist?

If there is no key-based authentication for root allowed, can there be for
non-root users (not sure how much this will help).

One thing I'm looking for is a way that a central Linux system can pull
important data (/etc/fstab /etc/zipl.conf,
/etc/sysconfig/network/ifcfg-qeth-*), and run certain commands remotely on
other Linux systems without the need for someone sitting typing a password
many times.

Systems management tasks need to be automated to scale the number of
servers a single admin can care for, but security rules in certain shops
seem to be preventing that.  There must be some intelligent compromise
(and it's probably involves sudo)

Thanks.

"Mike MacIsaac"(845) 433-7061

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Andrej]

2009/1/17 CHAPLIN, JAMES (CTR) :
> We have a security requirement (which is common with Linux) to prevent
> ssh login for root (setting PermitRootLogin to no).  One problem we
> find, as system administrators, we like to use secure copy (remote file
> copy program, scp) files between systems. However this will not work for
> any root level files, since scp uses ssh to copy files over a network.
> Does anyone have a suggested solution or better way around this issue?
Still a kludge, but I commonly (if the files I want to grab are world-readable)
ssh to the target machine, su and then copy them with
scp -p u...@host:/path/to/file /path/to/file


Cheers,
Andrej

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[CHAPLIN, JAMES (CTR)]

Tom Kern from DOE called me with a good solution, using pubkeys and in
the sshd_conf file, set PermitRootLogin to without-password. Did a
google search on " PermitRootLogin  without-password" and got allot of
hits, trying to set up a test right now (phone keeps ringing with other
peoples problem;-0). But this is looking like the best solution. Will
update soon, thanks for the suggestions.

Thanks Tom for pointing me in the right direction.

James Chaplin
Systems Programmer, MVS, zVM & zLinux
Base Technologies, Inc

-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Romanowski, John (OFT)
Sent: Friday, January 16, 2009 1:49 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Security question and using scp

Have the same issue here.
As workarounds I sometimes use an NFS mount to transfer multiple files,
or a VDISK used a thumb drive to copy multiple files from one guest to
another on the same VM system

> -Original Message-
> From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
> CHAPLIN, JAMES (CTR)
> Sent: Friday, January 16, 2009 11:20 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Security question and using scp
>
> We have a security requirement (which is common with Linux) to prevent
> ssh login for root (setting PermitRootLogin to no).  One problem we
> find, as system administrators, we like to use secure copy (remote
file
> copy program, scp) files between systems. However this will not work
> for
> any root level files, since scp uses ssh to copy files over a network.
> Does anyone have a suggested solution or better way around this issue?
>
>
>
> James Chaplin
>
> Systems Programmer, MVS, zVM & zLinux
>
> Base Technologies, Inc
>
> Supporting the zSeries Platform Team
> Data Center Operations Branch
>
> Enterprise Data Center Operations Group
> Enterprise Data Management & Engineering Division
>
> Office of Information and Technology
>
> Department of Homeland Security/U.S. Customs & Border Protection
>
> (703) 921-6220
>
> james.chap...@cbp.dhs.gov
>
>
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390
> or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390


This e-mail, including any attachments, may be confidential, privileged
or otherwise legally protected. It is intended only for the addressee.
If you received this e-mail in error or from someone who was not
authorized to send it to you, do not disseminate, copy or otherwise use
this e-mail or its attachments.  Please notify the sender immediately by
reply e-mail and delete the e-mail from your system.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Romanowski, John (OFT)]

Have the same issue here.
As workarounds I sometimes use an NFS mount to transfer multiple files, or a 
VDISK used a thumb drive to copy multiple files from one guest to another on 
the same VM system

> -Original Message-
> From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
> CHAPLIN, JAMES (CTR)
> Sent: Friday, January 16, 2009 11:20 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Security question and using scp
>
> We have a security requirement (which is common with Linux) to prevent
> ssh login for root (setting PermitRootLogin to no).  One problem we
> find, as system administrators, we like to use secure copy (remote file
> copy program, scp) files between systems. However this will not work
> for
> any root level files, since scp uses ssh to copy files over a network.
> Does anyone have a suggested solution or better way around this issue?
>
>
>
> James Chaplin
>
> Systems Programmer, MVS, zVM & zLinux
>
> Base Technologies, Inc
>
> Supporting the zSeries Platform Team
> Data Center Operations Branch
>
> Enterprise Data Center Operations Group
> Enterprise Data Management & Engineering Division
>
> Office of Information and Technology
>
> Department of Homeland Security/U.S. Customs & Border Protection
>
> (703) 921-6220
>
> james.chap...@cbp.dhs.gov
>
>
>
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390
> or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390


This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments.  Please notify the sender immediately by reply e-mail and delete 
the e-mail from your system.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Marcy Cortes]

Same rule here  (if only some of these vendors (cough ibm/tivoli
cough) would comprehend... ) 
 

1. "scp -p filename non-rootu...@target.system" and then SSH to the
target system, su to root, move the file to the right place and chown it
back to what it should be.

That's what I mainly do -- except I do the copy and then "ssh ma...@host
sudo mv somefile /etc/somefile"


Marcy 

"This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Mark Post
Sent: Friday, January 16, 2009 8:33 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Security question and using scp

>>> On 1/16/2009 at 11:20 AM, "CHAPLIN, JAMES (CTR)"
 wrote: 
> We have a security requirement (which is common with Linux) to prevent

> ssh login for root (setting PermitRootLogin to no).  One problem we 
> find, as system administrators, we like to use secure copy (remote 
> file copy program, scp) files between systems. However this will not 
> work for any root level files, since scp uses ssh to copy files over a
network.
> Does anyone have a suggested solution or better way around this issue?

While I agree with the principle of no direct root logins, this side
effect bugs me to no end, since I do a lot of scp work.  The only ways
I've found to get around it are to:
1. "scp -p filename non-rootu...@target.system" and then SSH to the
target system, su to root, move the file to the right place and chown it
back to what it should be.
2. Create a tar file with the file in it, scp it as the non-root user,
SSH to the target system, su to root, untar the file in place.
3. Enable SSL FTP, then get and use an SSL FTP client.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions, send
email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Security question and using scp

[Mark Post]

>>> On 1/16/2009 at 11:20 AM, "CHAPLIN, JAMES (CTR)"
 wrote: 
> We have a security requirement (which is common with Linux) to prevent
> ssh login for root (setting PermitRootLogin to no).  One problem we
> find, as system administrators, we like to use secure copy (remote file
> copy program, scp) files between systems. However this will not work for
> any root level files, since scp uses ssh to copy files over a network.
> Does anyone have a suggested solution or better way around this issue?

While I agree with the principle of no direct root logins, this side effect 
bugs me to no end, since I do a lot of scp work.  The only ways I've found to 
get around it are to:
1. "scp -p filename non-rootu...@target.system" and then SSH to the target 
system, su to root, move the file to the right place and chown it back to what 
it should be.
2. Create a tar file with the file in it, scp it as the non-root user, SSH to 
the target system, su to root, untar the file in place.
3. Enable SSL FTP, then get and use an SSL FTP client.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Security question and using scp

[CHAPLIN, JAMES (CTR)]

We have a security requirement (which is common with Linux) to prevent
ssh login for root (setting PermitRootLogin to no).  One problem we
find, as system administrators, we like to use secure copy (remote file
copy program, scp) files between systems. However this will not work for
any root level files, since scp uses ssh to copy files over a network.
Does anyone have a suggested solution or better way around this issue?

 

James Chaplin

Systems Programmer, MVS, zVM & zLinux

Base Technologies, Inc

Supporting the zSeries Platform Team
Data Center Operations Branch

Enterprise Data Center Operations Group 
Enterprise Data Management & Engineering Division

Office of Information and Technology

Department of Homeland Security/U.S. Customs & Border Protection

(703) 921-6220

james.chap...@cbp.dhs.gov

 


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390