Extended Use of SSH Tunnelling with Putty to Access Inaccessible Remote Desktop and URL

Now, let us take another samples of using Putty for SSH tunneling, other than like explained in previous article.

Basically, the pre-conditions are similar with previous one. First, there is Server-A which it can be connected through SSH from user’s PC, and Server-A has connectivity to access remote desktop and web server of Server-B. Second, TCP forwarding is enabled in Server-A. (Kindly read previous article how to enable it, if required)

Note: To make sure Server-A has connectivity through remote desktop to Server B, TCP port 3389 has to be opened from Server-A to Server-B. And for accessing web server, TCP/HTTP port 80, used as sample, has to be opened from Server-A to Server-B.

URL

Dynamic port method will be used to access inaccessible URL: http://Server-B/.

First, establish SSH connection to Server-A using Putty. Once connected, open change settings menu (right click on top panel and choose change settings). There is category box on left side, go to Connection > SSH > then click Tunnels. Put any available local port on Source port text box (in this example, 4000 is chosen), tick Dynamic radio button, after that click Add then Apply.

Second, open browser (in this sample, Mozilla is used), go to Options > Advanced > Network > Connections Settings. Tick Manual Proxy Configuration, leave all with empty/default value, except on SOCKS Host, fill as localhost and Port: 4000. And also kindly do not forget to tick SOCKS v5, then click OK button.

Once done, now try to access http://Server-B/, it will be opened.

Remote Desktop

Method that will be used is putting IP and Port of Server-B explicitly in tunneling. Assuming IP of Server-B is 10.10.10.11.

First, Establish SSH connection to Server-A using Putty. Once connected, open change settings menu (right click on top panel and choose change settings). There is category box on left side, go to Connection > SSH > then click Tunnels. Put any available local port on Source port text box (in this example, 4002 is chosen). And on Destination, fill explicitly the IP and port of Server-B, with format IP:port, in this example, value is 10.10.10.11:3389), tick Local radio button, after that click Add then Apply.

Second, Open Remote Desktop Application, fill the Computer’s field with localhost:4002 then Connect, or simply Ctrl+R then type: mstsc /v: localhost:4002 then Enter. After that, Remote Desktop to Server-B will be possible.

Advertisements

Step by Step: SSH Tunneling with Putty

Supposed there is server A (UNIX based), where you have firewall opened to do SSH connection from your PC directly. And there is another server (server B), where it’s connected from Server A with SSH but you have no direct SSH connection from your PC to server B (firewall is not opened from your PC to server B) .

This article will try to give tips, to make direct SSH connection possible with SSH tunneling from your PC toward server B by using Putty tool.

Note: as pre-requisite to do SSH tunneling, please set AllowTcpForwarding parameter with value equal Yes inside sshd_config fileof Server A, then restart ssh service

server-A> grep -i tcp /etc/ssh/sshd_config
AllowTcpForwarding yes
server-A> svcadm restart ssh

Method#1- Using Dynamic Port

First, connect to Server A and setup the tunnel using dynamic port

Establish SSH connection to server A using Putty. Once connected, open change settings menu (right click on top panel and choose change settings). There is category box on left side, go to Connection > SSH > then click Tunnels. Put any available local port on Source port text box (in this example, 4000 is chosen), tick Dynamic radio button, after that click Add then Apply.

Second, connect to Server B using tunnel that already set

Prepare new putty session to connect to Server B, after putting the IP and port on session part, before clicking on Open button, go to Connection > then Proxy. Tick SOCKS 5 radio button on proxy type, then on proxy hostname, fill localhost and port 4000. Click open, then now you can connect to Server B directly by using server A as proxy to make a tunnel.

Method#2- Put IP and port of another server explicitly

First, connect to Server A and setup the tunnel using specific IP and port of Server B

Establish SSH connection to server A using Putty. Once connected, open change settings menu (right click on top panel and choose change settings). There is category box on left side, go to Connection > SSH > then click Tunnels. Put any available local port on Source port text box (in this example, 4001 is chosen). And on Destination, fill explicitly the IP and port of server B with format IP:port, in this example, value is 10.10.10.10:22), tick Local radio button, after that click Add then Apply.

Second, connect to Server B using tunnel that already set

Prepare new putty session to connect to Server B, on Hostname (or IP address), fill with localhost and port, is 4001. Click open, then connection to Server B can be done directly.

Resolving “Warning: Remote Host Identification Has Changed!”

Somehow the known_hosts file is getting problem and whenever ssh is performed to other host, it is giving below warning message. The simplest way, this situation can be tackled by removing specific line containing the IP/hostname that we want to connect in known_host file or other way by moving the current known_hosts file to other name or if it is not needed, remove it. Or they other way to re-initiate key for that hostname/IP.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
ad:23:94:29:84:70:54:96:fe:0a:89:90:3c:97:0f:45.
Please contact your system administrator.
Add correct host key in /home/username/.ssh/known_hosts to get rid of this message.
Offending key in /home/username/.ssh/known_hosts:99

RSA host key for xxx.xxx.xxx.xxx has changed and you have requested strict checking.
Host key verification failed.

Usually known_host file is located in .ssh directory inside home folder of related username

Above warning message shows us, it is placed under /home/username/.ssh/known_hosts

Generating new key for mentioned hostname/IP
ssh-keygen -R <hostname/IP>
Moving it to other file name
mv /home/username/.ssh/known_hosts /home/username/.ssh/known_hosts.old
Removing it
rm /home/username/.ssh/known_hosts

How to Enable Authentication for Ethernet Interface Connection in Windows

While connecting to a certain network, like LAN, it may be required to input the credential: username and password. To be able input the credential, the authentication for Ethernet Interface Connection must be activated.

So, how to make this authentication enabled? Kindly follow below steps:

(1) Open Services Tool

It can be opened via: (a) Control Panel\All Control Panel Items\Administrative Tools then click Services or (b) Ctrl+ R, then type services.msc, then press Enter

(2) Search for Wire AutoConfig Service, then start it

Note:

Below captures are showing the difference before and after authentication is enabled

Before

After

The credential, username and password, can be input by clicking Additional Settings and there will be pop up windows, tick Specify authentication mode, then just click Replace Credentials.

(To get above captures: Go to Control Panel\Network and Internet\Network Connections, right click on one of required connection then click properties)

How to Resolve TAR error: “filename is greater than 100” in UNIX

For instance, we want to tar one file called: adkfhasdkfhkjbasdfkusdbnwqpadwlfpwemrnfuabfasdfyasdfbasdflasdfdyfdfafdlsasdflkjasdflkasdfkljasdflkj.xml

Normal tar processing, will give an error as below:

# tar -cf result.tar adkfhasdkfhkjbasdfkusdbnwqpadwlfpwemrnfuabfasdfyasdfbasdflasdfdyfdfafdlsasdflkjasdflkasdfkljasdflkj.xml
tar: adkfhasdkfhkjbasdfkusdbnwqpadwlfpwemrnfuabfasdfyasdfbasdflasdfdyfdfafdlsasdflkjasdflkasdfkljasdflkj.xml: filename is greater than 100

To tackle such above issue, please run below command:

#  tar cEvf - adkfhasdkfhkjbasdfkusdbnwqpadwlfpwemrnfuabfasdfyasdfbasdflasdfdyfdfafdlsasdflkjasdflkasdfkljasdflkj.xml > result.tar

There is another case, for example, a folder (named: TESTFOLDER) containing lot of files whose filename’s length is more than 100 chars. The purpose is to tar and then compress it directly. Executing following command will help to deal with it:

#  tar cEvf - TESTFOLDER | gzip > result.tar.gz

How to Get ILO’s MAC Address of HP Servers DL360p G8/ DL380 G6/ BL460c G8/ BL620c G7/ BL460c G6

For standalone servers like, HP DL360p G8 or HP DL380 G6, at least two ways can be used:

First, ssh or telnet to the ILO IP, then run following command
show /map1/enetport1

The mac address will be shown under PropertiesPermanentAddress attribute

Second, go to ILO URL

After login through ILO URL (https : //<ILO-IP > or http : //<ILO-IP >), go to menu System Information then Network (if it is using ILO 4) or NIC Information (if it is using ILO 3) or NIC (if it is using ILO 2) to show the mac address

Additionally for blade servers with type (BL460c G8 or BL620c G7 or BL 460c G6), the ILO’s mac address can also be retrieved via On-board Administrator (OA).

Third, go to OA

Once login completed toward OA URL (https : //<OA-IP > or http : //<OA-IP >), expand the menu Device Bays on the left side, choose related server, then click the ILO. The mac address will be shown under sub-menu Processor Information

How to Troubleshoot “Not Working SSH Password Less Setup”

Usually, ssh password less setup that i have done many times before were working fine. But, one time it was not, albeit same instructions were followed. Similar hardware, similar operating system. Interesting!

Finally, after spent some time, i got it resolved. Here are summarized notes of my experience for additional guidance to troubleshoot. Hopefully it will be also useful for anybody having similar issue.

1# Run ssh with verbose mode from source server toward destination server having problem to see for any error or useful message as clue

debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/identity
debug1: Trying public key: /.ssh/id_rsa
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Trying public key: /.ssh/id_dsa
debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:

2# Do the same (ssh with verbose mode), but now toward destination server having no issue with password less

debug1: Next authentication method: publickey
debug1: Trying private key: /.ssh/identity
debug1: Trying public key: /.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 80aaf80 hint 1
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey)
debug1: SSH receive window size: 198560 B
debug1: channel 0: new [client-session]
debug1: send channel open 0

3# By comparing both logs, found that, it seems destination server does not accept key from source server. From log in point 2#, can be seen Server accepts key and Authentication succeeded. But it’s not in point 1#

4#  I thought, there it was due to something like mismatch key, then tried to re-setup password less between source and destination, but unfortunately it was not helping.

5# Double checked permission for .ssh directory and authorized_keys file, both were fine (.ssh is already 700 and authorized_keys is already 600). In this case, there should be no issue.

6# And last thing i forgot was to check parent directory of .ssh directory (which is home folder of the user). I came to know, the main problem was it! I used root user for this setup, and the permission for / was belong to other user instead of root.

So, for my case, the problem was incorrect permission for parent folder of .ssh

Permission of / before change

bash-3.2# cd /
bash-3.2# ls -la | head
total 9456
drwxr-xr-x  48 webservd     webservd        1536 Feb 22 14:28 .

Got it correct

bash-3.2#chown root:root .

After change

bash-3.2# ls -la | head
total 9456
drwxr-xr-x  48 root     root        1536 Feb 22 14:28 .

Note: Above was tried on Unix Solaris 10 operating system.