This site is now 100% read-only, and retired.

A couple of tricks with the secure shell

Posted by prhlava on Thu 7 Sep 2006 at 15:08

One can do a lot more with ssh than use it for remote terminal session. Here we'll show how to copy files using ssh, use ssh as part of a pipe, vnc or samba forwarding via ssh and mounting filesystems using ssh (fuse + sshfs)

(Several of these subjects have been covered upon this site before.)


Sebastian Broekhoven
pointed to obvious method of file copying over ssh - the scp command.
Hardik Dalwadi
showed the simple method of taking advantage of log-in without password (section 6.1).

the version with pictures

1 Transferring files over ssh

1.1 using scp

The scp can be used to copy file(s) between two remote ssh server machines and copy files from local to remote or from remote to local.

It has options to (for more see the man page):

  • turn on ssh compression (-C)
  • preserve mode, access time and modification time (-p)
  • do recursive copy (-r)
To copy content of local directory "mydir" to user's home directory on a remote machine do: # scp -r mydir user@remote-box:

To copy in the opposite direction do

# scp -r user@remote-box:mydir .

Symlinks to directories are followed (not copied as symlinks) - in the result of the copy, symlink to directory will be a directory (named after the symlink's name).

1.2 Transferring files via pipe

The ssh works well as a part of the pipe. This can be used to transfer files directly over ssh. In combination with tar, multiple files can be transferred easily.

1.2.1 Transferring single file

# cat myfile | ssh user@server "cat > myfile"

This transfers a local file "myfile" to the server. The location of the resulting file is the home directory of the "user".

The first "cat" command simply outputs the contents of "myfile" to stdout, the stdout gets piped to the local part of the ssh session and transferred to stdin of the shell on the server. The second "cat" command (runs on the server) outputs the transferred stdin to stdout. The stdout gets redirected to the "myfile" file on the server (one can choose a different name for the resulting file as required). After the transfer is complete, the ssh exits and user is left in the local terminal window.

If different location is required for the resulting file on the server, two options are available: specifying a full path for the file or changing to the desired directory before running the "cat" command (i.e. running two commands in sequence on the server):

# cat myfile | ssh user@server "cat > ~/backups/myfile"


# cat myfile | ssh user@server "cd ~/backups; cat > myfile"

To transfer in the opposite direction (from remote to local), the pipe is reversed:

# ssh user@server "cat myfile" > myfile

or from a different location:

# ssh user@server "cd ~/backups; cat myfile" > myfile

1.2.2 Transferring multiple files and using archives

The simple option is to create an archive file (e.g. using tar) of files required for transfer, transfer the archive as single file and then unarchive the transferred archive on the server. But tar has an ability to create archive to stdout and read archive from stdin. This can be used in combination with ssh to transfer multiple files.

Transferring a directory (from local to remote):

# tar -c -f - mydir | ssh user@server "cat | tar -x -f -"

The first "tar" command creates archive to stdout using the contents of "mydir" directory. The stdout gets piped to ssh. On the server, the "cat" command copies stdin to stdout and the stdout gets piped to "tar". The "tar" reads the archive from stdin and extracts the content of the archive to user's home directory.

To extract the archive on the server to a different location, change the directory before executing "cat | tar" pipe:

# tar -c -f - mydir | ssh user@server "cd ~/backups; cat | tar -x -f -"

It is not a law to unarchive on the remote side. When creating backups of local files, one can keep them in tar archive on the server:

# tar -c -f - mydir | ssh user@server "cd ~/backups; cat > mydir.tar"

To transfer the files the other direction (from remote to local), the pipe is again reversed:

# ssh user@server "tar -c -f - mydir" | tar -x -f -

Again, one can keep the local archive of remote files instead of unarchiving:

# ssh user@server "tar -c -f - mydir" > mydir.tar

It is possible to create compressed archives directly by tar.

To transfer files in "mydir" directory, while compressing the archive (= less network traffic):

# tar -cz -f - mydir | ssh user@server "cat | tar -xz -f -"

To transfer files in "mydir" directory to a remote compressed archive:

# tar -cz -f - mydir | ssh user@server "cat > mydir.tar.gz"

2 Tunneling SAMBA over ssh

The ssh has an ability to forward TCP ports. It can make a remote port appear on a local network interface (or vice versa). Once this forwarding (or tunnel) is set up a program can connect to the local port and use the remote service as if it was local.

If SAMBA and ssh servers run on the same machine, it is possible to tunnel SAMBA over ssh. This is done in two steps: setting up the tunnel and then mounting the SAMBA share over the tunnel.

2.1 Setting up the tunnel

# ssh -L 9999:localhost:139 user@server

The above command forwards remote port 139 (the SAMBA service) on the remote "localhost" network interface to local port 9999 on the local "localhost" network interface (the local TCP ports are always open on the "localhost" network interface by ssh).

The ssh allows forwarding of local privileged TCP ports (anything below number 1025) only when run as the superuser (root). The local port 9999 (above 1024) is used to allow a non-superuser to set up the the tunnel. It is a good idea to make sure that no local service is listening on forwarded local port (localhost:9999 in this case) before setting up the tunnel. Any unused and unprivileged port on "localhost" network interface can be used instead of port 9999.

2.2 The tunnel is up, how do I mount?

One problem is that the SAMBA name resolution works over UDP and the ssh cannot forward that, The trick is to tell the "smbmount" command to connect to the specific network interface and TCP port directly, without using SAMBA name resolution (see "man smbmount" for more information).

To mount over the ssh tunnel, run in a new shell window (replacing [mount-point] and [username] with relevant values):

# smbmount //localhost/share [mount-point] -o username=[username],ip=localhost,port=9999

The //localhost would be normally a NET-BIOS name of the SAMBA server, but in this case the option "ip=" overrides it (no name resolution is used), the "smbmount" connects directly to local "localhost" network interface on port 9999.

It is a good idea to unmount the local SAMBA mount point ("smbumount" command) before closing the ssh session running the tunnel.

3 Jumping multiple hops with ssh

To connect from workstation1 to workstation2 using the server as a proxy:

# ssh -t user@server "ssh user@workstation2"

The command will ask for the password twice, the first time for server and the second time for workstation2. The X window forwarding also works given the correct configuration of all nodes in the chain.

4 Tunneling VNC over ssh

This is not much different than tunneling samba. The VNC usually uses TCP port 5900 and this can be forwarded. This method also works if multiple "hops" are in place. The example setup will allow user to connect to the existing X11 session on linux desktop from a linux VNC viewer over ssh.

  1. install x11vnc server on the linux box
  2. create .x11vncrc in the user's home directory (the example allows connecting multiple times and only uses localhost interface on the linux machine). Example content of .x11vncrc file (replace [my-password] with actual password later used in VNC client connection):



    -password [my-password]

  3. install TightVNC under windows
  4. install copssh under windows (putty should work as well)
  5. start a ssh tunnel from windows:

    # ssh -L 5900:localhost:5900 [user]@[linux-box]

  6. start the ThightVNC viewer (on the windows box) and ask it to connect to the localhost, port 5900
  7. supply the password (configured in .x11vncrc on the linux box)
Note, that if there is no direct ssh connection possible to the linux box, but there is a way to ssh to a server and then to the linux-box, one can carry the tunnel forward, e.g.: on the windows box: # ssh -L 5900:localhost:5900 [user]@[server] then, on the [server] machine: # ssh -L 5900:localhost:5900 [user]@[linux-box] This will create 2 tunnels: one between the windows and the server, second between the server and the linux-box - effectively having port 5900 forwarded from the linux-box to the windows box where server acts as a packet forwarder... After this, one uses the TightVNC viewer as previously (connecting to the localhost, port 5900, on the windows box).

5 sshfs + fuse = a way to mount over ssh session

There is a way to make mount of remote file system location over ssh. The sshfs is a file system built on top of ssh protocol, it uses fuse (support for file systems in user space) to function.

How to make this work under debian sarge:

  1. change /etc/apt/sources.list to point to
  2. get the libfuse-dev and fuse-utils from backports
  3. get the source for sshfs from
  4. build the sshfs from source
  5. install the sshfs
  6. enable fuse support in the kernel ("files systems" -> "file system in user space support")
  7. to mount the remote location over ssh:
    # sshfs hostname:/path [mount-point]
  8. to unmount the file system:
    # fusermount -u [mount-point]
The fusermount command needs full path to the mount point when unmounting.

6 Setting up ssh authentication using keys

This way, ssh will not ask for the password - handy for doing periodic automated backups (no need to store password in a script).

On the client (logged in as user which will use the key):

  1. # ssh-keygen -t dsa
If the pass-phrase is left empty, the ssh will not ask for anything on log-in. The above command will create 2 files in ~/.ssh directory: id_dsa (the private key) and the (the public key).

Transfer the to the user's ~/.ssh directory on the server, then on the server (in the user's ~/.ssh directory):

  1. # chmod 0600
  2. # cat > authorized_keys
The user account on the client can be different from user account on the server (e.g. user "bob" on client machine can log-in by ssh using keys to account "backup" on the server, if the and authorized_keys are in the ~/.ssh of the "backup" user on the server).

6.1 Taking advantage of log-in without password

For example, one often needs to log in to three servers "red", "green" and "blue".

  1. create a simple script called "ssh-to-server" and put it in /usr/local/sbin:

    #! /bin/bash

    ssh `basename $0` $*

  2. create symlinks with names of the servers:

    # cd /usr/local/sbin

    # chmod 0755 ssh-to-server

    # ln -s ssh-to-server red

    # ln -s ssh-to-server green

    # ln -s ssh-to-server blue

Then (if your path includes /usr/local/sbin) one can simply ssh to "red" server by typing red (or run a command uptime on the "red" server by red uptime). If the servers need to be accessed by fully qualified domain name, symlink the "ssh-to-server" script to the FQDN.



Re: A couple of tricks with the secure shell
Posted by Rail (195.225.xx.xx) on Thu 7 Sep 2006 at 15:31
In "6 Setting up ssh authentication using keys" step 2 (transfer of key) can be done by ssh-copy-id(1).

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by shavenwarthog (71.107.xx.xx) on Thu 7 Sep 2006 at 17:24
If you dont have ssh-copy-id, this one-liner works:
cat ~/.ssh/ | ssh remotehost 'mkdir .ssh ; cat >> .ssh/authorized_keys'
Then test with this command:
ssh remotehost id

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by Anonymous (147.143.xx.xx) on Thu 7 Sep 2006 at 16:02
To transfer your public key to the server, use ssh-copy-id, as this sorts out the permissions for you.

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by randallb (68.45.xx.xx) on Thu 7 Sep 2006 at 16:22
Just my 2 cents:

Rsync supports copying symlinks, unlike scp which turns symlinks into actual files on the remote end. Most versions of rsync actually use ssh by default. Rsync can also be more efficient than scp when you are just updating the remote directory. There are other advantages to using rsync instead of scp. However, for simple single-file transfers I still usually use scp.

Also, another way to simplify logging into servers is to use the ssh-argv0 command. You use it pretty much the same way as the script in part 6.1. Create a symlink that points to /usr/bin/ssh-argv0, using the remote machine's domain name as the symlink's filename:

ln -s /usr/bin/ssh-argv0 /usr/local/bin/

Then you use it just as with the script above: uptime

[ Parent ]

rsync trick
Posted by shavenwarthog (71.107.xx.xx) on Thu 7 Sep 2006 at 17:19
Seconded: 'rsync' is a fantastic tool. I now use it even for local copies, like from a flaky cdrom. The "-P" (show progress) "-a" (archive, recursive copy), and "-v" (verbose) options are very often used.

To move files, use a command like this:

rsync -av --remove-sent-files zoot.tar.gz /tmp/

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by Anonymous (66.92.xx.xx) on Thu 7 Sep 2006 at 20:19
Note that passwordless keys are a security risk: anyone who has cracked your account now has access to all the machines with non-passworded keys for you.

The nice solution is to limit the access that a non-passworded key can grant. On the target account, edit the ~/.ssh/authorized_keys file.

For example, to limit the ability of a key to only allow forwarding port 6000, without logins, preface the key in authorized_keys with


There are more of these limitations documented in the man page for sshd.

Another important resource not mentioned is the ~/.ssh/config file. This can contain default options on a general and per-host basis, and is the best way of organizing the plethora of keys that you will no doubt accumulate in the course of administering a dozen or a thousand machines.


[ Parent ]

Re: A couple of tricks with the secure shell
Posted by adumont (80.25.xx.xx) on Fri 15 Sep 2006 at 23:45
The number of keys that you have to administer should not be increasing with the number of hosts that you have, but with the number of users that can enter them.

I mean, that each user (by user I mean person, not "unix account") should have one and only one prublic/private key pair (one pair! only): Not one pair per machine! One per, not depending te number of machine that you have.

IMHO, the ideal scenario is that every user own it's own key pair, and every time he starts his desktop computer (or his workstation, his laptop...) he loads his private key into the ssh-agent (or Putty Agent or whatever). At that time he should introduce his passphrase.

On the other hand, the user (or sometime for administration sakes, the system administrator -- see further) should place the unique user's public key (every user only has 1 public key, remember?) in the ~/.ssh/authorized_keys of all the unix account of every systems he has access.

In that way, the user can log into all it's accounts by using SSH private/public key authentication and SSH Agent forwarding. He can alsojumps from one machine to another (without providing password).

At my work, we have 206 Unix boxes(HP-UX, Solaris, and a few Linux). We administer 85 public keys for 85 users and have set up access to over 2100 unix users amongs that 206 boxes. We have created a set of scripts for administrating the users into groups of users so we can easily distribute their public keys giving permission for a unix accounts on a group or user basis. For example we distribute the public keys of all the member of the ADMUNIX (Unix System admins) to the root's authorized_keys of all the managed systems.

So, if you think about it: 85 users (persons), 206 boxes; a total of 2100 unix accounts: only 85 public keys. Not that much!


Le Blog d'Alex --

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by suspended user szabek (89.132.xx.xx) on Thu 7 Sep 2006 at 21:52
Is it possible to do the "reverse" ssh?
I mean, I need to reach the host1, but I have no access on fw, but my friend sit next to host1 and he can connect to host2. And when the connection is living from host1 to host2 and I can use host1.

[ Parent ]

Browsing the web using a SSH tunnel?
Posted by Anonymous (201.7.xx.xx) on Fri 8 Sep 2006 at 02:57
Is it possible to use the web (with a browser) using a SSH tunnel?
For example, I have machine A (my) and machine B (remote). How do I setup a tunnel (if possible) so I can use machine B as a proxy, but using a SSH tunnel?

[ Parent ]

Re: Browsing the web using a SSH tunnel?
Posted by Anonymous (82.231.xx.xx) on Fri 8 Sep 2006 at 13:42
I think what you are looking for is ssh's -D option: Use e.g. "ssh -D 7070 B" to establish your connection. Configure your browser proxy settings to use localhost:7070 as a SOCKS proxy. Boom, your browsing traffic is tunnelled through B.

Beware of DNS leaks, though: SOCKS 4 doesn't support proxying DNS. Even with SOCKS 4a/5 (ssh can do 4/5, dunno about 4a), some apps still resolve names locally and only transmit the resulting IP to the proxy. E.g. firefox resolves locally by default (see the network.proxy.socks_remote_dns setting to change that). Privoxy is also mentionned here and there as a DNS leak solution throughout the web, though I never personnally tried that. Tor's website has more details about DNS leaks.

Firefox tip: There a numerous extensions designed to help with proxy management (such as SwitchProxy or FoxyProxy).

Last word: Such things are a good way to _not_ get along well with your sysadmin if local policy says you should not do it (TM). Sure, the traffic is tunnelled/encrypted, but don't think it doesn't show at all -- any decent network person will understand what you are doing in a breeze. You Have Been Warned.

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by flyboy (66.92.xx.xx) on Fri 8 Sep 2006 at 03:00
Very cool.

In the first example of section 1.2.2, is there really any reason you need the "cat" command? It seems to be doing nothing.

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by prhlava (158.143.xx.xx) on Fri 8 Sep 2006 at 10:33
[ View Weblogs ]
"cat | tar -x -f -" : if you look at the version with pictures, it is on the first picture - basically, what you pipe to ssh will end up on stdin of the remote shell, the cat will dum that to stdout and "|" will transfer that to tar...

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by Anonymous (66.93.xx.xx) on Sat 9 Sep 2006 at 02:56
Um, right, but you could leave out the "cat |" entirely, and get the same result; the tar gets fed the file on stdin regardless.

A "cat" with no arguments is always a no-op as far as I can tell.

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by Anonymous (158.36.xx.xx) on Fri 8 Sep 2006 at 13:15
i have to admit, instead of a shell script and different symlinks pointing to it (the very last point in the article), i'd much rather just setup aliases...

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by ntropia (193.205.xx.xx) on Fri 8 Sep 2006 at 14:58
Very interesting! For a coincidence I was re-arranging all my notes about ssh I collected during years, and it's very similar to this article.

Anyway, I'm not shure about the forward of a forwarded port in section 4: probably it misses the "-g" option, which allows to other hosts different than localhost to access to a forwarded port? Or maybe it's not needed here, but can be useful for other tricks.


[ Parent ]

Re: A couple of tricks with the secure shell
Posted by sgeiger (24.153.xx.xx) on Sun 10 Sep 2006 at 00:20
My thoughts exactly! This has many of my own tips. Here are a few more:


-- Serving SSH sessions: This document shows how to provide a login session that directly connects to remote hosts with SSH.



alias a31-from-outside='ssh -f -L2099: sleep 10 & (sleep 5; ssh -p 2099 sgeiger@localhost)'




- a good SSH approach to handling the issue of writing mail when you are offline...and flushing the mail queue when you go back online



alicehost$ ssh alice@bobhost "cat file" > file

falicehost$ cat file | ssh alice@bobhost "cat > file"

alicehost$ ssh alice@bobhost "ls"

alicehost$ ssh alice@bobhost "tar -cf - /etc" | tar -xf -

alicehost$ ssh alice@bobhost "tail -c 231244 file" >> file
-- Caution. I'm a little suspicious of this command. Doesn't one have to know the file size in bytes? and isn't that dependent upon the block size used by the filesystem (meaning it might be different on the other host) I need to look into that.

### Another variation on a put: transferring a partition to a remote file:
sudo dd if=/dev/hda5 | ssh sgeiger@ "cat >"

### Since /dev/hda5 is treated just as a file, you should be able to use rsync on that single file.

### Otherwise, if it is mounted, you can mount on both sides and then:
### on remote:
mount -o loop -t ext3 /mnt/foobar
### on origin machine:
## sudo rsync -avz /dev/hda5 -e ssh sgeiger@ /mnt/foobar/



Placing the following commands in the .muttrc file will create and utilize a tunnel for each connection:

From the .muttrc

set tunnel="ssh -q /usr/sbin/imapd"
set preconnect="ssh -f -q -L sleep 5
-- with the first of them, you don't even need to hvae an imap server running.





To debug sshd (server), run this as root on the server: "sshd -d -p 2222". Then use "ssh -p 2222 username@servername" on the client.



Don't forget keychain and ssh-agent for holding onto your keys. ;-) A decent alternative to ssh-copy-id



kdessh is for running remotely gui programs, I guess. I haven't used it.



This should avoid having to set up a local mail transfer agent...and avoids having to deal with the DNS issues of having a local MTA.

ssh sgeiger@ 'echo "evdo connection came up again" | mail -s "evdo up"'

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by sgeiger (24.153.xx.xx) on Sun 10 Sep 2006 at 00:27
And some more tricks.


- has a link to a very small x.exe



Use the -C flag with SSH when doing X11 Forwarding. It noticably improve performance of tunneled X apps.



Set "sshd: ALL" in /etc/hosts.allow, or preferably, if you know where you will SSH from, list only those hosts.





It almost doesn't seem right to talk about ssh without talking about autossh.

# You have to have this installed on both sides of the connation.
sudo apt-get install autossh
-- do this on both computers--that is, the local and remote ones (the remote one being a publically-accessible or other SSH server that can be reached by your local computer)

...on darwin ports: sudo port install autossh

## Do ssh dynamic port forwarding or something else like that:
autossh -M 1300 -D 5333 sgeiger@

# Verify that the ports that should be open actually are open:

sgeiger@t42:~\ 17:39:25$ sudo lsof -i :1300
ssh 3854 sgeiger 4u IPv4 8024 TCP localhost:wipld (LISTEN)
sgeiger@t42:~\ 17:39:38$ sudo lsof -i :1301
autossh 3853 sgeiger 3u IPv4 8018 TCP localhost:1301 (LISTEN)
sgeiger@t42:~\ 17:39:39$

ssh 3820 sgeiger 4u IPv4 7426 TCP localhost:wipld (LISTEN)
sgeiger@t42:~\ 17:37:21$ sudo lsof -i :1300
sgeiger@t42:~\ 17:37:42$

You might even have good luck without even using the "-M" option...

So, now I will use this command to do dynamic port forwarding for my gaim IM client to the NY server.

It seems to work pretty well. If I move between wireless networks, it will log in again to the remote server. Coupling this with an IM client that will log you in again after being disconnected, you might never have to log into your private IM server manually again.



redir is handy in some situations.



#Protocol 2,1
Protocol 2

Do this to make sure you are using the more secure of the protocols.



Adding "UseDNS no" to /etc/ssh/sshd_config worked for me. :-) (That can be a very annoying problem. You might have to wait 30 seconds before you can log in.)

Read more here:


[ Parent ]

Re: A couple of tricks with the secure shell
Posted by sgeiger (24.153.xx.xx) on Sun 10 Sep 2006 at 20:05
# Filename: /usr/bin/hussh
# Author: Shane Geiger <>
# Transfer SSH keys to a remote machine so that you don't have to
# interactively connect to the SSH server, esentially telling it to
# be quiet and simply do what you want it to do. :-) Thus the name.
# This script handles not only permissions but also ownership, will
# create the ~/.ssh directory if it doesn't exist, will generate keys for
# you if they don't exist, gives syntax usage info if it is invoked
# incorrectly, and is simple to put onto any machine.
# I know of several programs that transfer ssh keys:
# lussh - which is distributed with Lufs ( )
# ssh-copy-id - distributed with openssh nowadays, it appears
# ssh-installkeys - Eric Raymond's, which is found at
# hussh - my own, which you can find below.
# I like my script better than the others because
# 1) it doesn't have dependencies of any sort (other than /bin/sh), as does ssh-installkeys
# 2) it doesn't require you to enter the password twice (as does lussh)
# 3) you can transfer keys to an ssh server listening on a non-standard port (a failing of perhaps all the others)
# 4) it balances simplicity with functionality
# For more great SSH tricks, see
# Copyright (C) 2004 Free Software Foundation, Inc.
# There is NO warranty. You may redistribute this software under
# the terms of the GNU General Public License.
if [ $# -lt 1 ]; then
echo "Syntax:"
echo "$0 [-p 22] [<user>@]<hostname>"
exit 1
test -e $HOME/.ssh/id_rsa || ssh-keygen -q -t rsa -f $HOME/.ssh/id_rsa -C '' -N ''
test -e $HOME/.ssh/id_dsa || ssh-keygen -q -t dsa -f $HOME/.ssh/id_dsa -C '' -N ''
cat $HOME/.ssh/ | ssh $args '
mkdir -p $HOME/.ssh &&
chmod 0700 .ssh &&
cat >> $HOME/.ssh/authorized_keys &&
export IAM=`whoami` &&
chown ${IAM}:${IAM} $HOME/.ssh/authorized_keys &&
chmod 0600 $HOME/.ssh/authorized_keys &&
chmod go-w $HOME
' # don't accidentally remove this character

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by sgeiger (70.13.xx.xx) on Fri 22 Sep 2006 at 18:05
Read this article for a great introduction to OpenSSH ControlMaster, which can speed up your usage of SSH:

The above article's commands are summarized here:

for i in `seq 5`; do time ssh "hostname"; done

Host *
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

ssh -M -S ~/.ssh/

ssh -S ~/.ssh/

for i in `seq 5`; do time ssh -S ~/.ssh/ "hostname"; done

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by emeitner (216.153.xx.xx) on Fri 8 Sep 2006 at 15:16
[ View Weblogs ]
Lets not forget tunneling the X protocol over ssh:
$ ssh -X
$ xeyes # or any other X application...
Note that X can be very bandwidth greedy. Don't expect visually complex applications to be very responsive over 256k DSL.

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by prhlava (158.143.xx.xx) on Fri 8 Sep 2006 at 15:55
[ View Weblogs ]
freenx comes to the rescue when doing gui over ssh over adsl...

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by ntropia (62.11.xx.xx) on Sun 10 Sep 2006 at 17:02
...Oh, and don't forget the reverse port forwarding! ;-)

[ Parent ]

using 'red' or 'green'
Posted by johill (153.96.xx.xx) on Tue 12 Sep 2006 at 08:13
I'd suggest sticking an 'exec' into the script as such:
exec ssh `basename $0` $*
Also, if servers need to be accessed with a fully qualified name, then you just put
Host red
into ~/.ssh/config and can still use `red' as before.

[ Parent ]

Re: using 'red' or 'green'
Posted by johill (153.96.xx.xx) on Tue 12 Sep 2006 at 10:08
Just realized that ssh ships with a script to do this, called ssh-argv0.

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by wuzzeb (64.5.xx.xx) on Wed 13 Sep 2006 at 02:43
A program called gstm was just added into debian unstable this week, and it looks like a really nice tool! It allows you to set up ssh port forwarding using a gui, and also store configurations

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by dmonty (24.71.xx.xx) on Sun 24 Sep 2006 at 23:01

Section 4 talked about using ssh with vncviewer by using tunnels.

ssh -L 5900:localhost:5900
vncviewer localhost;

An easier way is to use vncviewer's built-in ssh command line option -via

vncviewer -via
* is your *nix firwall with ssh running on it.
* is a workstation behind the firewall

If you have the latest bashcompletion package installed then tab completion will work both for your gateway and for the hosts behind the gateway. The last part of the tab completion takes some time because bash will ssh into the gateway to bing the broadcast and return the available hosts.

[ Parent ]

Re: A couple of tricks with the secure shell
Posted by Anonymous (158.250.xx.xx) on Sat 7 Oct 2006 at 06:39
I have created a tunnel and let someone to connect to Internet through a port. Now, I would like to log the pages that they visited. What should I do?
Please help.

[ Parent ]