Setting up Telnet and SSH Servers
RemotelyAnywhere allows you to set up Telnet and SSH connections to access a computer.
Telnet provides a text-oriented virtual terminal connection. By setting up a Telnet server you can select a TCP/IP port or address to listen on for telnet connections. Go to Preferences > Telnet Server to specify which port or address you want RemotelyAnywhere to listen on for communication.
An SSH server is a software program which uses the secure shell protocol to accept connections from remote computers. It is especially useful for setting up SFTP file transfers and remote terminal connections.
How to Set Up a Telnet Server
Follow this procedure to make sure that users can access your RemotelyAnywhere host computers.
- Click Preferences to access the host preferences.
- Under Telnet Server, select from the following options:
Option Description TCP/IP port to listen on Type the port that you want RemotelyAnywhere to listen on for telnet connections. By default, port 23 is used. TCP/IP address to listen on Type the IP address that you want RemotelyAnywhere to listen on for telnet connections. Accept RemotelyAnywhere connections (secure) Allow connections from RemotelyAnywhere's built in Command Prompt. Accept Telnet connections Allow plaintext terminal emulator connections. If disabled, only the built-in Java client can be used to access Telnet. Show login banner Enable or disable the login message sent by the Telnet/SSH servers when a connection is established. Maximum simultaneous connections Set the maximum number of connections to the Telnet/SSH servers. It's a good idea to set a reasonable limit, especially on computers connected to the Internet. Every new connection uses resources on the computer. Timeouts Set the login timeout (number of seconds the user may remain idle during the login process), the idle timeout (number of seconds the user may remain idle during a Telnet/SSH session) and the session recovery timeout. When a Telnet connection is broken ungracefully (that is, the user does not type exit at the command prompt) it is possible to reconnect to the session and continue work where it was left off for a period of time. You can specify the amount of time for which you want the lost telnet session to remain available. Any and all running programs started by the user in the Telnet session will be available when the session is resumed. RemotelyAnywhere Client Set the number of columns and rows that the console window will occupy. You can also specify whether you would like to have the client open in a new window, or in a new window in full screen mode. Telnet/SSH Client Default Parameters Set the default parameters for the Telnet/SSH client. You can also select the console mode (Stream, Full ANSI Colors, or Full Monochrome) and enable/disable the console parameters option. - Click Apply.
Result: Your settings are applied after restarting RemotelyAnywhere.
How to Set Up an SSH Server
Follow this procedure to make sure that users can access your RemotelyAnywhere host computers.
- Click Preferences to access the host preferences.
- Under SSH Server, select from the following options:
Note: Certain Telnet settings also apply to SSH connections.
Option Description TCP/IP port to listen on Type the port that you want RemotelyAnywhere to listen on for SSH connections. By default, port 22 is used. TCP/IP address to listen on Type the IP address that you want RemotelyAnywhere to listen on for SSH connections. Features Enabled Select the features that you want to enable for your SSH server. SSH Protocol v1/ v2 Select which version of SSH the server should use. SFTP server (SSH2 only) Select this option to enable an interactive secure file transfer method. SCP server Select this option to enable a non-interactive secure file transfer method. Map network drives Select this option to map your network drives. Compression Select the compression method that you want to use for sending data: - Delayed The start of 'zlib' compression is delayed until the user has been authenticated successfully. This eliminates the risk of any zlib vulnerability leading to a compromise of the server from unauthenticated users.
- Enabled Data sent over the network will be compressed.
- Disabled Data sent over the network will not be compressed.
Password authentication Select this option to force the user to enter a username / password combination in the terminal emulator client program and use that to gain access to the RemotelyAnywhere host. Keyboard-interactive authentication This is similar to the Password authentication option, but the user will not be able to save the username / password in the terminal client. Public key authentication Select this option to allow the user to enter a username and then gain access to the SSH host without entering a password. A private key is used on the client side to authenticate against the matching public key on the host. Cross check IP and DNS entry of clients Select this option to check if the IP address and DNS of a client matches. For example, if the client has the IP address 192.168.0.10, and this IP address resolves to COMPUTER1, but COMPUTER1 does not resolve to 192.168.0.10, the connection will be refused. Forwarding of server-side ports SSH Port Forwarding allows server-side ports to be forwarded to others, effectively creating a virtual encrypted tunnel for the duration of the SSH session. - Enabled port forwarding requests from users are accepted by the SSH server
- Disabled SSH port forwarding is not available for users
- Restricted for every port forwarding request RemotelyAnywhere will check if the target host is in the defined HOST:PORT list. To set up restrictions, go to Security > Access Control, click the name of a user and click SSH Port Forward restrictions. Port forwarding will only start if it is defined.
Remote connects to forwarded ports Select this option to allow the ports to be forwarded outside the server; that is, to any computer on the network that the server can access. Local ports accept connections from other hosts. Remote ports do the same. Path Mapping in SCP/SFTP Use this feature to create virtual folders for SCP and SFTP. To create a new path mapping entry, type the Virtual path and the Physical path. You can use standard Windows path syntax and/or environment variables in the physical path (for example %TEMP% to /tmp, or c:\LogFiles to /log).
When the connection is made to the Host with SCP or SFTP, virtual folders can be addressed in the same format as physical.
Virtual and physical folders must be referenced UNIX style, using a forward slash mark in place of a back slash Example: c/Program Files/RemotelyAnywhere/x86/RemotelyAnywhere.exe
Note:- SFTP does not list virtual folders
- It is possible to create virtual folders within physical folders /c/windows/pic > d:\Pictures where /c/windows is a physical folder
- It is possible to create virtual folders within existing virtual folders /doc/video > d:\Videos where /doc is a previously created virtual folder
- If a virtual and a physical folder are located under the same path, the virtual folder takes precedence /c/windows/system32 > d:\DataFiles. By entering /c/windows/system32 you will see the contents of d:\DataFiles instead of c:\Windows\system32
- It is possible to create a virtual folder without creating its parent folder /jpg/2007 > d:\Images
Host Keys The SSH Host Keys section lets you re-generate SSH1 and SSH2 host keys used by the SSH server. You can specify the key size, but the larger the key, the longer it takes to generate it. Anything above 2048 bits is excessive, and will take a very long time even on a fast computer. SSH hosts have keys that can be used to identify them, much like SSL-protected websites have certificates. SSH1 only supports a single host key, while SSH2 supports both RSA and DSA keys. The key length is recommended to be 1024 bits or more, and can be 512, 768, 1024, 2048 or 4096. The SSH1 server key is a key that is relatively short, and has a short lifetime. It is used in conjunction with the host key to negotiate a one-time session key for each connection. SSH2 uses the Diffie-Hellman key exchange protocol to negotiate the session key and therefore does not need one.
Export SSH2 public host keys in SECSH format lets you export the host keys and save them in your terminal emulator. This way, you can be sure that when the emulator connects to the RemotelyAnywhere computer and does not put up a warning about an unknown host key, you are still in fact connecting to the intended computer. Privilege Separation The server needs to execute with LocalSystem privileges to access resources required for user authentication and impersonation. For information on privilege separation, click What is it? - Click Apply.
Result: Your settings are applied immediately to the host.