7021999: Local and Remote Port Forwarding and the Reflection for Secure IT Client 7.1 or Higher

A Brief Introduction to SSH

SSH is a computer program based on the Secure Shell protocol. SSH provides strong, encrypted authentication and a secure encrypted tunnel through which users can execute commands and move data. The current version of Secure Shell is ssh-2. (The ssh-1 protocol is deprecated; therefore, it is highly recommended that you use ssh-2.)

For more information about Secure Shell, see “Fortified SSH: A Cost-Effective Way to Safeguard Your Network” on Attachmate.com: http://www.attachmate.com/WhitePapers/Literature_0954.htm.

An Introduction to Port Forwarding (Tunneling)

Port forwarding, also known as tunneling, provides a way to redirect non-secure TCP/IP communications through a secure SSH connection. When port forwarding is configured, all data sent to a specified port is redirected through the secure channel. Most remote services that use TCP/IP can be secured, including client-server applications, database systems, and services such as HTTP, Telnet, FTP, POP3, and SMTP. The Reflection for Secure IT and Reflection clients also provide dynamic forwarding for the X11 Windows System commonly used on UNIX machines.

There are two types of port forwarding: local and remote.

Local Port Forwarding—In most cases, local port forwarding is used to forward data securely from another client application running on the same computer as the Secure Shell client. The Secure Shell client is configured to redirect data from a specified local port (on the same computer as the Secure Shell client), through the secure tunnel to a specified destination host and port. You can configure any other client running on the same computer to connect to the forwarded port (rather than directly to the destination host and port). After the Secure Shell connection is established, the Secure Shell client listens on the specified port and redirects all data sent to that port through the secure tunnel to the Secure Shell server. The server decrypts the data, and then directs it to the destination host and port.

Remote Port Forwarding—Remote port forwarding is used to forward data securely from any client application running on the same computer as the Secure Shell server. In this case, the client session requests that a specified remote port (on the same computer as the Secure Shell server) be used to redirect the data. You can configure any other client running on the same computer as the Secure Shell server to connect to the forwarded port (rather than directly to the destination host and port). After the Secure Shell connection is established, the Secure Shell server listens on the specified port and redirects all data sent to that port through the secure tunnel to the Secure Shell client. The client decrypts the data and then directs it to the destination host and port.

To tunnel TCP traffic with SSH, you must configure local or remote port forwarding (or both), establish the SSH connection, and then configure the application you want to secure to redirect its communication through the SSH tunnel.

Using the Reflection for Secure IT Client for Secure Connections

Port forwarding is configured only by the SSH client, not the Reflection for Secure IT server. However, you can configure the server to enable or disable requests made by the client.

Step I—Configuring the SSH Server to Allow TCP Tunneling

Before using port forwarding, ensure that the SSH server is configured to enable tunneling. How you configure the server depends on which server version and platform you are using.

Both local and remote port forwarding are enabled by default in version 7.0 or higher of the Reflection for Secure IT Server. For details about these settings, go to the product documentation page, http://support.attachmate.com/manuals/sshdocs.html. Select your product; open the Reflection for Secure IT Server Users Guide for your product version; and search for Port Forwarding.

For details on configuring other SSH server software, refer to your man pages or the product’s documentation.

Step II—Configuring Port Forwarding

The client can be configured to request local or remote port forwarding, or both.

For information about configuring the Reflection for Secure IT Client for port forwarding, go to the product documentation page, http://support.attachmate.com/manuals/sshdocs.html. Select your product; open the Reflection for Secure IT Client Users Guide for your product version; and search for Port Forwarding.

Using the Reflection for Secure IT Interface (Windows Client)

Follow the steps below to create, close, and edit an SSH tunnel using the Reflection for Secure IT Windows Client.

Configure Local Port Forwarding

To create a local tunnel:

  1. Click Start > Programs > Attachmate Reflection > SSH Client.
  2. Click Connection > Connection Setup; enter the host name, and then click Security.
  3. On the Tunneling tab, under Local Forwarding, click Add.
  4. In the Forward local port field, enter a local port number that the Reflection client should use to listen for TCP or FTP data requests. Data sent from this port will be forwarded through the Secure Shell tunnel.

Note the following:

    • Port numbers higher than 1025 are user-defined ports. Using ports 1 – 1024 requires administrative privileges.
    • Make sure to select a non-used port for your Source Port. If the port number entered matches a port that is already configured to listen for another service, the Reflection SSH client will be unable to forward the data.
    • If you create several tunnels for one connection, you must specify a different local port for each tunnel.
  1. In the Name field in the Destination Host section, enter localhost.

Important: Localhost is used for the name of the remote machine if the tcp application server you are connecting to through the tunnel is running on the same server where the SSH daemon resides, which is often the case.

If the SSH daemon resides on a different host than the host on which the tcp application is running, enter the name of the host you are connecting to in the Destination Host field. In this instance, the connection between the Reflection SSH client and the SSH daemon is secure, but the connection between the SSH daemon and the target host is not secure.

  1. In the Port field, enter the TCP/IP port on the SSH server where the application that uses the tunnel sends its data requests. For example, if you will be forwarding Telnet, the default port for Telnet is 23.
  2. Optional: The Local Port Forwarding dialog box enables you to configure several additional settings including Tunnel Remote Desktop, Forward type, and Application to Launch. For information about these settings, click the Help button on the Local Port Forwarding dialog box.
  3. Click OK twice to return to the Connection Setup dialog box.

This tunnel configuration is automatically saved to the user’s config file (under SSH config scheme) and will be used again when you connect to the same host (using the same host name).

  1. Enter a User name and click Connect. Once the SSH connection has been established, unencrypted TCP traffic from a third-party application can be securely sent through the SSH tunnel.
  2. To save all of the non-SSH related settings, such as host and user names, for use the next time you launch the Reflection for Secure IT client, click File > Save in the SSH client window. Enter a file name and click Save.

When the Reflection SSH client receives a local request on the specified source port, the application is connected to the destination port through the SSH tunnel.

Note the following:

  • Changes you make to these settings are saved to the currently specified SSH config scheme.
  • Secure Shell settings are saved to the Secure Shell configuration file. You can also configure Secure Shell settings by editing this file manually in any text editor. The keyword used to configure local port forwarding is LocalForward.

Close a Tunnel

To close a tunnel, terminate the host session.

Edit a Tunnel Configuration

To edit tunnel settings:

  1. While the tunnel is not connected (no host connection has been made), click Connection > Connection Setup. Make sure that the correct host name has been entered, and then click Security.
  2. On the Tunneling tab, select the local tunnel you want to edit and click Modify.
  3. Edit the settings and click OK twice.

Using the Command Line (Windows and UNIX Clients)

You can use commands to establish the SSH connection and create the SSH tunnel from the command line.

Use the following command to forward TCP traffic on the workstation through an SSH tunnel to the SSH server.

Syntax:

ssh –L <local workstation port>:localhost:<SSH server port> <user name>@<host name>

Example:

ssh –L 4000:localhost:4005 RKoa@mySSHserver

In the example above, TCP traffic will be forwarded through port 4000 on the workstation to port 4005 on the SSH server.

Step III—Configuring the Application to Use the SSH Tunnel

After creating the SSH tunnel by following the procedure in Step II, you must configure your application to use the SSH tunnel. The configuration will be different for each application. For details, refer to the application documentation.

An Example

The following example shows how to configure Reflection for HP or Reflection for UNIX and OpenVMS to redirect a Telnet session over the port you have redirected to connect through SSH.

  1. Start the Reflection for Secure IT SSH tunnel (see Step II for details).
  2. Open Reflection for HP or Reflection for UNIX and OpenVMS, and then click Connection > Connection Setup.
  3. Under Connect using, select Network and Telnet. In the ‘Host name’ field, enter localhost, and then click More Settings.
  4. On the General tab, select TCP port 1025 (or whatever port number you configured in Step II-4 above), and then click OK.
  5. Click Connect, and log in to the host.

Verifying the Secure Connection with the Windows Client

To verify that your Telnet session is running through the SSH tunnel, follow these steps.

  1. Click Start > Run.
  2. In the Open field, type cmd, and then click OK.
  3. In the Windows Command window, type netstat.

Note: If the netstat command is not recognized, navigate to the C:WindowsSystem32 directory and enter the command again.

If the port forwarding is successful, you should see a response similar to the following:

Active Connections

Proto Local Address Foreign Address State

TCP My_PC:1554 my.server.com:22 ESTABLISHED

TCP My_PC:1025 localhost:1564 ESTABLISHED

TCP My_PC:1564 localhost:1025 ESTABLISHED

In the example above, the first TCP row shows the SSH connection from port 1554 (a random port) on the workstation to port 22 (the default SSH port) on the SSH server.

The second and third TCP rows show the Telnet connection between port 1025 on the workstation, the port that has been configured to redirect Telnet connections (port 23) through the SSH tunnel (port 22), and a random port (1564) on the SSH server.

Note: If the second or third TCP row shows the actual host name, such as my.server.com:telnet(23), instead of localhost:<port number>, the tunnel has failed and the Telnet connection is not encrypted.

Sample Settings

The following sample settings show how to forward HTTP.

Forwarding HTTP

  1. Use the Reflection SSH client to connect to the host running the HTTP and SSH servers.
  2. Create a local tunnel with the following values.
    Field
    Data
    Local forward
    8080

    Note: This number can be any port number over 1024.

    To remote
    localhost
    Port
    80
  1. Open your web browser and go to http://localhost:8080.

Your HTTP connection is now going through the SSH tunnel.

Related:

how to run gnome-terminal on remote centos 7 machine?

My local machine is linux mint, and remote one is centos 7.
I try to open gnome-terminal on remote machine with x-forwarding, and its not working.

When I connect to host in interactive mode

$ ssh -Y centos-host

Then in opened session I can run gnome-terminal and x-forwarding working

$ gnome-terminal 
$ netstat -nltp
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN      -  

However when I try yo run

$ ssh -Y centos-host gnome-terminal

The window with gnome terminal opened, but no tunnel for X created.

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -

I have an another linux mint remote machine, and not experienced such problem with it. So, I think something wrong with centos 7.

Please, help.
Thank you.

Related:

Error authenticating via SSH

One of our clients is attempting to start an SFTP session on our file transfer server. When they try to authenticate we see these errors in the auth.log.

Jan 16 11:24:34 ft sshd[6898]: error: kex protocol error: type 30 seq 1 [preauth]
Jan 16 11:24:34 ft sshd[6898]: error: Received disconnect from xxx.xxx.xxx.xxx port xxxxx:3: Expected SSH_MSG_KEX_GEX_GROUP [preauth]
Jan 16 11:24:34 ft sshd[6898]: Disconnected from xxx.xxx.xxx.xxx port xxxxx [preauth]

We can’t figure out why this client cannot connect and all other clients can connect.

Versions: Ubuntu 16.04.1 LTS OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 OpenSSL 1.0.2g

Edit: Forgot to mention the fact that our client can connect using their local machines, the issue is that their production server cannot connect. We have set up our sshd_config to permit all available KexAlgorithms and Ciphers as listed by man sshd_config.

I’m just trying to understand what exactly is failing. Is it their server failing to establish an SSH connection to begin the authentication process?

Related:

How to temporarily run a secondary SSH server on a separate port

How do you run an SSH daemon on a different port other than the standard 22?

I screwed up something with my SSH configuration on a cloud VM, so that now SSH always prompts me for a password. My early attempts to fix this locked me out, forcing me to umount the disk, mount it inside a working VM, and fix the files to a known working state. However, it’s still forcing me to enter a password.

I’d like to update my /etc/ssh/sshd_config and restart the main ssh daemon, which I can test against, while still having another one running, using the old configuration, that I can use to revert the configuration in case the first one locks me out. How would I do this, specifically on Ubuntu?

Related:

How to temporarily disable local forwards

I have in my ~/.ssh/config file entries with local forward definitions like

HOST myServer
   hostname 10.10.0.1
   user xyz
   LocalForward 8080 localhost:80
   LocalForward 4000 127.0.0.1:4000
   ...

This works like a charm, but I also have scripts to synchronize some data.
These scripts show many warnings when they try to connect to the server while there is already a connection.

bind: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 8080
bind: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 4000
....

Is there a neat way to use ssh or rsync with an option to disable all local forwards for a session?

Obviously I could copy&paste each config block and build one with and one without local forwards, but I hope there is a better solution.

Related:

How to connect to remote server?

I want to connect to a remote server.

Before this command worked perfectly :
ssh -i vpsMain root@163.xxx.xxx.xxx

I need to connecto a other server on this VPS and beacause I’ve this error when I tried to connect it on VPS :`Provided Host header is not whitelisted“

I do this following command to add host of my server into whitelist of my remote server :

iptables -A INPUT -i eth0 -s ip addresse -j ACCEPT
iptables -A OUTPUT -o eth0 -d ip addresse -j ACCEPT

After this when I do telnet 163.xxx.xxx.xxx i’ve connection refused

So I wanted to remove iptables actions and do on the remote server :
iptables -P INPUT DROP

After this the remote server crash.
I now when I want to connect to it with this command :

ssh -i vpsMain root@163.xxx.xxx.xxxit doesn’t work and have this error :ssh: connect to host 163.xxx.xxx.xxx port 22: Operation timed out

Can someone help me?

Related:

Chaining sshuttle commands over two hops

I have the following scenario:

  • Host A: Mi machine
  • Host B: Server – 192.168.1.1
  • Host C: Hop node – 192.168.2.1
  • Network N: 192.168.3.0/24

Using sshuttle what’s the best way to forward and be able to reach machines of network N (192.168.3.0/24) from Machine A, passing thru B and C?

I can actually run:

sshuttle -r root@192.168.1.1 -v 192.168.3.0/24 &
ssh root@192.168.1.1
sshuttle -r root@$192.168.2.1 -v 192.168.3.0/24 &

If I open in the browser for example http://192.168.3.5 from Machine A I’m receiving the TCP packages in the destination node, but not getting routed correctly the answer.

Related:

How do I use my .pem file from Amazon EC2 with mosh?

To login with ssh I do this:

ssh -i ~/.ssh/kp1.pem ubuntu@ec2-xxxx.com

I tried all this with mosh:

mosh --ssh='ssh -i ~/.ssh/kp1.pem ubuntu@ec2-xxxx.com'

mosh -i ~/.ssh/kp1.pem ubuntu@ec2-xxxx.com

But I get the error:

/usr/bin/mosh: could not get canonical name for /home/$USER/.ssh/kp1.pem: Name or service not known
ssh_exchange_identification: Connection closed by remote host
/usr/bin/mosh: Did not find remote IP address (is SSH ProxyCommand disabled?).

Related:

accessing a server via SSH through ilo – dumping information/current state

I’m having to frequently access servers via ilo – ssh only, no web interface. Am I meant to be able to bring a server back up through just this tool? Or utilize others like ipmtool to be able to do things? Similarly when the server’s stuck in boot, how can I tell from this interface? So far all I can tel is how to power on/off, not obtain any useful information from the server.
There seems to be various syntax as well, one where I can go into map1, another with admin1.
Also although there is a power command, there is no view status option that I’m aware of.

Can I get advice, or a point to the right direction to find out this information?

Related: