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 and zlib@openssh.com (delayed zlib)
• 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:

1. Add the users that Deploy or Release should connect as.
2. Select Linux shell and Sftp from the shell list.
3. 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:

1. Add the users that Deploy or Release should connect as.
2. Select Login allowed.
3. 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 or wlst.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:

1. Create an overthere.SshJumpStation or overthere.HttpProxy CI that represents a host or proxy to which Deploy can connect directly.
2. For each remote host that cannot be reached directly by Deploy, create an overthere.Host CI and set the jumpstation property to refer to the overthere.SshJumpStation or overthere.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:

1. 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.

1. 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:

1. Log in to Release as a user with the Admin permission.

2. Select Settings > Shared configuration from the top menu.

note

Prior to Release 6.0.0, go to Settings > Configuration.

1. 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
2. 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.