| | 38 | |
| | 39 | === Login issue === |
| | 40 | |
| | 41 | One main obstacle is related to login issues. The current procedure I've been using is: |
| | 42 | |
| | 43 | * Start master connection using key card. |
| | 44 | * Start secondary connections on that host using the ControlMaster setup. I originally had this set as {{{ ControlPath /home/panstarrs/watersc1/.ssh/connection/%h_%p_%r}}} which is the suggested format as it makes the connection dependent on the remote hostname (%h), the remote port (%p), and the remote username (%r). I have now changed this to include %l, the local host name, as without that, multiple local hosts cannot log in at the same time (the connection described does not exist on the new host). |
| | 45 | * Connecting to multiple hosts can be done with only a single key entry, as you can generate a series of tokens once the card has been unlocked. These tokens do need to be manually entered when the host's master connection is initiated. |
| | 46 | * Become disconnected after 12 hours due to remote end security. |
| | 47 | |
| | 48 | This procedure becomes slightly trickier in an expanded/parallelized format. The current set of problems that I see at the moment are: |
| | 49 | * One user needs to initiate all connections. This can be alleviated by working as the IPP user, and dropping the %r in the ControlPath, and setting remote umask values in such a way that all local side users with key cards can resume a connection for the (local) IPP user. |
| | 50 | * Initializing large numbers of hosts is clunky. I don't see any way around sshing to all local connection hosts and starting the master connection. Being able to refresh tokens minimizes the trouble. |
| | 51 | * Every 12 hours, someone will need to refresh the connections due to the auto-disconnect. This could become a major concern for data-transfer tasks. It seems likely that data transfers will need to be running fairly regularly, and dropped connections reduces the duty cycle on this. |
| | 52 | |
| | 53 | |
| | 54 | |
