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

Contributors:

Sebastian Broekhoven
pointed to obvious method of file copying over ssh - the scp command. http://www.thenetwork.nl
Hardik Dalwadi
showed the simple method of taking advantage of log-in without password (section 6.1). http://www.biostat.jhsph.edu/bit/nopassword.html

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"

or

# 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):

    -forever

    -localhost

    -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 www.backports.org
  2. get the libfuse-dev and fuse-utils from backports
  3. get the source for sshfs from http://fuse.sourceforge.net/sshfs.html
  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 id_dsa.pub (the public key).

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

  1. # chmod 0600 id_dsa.pub
  2. # cat id_dsa.pub > 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 id_dsa.pub 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.

 

 


Posted by Rail (195.225.xx.xx) on Thu 7 Sep 2006 at 15:31
[ Send Message ]
In "6 Setting up ssh authentication using keys" step 2 (transfer of key) can be done by ssh-copy-id(1).

[ Parent | Reply to this comment ]

Posted by shavenwarthog (71.107.xx.xx) on Thu 7 Sep 2006 at 17:24
[ Send Message ]
If you dont have ssh-copy-id, this one-liner works:
cat ~/.ssh/id_rsa.pub | ssh remotehost 'mkdir .ssh ; cat >> .ssh/authorized_keys'
Then test with this command:
ssh remotehost id

[ Parent | Reply to this comment ]

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 | Reply to this comment ]

Posted by randallb (68.45.xx.xx) on Thu 7 Sep 2006 at 16:22
[ Send Message ]
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/web.server.com

Then you use it just as with the script above: web.server.com uptime

[ Parent | Reply to this comment ]

Posted by shavenwarthog (71.107.xx.xx) on Thu 7 Sep 2006 at 17:19
[ Send Message ]
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 | Reply to this comment ]

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

no-pty,permitopen="localhost:6000"

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.

-dsr-

[ Parent | Reply to this comment ]

Posted by adumont (80.25.xx.xx) on Fri 15 Sep 2006 at 23:45
[ Send Message ]
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!

Alex

Le Blog d'Alex -- http://adumont.serveblog.net/

[ Parent | Reply to this comment ]

Posted by szabek (89.132.xx.xx) on Thu 7 Sep 2006 at 21:52
[ Send Message ]
Is it possible to do the "reverse" ssh?
host1--->FW--->host2
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 | Reply to this comment ]

Posted by yarikoptic (69.115.xx.xx) on Fri 8 Sep 2006 at 04:32
[ Send Message ]
your friend on host1 or anything which is also behind firewall
ssh -R 2222:host1:22 host2

Then he needs to assure that this tunnel doesn't die due to time out (work in it or set ServerAliveInterval to some number)

And you from host2 do
ssh -p 2222 localhost

(it might start complaining that fingerprint of localhost known to be different, then you would need to remove that entry in known_hosts)

[ Parent | Reply to this comment ]

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 | Reply to this comment ]

Posted by yarikoptic (69.115.xx.xx) on Fri 8 Sep 2006 at 04:45
[ Send Message ]
apt-cache show secvpn

it is a VPN using ssh+pppd... quite cruel but "it works"

[ Parent | Reply to this comment ]

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 | Reply to this comment ]

Posted by flyboy (66.92.xx.xx) on Fri 8 Sep 2006 at 03:00
[ Send Message ]
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 | Reply to this comment ]

Posted by prhlava (158.143.xx.xx) on Fri 8 Sep 2006 at 10:33
[ Send Message | 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 | Reply to this comment ]

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 | Reply to this comment ]

Posted by yarikoptic (69.115.xx.xx) on Fri 8 Sep 2006 at 04:42
[ Send Message ]
connection reuse might be especially helpful if you decide to use advanced bash completions (source /etc/bash_completion) and then complete smth like
scp boomba.laboomba.com:/home/sdfaq/skd

and press TAB to complete - then it will complete you remote path... and it will be fast due to reuse of hopefully opened before connection to the remote host

[ Parent | Reply to this comment ]

Posted by colabus (203.87.xx.xx) on Fri 8 Sep 2006 at 11:44
[ Send Message | View Weblogs ]
It might be worth mentioning "putty-tools" package. Handy for generating those key files for Windows PuTTy.

[ Parent | Reply to this comment ]

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 | Reply to this comment ]

Posted by ntropia (193.205.xx.xx) on Fri 8 Sep 2006 at 14:58
[ Send Message ]
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.

eNjoy

[ Parent | Reply to this comment ]

Posted by sgeiger (24.153.xx.xx) on Sun 10 Sep 2006 at 00:20
[ Send Message ]
My thoughts exactly! This has many of my own tips. Here are a few more:

-----

SERVING SSH SESSIONS:

http://www.etherboot.org/doc/html/sshterminal/t1.html
-- Serving SSH sessions: This document shows how to provide a login session that directly connects to remote hosts with SSH.

-----

TRICK FOR SSH-ING TO A MACHINE THAT IS BEHIND A FIREWALL WITHOUT AN OPEN PORT EXCEPT FOR THE SSH PORT OF ANOTHER MACHINE:

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

-----

HOW TO CONFIGURE OPENSSH TO ALLOW SCP BUT NOT ALLOW LOGINS:

http://www.pdrap.org/code/enable_scp_disable_ssh/

-----


OFFLINE MAIL:

http://www.miek.nl/linux/postfix.html
- 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

-----

FILE TRANSFER TRICKS WITH SSH:

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

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

# LIST
alicehost$ ssh alice@bobhost "ls"

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

# RESUME GET
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@123.55.124.127 "cat > ns1.ncee.net-deb5"

### AND THEN A WAY TO KEEP THOSE TWO IN SYNC:
### 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 ns1.ncee.net-deb5 /mnt/foobar
### on origin machine:
## sudo rsync -avz /dev/hda5 -e ssh sgeiger@123.55.124.127 /mnt/foobar/

-----

MUTT AND SSH:

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

From the .muttrc

set tunnel="ssh -q imap.server.com /usr/sbin/imapd"
set preconnect="ssh -f -q -L 1234:imap.server.com:143 imap.server.com sleep 5
-- YOU CAN USE ONE OR THE OTHER OF THESE...
-- with the first of them, you don't even need to hvae an imap server running.

-----

VPN WITH SSH & PPP:

http://www.faqs.org/docs/Linux-mini/ppp-ssh.html

-----

DEBUGGING WITH SSHD:

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.

-----

KEYCHAIN AND SSH-AGENT:

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

-----

KDESSH:

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

-----

SENDING MAIL FROM AN SSH COMMAND TO A REMOTE HOST:

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@123.55.124.128 'echo "evdo connection came up again" | mail -s "evdo up" sgeiger@ncee.net'

[ Parent | Reply to this comment ]

Posted by sgeiger (24.153.xx.xx) on Sun 10 Sep 2006 at 00:27
[ Send Message ]
And some more tricks.

-----

QUICKLY SET UP AN X SERVER FOR WINDOWS AND ACCESS IT WITH PUTTY:
http://www.linuks.mine.nu/windows/sshx.html
- has a link to a very small x.exe

-----


X11 FORWARDING NOTE:

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

-----

HOSTS.ALLOW:

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

-----

SSH REMOTE FORWARDING:

http://www.hackinglinuxexposed.com/articles/20030309.html

-----


QUICK USAGE GUIDE TO AUTOSSH:

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@202.122.140.218

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

sgeiger@t42:~\ 17:39:25$ sudo lsof -i :1300
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
ssh 3854 sgeiger 4u IPv4 8024 TCP localhost:wipld (LISTEN)
sgeiger@t42:~\ 17:39:38$ sudo lsof -i :1301
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
autossh 3853 sgeiger 3u IPv4 8018 TCP localhost:1301 (LISTEN)
sgeiger@t42:~\ 17:39:39$

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
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.

-----

PORT FORWARDING ALTERNATIVE TO SSH:

redir is handy in some situations.

-----

TO DISABLE VERSION 1 OF THE PROTOCOL:

/etc/ssh/sshd_config:
#Protocol 2,1
Protocol 2

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

-----

FIXING SLOW LOGINS:

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: http://www.openbsd.org/faq/faq8.html#RevDNS

-----

[ Parent | Reply to this comment ]

Posted by sgeiger (24.153.xx.xx) on Sun 10 Sep 2006 at 20:05
[ Send Message ]
#!/bin/sh
#
# Filename: /usr/bin/hussh
#
# Author: Shane Geiger <shane.geiger@gmail.com>
#
# 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 ( http://lufs.sourceforge.net/lufs/install.html )
# ssh-copy-id - distributed with openssh nowadays, it appears
# ssh-installkeys - Eric Raymond's, which is found at http://www.catb.org/~esr/ssh-installkeys/
# 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 http://www.debian-administration.org/articles/438
#
# 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
fi
args=$@
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/id_rsa.pub | 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 | Reply to this comment ]

Posted by sgeiger (70.13.xx.xx) on Fri 22 Sep 2006 at 18:05
[ Send Message ]
Read this article for a great introduction to OpenSSH ControlMaster, which can speed up your usage of SSH: http://www.linux.com/article.pl?sid=06/05/19/145227

-----
The above article's commands are summarized here:

# TIME THE CONNECTION. THIS WILL GIVE YOU AN IDEA OF HOW MUCH FASTER ControlMaster WILL MAKE YOUR CONNECTION
for i in `seq 5`; do time ssh sgeiger@foo.bar.us "hostname"; done

# NOW ADD THESE THREE LINES TO ~/.ssh/config
Host *
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

# NEXT SET UP THE CONNECTION THAT SUBSEQUENT ACCESSES WILL USE
ssh -M -S ~/.ssh/foo.bar.us sgeiger@foo.bar.us

# MAKE SURE IT WORKS
ssh -S ~/.ssh/foo.bar.us sgeiger@foo.bar.us

# NOW TEST AGAIN TO SEE WHAT THE SPEED IS LIKE
for i in `seq 5`; do time ssh -S ~/.ssh/foo.bar.us sgeiger@foo.bar.us "hostname"; done

[ Parent | Reply to this comment ]

Posted by emeitner (216.153.xx.xx) on Fri 8 Sep 2006 at 15:16
[ Send Message | View emeitner's Scratchpad | View Weblogs ]
Lets not forget tunneling the X protocol over ssh:
$ ssh -X username@remote.box
$ 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 | Reply to this comment ]

Posted by prhlava (158.143.xx.xx) on Fri 8 Sep 2006 at 15:55
[ Send Message | View Weblogs ]
freenx comes to the rescue when doing gui over ssh over adsl...

[ Parent | Reply to this comment ]

Posted by ntropia (62.11.xx.xx) on Sun 10 Sep 2006 at 17:02
[ Send Message ]
...Oh, and don't forget the reverse port forwarding! ;-) http://www.debian-administration.org/articles/309#comment_2

[ Parent | Reply to this comment ]

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

[ Parent | Reply to this comment ]

Posted by johill (153.96.xx.xx) on Tue 12 Sep 2006 at 10:08
[ Send Message ]
Just realized that ssh ships with a script to do this, called ssh-argv0.

[ Parent | Reply to this comment ]

Posted by wuzzeb (64.5.xx.xx) on Wed 13 Sep 2006 at 02:43
[ Send Message ]
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

http://gstm.sourceforge.net/

[ Parent | Reply to this comment ]

Posted by dmonty (24.71.xx.xx) on Sun 24 Sep 2006 at 23:01
[ Send Message ]

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 firewall.mygateway.com 192.168.5.3
where:
* firewall.mygateway.com is your *nix firwall with ssh running on it.
* 192.168.5.3 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 | Reply to this comment ]

Posted by Anonymous (158.250.xx.xx) on Sat 7 Oct 2006 at 06:39
Hi,
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.
Thanks

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

Which init system are you using in Debian?






( 1062 votes ~ 6 comments )