app:jta The Java Telnet Applet 

Basic Info 



The Java(tm) Telnet Applet is a fully featured telnet/SSH program that allows users to connect and login to remote hosts via the Internet or an Intranet using only their WWW Browser.


The Java Telnet Applet is a fully featured telnet implementation coupled with a very sophisticated terminal emulation for VT and ANSI terminals.




Version 2.6 (Swing, Java WebStart based), 27. September 2005

documented on: 2007.07.28

Keeping Bash Session Alive 

Newsgroups:  comp.os.linux.misc
Date:        Fri, 11 Jun 2004 13:25:04 GMT

A bash session through a firewall to linux gets timed out after a certain amount of minutes of inactivity. Is there something I can do in the shell to make it seem like it is alive? It seems that anything I do would be a background process and spawn another shell.

Keeping Bash Session Alive 

What I do is to setup a script that send an 'ls' along the pipe and then sleep for 5 minutes, then send another ls and so on… ok, it's crude and it's uggly but… hey! it works!


Keeping Bash Session Alive 

> [quoted text muted]

More like

# in file ~/bin/
while true ; do
   echo " " ; sleep 300
# end script

just execute " &" from your session and "kill %1" before logging out. The spaces it echoes may screw up formatting but they'll be easier to remove than the output from ls.

Matt G

Keeping Bash Session Alive 

how about:

(while true ; do echo -ne "\000" ; sleep 300 ; done ) &

As far as i can work out, the null chars do get sent to the controlling tty, but aren't displayed, so they won't screw up the display (except if they get inside escape sequences).

Keeping Bash Session Alive 

> [quoted text muted]

Assuming you are using ssh, you should, simply use 'ClientAliveInterval' and 'ClientAliveCountMax'.

Try 'man sshd_config' for more info, that usually prevents firewalls from closing connections.

Michael Heiming

Keeping Bash Session Alive 

> [quoted text muted]

An alternative you might actually prefer is GNU Screen. This makes your session a "virtual" session that survives a disconnection. If the bash session is killed—via time out or logging out or whatever—then the screen session survives. You can log into another bash shell and reconnect with the orphaned screen session. You can even spawn multiple screen sessions and flip from one to another, or even view multiple sessions in text "windows" on the same terminal. You can even remotely disconnect a screen session from one term and then connect it to your current term (i.e. you've walked to another computer and want to move your screen session to this computer).

With screen, you won't have to worry about your bash session timing out—you can just start up a new bash shell and continue with your disconnected session! From a security standpoint, you and your sysadmin may actually prefer this solution.

Isaac Kuo

ssh PATH setting 


Can't launch rsync from within iitrc:

$ ssh -v iitrc rsync
debug: Sending command: rsync
debug: Entering interactive session.
bash: rsync: command not found


rsync is there, at /opt/gun/bin. The problem is that ssh can't find it.


cd /etc
ln -s environment
Tip !!
$ ssh iitrc type rsync
Warning: Remote host denied X11 forwarding.
rsync is /shared/local/bin/rsync

— /shared/…, yeah right!

Remotely invoking commands via ssh 



ssh host /bin/true

prints anything then you need to fix your dot-files.

Solution / Conclusion 


around .bash_profile & .bashrc

Trying History 

Adding the code:

will only cause "lost connection" because they are being sourced by the login service.

openssh: auto start under linux 

>I can't make openssh 2.1.1p3 auto started when my machine starts, by
>putting it under rc?.d. The boot log says:

Check to see if you have an rc.local anywhere on the system. Add the line


to it, if it's not already in there.

If there's no rc.local, go into /etc/init.d (or maybe /etc/rc.d/init.d) and either add that line to an existing script, or use an existing script as a template to create an sshd script.

Mike Tatroe

openssh: auto start under linux 


exit 0

to the top of the rc.local, 'cause the rest is trying to rewrite /etc/issue everytime when it reboot.

cmd:ssh (Secure Shell) 

SSH2 Version: 2.3.0 

latest non-commercial Unix SSH2 version


What has changed since SSH1?


Master site for SSH
Getting started with SSH A good overview of this procedure, along with troubleshooting info.
links2go SSH Collection

Build, Test run & Installation 

  1. uninstall old version 1st!

    root@sunny:/export/pub/installs/ssh-1.2.27# make uninstall
  2. build

  3. Install

    make -n install | tee ../logs/$pkg.log.0
    make install | tee ../logs/$pkg.log.1

This should set everything up and create the host key.

The old files are moved to *.old files. If you don't want them around, goto apps/ssh and run

# cd apps/ssh
# make clean-up-old

Configuration & Twisting 

$ dir /etc/ssh2/ /etc/ssh2/hostkey
-rw-------   1 root     root          828 Sep 28 00:31 /etc/ssh2/hostkey
-rw-r--r--   1 root     root          697 Sep 28 00:31 /etc/ssh2/

— Public and private hostkeys for sshd2. Created by "make install".


Also, a user has to set up her/his ~/.shosts (which only SSH uses) or ~/.rhosts file (insecure, as it is also used by the r*-commands). If the username is the same in both hosts, it is adequate to put the public hostkey to /etc/ssh2/knownhosts and add the host's name to /etc/shosts.equiv (or /etc/hosts.equiv).


This file is used during .rhosts authentication. In its simplest form, this file contains host names, one per line. Users on those hosts are permitted to log in without a password, provided that they have the same user name on both machines.


buggy document 

The document for Official SSH is way tooooo buggy.

For host based authentication:

The README file says ~/.ssh2/knownhosts/

The man page says ~/.ssh2/

But I found out the program actually looks for ~/.ssh2/hostkeys/ e.g.: ~/.ssh2/hostkeys/

What's more no detail explanation about how to setup ~/.rhosts!

buggy implementation 

Why does SSH 2.3 have problems interoperating with OpenSSH 2.1.1?

SSH 2.3 and earlier versions contain a flaw in their HMAC implementation. Their code was not supplying the full data block output from the digest, and instead always provided 128 bits. For longer digests, this caused SSH 2.3 to not interoperate with OpenSSH.

documented on: Aug 25 2000

Version: v1.2.27 

Build, Test run & Installation 


For most machines and configurations, the above is all you need.

will install to /usr/local


Might need to "make distclean" first

make: *** No rule to make target `distclean'.  Stop.

One should be careful not to use "xin" or "xstart" or other similar scripts that explicitly set DISPLAY to start X sessions in a remote machine, because the connection will then not go over the secure channel. The recommended way to start a shell in a remote machine is

xterm -e ssh host &

and the recommended way to execute an X11 application in a remote machine is

ssh -n host emacs &

If you need to type a password/passphrase for the remote machine,

ssh -f host emacs

may be useful.