Ssh Client

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.

http://javassh.org/

documented on: 2007.07.28

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!

Davide

More like

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.

Matt G

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).

http://www.niftybits.ukfsn.org/

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

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.

http://www.gnu.org/software/screen/

Isaac Kuo

Can't launch rsync from within iitrc:

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

— /shared/…, yeah right!

if

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

wrap

around .bash_profile & .bashrc

Adding the code:

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

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

Add:

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?

http://www.heimhardt.de/htdocs/ssh.html

http://nago.cs.colorado.edu/udp/ssh-howto.html http://www.cs.colorado.edu/csops/FAQ/ssh.html#2

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

— 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

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

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

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

may be useful.