SSH Tricks

Debian Administration :: A couple of tricks with the secu...
http://www.debian-administration.org/articles/438
A couple of tricks with the secure shell

Posted by prhlava on Thu 7 Sep 2006 at 15:08
Tags: cookbook, scp, ssh, sshfs, tunneling, vnc
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"
1 of 16
13/10/06 15:30
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:
2 of 16
13/10/06 15:30
# 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

3 of 16
13/10/06 15:30
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.
4 of 16
13/10/06 15:30
How to make this work under debian sarge:

1.
2.
3.
4.
5.
6.
7.
change /etc/apt/sources.list to point to www.backports.org

get the libfuse-dev and fuse-utils from backports
get the source for sshfs from http://fuse.sourceforge.net/sshfs.html
build the sshfs from source
install the sshfs
enable fuse support in the kernel ("files systems" -> "file system in user space support")
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
5 of 16
13/10/06 15:30
# 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).

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/id_rsa.pub | ssh remotehost 'mkdir .ssh ; cat >> .ssh/authorized_keys'
Then test with this command:

ssh remotehost id

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.

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/web.server.com
Then you use it just as with the script above: web.server.com uptime
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/

6 of 16
13/10/06 15:30
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-

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!
Alex
Le Blog d'Alex -- http://adumont.serveblog.net/

Posted by szabek (89.132.xx.xx) on Thu 7 Sep 2006 at 21:52
Is it possible to do the "reverse" ssh?
7 of 16
13/10/06 15:30
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.

Posted by yarikoptic (69.115.xx.xx) on Fri 8 Sep 2006 at 04:32
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)
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?
Re: Browsing the web using a SSH tunnel?

apt-cache show secvpn

it is a VPN using ssh+pppd... quite cruel but "it works"
Re: Browsing the web using a SSH tunnel?

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.

Posted by flyboy (66.92.xx.xx) on Fri 8 Sep 2006 at 03:00
8 of 16
13/10/06 15:30
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.

Posted by prhlava [Weblogs] (158.143.xx.xx) on Fri 8 Sep 2006 at 10:33
"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...

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.

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

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

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

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.
eNjoy
9 of 16
13/10/06 15:30

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:
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 [email protected] 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 [email protected] "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.
10 of 16
13/10/06 15:30
### 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 [email protected] /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 [email protected] 'echo "evdo connection came up again" | mail -s "evdo up"
[email protected]'

And some more tricks.

----QUICKLY SET UP AN X SERVER FOR WINDOWS AND ACCESS IT WITH PUTTY:
11 of 16
13/10/06 15:30
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 [email protected]
# 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)
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: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.
12 of 16
13/10/06 15:30
----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
-----

#!/bin/sh
#
# Filename: /usr/bin/hussh
#
# Author: Shane Geiger <[email protected]>
#
# 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
#
13 of 16
13/10/06 15:30
# 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

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: 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 [email protected] "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 [email protected]
# MAKE SURE IT WORKS
ssh -S ~/.ssh/foo.bar.us [email protected]
# NOW TEST AGAIN TO SEE WHAT THE SPEED IS LIKE
for i in `seq 5`; do time ssh -S ~/.ssh/foo.bar.us [email protected] "hostname"; done

Posted by emeitner [Weblogs] (216.153.xx.xx) on Fri 8 Sep 2006 at 15:16
Lets not forget tunneling the X protocol over ssh:

$ ssh -X [email protected]
$ 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.

14 of 16
13/10/06 15:30
Posted by prhlava [Weblogs] (158.143.xx.xx) on Fri 8 Sep 2006 at 15:55
freenx comes to the rescue when doing gui over ssh over adsl...

Posted by ntropia (62.11.xx.xx) on Sun 10 Sep 2006 at 17:02
...Oh, and don't forget the reverse port forwarding! ;-)

http://www.debian-administration.org/articles/309#comment_2
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:

#!/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.
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.

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
http://gstm.sourceforge.net/

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 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
15 of 16
13/10/06 15:30
because bash will ssh into the gateway to bing the broadcast and return the available hosts.

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
Articles and comments are the property of their respective posters.

Trademarks are the property of their respective owners.
Debian is a registered trademark of Software in the Public Interest, Inc.
This site is copyright 2004, 2005, 2006 Debian Administration / Steve Kemp.
Site hosting provided by Bytemark Hosting.
Email: [email protected]
Article Feeds in Atom, RSS, & RDF formats
16 of 16
13/10/06 15:30

SSH Tricks

Uploaded by

Copyright:

Available Formats

SSH Tricks

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SSH Tricks

Uploaded by

Copyright:

Available Formats

Debian Administration :: A couple of tricks with the secu...

A couple of tricks with the secure shell

Tags: cookbook, scp, ssh, sshfs, tunneling, vnc

1 Transferring files over ssh

1.2 Transferring files via pipe

1.2.1 Transferring single file

Debian Administration :: A couple of tricks with the secu...

1.2.2 Transferring multiple files and using archives

Debian Administration :: A couple of tricks with the secu...

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

2 Tunneling SAMBA over ssh

2.1 Setting up the tunnel

2.2 The tunnel is up, how do I mount?

3 Jumping multiple hops with ssh

Debian Administration :: A couple of tricks with the secu...

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

4 Tunneling VNC over ssh

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

Debian Administration :: A couple of tricks with the secu...

How to make this work under debian sarge:

change /etc/apt/sources.list to point to www.backports.org

6 Setting up ssh authentication using keys

6.1 Taking advantage of log-in without password

Debian Administration :: A couple of tricks with the secu...

Re: A couple of tricks with the secure shell

Re: A couple of tricks with the secure shell

If you dont have ssh-copy-id, this one-liner works:

Then test with this command:

Re: A couple of tricks with the secure shell

Re: A couple of tricks with the secure shell

Re: A couple of tricks with the secure shell

Debian Administration :: A couple of tricks with the secu...

Posted by Anonymous (66.92.xx.xx) on Thu 7 Sep 2006 at 20:19

Re: A couple of tricks with the secure shell

Re: A couple of tricks with the secure shell

Is it possible to do the "reverse" ssh?

Debian Administration :: A couple of tricks with the secu...

Re: A couple of tricks with the secure shell

your friend on host1 or anything which is also behind firewall

Browsing the web using a SSH tunnel?

Is it possible to use the web (with a browser) using a SSH tunnel?

Re: Browsing the web using a SSH tunnel?

apt-cache show secvpn

Re: Browsing the web using a SSH tunnel?

Re: A couple of tricks with the secure shell

Debian Administration :: A couple of tricks with the secu...

Re: A couple of tricks with the secure shell

Re: A couple of tricks with the secure shell

Re: A couple of tricks with the secure shell

Re: A couple of tricks with the secure shell

Re: A couple of tricks with the secure shell

Re: A couple of tricks with the secure shell

Debian Administration :: A couple of tricks with the secu...

Re: A couple of tricks with the secure shell

Debian Administration :: A couple of tricks with the secu...

Re: A couple of tricks with the secure shell

And some more tricks.

Debian Administration :: A couple of tricks with the secu...