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.
documented on: 2007.07.28
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.
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!
> [quoted text muted]
#!/bin/bash # in file ~/bin/keepalive.sh while true ; do echo " " ; sleep 300 done # end script
just execute "keepalive.sh &" 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.
(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).
> [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.
> [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.
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 init_script.sh environment
init_script.sh is source in profile, for rudimental setting.
/etc/environment is for ssh env setting.
$ ssh iitrc type rsync Warning: Remote host denied X11 forwarding. rsync is /shared/local/bin/rsync
— /shared/…, yeah right!
ssh host /bin/true
prints anything then you need to fix your dot-files.
around .bash_profile & .bashrc
Adding the code:
will only cause "lost connection" because they are being sourced by the login service.
>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.
/usr/local/sbin/sshd exit 0
to the top of the rc.local, 'cause the rest is trying to rewrite /etc/issue everytime when it reboot.
latest non-commercial Unix SSH2 version
What has changed since SSH1?
SSH has been 98% rewritten.
SSH now supports other key-exchange methods besides double- encrypting RSA key exchange. The current distribution comes with Diffie-Hellman key exchange.
SSH now has support for DSA and other public key algorithms besides RSA.
The protocol is more secure and allows future integration into public key infrastructures.
The protocol complies with the upcoming 'secsh' internet standard.
SSH now supports "subsystems", platform-independent modules that implement particular functions such as file transfers.
SSH now has built-in SOCKS support.
A new feature has been added: sftp, the secure file transfer protocol.
uninstall old version 1st!
root@sunny:/export/pub/installs/ssh-1.2.27# make uninstall
pkg=ssh 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 /export/pub/installs/ssh-2.3.0/apps/ssh
# make clean-up-old
$ dir /etc/ssh2/hostkey.pub /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/hostkey.pub
— 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.
The document for Official SSH is way tooooo buggy.
For host based authentication:
The README file says ~/.ssh2/knownhosts/xxxxyyyy.pub
The man page says ~/.ssh2/hostkey_PORTNUMBER_HOSTNAME.pub
But I found out the program actually looks for ~/.ssh2/hostkeys/key_PORTNUMBER_HOSTNAME.pub e.g.: ~/.ssh2/hostkeys/key_22_sunny.pub
What's more no detail explanation about how to setup ~/.rhosts!
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
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.