[tarballed]

Hello everyone.
Well, I have been playing around a little with SSH and generating public and private keys. I followed the article from www.bsdhound.com in trying to further understand SSH and how to futher enhance security on my network...

I should mention, that at the moment, I am using OpenSSH 3.4, but that will be updated here soon.

My question is that I have followed the basic instructions on how to generate a key and copy it to the remote box. Now, I have been trying to figure out how to make it so the SSH connections will use the keys, but I am having no luck. It still prompts me for the password.

I was curious. Do I need to make some adjustments in any of my ssh config files? I have uncommented RSAAuthentication in /etc/ssh_config, but still no dice.

Any idea on what I may be missing?

Tarballed

[bsdjunkie]

Dont have time to write a full description right now, but can do so later.. Until then, check out this link i found... :roll:

http://www.ldeo.columbia.edu/~vschmidt/notes/sshconfig_notes.htm

[soup4you2]

About public key cryptography

Public key cryptography uses a public key to encrypt data and a private key to decrypt it. The name public key comes from the fact that you can make the encryption key public without compromising the secrecy of the data or the decryption key.


What this means is that it is safe to send your public key (i.e. the contents of the ~/.ssh/identity.pub file) in electronic mail or by other means e.g. to have a system administrator of a remote site install that key into your ~/.ssh/authorized_keys file. For anyone to actually gain access they need the corresponding private key (i.e. the decrypted contents of ~/.ssh/identity) to identify themselves.

To further protect your private key you should enter a passphrase to encrypt the key when it is stored in the filesystem. This will prevent people from using it even if they gain access to your files.

Creating your authentication key

The very first step is to use ssh-keygen to create an authentication key for yourself. In most cases the defaults for this command are what you want.

Always, always, type in a good pass-phrase when prompted for one, and it can be multiple words

Here is a sample session, your input is in bold.

[code:1:a92ed04fa1]
($:~)=> ssh-keygen -b 1024 -t rsa -f identity
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): gimme da goodz
Enter same passphrase again: gimme da goodz
Your identification has been saved in identity.
Your public key has been saved in identity.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx :xx:xx god@bsdhound.com
[/code:1:a92ed04fa1]

If you have multiple accounts you might want to create a separate key on each of them. I have separate keys for

* your office
* your private systems
* your Internet service provider (ISP) systems


Changing your pass-phrase

You can change the pass-phrase at any time by using the -p option of ssh-keygen.

[code:1:a92ed04fa1]
($:~)=> ssh-keygen -p
Enter file in which the key is (/home/god/.ssh/id_rsa): identity
Enter old passphrase: gimme da goodz
Key has comment 'identity'
Enter new passphrase (empty for no passphrase): f00lz
Enter same passphrase again: f00lz
Your identification has been saved with the new passphrase.
[/code:1:a92ed04fa1]

Authorizing access

To allow access to a system for a given identity place the public key in your ~/.ssh/authorized_keys file on that system. All keys listed in that file are allowed access.

Usually you will want to authorize access to the local system using the local key (especially in an environment where multiple systems share the same home directory e.g. using NFS). Thus a good start is to copy the public key for your default identity into the ~/.ssh/authorized_keys file.

[code:1:a92ed04fa1]
($:~)=> cd ~/.ssh
($:~/.ssh)=> cp ../identity.pub ./authorized_keys
[/code:1:a92ed04fa1]

You could now copy the ~/.ssh/authorized_keys file to other systems to allow access from the local system. One way to copy the file is to use the ftp command.

Use a text editor to add more keys to the file. If you use cut and paste to copy the key make sure each key entry is a single line in the file. The keys to add are always the public keys (from files with the .pub extension).

NOTE: To gain access to restricted systems you might need to send your public key in electronic mail to the administrator of the system. Just include the contents of the ~/.ssh/identity.pub file in the message.

Directory and file permissions

If access to the remote system is still denied you should check the permissions of the following files on it:

* the home directory itself
* the ~/.ssh directory
* the ~/.ssh/authorized_keys file

The permissions should allow writing only by you (the owner). This example shows the most relaxed permissions you could use.

[code:1:a92ed04fa1]
($:~)=> cd
($:~)=> ls -ld . .ssh .ssh/authorized_keys
drwx-----x 9 god god 1.0k Jan 29 09:38 ./
drwx------ 2 god god 512 Jan 29 10:06 .ssh/
-rw-r--r-- 1 god god 951 Jan 29 10:06 .ssh/authorized_keys
[/code:1:a92ed04fa1]

To make the remote system allow access you must change the permissions to disallow writing by others than the owner.

[code:1:a92ed04fa1]
($:~)=> cd
($:~)=> chmod go-w . .ssh .ssh/authorized_keys (or chmod 600)
[/code:1:a92ed04fa1]

Remember to do this on all the systems you want to have access to.
Logging into remote systems

To establish an interactive connection to a remote system you would use either the slogin or the ssh command. The only parameter is the name of the remote system. The pass-phrase is not echoed back to you when you type it.

[code:1:a92ed04fa1]
($:~/.ssh)=> slogin ariel
Enter passphrase for key '/home/god/.ssh/identity': foolz
Warning: your password expires on Fri Feb 14 21:10:07 2003
[/code:1:a92ed04fa1]

You can avoid the pass-phrase prompts by keeping the authentication keys in memory. You only need to type the pass-phrase when you add a key into memory.


Keeping authentication keys in memory

If you frequently open connections to remote systems you can run your session under the ssh-agent. The agent will provide decrypted authentication keys to all the commands when new connections are created.

When you start ssh-agent you need to provide it a command to spawn. This is usually either your shell or a command to start a windowing environment. When you exit the command all keys will be removed from memory.

[code:1:a92ed04fa1]
($:~/.ssh)=> ssh-agent $SHELL
bash-2.05b$
[/code:1:a92ed04fa1]

You will now need to add keys into memory to have them available for other commands

Running X on a local display

If you have workstation where you start the X window system after logging in you can have the whole windowing environment benefit from the keys in memory. The X window system is normally started with startx and the initial clients are in your ~/.xinitrc file.

[code:1:a92ed04fa1]
($:~/.ssh)=>ssh-agent startx &
[/code:1:a92ed04fa1]

If your workstation has virtual consoles it is good to put the X window system in the background so the current virtual console can still be used for more commands if necessary. It won't hurt to background the command even without virtual consoles.

NOTE: Your system might have a non-standard way of starting the X window system. Replace startx with the appropriate command if necessary. Please ask your system administrator for the exact command to use.

Running X with an xdm session

If you use an X-terminal or your workstation is running xdm you need to arrange for the clients to run under ssh-agent. The easiest way (which is conveniently compatible with the method used without xdm) is to put all initial clients into the ~/.xinitrc file which in turn is called from the ~/.xsession file.

An example ~/.xsession file is below. It runs ssh-agent only if you have a ~/.ssh directory.

[code:1:a92ed04fa1]
#!/bin/sh
if [ -d $HOME/.ssh ]
then EXEC="exec ssh-agent"
else EXEC="exec"
fi
if [ -x $HOME/.xinitrc ]
then $EXEC $HOME/.xinitrc
else $EXEC xterm -geometry 80x24+0-60 -ls
fi
[/code:1:a92ed04fa1]

Make sure the files are executable. The following command will change the permissions suitably.

[code:1:a92ed04fa1]
($:~/.ssh)=> chmod a+x ~/.xinitrc ~/.xsession
[/code:1:a92ed04fa1]

NOTE: If you are using an X-terminal keep in mind that your session is most likely not secure. Usually anything you type can be captured on the local area network you are connected to.

Managing keys in memory

Before your connections can be authenticated without prompts for a pass-phrase you have to use ssh-add to add the necessary keys to memory. To add the default key on the current system to memory no options are needed. The pass-phrase is prompted for to decrypt the key. It is not echoed back as you type it.

[code:1:a92ed04fa1]
($:~)=> ssh-add
Need passphrase for /home/god/.ssh/identity (god@bsdhound.com).
Enter passphrase: f00lz
Identity added: /home/god/.ssh/identity (god@bsdhound.com)
[/code:1:a92ed04fa1]

You can specify the file that contains the key if you have other identities than the default. You must use the private key file (the one that does not have the .pub extension).

The -d option will have the key deleted from memory. There is no ssh-delete command.

[code:1:a92ed04fa1]
($:~)=> ssh-add -d ~/.ssh/isp
[/code:1:a92ed04fa1]

To list all keys currently in memory use the -l

[code:1:a92ed04fa1]
($:~)=>ssh-add -l
1024 37 [lots of numbers] god@bsdhound.com
1024 35 [lots of numbers] god@someplace.org
[/code:1:a92ed04fa1]

You can delete all keys from memory at once with the -D option.

[code:1:a92ed04fa1]
($:~)=> ssh-add -D
[/code:1:a92ed04fa1]

This is useful if you have added keys into memory on remote systems and don't want to reconnect just to delete the keys.

Running commands on remote systems

The ssh command can also be used to run commands on remote systems without logging in. The output of the command is displayed and control returns to the local system. Here is an example which will display all the users logged in on the remote system.

[code:1:a92ed04fa1]
($:~)=> ssh bsdhound who
christos ttyp8 Oct 17 20:42 (milou)
($:~)=>
[/code:1:a92ed04fa1]

If you are using the X Window System you can use this capability to start a terminal window to start an interactive session on the remote system.

[code:1:a92ed04fa1]
($:~)=> ssh -n bsdhound xterm &
[1] 15866
($:~)=>
[/code:1:a92ed04fa1]

Use the -n to prevent the remote system from trying to read from the terminal starting the xterm and put the process in the background. A new window from the remote system should appear shortly on your display.