The Secure Shell(SSH) protocol provides secure authentication and encryption replacing insecure login protocols such as telnet, rlogin and r-commands. It also supports the port forwarding of the X11 connections and arbitrary TCP/IP protocols.

SSH is based on the protocol documented by the SECSH Working group of IETF where many standard documents of network protocols are maintained by network designers, operators, vendors, and researchers.

Characters are not Displaying Correctly

Non ASCII characters may at time not be able to be shown like below:Abnormal status:Normal status:

This is caused by differences between language settings.

System $LANG Environment Variable.

To fix this issue run a command to find out what language and which encoding of that language is being utilized by your terminal.

test@uby:~$ echo $LANG
ko_KR.UTF-8
test@uby:~$

The output above indicates that the terminal is displaying information in the Korean format and the encoding of Korean characters is UTF-8.Broken characters are due to this encoding discordance with the terminal emulator.

The Encoding of Xshell

The encoding of the tool bar is set by the session file. But this can be changed at any time and even after the session is started. So when broken characters are shown, check this value.

Match the Encoding Between the Terminal and Xshell

The encoding of Unix and Linux is UTF-8 or Non-UTF-8. UTF-8 is common to all languages and utf8 and UTF-8 are the same. One is the alias of the other.

But Non-UTF-8 encoding is a little different. If your system uses Non UTF-8 such as EUC(Extend Unix Codes), ISO8859 series, or various Chinese encodings like BIG5, GB, etc., first set the encoding of Xshell to Default Language and try switching between the other encodings in the "More" area of the encoding button. You may need to go through several encodings to find the one that will work correctly.

When using Xagent to connect to an Xshell session, the user receives the following error:

RESOLUTION

During authentication, SSH Agents, including Xagent, continuously provide their keys one by one until a proper key matches. However, every SSH server limits the number of authentication attempts allowed. If too many unsuccessful auth attempts are made and the limit is reached, the ssh server will disconnect the session.

You can choose either to increase the limit of the ssh server or reduce the number of keys for Xagent, or both. To increase the limit, you'll need to configure your sshd_config files in your ssh server.

Once in your sshd_config file, increase "MaxAuthTries" to a desired number which represents the limit of failed auth attempts before the session disconnects. The default value for OpenSSH servers is 6.

Most terminals prints out its terminal name when the ^E character is echoed. When users execute the cat command of binary files or there is an abrupt interruption of the running program, an unintended ^E character can be outputted.

When this happens, Xshell prints its terminal name, "Xshell" in the terminal.

If you would like to avoid this behavior, you can prevent Xhsell from echoing back its terminal name. Go to your session properties and leave the "Answerback to ^E" field empty under Terminal -> Advanced.

Xshell Sessions Files set to ‘Read-Only’ After Upgrading to Windows 10

This is an issue with Windows 10. You may have trouble saving changes to your Xshell session files because you do not have permission to write. To fix this issue, you must grant yourself full control over your C:\Users folder. We have outlined a few of the solutions below.

Please keep in mind that these are not official solutions provided by Microsoft, and this issue has yet to be addressed by Microsoft. There does not seem to be a “one-solution-fits-all” for this issue as of now.

Option A:

Right click your C:\Users folder and click Properties

Navigate to the Security tab and click Advanced

Make sure your user account is listed under ‘Permission entries:’ and has ‘Full Control’ permissions

If not, click Change permissions and add your user account

Check the “Replace all child object permission entries with inheritable permission entries from this object” box

To connect to Server A through an intermediate server, Server B, you can use the Wait & Response feature. Please follow the instruction below:

Open Xshell.

Click File, and then Open.RESULT: Sessions dialog box opens up.

Select a session that will be an intermediate server. (Server B)

Right click on the session, and then click Properties.RESULT: Session Properties dialog box opens up.

Click Logon Scripts.RESULT: Logon Scripts page opens up.

Select the Execute the following Expect & Send pairs.

Click Add.RESULT: Wait & Response Rule dialog box opens up.

In the Expect field, type in the last few characters of the shell promptEx:If your prompt says [oracle@OTS oracle]$, then you should write oracle]$.NOTE: This is the last line you see on the Xshell terminal when you login to the destination server.

In the Response field, type in the SSH or Telnet command you use when connecting to the destination server.Ex: ssh John@192.168.1.193

SSH2 is a complete rewrite of the SSH1 protocol. They are two entirely different protocols. SSH2 is a significant improvement over older versions of the Secure Shell protocol. It is more secure, better designed and more flexible, so anyone who is still using SSH1 is strongly encouraged to upgrade to SSH2.

The SSH2 protocol provides the services such as server authentication, encryption, data integrity verification, and client authentication. The server authentication is performed using the DSA public key algorithm. For the encryption and the data integrity verification, a number of algorithms that can be implemented in modular fashion on every SSH2 product are provided. The client authentication can be performed using password and public key algorithm such as DSA or RSA as well as a variety of other methods.

The supported ciphers are AES128/192/256, 3DES, BLOWFISH, CAST128, ARCFOUR, and RIJNDAEL. And Xshell supports SHA1, SHA1-96, MD5, MD5-96, and RIPEMD160 MAC algorithms. You can configure multiple ciphers and MAC algorithms to be tried in order of the appearance in the list.

The SSH port forwarding is a good method of allowing secure, encrypted connections to traditionally non-encrypted services, such as POP3 for email, NNTP for news, etc. You can easily setup a port forwarding rule from Xshell. Simply put proper information to the Forwarding Rules dialog box.

If you are connecting from local client applications to the remote server application, you should set Xshell to forward the local port to the remote port.

If you are making secure connection to a POP3 server (mail.xyz.com:110) over Xshell, you may set as follows:

Listen Port: 5110Remote Host: mail.xyz.comRemote Port: 110

And, on the mail client(MS Outlook), you must setup the mail server and port.

Incoming mail server: localhostIncoming mail port: 5110

The POP3 client will connect to Xshell at local rather than connecting to the remote mail server directly. Xshell forwards all traffics to the mail server over the secure tunnel and transfers all traffics received from the mail server to the POP3 client.