Differences

This shows you the differences between two versions of the page.

--- cluster:157 [2017/04/06 15:44]
hmeij07
+++ cluster:157 [2017/04/06 19:31] (current)
hmeij07
@@ Line 4: / Line 4: @@
 ==== Centralize SSH Key Management ====
-Lest assume we have 3 colleges (CollegeA, CollegeB, CollegeC) and we write a grant proposal and each institution will do something unique science wise. Grant gets funded and specialized hardware or software gets deployed at each college (for maybe brain scan analyses, deep learning, and engineering).
+Lets assume we have 3 colleges (CollegeA, CollegeB, CollegeC) and we write a grant proposal and each institution will do something unique science wise. Grant gets funded and specialized hardware or software gets deployed at each college (for maybe brain scan analyses, deep learning, and engineering).
 The grant mentioned that all members of participating colleges can request access at any college. How would one do that without a mess developing? Nobody, not even admins, should have access to any user level passwords. Accounts should be able to be revoked. CPU usage should be accountable. In short, some sort of "federated SSH access". Command line access so we can rule out InCommon, it appears not to be ready for this. One option might be GSI-OpenSSH but it looks very complicated. Consult
@@ Line 15: / Line 15: @@
 ** SSH public key authentication**
-In the ''/etc/ssh/sshd_config'' file, specify the path to user SSH public key files using a description like:
+On a selected collge, behind the firewall, set up a management server. In the ''/etc/ssh/sshd_config'' file, specify the path to user SSH public key files using a description like:
   * ''AuthorizedKeysFile /etc/ssh/authorized_keys/%u''
- For this example, the /etc, /etc/ssh, and /etc/ssh/authorized_keys are directories owned and only writable by root.  The sshd service interprets ''%u'' as the authenticated user's username on the system. So in this approach, every user has a file named after their username in the ''/etc/ssh/authorized_keys'' directory, root-owned.
+For this example, the /etc, /etc/ssh, and /etc/ssh/authorized_keys are directories owned and only writable by root.  The sshd service interprets ''%u'' as the authenticated user's username on the system. So in this approach, every user has a file named after their username in the ''/etc/ssh/authorized_keys'' directory, root-owned.
 <code>
- # ls -ld /etc /etc/ssh /etc/ssh/authorized_keys
  drwxr-xr-x. 135 root root 12288 Mar 23 16:59 /etc
  drwxr-xr-x.   3 root root  4096 Nov  9 14:02 /etc/ssh
@@ Line 31: / Line 30: @@
 </code>
-Unique usernamaes and UID/GID need to be created. We need a simple web page where public keys ''ssh-keygen -t rsa'' can be uploaded with username requested. The username will be prefixed by first 3 characters of College ('wes' for Wesleyan, 'laf' for Lafayette', etc). Script figures from passwd file which UID/GID is next, then
+We need to collect all ''root'' public keys into a single file called ''root''. So that each college can retrieve the guest accounts and add them to their local passwd/shadow/group files. UID/GID ranges and usernames need to be unique. So we can assign ranges 15001-20000, 20001-25000, 25001-30000 for College[A|B|C]. Usernames prefixed with 3 character (wesleyan with wes, lafayette with laf, etc).
-<code>
+Workflow
-nid=15001
+  * User hmeij of CollegeA (Wesleyan) requests access to College[B|C], goes to a web site and type in 'hmeij'
-pre=wes
+  * Script does the following steps, figures out next UID/GID, referer ip yields prefix
-unm=hmeij
+    * echo "weshmeij:x:15001" >> /etc/group
-[root@ ~]# echo "$pre$unm:x:$nid" >> /etc/group
+    * useradd -u 15001 -g 15001 weshmeij
-[root@ ~]# useradd -u $nid -g $nid $pre$unm
+    * echo `date | md5sum | awk '{print $1}'` | passwd weshmeij --stdin
-[root@ ~]# echo "`date | md5sum | awk '{print $1}'`" | passwd $pre$unm --stdin
+    * su - weshmeij -c "ssh-keygen -b 2048 -t rsa -f /home/weshmeij/.ssh/weshmeij -q -N '''' " # 4 single quotes before closing double quote
-[root@ ~]# cp /tmp/$upfile /etc/ssh/authorized_keys/$pre$unm
+    * mv /home/weshmeij/.ssh/weshmeij.pub /etc/ssh/authorized_keys/weshmeij
-[root@ ~]# chmod 0444 /etc/ssh/authorized_keys/$pre$unm
+    * chown root:root /etc/ssh/authorized_keys/weshmeij
-</code>
+    * cat /home/weshmeij/.ssh/weshmeij # present in browser
+    * CollegeA user hmeij saves private key to $HOME/.ssh/weshmeij.priv; alters permissions chmod go-rwx
-We need ''root'' authorized keys from each site so that from each college the respective block of UID/GID canbe grabbed and added to local passwd, shadow and group files.
+    * script finishes; rm -f /home/weshmeij/.ssh/weshmeij
+    * that night college[A|B|C] root retrieves all lines in the range 15001-30000
+      * makes home dirs if they do not exist (parse lines build useradd, or via pam.d/sshd?)
+      * download public keys, updates in /etc/ssh/authorized_keys (rsync with --delete)
+      * replaces local passwd/shadow/group with retrieved lines
+  * user hmeij@wes: ssh weshmeij@openhpc.lafayette.edu -i /home/hmeij/.ssh/weshmeij.priv
-Hmm, this requires that at CollegeA user hmeij can switch to weshmeij credentials before connecting to CollegeB (echo "$unm $localhost=/bin/su - $pre$unm" >> /etc/sudoers"). Not pretty.
+That would work. Nobody knows the passwords for these guest accounts.
-Ahh, since
 **Kerberos & AD**

DokuWiki

User Tools

Site Tools

Differences

Page Tools