CONDOR_SSH_TO_JOB(1)
π condor_ssh_to_job π
hey bestie, this is condor_ssh_to_job from the HTCondor Manual β the little tool that opens an SSH session inside a running job. yes, while it's still vibing on the execute machine. no cap. β¨
β¨ NAME β¨
condor_ssh_to_job β create an SSH session to a running job. that's the whole assignment. π«Ά
πΈ SYNOPSIS πΈ
condor_ssh_to_job [-help]
condor_ssh_to_job [-debug] [-name schedd-name] [-pool pool-name] [-ssh
ssh-command] [-keygen-options ssh-keygen-options] [-shells
shell1,shell2,...] [-auto-retry] [-remove-on-interrupt] [-X | -x]
cluster | cluster.proc | cluster.proc.node [remote-command]
π¦ DESCRIPTION π¦
so condor_ssh_to_job creates an ssh session to a running job. the job is specified with the argument. if you only give the job cluster id, then the job process id just defaults to 0. easy.
condor_ssh_to_job ships in Unix HTCondor distributions, and it only works with jobs in the vanilla, container, docker, vm, java, local, or parallel universes. in the grid universe it only works with EC2 resources. other grid universe jobs? nope, not happening. π
you've gotta be the owner of the job, or a queue super user, and both the condor_schedd and condor_starter daemons must be configured to allow condor_ssh_to_job access. if no remote-command is specified, you get an interactive shell. want an alternate ssh program like sftp for uploading and downloading files? use the -ssh option. iconic.
the remote command or shell runs with the same user id as the running job, and it's initialized with the same working directory. the environment is initialized to be the same as that of the job, plus any changes made by the shell setup scripts and any environment variables passed by the ssh client. and on top of that, the environment variable _CONDOR_JOB_PIDS is defined. it's a space-separated list of PIDs associated with the job. at a minimum, the list will contain the PID of the process started when the job was launched, and it will be the first item in the list. it may contain additional PIDs of other processes that the job has created. very main character of it. π
if the job is a docker or container universe job, the interactive shell gets launched inside the container, and as much as possible should have all the access and visibility that the job proper does. but heads up bestie β this requires the container image to have a shell inside it. condor_ssh_to_job will fail if the container lacks a shell. π
the ssh session and all processes it creates are treated by HTCondor as though they are processes belonging to the job. if the slot is preempted or suspended, the ssh session is killed or suspended along with the job. if the job exits before the ssh session finishes, the slot remains in the Claimed Busy state and is treated as though not all job processes have exited until all ssh sessions are closed. multiple ssh sessions may be created to the same job at the same time, fr fr. resource consumption of the sshd process and all processes spawned by it are monitored by the condor_starter as though these processes belong to the job, so any policies such as PREEMPT that enforce a limit on resource consumption also take into account resources consumed by the ssh session. π₯
condor_ssh_to_job stores ssh keys in temporary files within a newly created and uniquely named directory. that new directory lives inside the directory defined by the environment variable TMPDIR. when the ssh session is finished, this directory and the ssh keys contained within it are removed. clean. β¨
see the HTCondor administrator's manual section on configuration for the details of the configuration variables related to condor_ssh_to_job. iykyk.
okay so here's how the whole ssh session actually works, and it's lowkey elegant:
an ssh session works by first authenticating and authorizing a secure connection between condor_ssh_to_job and the condor_starter daemon, using HTCondor protocols. the condor_starter generates an ssh key pair and sends it securely to condor_ssh_to_job. then the condor_starter spawns sshd in inetd mode with its stdin and stdout attached to the TCP connection from condor_ssh_to_job. condor_ssh_to_job acts as a proxy for the ssh client to communicate with sshd, using the existing connection authorized by HTCondor. at no point is sshd listening on the network for connections or running with any privileges other than that of the user identity running the job. if CCB is being used to enable connectivity to the execute node from outside of a firewall or private network, condor_ssh_to_job is able to make use of CCB in order to form the ssh connection. π
the sshd command HTCondor runs on the EP requires an entry in the /etc/passwd file with a valid shell and home directory. as these are often missing, the condor_starter uses the LD_PRELOAD environment variable to inject an implementation of the libc getpwnam function call into the ssh that forces the shell to be /bin/sh and the home directory to be the scratch directory for that user. this can be disabled on the EP by setting CONDOR_SSH_TO_JOB_FAKE_PASSWD_ENTRY to false. π
condor_ssh_to_job is intended to work with OpenSSH as installed in typical environments. it does not work on Windows platforms. if the ssh programs are installed in non-standard locations, then the paths to these programs will need to be customized within the HTCondor configuration. versions of ssh other than OpenSSH may work, but they will likely require additional configuration of command-line arguments, changes to the sshd configuration template file, and possibly modification of the $(LIBEXEC)/condor_ssh_to_job_sshd_setup script used by the condor_starter to set up sshd. so like, bring snacks. π
for jobs in the grid universe which use EC2 resources, a request that HTCondor have the EC2 service create a new key pair for the job by specifying ec2_keypair_file causes condor_ssh_to_job to attempt to connect to the corresponding instance via ssh. this attempts invokes ssh directly, bypassing the HTCondor networking layer. it supplies ssh with the public DNS name of the instance and the name of the file with the new key pair's private key. for the connection to succeed, the instance must have started an ssh server, and its security group(s) must allow connections on port 22. conventionally, images will allow logins using the key pair on a single specific account. because ssh defaults to logging in as the current user, the -l <username> option or its equivalent for other versions of ssh will be needed as part of the remote-command argument. although the -X option does not apply to EC2 jobs, adding -X or -Y to the remote-command argument can duplicate the effect. slay. β¨
π OPTIONS π
-helpβ display brief usage information and exit. bye bestie π-debugβ causes debugging information to be sent tostderr, based on the value of the configuration variableTOOL_DEBUG.-nameschedd-name β specify an alternatecondor_schedd, if the default (local) one is not desired.-poolpool-name β specify an alternate HTCondor pool, if the default one is not desired. does not apply to EC2 jobs.-sshssh-command β specify an alternate ssh program to run in place of ssh, for examplesftporscp. additional arguments are specified as ssh-command. since the arguments are delimited by spaces, place double quote marks around the whole command, to prevent the shell from splitting it into multiple arguments tocondor_ssh_to_job. if any arguments must contain spaces, enclose them within single quotes. does not apply to EC2 jobs.-keygen-optionsssh-keygen-options β specify additional arguments to thessh_keygenprogram, for creating the ssh key that is used for the duration of the session. for example, a different number of bits could be used, or a different key type than the default. does not apply to EC2 jobs.-shellsshell1,shell2,... β specify a comma-separated list of shells to attempt to launch. if the first shell does not exist on the remote machine, then the following ones in the list will be tried. if none of the specified shells can be found,/bin/shis used by default. if this option is not specified, it defaults to the environment variableSHELLfrom within thecondor_ssh_to_jobenvironment. does not apply to EC2 jobs.-auto-retryβ specifies that if the job is not yet running,condor_ssh_to_jobshould keep trying periodically until it succeeds or encounters some other error. stubborn queen behavior, we love it. π-remove-on-interruptβ if specified, attempt to remove the job from the queue ifcondor_ssh_to_jobis interrupted via a CTRL-c or otherwise terminated abnormally. β οΈ yes this really removes the job, be careful.-Xβ enable X11 forwarding. does not apply to EC2 jobs.-xβ disable X11 forwarding.
π EXAMPLES π
okay so here's the classic:
$ condor_ssh_to_job 32.0
Welcome to slot2@tonic.cs.wisc.edu!
Your condor job is running with pid(s) 65881.
$ gdb -p 65881
(gdb) where
...
$ logout
Connection to condor-job.tonic.cs.wisc.edu closed.
to upload or download files interactively with sftp:
$ condor_ssh_to_job -ssh sftp 32.0
Connecting to condor-job.tonic.cs.wisc.edu...
sftp> ls
...
sftp> get outputfile.dat
this example shows downloading a file from the job with scp. the string "remote" is used in place of a host name in this example. it is not necessary to insert the correct remote host name, or even a valid one, because the connection to the job is created automatically. therefore, the placeholder string "remote" is perfectly fine. π«Ά
$ condor_ssh_to_job -ssh scp 32 remote:outputfile.dat .
this example uses condor_ssh_to_job to accomplish the task of running rsync to synchronize a local file with a remote file in the job's working directory. job id 32.0 is used in place of a host name in this example. this causes rsync to insert the expected job id in the arguments to condor_ssh_to_job.
$ rsync -v -e "condor_ssh_to_job" 32.0:outputfile.dat .
note that condor_ssh_to_job was added to HTCondor in version 7.3. if one uses condor_ssh_to_job to connect to a job on an execute machine running a version of HTCondor older than the 7.3 series, the command will fail with the error message π
Failed to send CREATE_JOB_OWNER_SEC_SESSION to starter
β EXIT STATUS β
condor_ssh_to_job will exit with a non-zero status value if it fails to set up an ssh session. if it succeeds, it will exit with the status value of the remote command or shell. so like, the exit code is literally just the vibe of whatever you ran. no cap.
πΈ SEE ALSO πΈ
condor_submit, condor_q, condor_tail, condor_transfer_data
π AVAILABILITY π
Linux, MacOS
π AUTHOR π
HTCondor Team
π COPYRIGHT π
1990-2026, Center for High Throughput Computing, Computer Sciences Department, University of Wisconsin-Madison, Madison, WI, US. Licensed under the Apache License, Version 2.0.
and that's the whole page bestie π this was the HTCondor Manual version of condor_ssh_to_job, dated Oct 16, 2026 β go forth and ssh into your jobs, you absolute icon. periodt. β¨π¦π
π¦ where this page comes from
- fedora 43: condor 25.14.1-1.fc43 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms