Linux screen - quick guide

http://magazine.redhat.com/2007/09/27/a-guide-to-gnu-screen/

A guide to GNU Screen

by The editorial team

written by Steve ‘Ashcrow’ Milner and Anderson Silva

The same way tabbed browsing revolutionized the web experience, GNU Screen can do the same for your experience in the command line. GNU Screen allows you to manage several interactive shell instances within the same “window.” By using different keyboard shortcuts, you are able to shuffle through the shell instances, access any of them directly, create new ones, kill old ones, attach and detach existing ones.

Instead of opening up several terminal instances on your desktop or using those ugly GNOME/KDE-based tabs, Screen can do it better and simpler.

Not only that, with GNU Screen, you can share sessions with others and detach/attach terminal sessions. It is a great tool for people who have to share working environments between work and home.

By adding a status bar to your screen environment, you are able to name your shell instances on the fly or via a configuration file called .screenrc that can be created on the user’s home directory.

Recording the session

Recording the session

It is strongly recommended that you use the /usr/bin/script program to record a transcript of the upgrade session. Then if a problem occurs, you will have a log of what happened, and if needed, can provide exact information in a bug report. To start the recording, type:

# script -t 2>~/upgrade-wheezystep.time -a ~/upgrade-wheezystep.script

or similar. If you have to rerun the typescript (e.g. if you have to reboot the system) use different step values to indicate which step of the upgrade you are logging. Do not put the typescript file in a temporary directory such as /tmp or /var/tmp (files in those directories may be deleted during the upgrade or during any restart).

Polecenia OpenSSL

LINK

Polecenia OpenSSL

Generowanie klucza prywatnego z hasłem

Hasło będzie należało podać podczas startowania serwera.
openssl genrsa -des3 -out mojadomena.key 2048

Generowanie klucza prywatnego bez hasła

Potencjalnie niebezpieczne, ale umożliwi wystartowanie serwera bez podawania hasła.
openssl genrsa -out mojadomena.key 2048

Usunięcie hasła z klucza prywatnego

openssl rsa -in mojadomena.key -out mojadomena.bezhasla.key

Generowanie CSR

Wpisz poniższe polecenie, aby wygenerować CSR wg prywatnego klucza RSA. (w formacie PEM). Zakładamy, że plik CSR będzie nosił nazwę mojadomena.csr.
openssl req -new -key mojadomena.key -out mojadomena.csr
Przykładowa zawartość pliku CSR:
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIDCjCCAnMCAQAwdTEZMBcGA1UEAxMQaG9zdC5kb21haW4ubmFtZTEVM
BMGA1UECxMMT3JnYW5pemF0aW9uMRUwEwYDVQQKEwxPcmdhbml6YXRpb2
Vnq2AWTDw2ykyxKg6neb2vYTZRvbot7M578Vvh6P8CAwEAAaCCAVMwGgY
KKwYBBAGCNw0CAzEMFgo1LjAuMjE5NS4yMDUGCisGAQQBgjcCAQ4xJzAl
MA4GA1UdDwEB/wQEAwIE8DATBgNVHSUEDDAKBggrBgEFBQcDATCB/QYKK
IhvcNAQEFBQADgYEAg4+QHTvkP5CG+WcGnrhKiMkJnMP6QEsds40obUDS
dGtEupQz8C+4xoMd1aM68q9Ri6Va+JTeuhKHxLz9hT/KUJhNBy0sRfnx+
JkQdrKG69UanTwvLqXINh9xChw9ErIto/2kZI5kl2KYQdiOqTv6p0GEUP
Rq/MD52Zy3bOzSRF0=
-----END NEW CERTIFICATE REQUEST-----
Szczegółowe informacje na temat generowania CSR.

Weryfikacja klucza prywatnego

openssl rsa -in mojadomena.key -check

Weryfikacja pliku CSR

openssl req -noout -text -in mojadomena.csr
lub
openssl req -noout -verify -in mojadomena.csr

Weryfikacja certyfikatu SSL

openssl x509 -noout -text -in mojadomena.pem

Weryfikacja sum kontrolnych certyfikatu i klucza prywatnego

Poniższe polecenia umożliwiają porównanie sum kontrolnych certyfikatu i klucza prywatnego. Jeżeli wynik działania obu poleceń jest identyczny, oznacza to, iż klucz prywatny pasuje do certyfikatu SSL.

Sprawdzenie sumy kontrolnej klucza prywatnego:

openssl rsa -in mojadomena.key -modulus -noout | openssl md5
Przykładowy wynik działania:
ccd4ca8dc071f3a61b580b7e7427a7cf

Sprawdzenie sumy kontrolnej certyfikatu SSL:

openssl x509 -in mojadomena.pem -modulus -noout | openssl md5
Przykładowy wynik działania:
ccd4ca8dc071f3a61b580b7e7427a7cf

Weryfikacja certyfikatu i CA

Gdzie cacert.pem to plik pobrany z serwera wystawcy.
openssl verify -verbose -CAfile cacert.pem mojadomena.pem

Wygenerowanie CSR-a na podstawie istniejącego certyfikatu SSL

openssl x509 -x509toreq -in mojadomena.pem -out mojadomena.csr -signkey mojadomena.key

Konwersja klucza prywatnego z formatu PEM do DER

openssl rsa -inform PEM -in mojadomena.pem -outform DER -out mojadomena.der

Konwersja klucza prywatnego z formatu DER do PEM

openssl rsa -inform DER -in mojadomena.der -outform PEM -out mojadomena.pem

Konwersja certyfikatu i klucza prywatnego z Apache'a do zaimportowania w IIS na serwerze Windows (z formatu PEM do PKCS#12).

Poniższe polecenie utworzy kopię zapasową certyfikatu, klucza prywatnego i certyfikatów pośrednich w pliku iis.pfx w formacie PKCS#12.
openssl pkcs12 -export -inkey mojadomena.key -in mojadomena.pem -certfile intermediate.pem -out iis.pfx

Konwersja certyfikatu z formatu PEM do PKCS#7 (P7B).

Poniższe polecenie utworzy kopię zapasową certyfikatu serwera i certyfikatu pośredniego w pliku mojadomena.pfx w formacie PKCS#7.
openssl crl2pkcs7 -nocrl -certfile mojadomena.pem -out mojadomena.p7b -certfile certyfikat_posredni.cer

Konwersja certyfikatu i klucza prywatnego z IIS-a do Apache'a lub innego serwera (z formatu PKCS#12 do PEM).


Przeniesienia certyfikatu

Poniższe polecenie utworzy plik mojadomena.pem zawierający certyfikat.
openssl pkcs12 -in iis.pfx -clcerts -nokeys -out mojadomena.pem

Przeniesienia klucza prywatnego

Poniższe polecenie utworzy plik mojadomena.key z kluczem prywatnym zabezpieczonym hasłem.
openssl pkcs12 -in iis.pfx -nocerts -out mojadomena.key
Poniższe polecenie utworzy plik mojadomena.key z kluczem prywatnym bez hasła
openssl pkcs12 -in iis.pfx -nocerts -nodes -out mojadomena.key

Sprawdzenie poprawności instalacji certyfikatu SSL na serwerze

root_ca.cer - plik z certyfikatem Root CA dla właściwego certyfikatu
www.moja-domena.pl:443 - adres serwera oraz port (443 - domyślny dla połączeń HTTPS)
Wersja skrócona

openssl s_client -CAfile root_ca.cer -quiet -connect www.moja-domena.pl:443
Przykładowy wynik działania powyższego polecenia
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = "GeoTrust, Inc.", CN = RapidSSL CA
verify return:1
depth=0 serialNumber = gas3S67znrMS0G-Ak1BxcG0zb6RTNpBx, C = PL, O = www.moja-domena.pl, OU = GT985185119, OU = See www.rapidssl.com/resources/cps (c)10, OU = Domain Control Validated - RapidSSL(R), CN = www.moja-domena.pl
verify return:1

Wersja rozszerzona

openssl s_client -CAfile root_ca.cer -connect www.moja-domena.pl:443
Przykładowy wynik działania powyższego polecenia
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = "GeoTrust, Inc.", CN = RapidSSL CA
verify return:1
depth=0 serialNumber = gas3S67znrMS0G-Ak1BxcG0zb6RTNpBx, C = PL, O = www.moja-domena.pl, OU = GT985185119, OU = See www.rapidssl.com/resources/cps (c)10, OU = Domain Control Validated - RapidSSL(R), CN = www.moja-domena.pl
verify return:1
---
Certificate chain
0 s:/serialNumber=gas3T67enrMS0G-Ak1BxcG0zs6RTNpBx/C=PL/O=www-moja-domena.pl/OU=GT90180134/OU=See www.rapidssl.com/resources/cps (c)10/OU=Domain Control Validated - RapidSSL(R)/CN=www.moja-domena.pl
i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE2TCCA8GgAwIBAgICAUAwDQYJKoZIhvcNAQEFBQAwPDELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDkdlb1RydXN0LCBJbmMuMRQwEgYDVQQDEwtSYXBpZFNTTCBDQTAe
Fw0xMDEyMDgxNDQ5NDBaFw0xMTExMTQxOTA2MDZaMIHtMSkwJwYDVQQFEyBnYXMz
VDY3ZW5yTVMwRy1BazFCeGNHMHpzNlJUTnBCeDELMAkGA1UEBhMCUEwxHDAaBgNV
BAoTE3JhcGlkc3NsLmdpZ2FvbmUucGwxEzARBgNVBAsTCkdUOTAxODAxMzQxMTAv
BgNVBAsTKFNlZSB3d3cucmFwaWRzc2wuY29tL3Jlc291cmNlcy9jcHMgKGMpMTAx
LzAtBgNVBAsTJkRvbWFpbiBDb250cm9sIFZhbGlkYXRlZCAtIFJhcGlkU1NMKFIp
MRwwGgYDVQQDExNyYXBpZHNzbC5naWdhb25lLnBsMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEArLaestflJoCOIaRwYk5P4eH6wz/I3tHZcwB+fkfbPiuZ
D2TuMdMxGIsVlES/YbQ6dYmbjVFFGQOl9lcX1K4LoDfByVH2W9jH729KKZ05hLWE
6gHiAzkDEsEnxEX8eh+B0NuIHBAbgGgg2gu2D8jamf95tpd3NKnZJ5VFdhRAMwS4
Wihz06KpXadFTnk6Ra4Vo2Qkd8va+UW1aJlk3Qz1uWZonY4DN5aWtBqigCXYfW/k
urYIUnkt0IYWB8xPfl54NtRCnEpSkoAgo2JY3+zjw87Ytuo2aiwFReQwC+4ogD/O
ZiFWwf9ZYBZoTHcQW0/RDdptvUmnkuGcZtclw46CKwIDAQABo4IBMTCCAS0wHwYD
VR0jBBgwFoAUa2k9ahhCSt2PAmU5/TUkhniRFjAwDgYDVR0PAQH/BAQDAgWgMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAeBgNVHREEFzAVghNyYXBpZHNz
bC5naWdhb25lLnBsMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9yYXBpZHNzbC1j
cmwuZ2VvdHJ1c3QuY29tL2NybHMvcmFwaWRzc2wuY3JsMB0GA1UdDgQWBBSOQy0O
ebxt/rc1Xlb+zc05dRQygzAMBgNVHRMBAf8EAjAAMEkGCCsGAQUFBwEBBD0wOzA5
BggrBgEFBQcwAoYtaHR0cDovL3JhcGlkc3NsLWFpYS5nZW90cnVzdC5jb20vcmFw
aWRzc2wuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBFbkwLXqTdNn/H1MrF7Uhnb8xg
vzquhcOdKrdBmLBLK2O8VNveTwEIe+sJMpb0M+ozjhacbA4c7Amj4Y9ZFHS1UA4B
y56fRr634TOCO+fgUX/H7Xr1dc9tKM9b8s7Tb82V/NkWD7YaRbBS4AUWDW+y31/Q
IUXn98OmuI3SEvEivqGiSaq1aEEjUzC8m6xY/WT/KKg/bC+3b71R5GeWpli5XroO
SU11e7kE+WSCstRSopJzqeDxmuL1NdpfMiDnu4GvrC0ybORd96RxdqBQbe0RSbnE
Fjkv8GyzBh9N8k373v9CFh5dPYrzGylNo+ysCChqPPRYws60zJqkfs6BVkhf
-----END CERTIFICATE-----
subject=/serialNumber=gas3S67znrMS0G-Ak1BxcG0zb6RTNpBx/C=PL/O=www.moja-domena.pl/OU=GT90180134/OU=See www.rapidssl.com/resources/cps (c)10/OU=Domain Control Validated - RapidSSL(R)/CN=www.moja-domena.pl
issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
---
No client certificate CA names sent
---
SSL handshake has read 3938 bytes and written 409 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 1F3AFADC347E7743904615AA175962936D9E36335CCCDDF2C658E986E31A553F
Session-ID-ctx:
Master-Key: 467AA14A3CA9FB415F67CB7B7C6F0DC66ABE9075E0DF11F14126F26D32EBBFE814A397503782DBF29AF54CEDE4DCBCD1
Key-Arg : None
PSK identity: None
PSK identity hint: None
TLS session ticket:
0000 - e3 66 0c 65 55 1c aa ea-61 b7 32 2b f3 13 75 8d .f.eU...a.2+..u.
0010 - 69 0e d0 18 f2 35 8e 5c-11 27 fa c5 67 4f 0b d9 i....5.\.'..gO..
0020 - 9d 7f ab 75 aa 90 4f 57-ba d6 b8 7e 28 45 3d 97 ...u..OW...~(E=.
0030 - 35 84 15 f1 0a 4c 2e c7-e9 ed 8a f9 bb 44 c8 ca 5....L.......D..
0040 - 9d 72 59 71 28 07 b3 e2-10 57 db cb 07 32 7f cb .rYq(....S...2..
0050 - b7 46 db a2 d9 8b 01 6e-20 ca 13 36 19 63 11 e2 .F.....n ..6.c..
0060 - 64 70 e1 32 42 fd 3f 3f-1a 49 e9 ea f0 51 a9 66 dp.2B.??.I...Q.f
0070 - bb dd d8 a2 52 8a df 8f-a6 d6 62 60 dd 53 54 5b ....R.....b`.ST[
0080 - 26 31 47 25 73 5b 7e 67-d6 52 36 94 7b a9 aa 97 x1G%s[~g.R6.....
0090 - 6b 82 1d 60 ca 6a e4 a4-0b 3c d5 33 b5 82 a7 a1 k..`.j.....3....

Compression: 1 (zlib compression)
Start Time: 1302325519
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

GNOME fallback

Przełączenie do starego trybu
LINK

Change Default Session from gnome to gnome-fallback
Thread Tools
Display
12-Sep-2011, 10:33 #1 ryanrio95
Newcomer


Join Date
Aug 2011
Posts
34
Change Default Session from gnome to gnome-fallback
Does anyone knows how to do this for all users with one command?
Or which file i have to edit to do this?

Regards, Ryan.
Reply With Quote
12-Sep-2011, 10:58 #2 please_try_again
Flux Capacitor Penguin


Join Date
Sep 2008
Posts
7,577
Re: Change Default Session from gnome to gnome-fallback
I wrote a script which doses that - among other things:

compositor: quickly sets/unsets compositing (helps with fullscreen Flash on ATI)

To switch from gnome to gnome-fallback, just type the following and restart Gnome:
Code:
compositor
To switch from gnome-fallback to gnome: Just type:
Code:
compositor gnome3
If you type
Code:
compositor
while in gnome-fallback, it switches compositing on/off.

This script in also included in the package conkyconf, available in my repo (has little to do with conky though): Easy configuring conky with conkyconf.
Reply With Quote
12-Sep-2011, 12:11 #3 malcolmlewis
Global Moderator


Join Date
Jun 2008
Location
Podunk
Posts
11,708
Blog Entries
13
Re: Change Default Session from gnome to gnome-fallback
Originally Posted by ryanrio95
Does anyone knows how to do this for all users with one command?
Or which file i have to edit to do this?

Regards, Ryan.
Hi
Under System Settings -> Graphics Forced Fallback Mode on, or;
Code:
gsettings set org.gnome.desktop.session session-name gnome-fallback
--
Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.4 (x86_64) Kernel 2.6.37.6-0.7-desktop
up 6 days 17:38, 5 users, load average: 0.16, 0.13, 0.27
GPU GeForce 8600 GTS Silent - Driver Version: 280.13

Reply With Quote
12-Sep-2011, 12:12 #4 ryanrio95
Newcomer


Join Date
Aug 2011
Posts
34
Re: Change Default Session from gnome to gnome-fallback
isn't there an command in opensuse that can do this? for the whole system?
Reply With Quote
12-Sep-2011, 12:16 #5 please_try_again
Flux Capacitor Penguin


Join Date
Sep 2008
Posts
7,577
Re: Change Default Session from gnome to gnome-fallback
Originally Posted by ryanrio95
isn't there an command in opensuse that can do this? for the whole system?
Yes, the command I use in the script. Otherwise, you can click on System Info -> Graphics -> Forced Fallback mode: ON ... if you can find it.
Reply With Quote
12-Sep-2011, 12:22 #6 ryanrio95
Newcomer


Join Date
Aug 2011
Posts
34
Re: Change Default Session from gnome to gnome-fallback
but this only changes it for one user. can it be changed on the whole system?
Reply With Quote
12-Sep-2011, 12:59 #7 ryanrio95
Newcomer


Join Date
Aug 2011
Posts
34
Re: Change Default Session from gnome to gnome-fallback
i think there is a file in /etc/ or something that contains the default gnome session, which i'am able to edit?
Reply With Quote
12-Sep-2011, 13:41 #8 please_try_again
Flux Capacitor Penguin


Join Date
Sep 2008
Posts
7,577
Re: Change Default Session from gnome to gnome-fallback
Originally Posted by ryanrio95
i think there is a file in /etc/ or something that contains the default gnome session, which i'am able to edit?
You can try to edit /usr/share/xsessions/gnome.desktop (or whatever this file is called, as I'm not using the default sessions) and use the following values for Exec and TryExec in this file:
Code:
Exec=gnome-session --session=gnome-fallback
TryExec=gnome-session --session=gnome-fallback
Please report if it works.
Reply With Quote
13-Sep-2011, 08:57 #9 ryanrio95
Newcomer


Join Date
Aug 2011
Posts
34
Re: Change Default Session from gnome to gnome-fallback
No,this just removes the Gnome option from the login screen.
But i really like this type of idea.
Reply With Quote
13-Sep-2011, 10:04 #10 please_try_again
Flux Capacitor Penguin


Join Date
Sep 2008
Posts
7,577
Re: Change Default Session from gnome to gnome-fallback
If you disable 3D rendering, you won't be able to use gnome-shell (but you won't be able to do some other things as well).
Adding this to /etc/X11/xorg.conf did the trick on Fedora (I don't have Gnome3 on openSUSE yet):

Code:
Section "Module"
Disable "glx"
EndSection
If that doesn't work, another even worse hack would be to rename /usr/lib64/xorg/modules/extensions/libglx.so (or /usr/lib/xorg/modules/extensions/libglx.so) on 32bit systems. But really, the cleanest and fastest way to switch from gnome to gnome-fallback (and vice-versa) is probably to use compositor at a user level. I needed to do so and this is one of the reason why I wrote this script (that I'm going to update pretty soon btw). It's not a big deal for users to type "compositor" once.

Gnome3 is not fun because it now uses a binary config file - simply unacceptable IMO under Linux or Unix. My guess is that the kids who developed Gnome3 must have learned to programm under WIndows. I might miss the point but I can't see any good reason not to use a configuration which is readable an parsable with basic Unix tools. If you have to set up Gnome3 in fallback mode for hundreds of users, you can try to set it up once and copy ~/.config/dfconf/user to /etc/skel/.config/dconf/user. so that each new user you create would default to gnome-fallback (I haven't tried though but I have this file in my skeleton for other settings than gnome-fallback). Another possibility is to use this command in one of the X startup scripts, executed by the user (not root), such as the Xsession script:

Code:
gsettings set org.gnome.desktop.session session-name gnome-fallback
I'm surprised that the --session option didn't work.

LVM2: vgscan fails to recreate lvmtab

LINK

I recently moved an LVM array from one server to another. When I tried to recreate the lvmtab with pvscan/vgscan, it successfully found my 3 disks, but do not recreate lvm tab.

# pvscan -v
Wiping cache of LVM-capable devices
Wiping internal VG cache
Walking through all physical volumes
PV /dev/sdb1 VG vg0 lvm2 [4.00 GiB / 0 free]
PV /dev/sdc1 VG vg0 lvm2 [4.00 GiB / 0 free]
PV /dev/sdd1 VG vg0 lvm2 [4.00 GiB / 0 free]
Total: 3 [11.99 GiB] / in use: 3 [11.99 GiB] / in no VG: 0 [0 ]


# vgscan -v
Wiping cache of LVM-capable devices
Wiping internal VG cache
Reading all physical volumes. This may take a while...
Finding all volume groups
Finding volume group "vg0"
Found volume group "vg0" using metadata type lvm2


# lvscan -v
Finding all logical volumes
inactive '/dev/vg0/opt' [11.99 GiB] inherit

At the end, I have no /dev/vg0 and no /etc/lvmtab.

Any ideas?

lvchange -ay /dev/vg0/opt

The volume is not activeated, with this command you actually activate it.

SSH key authentication

4. SSH with Keys in a console window

This first short wil learn us how to generate a key without a passphrase, and use it in a console.

4.1 Creating A Key

When you want to use ssh with keys, the first thing that you will need is a key. If you want to know more about how this mechanism works you can have a look in chapter 3, SSH essentials. Hence there are 2 versions, we will show examples for the both of them.

4.2 Protocol version 1 key generation

To create the most simple key, with the default encryption, open up a console, and enter the following command :

[dave@caprice dave]$ ssh-keygen
Wil output the following :

Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/dave/.ssh/identity): /home/dave/.ssh/identity
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dave/.ssh/identity.
Your public key has been saved in /home/dave/.ssh/identity.pub.
The key fingerprint is:
22:bc:0b:fe:f5:06:1d:c0:05:ea:59:09:e3:07:8a:8c dave@caprice
When asked for a "passphrase", we won't enter one. Just press enter twice.

The ssh-keygen program will now generate both your public and your private key. For the sake of this first simple tutorial I will call these files by their default names "identity" and the public key "identity.pub".

Your keys are stored in the .ssh/ directory in your home directory, but you can store them where ever you'd like. Good practice is to backup your keys on a floppy. If you do so, guard this floppy with your life!

Lets have a look at your keys.

cd ~.ssh; ls -l
-rw------- 1 dave dave 526 Nov 2 01:33 identity
-rw-r--r-- 1 dave dave 330 Nov 2 01:33 identity.pub
The file identity contains your private key. YOU SHOULD GUARD THIS KEY WITH YOUR LIFE! This key is used to gain access on systems which have your private key listed in their authorized keys file. I cannot stress this enough, dont have your keys drifting around. Also, make sure your private key always is chmod 600, so other users on the system won't have access to it.

The file identity.pub contains your public key, which can be added to other system's authorized keys files. We will get to adding keys later.

4.3 Protocol version 2 key generation

Creating a version 2 keypair is much like creating a version 1 keypair. Except for the fact that the SSH protocol version 2 uses different encryption algorithms for its encryption. In this case we can even choos it ourselves! Huray! To find out which versions are available on your system I'd advise you to have a look in the ssh-keygen manpage.

In our example we wil create a keypair using dsa encryption. This can be done by passing the key encryption method type to ssh-keygen. This is done in the following way :

[dave@caprice dave]$ ssh-keygen -t dsa
Which will output the following :

[dave@caprice dave]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/dave/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dave/.ssh/id_dsa.
Your public key has been saved in /home/dave/.ssh/id_dsa.pub.
The key fingerprint is:
7b:ab:75:32:9e:b6:6c:4b:29:dc:2a:2b:8c:2f:4e:37 dave@caprice
Again, we will retain the default locations, and we will not use a passphrase either.

Your keys are stored in the .ssh/ directory in your home directory.

Lets have a look at your keys.

cd ~.ssh; ls -l
-rw------- 1 dave dave 526 Nov 3 01:21 id_dsa
-rw-r--r-- 1 dave dave 330 Nov 3 01:21 id_dsa.pub
The file id_dsa contains your version 2 private key.

The file id_dsa.pub contains your version 2 public key, which can be added to other system's authorized keys file.

Again, I have listed a full ls -l with permissions, make sure you have the permissions set up correctly, otherwise other users may be able to snatch it from you. It is also a good idea to give your keys a non-standard name, since it makes guessing the name of your keypair files more easy.

4.4 Placing the public key on the remote server

To be able to log in to remote systems using your pair of keys, you will first have to add your public key on the remote server to the authorized_keys (for version 1) file, and the authorized_keys2 (for version2) file in the .ssh/ directory in your home directory on the remote machine.

In our example we will assume you don't have any keys in the authorized_keys files on the remote server. (Hint: If you do not have a remote shell, you can always use your own useraccount on your local machine as a remote shell (ssh localhost))

First we will upload the public keys to the remote server :

[dave@capricedave]$ cd .ssh/
[dave@caprice .ssh]$ scp identity.pub dave@192.168.1.3:./identity.pub
identity.pub 100% |*****************************************************| 526 00:00
[dave@caprice .ssh]$ scp id_dsa.pub dave@192.168.1.3:./id_dsa.pub
identity.pub 100% |*****************************************************| 614 00:00
This will place your keys in your home directory on the remote server. After that we will login on the remote server using ssh or telnet the conventional way... with a password.

When you are logged in you should create a .ssh directory, and inside the .ssh/ directory create an authorized_keys and an authorized_keys2 file and add the keys to the files. Make sure the files are not readable for other users/groups. chmod 600 authorized_keys* does the trick.

Adding the public key for version 1 works like this:

[dave@caprice dave]$ ssh 192.168.1.3 -v
[I edited out the verbose output, and entered the password]
[Remember kids, always use -v so dont try this at home :) ]

[dave@julia dave]$ mkdir .ssh
[dave@julia dave]$ chmod 700 .ssh
[dave@julia dave]$ cd .ssh
[dave@julia .ssh]$ touch authorized_keys
[dave@julia .ssh]$ chmod 600 authorized_keys
[dave@julia .ssh]$ cat ../identity.pub >> authorized_keys
[dave@julia .ssh]$ rm ../identity.pub
Placing the key for version 2 works about the same :

[dave@julia dave]$ cd .ssh
[dave@julia .ssh]$ touch authorized_keys2
[dave@julia .ssh]$ chmod 600 authorized_keys2
[dave@julia .ssh]$ cat ../id_dsa.pub >> authorized_keys2
[dave@julia .ssh]$ rm ../id_dsa.pub
If you take a little peek inside your public key files, you will find it to be a bunch of crypto, separated over a couple of rules. The public key is *1 line*. It is worth to note that the entire public key file should be one line in the authorized_keys files. So using >> is preferred over copying and pasting it from one document to another. This could put line breaks in your key which makes it useless.

Either way, your keys are in place, you are ready to go to the final step and log in using your keys.

4.5 Log in using your key

To log in using your key use the ssh command. We will add -1 to make sure we are using SSH Protocol version 1.

ssh -1 -v dave@192.168.1.3
This logs you into a system using your version 1 key.

Try it again, now for version 2

ssh -2 -v dave@192.168.1.3
Have a look in the output of both ssh logins and you will be able to see some differences between version 1 and 2.