Basic N1 SSH config questions...
At the risk of asking remedial questions, are these actions correct?:
<li> When generating SSH keys, I am to generate one set with the ID used to install/owner of the MS (agent, server, cli)? (i cant remember now if cli installed w/ the master seerver or not, i think it did)</li>
<li> I am to create a second user and generate keys, and place this users pub key into the authorized_keys2 file of the first user (product install/owner of MS) </li>
<li>How do I tell N1 about the existance of this second user? Is this what pe.defaultUserToRunAs is for? I cannot find this in the docs. </li>
<li> According to previous postings, root ssh'ing is required for OSP. This makes no sense to me when the agent can be owned by a non-root user, yet can execute native commands with root priv.</li>
<li>The docs state that SSH forwarding works downstream, but can it use loop back to the master server?</li>
<li>Why do I see the product use a root shell to CLI back to the Master server (OSP question)? Should this be happening?</li>
Thanks for everyones help.
Pete.
[1216 byte] By [
peteziua] at [2007-11-26 13:36:46]
# 1
<li> When generating SSH keys, I am to generate one set with the ID used to install/owner of the MS (agent, server, cli)? (i cant remember now if cli installed w/ the master seerver or not, i think it did)</li>
yes
<li> I am to create a second user and generate keys, and place this users pub key into the authorized_keys2 file of the first user (product install/owner of MS) </li>
yes
<li>How do I tell N1 about the existance of this second user? Is this what pe.defaultUserToRunAs is for? I cannot find this in the docs. </li>
still not sure about this one
<li> According to previous postings, root ssh'ing is required for OSP. This makes no sense to me when the agent can be owned by a non-root user, yet can execute native commands with root priv.</li>
yes, required (Thanks chappe! [pete])
<li>The docs state that SSH forwarding works downstream, but can it use loop back to the master server?</li>
yes
<li>Why do I see the product use a root shell to CLI back to the Master server (OSP question)? Should this be happening?</li>
yes
However, the docs fail to mention that when setting up SSH for the second user, that you have to move the pub key to the cli box in the .ssh dir of the second user (remote box) before you can execute cli as that user. Also, just as you set up the second user, you have to setup root, and make modifications to sshd.conf to allow ssh root to occur (if OSP Jet box).
The docs don't say how to test the cli and root accounts. Not sure if this is right, but I tested this way:
from master server:
ssh -A -t <runas_account_name>@<clihostname> -ssh -A -t <runas_account_name>@<master_server_hostname> <command to run>
I have a new error now, but I am past the hostkey verification and access denied errors.
Pete.
Message was edited by:
peteziu
Message was edited by:
peteziu
Message was edited by:
peteziu
# 2
> At the risk of asking remedial questions, are these
> actions correct?:
>
> <li> When generating SSH keys, I am to generate one
> set with the ID used to install/owner of the MS
> (agent, server, cli)? (i cant remember now if cli
> installed w/ the master seerver or not, i think it
> did)</li>
True for MS/LD/RA as they always run with the same uid. CLI works best, if always invoked as the install owner. If the CLI is invoked as any other user, then there are couple options,
one is to make sure that each user has their ssh keys configured so that the connection from their machine to the MS machine with their ssh credential succeeds.
Another is to configure CLI to always a single identity to connect to the MS. For security reasons, you may want this identity to be different from the MS install owner. If you look at the ssh man page, it allows you to override the default uid and identity file locations through options -l & -i.
Lets say we create a new user spsuser, for CLI authentication.
We can then generate ssh keys for spsuser and put them in this identity file, lets say /home/spsuser/ssh/identity.
We can then configure sps CLI to override the ssh credentials that are used when connecting to the MS as
net.client.parms.1=sshargs=-o|BatchMode yes|-l|spsuser|-i|/home/spsuser/identity
That way CLI will always try to use the same ssh identity regardless of who invokes it. However, since I haven't tested this configuration, I'm not certain if it will work. The one possible issue here is that ssh may complain about the identity file having global read permissions.
>
> <li> I am to create a second user and generate keys,
> and place this users pub key into the
> authorized_keys2 file of the first user (product
> install/owner of MS) </li>
Nope, the keys always belong to the same user, unless you are overriding the default user to the first user when running ssh as the second user.
>
> <li>How do I tell N1 about the existance of this
> second user? Is this what pe.defaultUserToRunAs is
> for? I cannot find this in the docs. </li>
I think you are talking about the CLI here. In this case you'll be running the CLI as the second user, right? In that case all you need to do is to make sure that the second user is able to connect to the MS machine from the CLI machine using ssh, without requiring any user interaction.
>
> <li> According to previous postings, root ssh'ing is
> required for OSP. This makes no sense to me when the
> agent can be owned by a non-root user, yet can
> execute native commands with root priv.</li>
The ability to run native commands as root is only available when the agent is running as root. Otherwise the plan that tries to run exec native as root will fail if the agent that its running on is not running as root.
>
> <li>The docs state that SSH forwarding works
> downstream, but can it use loop back to the master
> server?</li>
Not sure I understand the question. downstream here implies from the machine invoking ssh client to the machine thats running the ssh daemon. I don't think ssh would care if the the ssh daemon was connected to via any IP address or loopback...
>
> <li>Why do I see the product use a root shell to CLI
> back to the Master server (OSP question)? Should
> this be happening?</li>
My opinion is that CLI doesn't need to run as root for most of its functionality. The only case where it may need to run as root is when the files that its trying to checkin are only readable by root. However, it may make sense make those file readable by the CLI user instead of running CLI as root in that case. Don't know if it makes sense to have OSP run the CLI as a non-root user instead..
hth,
Aj
aj.a at 2007-7-7 22:22:40 >
