[LUNI] SSH Trickery

[Demetri Mouratis]

On Wed, 7 Feb 2007, Ramin K wrote:

> Demetri Mouratis wrote:
>> Hi,
>> 
>> While I'm normally the one proposing SSH tricks like the one I'm after, I 
>> thought I would throw this one out there for discussion.
>> 
>> I have an office network, to which my, my boss's, and my entire engineering 
>> team's PCs are connected.  This network sits behind a NAT firewall and is 
>> locally addressed in RFC 1918 space.  We have a colo facility, with a 
>> number of Linux boxes and several networks laid out as VLANs.  One network 
>> is for the production hosts, and there is a second network we refer to as 
>> an admin network.  We run monitoring, logging, and other administrative 
>> processes from an ops2 server in this admin network against production, 
>> including SSH.  We want to prevent our Eng team from accessing the 
>> production network while still allowing my group, Operations, to do their 
>> jobs.
>
> ssh production_box
> useradd admin
> userdel engineer
>
> That's how we do it on my network. Am I making this too simple?
>
> Ramin

Thanks Ramin, for the reply.  I'm afraid that is a bit too simple as there 
are other ports/protocols in play here like the Oracle database, for which 
the same rules apply.  I should have mentioned that as the reason we 
implemented the firewall rules in the first place.

Back to SSH for a moment though.  We have a "shared" account, called 
rhythm, named after the company, that we allow use for under extraordinary 
circumstances.  We enable use of this account on a per-person basis by 
publishing the user's individual keys in the rhythm account 
authorized_keys file.  This is how we deal with the inevitable requests by 
engineers to access the system via a shell prompt without giving up 
control.  Password-based SSH access is disabled globally.

We chose this approach versus a one-to-one mapping of accounts as it 
scales better and we have a large number of machines and growing.

Thanks.

-D