Mastering SSH for fun and profit

[drag]

Mastering SSH for fun a profit.


Most Unix OSes have the wondrous joy of being able to take advantage of the benefits of OpenSSH, which is the best ssh implementation available in the entire world. People generally use it as a sort of encrypted and safe version of telnet, but it goes far far beyond that. For newer Linux users the power of SSH is going to be one of the major advantages of Linux over using Windows.

Several things you can use Openssh for (when combined with other programs):
Encrypted shell access.
Passwordless encrypted shell access.
Port forwarding.
Firewall penetration.
Server automation.
Remote encrypted file system.
Encrypted pseudo-FTP.
handy host to host secure file transfer.
Ad-hoc VPN.
Remote GUI access, either individual or entire desktop.
synchronising large amounts of data in a efficient manner
And a few others.



In order to increase the ease of use, safety, and maximise the advantages of Openssh the first thing you need to do is understand the various different sorts of authentication methods that you can use with OpenSSH.

Some examples (but they are not limited to):
Shared secret passwords (the default)
Private/Public keypair.
Private/Public keypair with passphrase.
Kerberos.
Multi-factor authentication (using PAM).. (say using RADIUS combined with One-Time-passcode, like FreeAuth or OpenID)



The most interesting from a average *nix user's perspective is going to be Private/Public keypair with passphrase. Using this authentication scheme combined with ssh-agent and a GUI front end you can easily setup password-less access to all your other computers.

Personally I have my desktop recently converted to a Linux-based media center, a work laptop, a file server, and a remote VPS. All of these I access using ssh from my single laptop. From my perspective they are just a single large cluster that I store various different resources and services on. All equally accessible.


So next post will be on how to setup a keypair, ssh-agent, and what to do with it.

 

[Brazen]

This is all well and good, but how about being a little more specific, such as how you set it up to do some of those neat things (I personally have never gotten keypairs to work, or tunneling).

 

[xSauronx]

i look forward to this, i just set up SSH on my laptop and tower (along with vnc4server on the tower) for the sake of playing around with it and would love to learn more about whats possible, and how to do it

 

[kamper]

Originally posted by: Brazen
This is all well and good, but how about being a little more specific, such as how you set it up to do some of those neat things (I personally have never gotten keypairs to work,

1) Run ssh-keygen on your client machine
2) It makes ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub (or dsa, doesn't really matter)
3) Copy id_rsa.pub to the server you want to log into
4) cat id_rsa.pub >> ~/.ssh/authorized_keys (on the server)
5) ssh server (from the client)

I believe ssh automatically tries id_rsa and id_dsa if you specify no private key. Specify a specific one with the -i flag or the IdentityFile option in ~/.ssh/config (man ssh_config(5)).

If you put a passphrase on the private key, you will have to type it in when you connect, unless you are using ssh-agent.

or tunneling).

ssh -L 1234:localhost:2345 server

This means "forward port 1234 on the client to port 2345 on whatever the server thinks is localhost". Your ssh client will now start listening on your machine for connections on port 1234. When something connects, it will forward that traffic over the ssh connection to the server where sshd will try to connect to port 2345 on localhost and deliver the traffic.

Example usage:
You have a subversion server running on your server but, for security reasons, it only accepts local connections. You want to use it from your client. Run the above command, changing the ports to 3690. Now run your svn client but tell it to connect to localhost instead of the server. It tunnels through ssh and actually does talk to the server.

Example 2:
While on your university campus you have access to a certain web server but a firewall blocks access from off campus. You go home but still want to access the website. You have ssh access to another server on campus which you can log into from home:

ssh -L 8080:webserver:80 sshserver

Now point your browser to http://localhost:8080 and you'll get the website. Note that "webserver" is a name or ip address as understood by the ssh server so if it's a name, the ssh server has to be able to look it up via dns and if it's an ip (let's say a 10.x.x.x behind a nat) it has to be one that makes sense to the ssh server, not your client.

This example is kind of artificial because using ssh as a SOCKS proxy for http is way better, if it's enabled.

 

[drag]

Ya I posting this as a series. I just haven't a lot of time lately.

I'll go through all the details. Setting up keys, sharing them.

Setting up per-host configurations for your user, selecting different defaults, different encryption methods.

Also I'll go into desktop integration, tunnelling, different ways to mount remote directories and transfer files and all that happy fun stuff.

 

[drag]

How to setup public/private keypairs.


How it basicly works is a bit complicated.

Generally speaking most encryption schemes are based around shared secrets. Say I use the password 'S3CRET' to encrypt a file then I'd have to tell you that same password for you to decrypt it. This is very common thing to do.

The public/private key is a bit different. With things like RSA or DSA what happens is that one key can only decrypt what the other key encrypted. In other words it's like a box that if you lock it with one key then you can only unlock it with the other pair. You can't unlock it with the same key you locked it with. This may not make sense, but it's all based on strong math. These sort of things were not figured out until the seventies...

So this is used to prove identities. Say I want to leave messages on a website. But I leave them anonymously and anybody else can leave messages and you can't tell who actually left them. So say I generate a RSA keypair. I give one to you and a bunch of other people, then I keep the other one a secret. Any message I post then I will encrypt with my secret key. So if any message you download that can be decrypted with my public key, then this will prove to you that I am the one that posted that message.


This is sort of how it works with ssh. I send a encrypted message to prove myself.

Also this sort of thing is used in other things. For example people use both keypairs and one-way hash (a third type of encryption) to create signatures for emails. It's very effective if you can trust that only one person has the private key.



Advantages of shared keys is that (if you has password support disabled at the server) it eliminates any chance of brute forcing or password guessing and it eliminates a lot of the chances for a spoofed host. Currently passwords and ssh are going to be the most common security concerns in a modern Linux system.




Part A. How to setup a key.

1. Open up a terminal.


2. run:
username@yourhome ~$ ssh-keygen

Let it create the id_dsa files in ~/.ssh and then enter a passphrase. If you want to have no passphrase then you can leave the it blank and just hit enter twice, but this is not recommended. It's much better to have a passphrase. The reason you have a passphrase is because the passphrase will be used to encrypt your private key using 3DES. This will help protect access to your other machines in the unlikely event that a attacker has gained access to your private key in one way or another. Without the additional use of a passphrase then they will have unfettered access to all your remote machines.

You can also have multiple keys if you'd like. Just name them slightly different. Like id_rsa.1 or something like that.

If you want to know a bit more about this stuff then just take a look at ssh-keygen man file. You can choose between RSA vs DSA, or you can choose higher levels of bits.. like 128 vs 256bit encryption.

username@yourhome ~$ man ssh-keygen




Part B. How to use a key.


username@yourhome ~$ ssh remotehost
username@remotehost ~$ mkdir ~/.ssh
username@remotehost ~$ chmod 700 ~/.ssh
username@remotehost ~$ exit
username@yourhome ~$ scp ~/.ssh/id_rsa.pub remotehost:~/.ssh/authorized_keys


That's it. You should be able to go:
username@yourhome ~$ ssh remotehost

And it should ask for your passphrase for the private key and that should allow you to then access the remote host.


Also you can have multiple authorized_keys. That scp command will overwrite any already in there. So instead you can copy it over your id_rsa.pub file and go like this:
username@remotehost ~$ cat id_rsa.pub >> ~/.ssh/authorized_keys

The "cat filename1 >> filename2" will append the contents of one file to the end of another without overwriting anything. This will allow you to support multiple public keys in a single file. This is different from "cat filename1 > filename2" which will overwrite any data.






Part C. A word on security.



I've been guilty of it, but there is a serious problem in the way that a lot of Linux users use ssh.



Say you have 3 machines; Yourhome, remote1, remote2.
Lets also say that remote1 has been successfully hacked and the attacker has installed a trojan version of Openssh that records keystrokes.

If you go:

username@yourhome ~$ ssh remote1
username@remote1 ~$ ssh remote2
username@remote2 ~$ scp filename yourhome:~/
username@remote2 ~$ exit
username@remote1 ~$ exit


Now through remote1 the attacker has grabbed access to all your passwords and now can gain access to "yourhome". This works the same for any 'ssh' command or any other sort of activity on 'remote2'. Sftp, ssh, scp, ftp, etc etc. It's all the same. So all passwords or authentication should only go one way.. from your localhost to remote.. never from remote to remote or from remote to localhost.

If you did this instead:
username@yourhome ~$ ssh remote1
username@remote1 ~$ exit
username@yourhome ~$ scp remote2:~/filename ~/

Then you would of been fine. The attacker still has access to remote1, but remote2 and yourhome will still be safe.

So that is a major thing that you can do to dramatically improve your security situation. I don't remember for a fact, but I believe that both Gentoo and Debian have had servers that were hacked because a unfortunate developer had ssh'd from third a insecure machine.




Another thing you can do would be once you have your passphrase setup to go and disable password authentication and also disable root logins. This can help a lot also. If your not sure of what this stuff is or what your doing, then don't worry about it. As long as you use secure passwords then your fine.


If you are able to, then edit /etc/ssh/sshd_config file on your machines and change:
PermitRootLogin yes
ChallengeResponseAuthentication yes
UsePAM yes
PasswordAuthentication yes

to
PermitRootLogin no
ChallengeResponseAuthentication no
UsePAM no
PasswordAuthentication no


Once you make the change then you can restart your ssh server.
~$ /etc/init.d/ssh restart

Will work for debian/ubuntu-style systems.

Be carefull, these options can lock you out of your own machine! So when playing around with these options then always leave a shell to your remote system open. That way if you mess up you can undo the edit and fix it.

To undo edits what you need to do is always make a backup copy of any configuration file you make. The copy the backup over the bad file to undo any changes. This is the easies and the safest way to do it. After a while it's very difficult to remember exactly what you've changed.

 

[Brazen]

Holy freaking heck, that is a long post. I'll link to it on the bottom of the Linux FAQ, if you don't mind.

 

[drag]

Just as long as all of it makes sense. I don't know how it would read for you, so if anybody has any questions or clarifications then please post.

 

[drag]

So you now have your keypair setup with a passphrase.

So what do you do to make it more convenient?

Well the answer is ssh-agent. What ssh-agent does is that it provides a way to cache your passphrase so that you don't have to keep typing it in. For ssh this provides a primitive form of 'single sign on'. That is you type in the passphrase once and it remains cache'd by ssh-agent until you log off.


So ssh-agent is a daemon that runs when you launch your shell or start your X session. A very simple way to invoke ssh-agent would be like this:

~$ ssh-agent bash
~$ ssh-add
Enter passphrase for /home/username/.ssh/id_rsa:


ssh-add just scans for any available keypair and asks for your password automatically.

It's pretty simple, right?



Gnome Integration:


With Gnome it's easy. Ssh-agent is usually running by default. So there is very little that you need to do. So that leaves ssh-add to deal with.

With ssh-add on very modern Gnome installations is handled automatically. If you open a shell and run ssh or try to access a remote directory through nautilus or whatnot then the first thing it'll do is launch a dialog were you can type in your passphrase and it'll use ssh-agent to store it. All automatic, very easy.

If you'd prefer to type in your passphrase immediately when you log in then you can install a program like ssh-askpass-gnome. Then you can open up your gnome-session-properties, either through a menu, or by hitting alt-f2 (or a xterm) and typing in 'gnome-session-properties'. Once you get the dialog open, on very modern Gnome systems you'll see 'additional startup programs', and you can click on 'new' and add this simple command:
ssh-add < /dev/null

When you run ssh-add like that its smart enough to know that you want to run the 'ssh-askpass' command, which is that little GUI dialog. With older versions of gnome the session properties is a bit different, but the concept is the same. Shouldn't be very difficult to figure it out.




KDE Integration:

With KDE it's a bit more difficult. I am not that familiar with KDE, but as far as I know there isn't any simple dialog to launch programs like with Gnome and ssh-agent is not started up by default. The best thing I could find was some Gentoo documentation. It's not bad, Gentoo usually is pretty good on this sort of thing. So here is the link to it:
http://gentoo-wiki.com/HOWTO_ssh-agent_the_easy_way






Generic xinitrc:

Xinitrc is the file that is used to setup your X environment when you launch X from the command line with the 'startx' command. It is not unusual for Linux users to prefer to do it this way as it allows easy control and makes dealing with flaky X drivers easier.


There are a few places that X looks at when starting the environment. Your system-installed xinitrc files are usually located in some place like /etc/X11/xinit/xinitrc and there are usually a few of them depending on how much software you have installed. Most users will setup their own custom xinitrc in their home folder and it will be something like ~/.xinitrc
The contents would be something like...

#!/bin/sh

exec startfluxbox

Very simple. So you can edit it to something like:

#!/bin/sh

exec ssh-agent startfluxbox

And that will start it with ssh-agent.



Personally I like to setup all sorts of extra programs. So what I like to do is have a separate bash script that I use and is launched by .xinitrc...

~/.xinitrc

#!/bin/sh
dbus-launch ssh-agent /home/username/bin/launch.desktop

~/bin/launch.desktop

#!/bin/bash
ssh-add < /dev/null &
conky &
xcfe4-panel &
gnome-terminal &
feh --bg-center ~/background.jpg
trackerd
openbox

Or something like that. It's nice because it allows you to be extra creative. This sort of setup will give you most of the juicy/useful parts of a modern desktop, but will happily run on 128 megs or less of ram.

 

[drag]

Doing file transfers with ssh.


There are a variety of ways to do file transfers with Openssh.
* scp --- like the 'cp' command, but over ssh from host to host.
* rsync --- useful for backing up large files over slow connections
* Gnome-VFS -- integrates into the Gnome GUI
* kio-slaves -- integrates into the KDE GUI
* sshfs -- userspace file system.




SCP ----

Very simple.


to upload a file:
~$ scp filename username@remotehost:/path/to/directory/
to download a file:
~$ scp username@remotehost:/path/to/filename ./

If your familiar with working in a Unix shell then your use to using the 'tab' button to autocomplete filenames and commands. If you have a shared key with ssh-agent setup correctly then autocomplete with tab even works over remote hosts. It's very convenient.



SFTP ---


sftp is meant to emulate ftp as close as possible. It's not perfect, but it does most everything most people use ftp for. The advantages over ftp are obvious. You only have to have ssh running were as ftp is troublesome to deal with sometimes with firewalls. But the main advantage is that username and passwords are encrypted and any data transfered is encrypted. The disadvantages of sftp over ftp are less obvious, but it has to do with the difficulty of dealing with users you give shell access to using ssh.

For simple command line stuff you can launch sftp:
~$ sftp username@remotehost
Connecting to remotehost...
sftp> help

(etc etc)

Since sftp is pretty close to ftp in functionality a lot of normal graphical ftp clients support it. For example Filezilla is fairly popular and it supports sftp. This is a nice way to transfer files if your using Windows or prefer these sort of apps.



Gnome-VFS ---


If your using mostly GTK-based applications then this will allow a easy way to have graphical file transfers. The only problem is if your using KDE applications, or anything that isn't gnome/gtk then you won't be able to use it.

There are two main ways to access a remote directory over ssh using gnome..

The first way is a temporary way were you access it through typing the 'location' of the remotehost and directory. There are a few different ways to get to the 'location' dialog were you can type in remote services or local directories. A few handy ones are:
* open up any nautilus file browser window. Hit control-l
* in any nautilus window, through the menu, File --> Open Location
* hit alt-F2 to open the 'run command' window. Type in the location there. (also works with filenames and directories, they are penned directly into their default application)

The location syntax is just your standard URL... ssh://username@remotehost/directory/
If you leave the 'directory' part off it'll just open into the root directory of the remote host. If you leave the username off it'll just use your regular username.



The second way opens up a nice icon on your desktop representing the remote share. Anytime you want to access it you can just click on that icon. This is done through the "Places" menu in the gnome panel, and the launcher is labelled "Connect To Server...". Also you can find it through the nautilus window were you go File ---> "Connect to Server.."

It opens up a nice dialog were you have to select 'ssh' from a drop-down list of supported protocols and then type in the other information.




KDE Kio-slaves ---


There are two different ways to connect to a ssh server using this stuff. One is the 'fish://' and the other is the 'sftp://'. (known as kio_fish and kio_sftp.).

Both work in a similar fashion. you open up konqueror and type in "fish://username@remotehost/directory" or "sftp://username@remotehost/directory"


Again I don't use KDE much so I don't know. Expect sftp and probably fish to be in KDE4 also.







FUSE-based Sshfs ---



FUSE stands for 'Filesystem in USErspace' or something like that. Fuse is a way to expose kernel file system features to userspace programs. What this means is that you can run programs that generate filespace-like areas. Normally file systems are kernel-only... like Ext3 or XFS. This is done for a variety of reasons, but it does make writing new file systems very difficult. Kernel hacking is very difficult and anything the kernel accepts has very specific requirements when it comes to code maturity, coding style, license, copyrights, etc etc. The kernel is a multi-threaded beast. When you write file systems in userspace you don't need to worry about all that. It's FUSE is fairly safe to use and very easy to program for, relatively. For example you can use what ever programming language you'd like as long as bindings exist.. perl, python, c, c++, c# and probably even ruby.

There are fuse systems for everything. You can have wiki articles show up as files. You can use BeagleFS to have virtual folders that show search results. They have file systems that expose memory data from running programs in certain languages. They have a filesystem that you can mount over http and it'll download blocks of the fs on demand.. which you can cache on a disk or in a web proxy. All sorts of stuff, anything you can imagine.

Sshfs is one of the more popular FUSE-based file systems and it uses the sftp protocol to mount remote directories as local file systems. Because of this you can do things like seek through media files. Multi-gigabyte files are dealt with with ease. Even with the full session encryption it's fast.. faster then NFS on networks up to full duplex 100Mb/s speeds. Because Ssh is so robust you can safely use it over the Internet. It's ideal for small networks with limited users.. it requires virtually no setup were compared to Samba or NFS it can take a lot of work to do and they are not nearly as secure, and in Samba's case, nearly as fast.

Debian and Ubuntu should support fuse very easily. Most other distros also. The gotcha is that if you want a user to use fuse you need to give them permissions to access /dev/fuse and use the fusermount program as setuid root (which is a security risk).

For this reason Debian has the 'fuse' group you can add your users to to give them permissions. Other distributions probably have something similar.

So to use you'd go like this:

~$ sudo apt-get install sshfs
~$ sudo adduser username fuse
<logout>
<login>
~$ sudo modprobe fuse
#the fuse module should autoload next time if it's not already loaded
# if there is a problem check permissions
# ls -l /dev/fuse
# ls -l $(which fusermount)
~$ mkdir remote
~$ sshfs username@remotehost:/home/username/ ./remote


And that is about that.


Oh, and there are older SSHFS implementations. For example there was a earlier LUFS effort that was similar to FUSE. They had a sshfs version for that.. and there is a kernel module for shfs, but I don't know what that is about. This is specificity a FUSE-based sshfs. Other ones are less desirable.




Gnome vs KDE vs SSHFS


Gnome-vfs and Kio-slave are very convenient and they integrate very well into their respective desktops. Kio-slave also has a related FUSE file system that you can mount for non-kde applications also. But I still prefer sshfs because it mounts like any other file system and thus is much more useful and work with most any application. The only limitations are that it doesn't support any special files like named pipes.

Oh, and the other problem is that if your using a desktop search program, like Beagle or Tracker, then they are not smart enough to realise that it's not part of your local file system. So if you mount a remote share to somewhere in your home directory then you can expect that the desktop search will start indexing it. Maybe this is desirable, maybe not. If not then you'll have to configure your search engine to ignore that directory. I have a ~/mount directory specificity setup for this purpose.




PROBLEMS ....


Aside from the indexing problem I mentioned, probably the most annoying issue is when you get disconnected. This is a serious issue with SSHFS, but it affects gnome and I am supposing that KDE will have problems also.

Namely is that when you try to access a remote share like this and the other end is not responding (say you going over wireless and you've dropped the signal) then the program will hang waiting on that I/O. If you totally lost the connection to the remote machine then you'll have to take steps to recover.

With Gnome-VFS this will cause nautilus to hang. To recover you just hit ctrl-f2 and type "killall nautilus". This will kill nautilus and the gnome-session-manager will restart it automaticly.

With KDE you can probably do the same thing with konqueror, but I don't know if this is a issue.

With sshfs it's a bit more complicated. Any program trying to access that share will have to be killed. Sometimes you can use the 'fuser' command to do this.. The fuser command has nothing to do with FUSE, though, so don't get confused. It's just a coincidence. In Debian it's part of the 'psmisc' package.

This command will list all the programs accessing a directory or file:
~$ fuser /directory

This command will kill any program accessing a directory or file:
~$ fuser -k /directory

Be careful with it though. Remember that the bash shell tries to do autocomplete.. do your shell will try to access that filesystem and will hang. So be sure to avoid that 'tab' key. I think fuser was intended for lock files and such. But it's very handy.


If you have problems with that then you'll have to do a 'lazy' unmount. A lazy umount will unmount a mount, but allow any program still running to keep accessing it. A normal umount will wait for all I/O to finish before allowing you to umount stuff.

You normally umount FUSE file systems with 'fusermount -u'. To do a lazy umount you do:
~$ fusermount -u -z /directory/mountpoint

If you have root rights then a 'sudo umount -l' will probably also work. Then you can simply kill sshfs process and then this will allow you to kill all the other hanged programs. The way to avoid this is just to remember to umount everything before disconnecting from a network. You can use the 'df' command to list mounts.

 

[xSauronx]

Gnome-VFS ---

and to think i was just setting up NFS today. i couldnt find quite the right info i needed to get it working properly but eh

now i wont be needing it

interesting reading so far, thanks!

 

[drag]

Your very welcome.

Personally, learning how to take advantage of SSH lead to a huge improvement in my quality-of-life (so to say) in using my desktop.


.....

If anybody has any questions or comments or want to explain how I am wrong on a certain detail be sure to speak up. I am happy to answer any questions or concernesanybody might have on the subject.

I am frequently incorrect about a lot of stuff, keep that in mind.

 

[kamper]

Originally posted by: drag
to upload a file:
~$ scp filename username@remotehost:/path/to/directory/
to download a file:
~$ scp username@remotehost:/path/to/filename ./

Or the remote to remote variation:
~$ scp username1@remotehost1:/path1 username2@remotehost2:/path2

I'm too lazy to find out for sure, but logic tells me that the traffic must pass through the client en route from remotehost1 to remotehost2 because of authentication and other issues. Can you confirm that drag? I've been in situations where it would have been a big timesaver to scp a file straight from one server to another without the intermediate stop.

 

[drag]

Nope that won't work. Don't know exactly why, but It won't.

You could probably write a script to do that if you want.. something along the lines of:

#!/bin/bash
# 2hostcopy
scp ${1}:${3} /tmp
scp /tmp/${3} ${2}
rm /tmp/${3}

Then you can go:
2hostcopy host1 host2 /path/to/file/on/host1

But what I prefer if I am working on multiple hosts.. say I have a 'production' webserver and a 'test' webserver then I'll just mount them to their respective directories using sshfs and then copy back and forth.. Also that way I can edit and move around files directly that way using regular command line tools or midnight commander or whatever else I'd like to use.

 

[kamper]

Originally posted by: drag
Nope that won't work. Don't know exactly why, but It won't.

Well then perhaps I misread this:

Originally posted by: scp(1)
Any file name may contain a host and user specification to indicate that the file is to be copied to/from that host. Copies between two remote hosts are permitted.

Anyway, it's now up to me to try it Tomorrow at work.

 

[Nothinman]

It looks like it should work that way, I just tried it and in the ssh debug output it said "debug1: Sending command: scp -v /tmp/blah hostb:/tmp/" although authentication failed for some reason that I'm not sure about right now.

 

[drag]

What it looks like to me is that it's try to send the command to one host to copy over to the other one instead of copying the file over your machine and then to the other one.

Sort of like this:

ssh remotehost1 'scp filename remotehost2:/tmp/'


I think that if you were to setup trust relationships (password-less logins I mean) between these machines using credential-forwarding with kerberos or passphrase-less private/public keys then you could make it work properly, but you'd also be exposing yourself a lot more (security-wise).

I'll have to take a closer look at it.

 

[kamper]

Interesting. That's the reason I figured it would try to do a 2 hop copy instead of direct. I don't see a -A option for scp like there is for ssh so I'm curious to know how this could ever work.

 

[drag]

You have to use the long form for the option. The -A is just a shortcut.
It would be:

-o ForwardAgent="yes"


Although in reality the only workable way to do this would be to setup a ~/.ssh/config file. The configuration files were going to be the subject of my next 'big' post. (which sucks because I had it finished, then I discovered that when you kill X and your using gedit that gedit does not save a working file like vim does. I guess I was spoiled, but I guess also that I am going to be using vim exclusively from now on also)

I scp from remotehost to remotehost working with ForwardAgent + shared keys, btw. Read the 'man ssh_config' file for the caveots though.

 

[drag]

SSH configuration.

OpenSSH uses two main types of configuration files; One type is client side, the other is server-side.

For server-side you have really one main one to worry about and that is /etc/ssh/sshd_config. I won't go into it here because the ample documentation provided by the actual configuration file and the man file is very good. The main thing most people will worry about is stuff like disabling or enabling X11 support or tunnelling support and other features. I like to disable root logins as just a matter of policy.

My recommendation is to open up /etc/ssh/sshd_config in one window and then in another xterm run the 'man sshd_config' file. Read through the sshd_config file and if you find any terms that you have questions with you can go into the xterm and use the / button to perform searches through the file. The man file will have much better descriptions. By using the highlight text then middle click to paste technique for copy-n-paste you can paste text into the xterm as if you were typing it out yourself. The one gotcha when performing searches through man files or 'less' is that it only searches down. If you want to search for a new term you need to go back to the top so you don't miss it.

Feel free to play around with settings, but keep in mind a few things. That this is a security sensitive thing and could open up holes. If you do a bad edit and something is wrong with the file then when you restart ssh server it will simply fail rather then try to work with a botched configuration file. This could be a serious issue if your working on a remote machine. It's also good policy to keep a backup of any configuration file in original condition just in case you make some mistakes. To recover from a bad edit, just copy the backup over your edited version and restart the service.. good as new.




Client side is much more interesting, as far as this discussion goes.

The manual file for client side is 'man ssh_config'. Each time you use the ssh or ssh-related command (scp, sftp, sshfs, rsync, etc) There are many places for providing client side configuration and they are as follows, in order of priority:

1. Command line options.
There is a 'short form' and a 'long form'. The short form is the various little shortcuts like -X that you use in the ssh command, however not all ssh-related tools are consistent in the availability of these options. The 'long form' is the -o switch followed by the various options described in the ssh_config man file.

2. Local user configuration. This is located in ~/.ssh/config and is not created by default, but has the same power and options as the ssh_config file.


3. System-wide configuration. This is provided to set the defaults for all users by the admin, but it has the lowest priority. It's found at /etc/ssh/ssh_config generally.


You can set host-specific options, and wildcards and aliases are supported. How it works is that each time you use a hostname ssh will go through the potential configuration files starting from the top and working it's way to the bottom. It will stop once it finds the first match.. so you want to put the more generic entries at the bottom and specific entries at the top. Like you want to have options setup for the entire *example.com domain, but you want to have specific different options for workstation.example.com, you'd make sure that the workstation.example.com comes first.


Say you have a machine with a very long domain name and your user has a different username for that particular computer. Instead of having to type all that stuff out all the time then you can setup a configuration file to save time and fingers. And then also you have your desktop computer on your local lan, which is a trusted computer and you want to have easy access to X and with a faster, less secure encryption method and no file compression (which slows things down on very fast links). So a example would go like this:

Host work
Hostname workstation.department.at.some.educational.institution.somewhere.edu
User fredericsamsung
Ciphers aes256-cbc


Host weirdname
Ciphers arcfour
ForwardX11 yes
ForwardX11Trusted yes
Compression no

(attatched code due to whitespace restrictions)
(ARGGGHH.. Ok, that didn't work out. Imagine that the lines after 'Host' are indented through spaces)

So there are a lot of different options you can do and these files should be honoured by most anything you'd want to do over ssh.. So this should simplify things considerably.. especially since there is often no easy way to enter configuration options through things like gnome-vfs or sshfs. You can also do other advanced configurations like automaticly setting up local or remote port forwarding, which I'll go into later.

 

[kamper]

Originally posted by: drag
You have to use the long form for the option. The -A is just a shortcut.
It would be:

-o ForwardAgent="yes"

Very cool. Thanks for pointing that out.

The one gotcha when performing searches through man files or 'less' is that it only searches down. If you want to search for a new term you need to go back to the top so you don't miss it.

Well, that's what N and ? are for, but you're right, it sucks, since it doesn't wrap.

Imagine that the lines after 'Host' are indented through spaces

Technically that's not necessary as ssh splits the file up by Host lines. I usually find that a blank line or two in between sections and no indentation works just fine.

Alright, I'm done nitpicking now

 

[you2]

Originally posted by: drag



Sshfs is one of the more popular FUSE-based file systems and it uses the sftp protocol to mount remote directories as local file systems. Because of this you can do things like seek through media files. Multi-gigabyte files are dealt with with ease. Even with the full session encryption it's fast.. faster then NFS on networks up to full duplex 100Mb/s speeds. Because Ssh is so robust you can safely use it over the Internet. It's ideal for small networks with limited users.. it requires virtually no setup were compared to Samba or NFS it can take a lot of work to do and they are not nearly as secure, and in Samba's case, nearly as fast.

Debian and Ubuntu should support fuse very easily. Most other distros also. The gotcha is that if you want a user to use fuse you need to give them permissions to access /dev/fuse and use the fusermount program as setuid root (which is a security risk).

For this reason Debian has the 'fuse' group you can add your users to to give them permissions. Other distributions probably have something similar.

So to use you'd go like this:

~$ sudo apt-get install sshfs
~$ sudo adduser username fuse
<logout>
<login>
~$ sudo modprobe fuse
#the fuse module should autoload next time if it's not already loaded
# if there is a problem check permissions
# ls -l /dev/fuse
# ls -l $(which fusermount)
~$ mkdir remote
~$ sshfs username@remotehost:/home/username/ ./remote



With sshfs it's a bit more complicated. Any program trying to access that share will have to be killed. Sometimes you can use the 'fuser' command to do this.. The fuser command has nothing to do with FUSE, though, so don't get confused. It's just a coincidence. In Debian it's part of the 'psmisc' package.

This command will list all the programs accessing a directory or file:
~$ fuser /directory

This command will kill any program accessing a directory or file:
~$ fuser -k /directory



If you have root rights then a 'sudo umount -l' will probably also work. Then you can simply kill sshfs process and then this will allow you to kill all the other hanged programs. The way to avoid this is just to remember to umount everything before disconnecting from a network. You can use the 'df' command to list mounts.
---

This is the right approach - use lazy umount. Also, if you set read/write timeouts at mount time then the apps should (in most cases) die on their own when the i/o fails. For nfs you would use something like timeo = 600 (for 60 seconds).

 

[drag]

Ya. I made a bit of a mistake there.

fusermount -u
will umount a fuse mount.

fusermount -u -z
will umount with the lazy option.

I don't think I made that clear anough.

I looked and I didn't see anything for timeouts for fuse stuff though, which is unfortunate.


If you have a cluster of machines that you have to deal with a thing that you may want would be 'afuse', which is a automounter for FUSE file systems.
~> mkdir sshfs
~> afuse -o mount_template="sshfs %r:/ %m" -o unmount_template="fusermount -u -z %m" ~/sshfs/

Then if you have aliases and such all properly setup in your ~/.ssh/config it makes it even more effective.

so you can just go...

~> cd ~/sshfs/remotemachine

and it will go and mount the root directory of 'remotemachine' to that directory. Pretty neat I think.