Home |
- passwordless ssh -running X applications with ssh on a
server
|
Back |
I wanted to set up something on our modest home network that would allow a user on a client to initiate a dial up session with our ISP. At the least this would require being able to to run Slackware's/usr/sbin/ppp-go and /usr/bin/ppp-off on the server from the client. Ssh seemed the way to go but, since I had a nine year old on a client, I wasn't really interested in something that required opening a shell, entering a command addressed to the server and then entering a password when prompted.
I finally I settled on using passwordless ssh after finding a couple articles on it while googling around one evening. Passwordless ssh might not be suitable if you think there is someone out there in cyberland with a burning desire to hack into your network, but for someone like me the risk was extremely minimal and it was a convenient way to solve my problem.
However, passwordless ssh only eliminated the need for entering a password and not the need to run the command from a shell. As it turned out, I could also run any X application installed on my server from my client with ssh and have the application display on the client This allowed me to create a script using gxmessage so that a user on a client could click on an icon and get a message box saying whether or not the server was online and offering the option to connect or disconnect.
The first thing you'll need to do is make sure you have ssh running on both clients and server. You can do this many ways but I'll use grep
rick@rick:~$ ps -A | grep sshd
107 ? 00:00:00 sshd
rick@rick:~$
|
Ssh is up and running on a box called "rick" which
happens to be the server on our home LAN.
If sshd (the ssh daemon) wasn't running the first thing I would do in Slackware is check and see if /etc/rc.d/rc.sshd is executable. In Slackware you will find that most services are started at boot via a script in /etc/rc.d. Slackware comes with with start/stop scripts ready to run for standard services like CUPS and ssh,but if you haven't made them executable during setup you will have to do it later on as root.
Next Check and see that user names and user id's and passwords are the same on both the client and the server. If not they will have to be changed. You can edit the file/etc/password to to change user names and id's into line. For example, in the section from my /etc/password file below the user "leila" has an id number of 1001 on the server. If she was set up as a user with an id number or 1002 on the client she uses she would not be able to log into the server using passwordless ssh.
nobody:x:99:99:nobody:/:
rick:x:1000:0:Rick Miles:/home/rick:/bin/bash
leila:x:1001:0:Leila Miles:/home/leila:/bin/bash
avellin:x:1002:0:Avellin Miles:/home/avellin:/bin/bash
|
You will need to have xauth installed on your clients and you will have to have X11 Forwarding set up on your server
To set up X11 Forwarding on the server edit /etc/ssh/sshd.config so that you have an uncommented line that reads as follows:
X11Forwarding yes
|
Note that there is both an /etc/ssh/ssh.config and an /etc/ssh/sshd.config. Ssh.config is for client configuration and sshd.config id for server configuration. If your running Slackware, the config files are complete templates and all you have to do is uncomment the appropriate line.
Creating public and private keys is a fairly simple procedure, but remember that the keys for each user must be created while logged in as that user on each client used by that user.
In the example below I will be setting up the user "rick" on a client with the hostname "leila". The server's host name is "rick". The server's IP is 192.168.1.1 and "rick" has an account on both machines.
First generate a public key
1.rick@leila:~$ ssh-keygen -t dsa
2.Generating public/private dsa key pair.
3.Enter file in which to save the key (/home/rick/.ssh/id_dsa):
4.Created directory '/home/rick/.ssh'.
5.Enter passphrase (empty for no passphrase):
6.Enter same passphrase again:
7.Your identification has been saved in /home/rick/.ssh/id_dsa.
8.Your public key has been saved in /home/rick/.ssh/id_dsa.pub.
|
Enter the command "ssh-keygen -t dsa" (line 1.).
When prompted on file where key is saved just hit "Enter" (line 3.).
When prompted for a passphrase just hit "Enter" (line 5.).
When prompted to confirm passphrase hit "Enter" a second time (line 6.).
Once you have created your public key you can copy it to the server.
1.rick@leila:~$ ssh-copy-id -i ~/.ssh/id_dsa.pub rick@192.168.1.1
2.26
3.The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
4.RSA key fingerprint is 8a:8a:53:b3:1c:d6:72:b5:e9:e8:7d:c7:81:8c:6f:0b.
5.Are you sure you want to continue connecting (yes/no)? yes
6.Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts.
7.rick@192.168.1.1's password:
8.Now try logging into the machine, with "ssh 'rick@192.168.1.1'", and check in:
|
Enter the command "ssh-copy-id -i [location of key] [username@server IP] (line 1.).
You may get some complaints due to defaults but when prompted to continue enter "yes" (line 5.).
You will next be prompted to enter the user's password (line 7.). Remember the user password must be the same on the the client and server
Finally you will be asked to see if you can log in via ssh on the server (line 8.).
If everything is correct you should now be able to log in on the server in a your user account without having to enter a password.
rick@leila:~$ ssh rick@192.168.1.1
Last login: Sat Feb 14 11:21:54 2004
Linux 2.4.22.
If the Nazi's had television with satellite technology, we'd all be
goose-stepping. Americans are just as suggestible.
-- Frank Zappa
rick@rick:~$ su
|
In the example above I started out as rick on leila (the client), but that I end up in a shell as rick on rick (the server). In this example fortune is running on the server and I am presented with a quote from Frank Zappa.
Note that I now have the same user privileges as I would have if I had actually sat down in front of the server and logged in as rick. I can run the usual command line aps and, if set up as discussed above, I can also run X applications on the server with display on the client's monitor.
Coming back to my reason for setting up passwordless ssh, I am now ready to set up so that I can run my little logon script from the clients using the following command:
ssh -X rick@192.168.1.1 /usr/local/bin/gx-logon
|
I actually have this listed as the command to execute when I click an icon on the client desktop but it could also be run in a shell.
The flag "-X" is required because I'm going to run an X application.
The address "rick@192.168.1.1" logs me into the server as rick with rick's user privileges.
The command "/usr/local/bin/gx-logon" will start my gx-logon script. Note that need to enter the complete path when using ssh regardless of what your normal PATH's would be if you were actually logged in on the server.
The result of running the above command is that the gx-logon script will be run on the server and a pop up message windows is displayed in the client desk top. Heres a screen shot of the gx-logon and message that is displayed if the server is off line.
|
|
The following screenshot is gx-logon displaying the output of /etc/ppp/ip-up which is run on the server after a connection is established via /usr/sbin/ppp-go.
|
|
I could not find the original reference I used but you can find a very good piece about running X aps on servers with displays on clients titled Remote Gkrellm Over SSH Mini How-To by Dan "OverrideX" McCombs here.
If you want to know a little more about RSA and DSA pasword encryption you can find a good article titled Common threads: OpenSSH key management, Understanding RSA/DSA authentication by Daniel Robbins here.
