Cluster internal ssh
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:
- Log into submit machine where this particular job was submitted from.
- Run
condor_ssh_to_job JOB.ID
whereJOB.ID
is the full id of the job as given by thecondor_q
command above. - 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:
cd /work/$(whoami)
mkdir -p .ssh; chmod 700 .ssh
ssh-keygen -f .ssh/id_ed25519 -t ed25519 -N /dev/null
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 usersa
with varying key sizes (via the-b
parameter). At the time of writing, we suggest not to use the key typesdsa
andecdsa
. - to set a passphrase interactively, please remove the
-N /dev/null
part. - if you have multiple private keys under
.ssh
you may need to tellssh
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.