Please note: Review first what you want to achieve. To retrieve data directly from the nodes or briefly check a state of an execute node should be fine. but bypassing HTCondor to start programs on execute nodes should never be done, as this may break jobs scheduled to this host!

If a Condor job is already running: condor_ssh_to_job

When a job is already running and you know the ID of the job via condor_q -nobatch -run, you can ask HTCondor to log you into the node where this job runs on:

  1. Log into submit machine where this particular job was submitted from.
  2. Run condor_ssh_to_job JOB.ID where JOB.ID is the full id of the job as given by the condor_q command above.
  3. If the job is still running, HTCondor should give you a shell on the compute node your job is running on.

If you want to use a node interactively

If you simply require a machine with a certain number of cores, amount of RAM and/or a specific CPU, you could create a simplified submit file and submit it via condor_submit -interactive submit.file. This should give you a shell once it was matched to available resources.

Please refer to the interactive job how-to page for more information.

Last resort: Direct ssh connection

Again, please do not use this method to start programs on nodes where HTCondor jobs can be scheduled to!

As there are no internal passwords for Atlas, you need to use ssh-public key authentication. Here, you can either create/use an internal-only key-pair or re-use an ssh-agent already running on your local computer.

using a dedicate, internal key-pair

For ease of use, we currently do not require you to use a secure pass-phrase to unlock the private key. Thus, the steps involved are:

  1. cd /work/$(whoami)
  2. mkdir -p .ssh; chmod 700 .ssh
  3. ssh-keygen -f .ssh/id_ed25519 -t ed25519 -N /dev/null
  4. cat .ssh/id_ed25519.pub >> .ssh/authorized_keys

Several notes:

  • this will overwrite any previously generated private key with the same name effectively locking you out of future use of the old key.
  • instead of the type ed25519 you could also use rsa with varying key sizes (via the -b parameter). At the time of writing, we suggest not to use the key types dsa and ecdsa.
  • to set a passphrase interactively, please remove the -N /dev/null part.
  • if you have multiple private keys under .ssh you may need to tell ssh which one to use, e.g. ssh -i .ssh/id_ed25519. If you only ever need it for our internal compute nodes, you can also use a stanza like this in your .ssh/config file(assuming ~ refers to your /work directory:
Host a????
  IdentityFile ~/.ssh/id_ed25519

This should allow you to ssh directly into any host whose hostname starts with an a and is followed by exactly four characters, e.g. a0101.

re-using your local ssh-agent

This set-up assumes you have a local ssh-agent running as described at the bottom of our getting started documentation.

Then you can simply print your local ssh public key and add it to your Atlas internal ssh set-up, e.g.

cat ~/.ssh/id_ed25519-atlas.pub |\
 ssh -i ~/.ssh/id_ed25519-atlas username@condor1.atlas.aei.uni-hannover.de \
 'mkdir -p ~/.ssh; cat - >> ~/.ssh/authorized_keys; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys'

This will append the public part of your local key you use to log into Atlas to the authorized_keys file on your work home.