Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
just-man-pages/condor_ssh_to_job(1)	   just-man-pages/condor_ssh_to_job(1)

Name
       condor_ssh_to_job create	an ssh session to a running job

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 ] cluster |
       cluster.process | cluster.process.node [	remote-command ]

Description
       condor_ssh_to_job creates an ssh	session	to a running job. The  job  is
       specified  with the argument. If	only the job cluster id	is given, then
       the job process id defaults to the value	0.

       condor_ssh_to_job is available  in  Unix	 HTCondor  distributions,  and
       works with two kinds of jobs: those in the vanilla, vm, java, local, or
       parallel	universes, and those jobs in the grid universe which  use  EC2
       resources. It will not work with	other grid universe jobs.

       For  jobs  in  the vanilla, vm, java, local, or parallel	universes, the
       user must be the	owner of the job or must be a queue  super  user,  and
       both  the  condor_schedd	 and  condor_starter  daemons  must allow con-
       dor_ssh_to_job access. If no remote-command is specified,  an  interac-
       tive  shell  is	created.  An alternate ssh program such	as sftp	may be
       specified, using	the -ssh option, for uploading and downloading	files.

       The  remote  command or shell runs with the same	user id	as the running
       job, and	it is initialized with the same	working	directory.  The	 envi-
       ronment	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. In addition, the environment variable	 _CON-
       DOR_JOB_PIDS is defined.	It is a	space-separated	list of	 PIDs  associ-
       ated  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.

       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 pre-
       empted 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. Resource con-
       sumption	 of the	sshd process and all processes spawned by it are moni-
       tored 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  ses-
       sion.

       condor_ssh_to_job  stores  ssh  keys  in	temporary files	within a newly
       created and uniquely named directory. The newly created directory  will
       be  within  the directory defined by the	environment variable  TMPDIR .
       When the	ssh session is finished, this directory	and the	ssh keys  con-
       tained within it	are removed.

       See  the	 HTCondor  administrator's manual section on configuration for
       details of the configuration variables related to condor_ssh_to_job .

       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  con-
       nection	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 login shell of the user id running the  job	is  used  to  run  the
       requested  command, sshd	subsystem, or interactive shell. This is hard-
       coded behavior in OpenSSH and cannot be	overridden  by	configuration.
       This means that condor_ssh_to_job access	is effectively disabled	if the
       login shell disables access, as in the example programs	/bin/true  and
       /sbin/nologin .

       condor_ssh_to_job is intended to	work with OpenSSH as installed in typ-
       ical 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  configu-
       ration.	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 modifica-
       tion of the  $(LIBEXEC)/condor_ssh_to_job_sshd_setup script used	by the
       condor_starter to set up	sshd .

       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 con-
       nect 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 log-
       ging 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.

Options
       -help

	  Display brief	usage information and exit.

       -debug

	  Causes debugging information to be sent to  stderr ,	based  on  the
	  value	of the configuration variable  TOOL_DEBUG

       -name schedd-name

	  Specify  an  alternate condor_schedd , if the	default	(local)	one is
	  not desired.

       -pool pool-name

	  Specify an alternate HTCondor	 pool,	if  the	 default  one  is  not
	  desired. Does	not apply to EC2 jobs.

       -ssh ssh-command

	  Specify  an alternate	ssh program to run in place of ssh , for exam-
	  ple sftp or scp . 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 to condor_ssh_to_job . If any arguments
	  must contain spaces, enclose them within  single  quotes.  Does  not
	  apply	to EC2 jobs.

       -keygen-options ssh-keygen-options

	  Specify additional arguments to the ssh_keygen program, for creating
	  the ssh key that is used for the duration of the session. For	 exam-
	  ple,	a  different  number of	bits could be used, or a different key
	  type than the	default. Does not apply	to EC2 jobs.

       -shells shell1,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 fol-
	  lowing ones in the list will be tried.  If  none  of	the  specified
	  shells  can  be found, /bin/sh is used by default. If	this option is
	  not specified, it defaults to	the environment	variable   SHELL  from
	  within  the  condor_ssh_to_job  environment.	Does  not apply	to EC2
	  jobs.

       -auto-retry

	  Specifies that if the	job  is	 not  yet  running,  condor_ssh_to_job
	  should keep trying periodically until	it succeeds or encounters some
	  other	error.

       -remove-on-interrupt

	  If specified,	attempt	to remove the  job  from  the  queue  if  con-
	  dor_ssh_to_job  is  interrupted via a	CTRL-c or otherwise terminated
	  abnormally.

       -X

	  Enable X11 forwarding. Does not apply	to EC2 jobs.

Examples
       % 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.	There-
       fore, 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 work-
       ing 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 argu-
       ments 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.

Author
       Center for High Throughput Computing, University	of Wisconsin-Madison

Copyright
       Copyright  (C) 1990-2015	Center for High	Throughput Computing, Computer
       Sciences	Department, University of Wisconsin-Madison, Madison, WI.  All
       Rights Reserved.	Licensed under the Apache License, Version 2.0.

				     date  just-man-pages/condor_ssh_to_job(1)

Name | Synopsis | Description | Options | Examples | Exit Status | Author | Copyright

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=condor_ssh_to_job&sektion=1&manpath=FreeBSD+11.1-RELEASE+and+Ports>

home | help