Using SSH
The remoting functionality for Deploy and Release supports the SSH protocol for connecting to a Unix, Microsoft Windows, or z/OS hosts. To connect to a remote host using the SSH protocol, you must to install an SSH server on that remote host. For more information, see Remoting plugin and SSH protocol.
Unix remote host
For Unix platforms, we recommend using OpenSSH. It is included in all Linux distributions and most other Unix-based systems.
Microsoft Windows remote host
For Microsoft Windows platforms, Deploy supports these SSH servers:
- OpenSSH on Cygwin. Copssh is recommended as a convenient packaging of OpenSSH and Cygwin. It is a free source download, but since 22 November 2011, the binary installers are a paid solution.
- WinSSHD is a commercial SSH server.
- Install Microsoft OpenSSHD on your Windows host and make sure the OpenSSH Server service is enabled.
Note: The SFTP, SCP, SUDO, and INTERACTIVE_SUDO connection types are only available for Unix hosts. To use SSH with z/OS hosts, use the SFTP connection type. To use SSH with Windows hosts, use the SFTP_CYGWIN or the SFTP_WINSSHD connection type or the SFTP_OPENSSHD connection type.
SSH compatibility
Remoting functionality is provided by the Deploy or Release Remoting plugin, which uses the sshj
library for SSH and supports all algorithms and formats that are supported by that library:
- Ciphers:
aes{128,192,256}-{cbc,ctr}
,blowfish-cbc
,3des-cbc
- Key Exchange methods:
diffie-hellman-group1-sha1
,diffie-hellman-group14-sha1
- Signature formats:
ssh-rsa
,ssh-dss
- MAC algorithms:
hmac-md5
,hmac-md5-96
,hmac-sha1
,hmac-sha1-96
- Compression algorithms:
zlib
andzlib@openssh.com
(delayedzlib
) - Private Key file formats:
pkcs8
encoded (the format used by OpenSSH)
SFTP connection type
To use the SFTP connection type, ensure that SFTP is enabled in the SSH server. This is enabled by default in most SSH servers.
SFTP_CYGWIN connection type
To use the SFTP_CYGWIN connection type, install Copssh on the Windows host. In the Copssh control panel:
- Add the users that Deploy or Release should connect as.
- Select Linux shell and Sftp from the shell list.
- Depending on the authentication method you want to use, Select Password authentication and/or Public key authentication,
Note: Windows-style paths such as C:\Program Files\IBM\WebSphere\AppServer
will be translated to Cygwin-style paths such as /cygdrive/C/Program Files/IBM/WebSphere/AppServer
, so that you can use Windows-style paths in Deploy or Release.
SFTP_WINSSHD connection type
To use the SFTP_WINSSHD connection type, install WinSSHD on the Windows host. In the Easy WinSSHD Settings control panel:
- Add the users that Deploy or Release should connect as.
- Select Login allowed.
- Select Allow full access in the Virtual filesystem layout. Alternatively, you can select Allow login to any Windows account to allow access to all Windows accounts.
Note: Windows-style paths such as C:\Program Files\IBM\WebSphere\AppServer
will be translated to WinSSHD-style paths such as /C/Program Files/IBM/WebSphere/AppServer
, so that you can use Windows-style paths in Deploy or Release.
SFTP_OpenSSHD connection type
To use the SFTP_OpenSSHD connection type, install OpenSSHD on your Windows host and make sure the OpenSSH Server service is enabled.
Note: Windows-style paths such as C:\Program Files\IBM\WebSphere\AppServer
will be translated to OpenSSHD-style paths such as /C/Program Files/IBM/WebSphere/AppServer
, so that you can use Windows-style paths in Deploy or Release.
SUDO and INTERACTIVE_SUDO connection types
To use the SUDO connection type, set up the /etc/sudoers
configuration so that the user who is identified by the username
property on the SSH host CI can execute the commands below as the user who is identified by the sudoUsername
property on the CI. The arguments passed to these commands depend on the exact usage of the Deploy or Release connection.
chmod
cp
ls
mkdir
mv
rm
rmdir
tar
- Any other command that might be invoked by a middleware plugin. For example,
wsadmin.sh
for WebSphere orwlst.sh
for WebLogic.
You must configure these commands with the NOPASSWD
setting in the /etc/sudoers
file. Otherwise, you must use the INTERACTIVE_SUDO connection type.
When the INTERACTIVE_SUDO connection type is used, every line of the output will be matched against the regular expression configured with the sudoPasswordPromptRegex
property on the SSH host CI. If a match is found, the value of the password property is sent.
Note: In Deploy, you can check the INFO messages on the com.xebialabs.overthere.ssh.SshConnection
category to see the commands that are executed.
SU connection type
SU - when selected, it uses SSH:SU to establish connection to the Unix host. The connection will use a specified suUsername
as the user to execute commands and perform file I/O. Select this connection type if the username you are connecting with does not have the right permissions to manipulate the files that need to be manipulated and/or to execute the commands that need to be executed.
Note: If this connection type is selected, the suUsername and suPassword connection options are required and you can use them to specify the username/password combination that have the necessary permissions.
Connect Deploy through an SSH jumpstation or HTTP proxy
When Deploy cannot reach a remote host directly, but that host can be reached by setting up one or more SSH tunnels, configure one or more SSH jumpstations or HTTP proxies as follows:
- Create an
overthere.SshJumpStation
oroverthere.HttpProxy
CI that represents a host or proxy to which Deploy can connect directly. - For each remote host that cannot be reached directly by Deploy, create an
overthere.Host
CI and set the jumpstation property to refer to theoverthere.SshJumpStation
oroverthere.HttpProxy
CI created in step 1.
When Deploy creates a connection to the remote host and determines that it needs to connect through a jumpstation or HTTP proxy, it will either:
- Open a connection to the jumpstation and then setup a SSH tunnel (also known as a local port forward) to the remote host.
- Ask the HTTP proxy to connect to the target system with an HTTP CONNECT request.
Notes:
- SSH jumpstations can refer to other SSH jumpstations for even more complex network setups, but cycles are not allowed.
- HTTP proxies cannot refer to other proxies or to SSH jumpstations like SSH jumpstations can. Only the first host in the chain can be an HTTP proxy.
- Because Deploy cannot transfer files through a jumpstation, the Check connection control task will fail for the jumpstation when it attempts to verify file transfer. However, it will still succeed for the target host associated with the jumpstation.
How to reach a Key Distribution Centre (KDC) through an SSH jumpstation
When Deploy must communicate with a target host on Windows and when Kerberos, SSH, and a SSH jumpstation are in use, to allow Deploy to communicate with the KDC to retrieve a ticket from Kerberos, you must manually perform these actions:
-
Start a SSH tunnel to the jumpstation with the
-L
option of the SSH command line tool:$ ssh -L 2088:kdcl.windows.example.com:88
Note: Kerberos runs on port 88 on both UDP and TCP.
-
Modify your
krb5.conf
file to use the specified tunnel:[realms]
XEBIALABS.LOCAL = {
kdc = localhost:2088
}
Connect Release through a jumpstation or HTTP proxy
When Release cannot reach a remote host directly, but that host can be reached via one or more SSH tunnels or HTTP proxies, you can configure these as follows:
-
Log in to Release as a user with the Admin permission.
-
Select Settings > Shared configuration from the top menu.
Note: Prior to Release 6.0.0, go to Settings > Configuration.
-
Depending on the kind of jumpstation you want to set up:
- Under Remote Script: SSH jumpstation click Add SSH jumpstation -or-
- Under Remote Script: HTTP proxy click Add HTTP proxy
-
Enter a name for the jumpstation and provide the connection details.
SSH jumpstations can also be reached via other jumpstations for even more complex network setups, but cycles are not allowed.
When Deploy creates a connection to the remote host and determines that it needs to connect through a jumpstation, and will first open a connection to that SSH jumpstation and then setup a SSH tunnel (also known as a local port forward) to the remote host.
Note: Jumpstations are configured globally in Release, not per-release.