sshd and ftpd

Preston Kutzner shizzlecash at
Sat Apr 25 17:03:23 UTC 2009

On Apr 25, 2009, at 6:48 AM, Karl F. Larsen wrote:

> Total amazment! I used the Gnome Places and it worked just fine! I  
> even
> gave my setup a name so I can call it again and again. The name  
> shows up
> when I click Places!
> I need to give it the password for the other computer but that is all.
> Display what you want and and slide it over on to your computer :-)
> Thank YOU!!!!!

If you don't want to have to enter a password every time you connect,  
you can use shared SSH keys to login to each box.  The nice thing  
about this method is that you don't have to specify a password for the  
ssh keys, so when you log in it doesn't ask for one.  It can also be  
more secure, as you could eventually turn off challenge-response  
logins altogether (login with username / password).

To create a key-pair to use with SSH perform the following steps:

On the client machine:

$ ssh-keygen

It will prompt you for a location to create the keyfiles as well as  
for a password, if you want to use one with the keyfiles.  For this  
exercise, we want to be able to connect to our remote host without  
having to provide a password, so just hit 'Enter/Return' when it asks  
for a password.  Also, by default, ssh-keygen will create RSA keys, so  
I will refer to the filenames generated by ssh-keygen's defaults YMMV,  
of course, especially if you change the location and type of keys  

If you used the defaults supplied by the ssh-keygen command, your new  
key-pair will have been created in ~/.ssh/ as id_rsa and

The next step is to get the public key over to your target host.  I  
usually use scp for this task, but you could conceivably use "Places"  
in Gnome for this task as well, assuming you've allowed it to show  
hidden files and folders.  For the scp command, here's what I would  
use, obviously modifying it for my specific situation:

$ scp ~/.ssh/ user at

Note the colon after the host name.  You must have that there,  
otherwise it will copy your ssh public key to a file named 'user at 
' on the local machine, which isn't what we want.  You will be  
prompted for the remote user's password, and after it has been  
entered, the file will be copied to the remote machine.  Now, we have  
to move our work to the remote machine.

On the remote machine:

Log-in to the target user on the remote machine via ssh.

Once logged in, check to see if .ssh already exists in the user's home  
directory.  You can do this by typing:

$ ls -d .ssh/

If you get a listing, then it's already there, if not, you'll have to  
create it using the following commands:

$ mkdir ~/.ssh
$ chmod 700 ~/.ssh

Once the directory is created, we need to export the contents of the file you copied to this client into another file.  I  
usually use the following command:

$ cat >> ~/.ssh/authorized_keys

After which, I usually delete the  I would verify that  
everything worked by trying to ssh into the remote host from the  
client host again.  I usually open a separate shell window for this.   
If you've done everything correctly, you should not be prompted for a  
password when you log in, it should just drop you to a prompt on the  
remote host.

You can do the entirety of the above in 2 commands if you're feeling  
up to it, omitting the need to interactively log in to the remote host  
using the following:

$ scp ~/.ssh/ user at
$ ssh user at "([ ! -d ~/.ssh ] && mkdir ~/.ssh && chmod 700  
~/.ssh && cat >> ~/.ssh/authorized_keys && rm  
|| cat >> ~/.ssh/authorized_keys"

Lather, Rinse, Repeat for each remote host you wish to access using  
your ssh key.  The second command above takes advantage of ssh's  
ability to run commands on the target host without an interactive  
prompt.  Note that the second command above is ONE LINE, if it shows  
up as multiple lines in your mail reader, it has been word-wrapped.   
It essentially logs in, runs the command(s) and logs out immediately  
after the commands have completed.  I'll break apart the command for  
posterity's sake on this list:

$ ssh user at 	# This is your normal login semantic you use  
with ssh.

The portion after the login part is the command(s) you wish to run on  
the target host, enclosed in double-quotes.  In this case it's one  
long conditional command.  The double ampersands "&&" tell bash to  
only move on to the next command if the previous command completes  
successfully, the double pipes "||" tell the shell to only execute the  
command(s) after the pipes if the first command(s) fail or evaluate to  
false.  So basically I have a string of 5 commands where each  
subsequent command only gets executed on the successful completion of  
the previous command followed by a command that gets executed only in  
the situation that the first command(s) didn't execute.  Basically,  
what I'm doing is checking to see if the ~/.ssh folder exsists, if it  
doesn't, I create it, set the correct permissions on it and then copy  
the contents of the file to a file named authorized_keys in  
the .ssh directory just created.  If the directory already exists, I  
just append the contents of the file to a file named  
authorized_keys in the .ssh directory.  The use of the ">>" after the  
cat statement makes sure that if the authorized_keys file doesn't  
exist, it gets created.  If it does exist, the contents get appended  
to the end of the file instead of overwriting the existing file with  
the new contents, as ">" would do.

[ ! -d ~/.ssh ]		# This is a bash/ksh test to see if the ~/.ssh  
directory already exists.
			#+ It's a negative test, so it only evaluates to "true" if the  
directory *doesn't* already exist.
			#+ [ -d ~/.ssh ] would evaluate to "true" if the directory *does*  
already exist.

&& mkdir ~/.ssh		# This command creates the ~/.ssh directory in the  
event the previous statement evaluated "true".

&& chmod 700 ~/.ssh	# This command sets permissions on the ~/.ssh  
directory to rwx------ which is what sshd expects.
			#+ sshd, by default will complain about insecure permissions if  
they aren't set to 700 and will
			#+ ignore the directory.

&& cat >> ~/.ssh/authorized_keys	# This command copies the  
contents of to ~/.ssh/authorized_keys
						#+ if the previous commands have all completed successfully.

&& rm	# Removes the key file if it was successfully copied  
to ~/.ssh/authorized_keys.

|| cat >> ~/.ssh/authorized_keys	# Copies the contents of  
the key file to ~/.ssh/authorized_keys if the
						#+ previous set of commands evaluated to "false", most likely  
						#+ the .ssh directory did already exist.

You could add more checks in after the || if you wanted, such as  
checking to make sure the .ssh directory is writable, if so also  
checking if the authorized_keys file is writable as well and only  
attempting to create/append to it if they are.  But that, I leave as  
an exercise to the reader.  I realize this is a long post, but  
hopefully people will find it beneficial.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

More information about the ubuntu-users mailing list