Przeniesienie bloga

Blog został przeniesiony na nowy adres

http://net-todo.eu

Apache 2 SSL

Przełączamy się w tryb administratora

KOD: ZAZNACZ CAŁY

sudo -i

Instalujemy apache2 oraz openssl

KOD: ZAZNACZ CAŁY

apt-get install apache2 openssl

Następnie generujemy lokalny certyfikat dla naszego serwera. Zazwyczaj robi sie go z ważnością na 1 rok a więc:

KOD: ZAZNACZ CAŁY

openssl genrsa -out /etc/apache2/ssl/apache.key 1024
openssl req -new -x509 -days 365 -key /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

Dodajemy port na jakim nasłuchuje standardowo apache dla ssl

KOD: ZAZNACZ CAŁY

echo "Listen 443" >> /etc/apache2/ports.conf

Załączamy moduł SSL

KOD: ZAZNACZ CAŁY

a2enmod ssl

Tworzymy i aktywujemy stronę ssl

KOD: ZAZNACZ CAŁY

cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl

Następnie edytujemy utworzony plik

KOD: ZAZNACZ CAŁY

vim /etc/apache2/sites-available/ssl

I modyfikujemy na samym początku kilka linijek

KOD: ZAZNACZ CAŁY

NameVirtualHost *:443
<virtualhost *:443>
       ServerAdmin webmaster@localhost

       SSLEngine On
       SSLCertificateFile /etc/apache2/ssl/apache.crt
       SSLCertificateKeyFile /etc/apache2/ssl/apache.key


       DocumentRoot /var/www/

...

Następnie załączamy stronę ssl

KOD: ZAZNACZ CAŁY

a2ensite ssl

Zostaje nam tylko piękny restart apacha

KOD: ZAZNACZ CAŁY

/etc/init.d/apache2 force-reload

I od tej pory możemy sie cieszyć szyfrowanym połączeniem z apachem. Po wejściu na ten adres powinno za pierwszym razem zapytać o akceptację certyfikatu
https://localhost

Bootowalny pendrive z Windows XP/2000/7/8

Procedura DISKPART w skrócie

Skrócona lista komend:

• diskpart
• list disk
• select disk 2 (UWAGA! Tutaj wpisz właściwy numer nośnika!)
• clean
• create partition primary
• active
• format fs=fat32 quick
• assign

XEN Server - zmiana wielkości woluminu

Zmiana wielkości woluminu w XEN Server

Jeśli konieczna jest zmiana wielkości woluminu, jest to możliwe do zrobienia z CLI, jak i z XenCenter.

UWAGA: Możliwe jest rozszerzenie woluminu (extend), nie jest możliwe jest zmniejszenie.

Zmiana wielkości woluminu z CLI:

1. Zalogować się na konsolę serwera XEN.

2. Wyłączyć odpowiednią maszynę wirtualną.

3. Odnaleźć odpowiedni UUID (Universal Unique Identifier) dysku za pomocą komendy:
       # xe vm-disk-list vm=<nazwa VM>

4. Zmienić rozmiar woluminu za pomocą komendy:
       # xe vdi-resize uuid=<vdi uuid> size=<size (GiB, MiB)>

MySql - przywracanie praw konta root'a

restore / repair / reset mysql root privileges

cat > restore_root_privileges.sql
update mysql.user set Super_priv='y' where user='root';
update mysql.user set Select_priv='y' where user='root';
update mysql.user set Insert_priv='y' where user='root';
update mysql.user set Update_priv='y' where user='root';
update mysql.user set Delete_priv='y' where user='root';
update mysql.user set Create_priv='y' where user='root';
update mysql.user set Drop_priv='y' where user='root';
update mysql.user set Reload_priv='y' where user='root';
update mysql.user set Shutdown_priv='y' where user='root';
update mysql.user set Process_priv='y' where user='root';
update mysql.user set File_priv='y' where user='root';
update mysql.user set Grant_priv='y' where user='root';
update mysql.user set References_priv='y' where user='root';
update mysql.user set Index_priv='y' where user='root';
update mysql.user set Alter_priv='y' where user='root';
update mysql.user set Show_db_priv='y' where user='root';
update mysql.user set Super_priv='y' where user='root';
update mysql.user set Create_tmp_table_priv='y' where user='root';
update mysql.user set Lock_tables_priv='y' where user='root';
update mysql.user set Execute_priv='y' where user='root';
update mysql.user set Repl_slave_priv='y' where user='root';
update mysql.user set Repl_client_priv='y' where user='root';
update mysql.user set Create_view_priv='y' where user='root';
update mysql.user set Show_view_priv='y' where user='root';
update mysql.user set Create_routine_priv='y' where user='root';
update mysql.user set Alter_routine_priv='y' where user='root';
update mysql.user set Create_user_priv='y' where user='root';
-----  8<  -----  8<  -----  8<  -----  8<  -----  8<  -----  8<  ----- 

sudo /etc/init.d/mysql stop
sudo mysqld --skip-grant-tables &
mysql -vv < restore_root_privileges.sql
sudo /etc/init.d/mysql restart
mysql -u root -p
mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION;
mysql> quit;

(The password of the "debian-sys-maint" user is : sudo cat /etc/mysql/debian.cnf )

XenServer - instalowanie patchy z CLI

Installing the update using the off-host CLI

1. Download the update to a known location on a computer that has the XenServer CLI or XenCenter installed.
2. Extract the xsupdate file from the zip.
3. If using Windows, start a Command Prompt and navigate to the XenCenter directory, for example:

cd C:\Program files\Citrix\XenCenter

4. Upload the xsupdate file to the Pool Master by entering the following commands:
   (Where hostname is the Pool Master's IP address or DNS name.)
   

   xe patch-upload -s <hostname> -u root -pw <password> file-name=<path_to_update_file> XS60E016.xsupdate

   XenServer assigns the update file a UUID which this command prints. Note the UUID.

   46BC6C41-3889-41BE-B394-A4D8455A58E2



5. Apply the hotfix to all hosts in the pool, specifying the UUID of the hotfix:

   xe patch-pool-apply uuid=<46BC6C41-3889-41BE-B394-A4D8455A58E2>

6. Verify that the update was applied by using the patch-list command.

   xe patch-list -s <hostname> -u root -pw <password> name-label=XS60E016

   If the update has been successful, the hosts field will contain the UUIDs of the hosts this patch was successfully applied to. This should be a complete list of all hosts in the pool.
7. The hotfix is applied to all hosts in the pool, but it will not take effect until each host has been rebooted. For each host, migrate the VMs that you wish to keep running, and shutdown the remaining VMs before rebooting the host.
8. To verify in XenCenter that the update has been applied correctly, select the Pool, and then click the General tab. This displays the Pool properties. In the Updates section, ensure that the update is listed as Fully applied.    

Cacti - monitorowanie serwera DNS - BIND9

Do uruchomienia monitorowania serwera DNS Bind9 będa potrzebne:
- skrypty i template do Cacti - bind9-stats-2.0.tar
- biblioteka do Perla - libsnmp-extension-passpersist-perl

Ponieważ nie mam jej w dystrybucji Debian Squeeze należy pobrać pakiet deb na dysk i zainstalować za pomocą:
# dpkg - i libsnmp-extension-passpersist-perl_0.06-1_all.deb

Przed instalacja należy doinstalować pakiety:

• libclass-accessor-perl (>= 0.30)
• liblist-moreutils-perl (>= 0.21)

1. Konfiguracja Binda i sprawdzenie działanie narzędzie RNDC

- do pliku konfiguracyjnego Binda dodajemy sekcje z kluczem MD5 dla RNDC, musi byc on zgodny z kluczem w pliku konfiguracyjny rndc.conf, oraz konfigurujemy Binda by generował statystyki do pliku (jeżeli Bind jest uruchamiany w sand-boxie, podajemy zwykłą ścieżkę do pliku, bez żadnych dodatkowych informacji)


key rndc-key {
        algorithm hmac-md5;
        secret " jakis sekretny klucz MD5 ";
        };

zone-statistics         yes;

dump-file               "/var/cache/bind/cache_dump.db";

statistics-file         "/var/cache/bind/named_stats.txt";

memstatistics-file      "/var/cache/bind/named_mem_stats.txt";

- restart Binda i sprawdzenie działanie narzędzia RNDC
# /etc/init.d/bind9 restart

# rndc status
version: 9.7.3 (DNS)

CPUs found: 1

worker threads: 1

number of zones: 28

debug level: 0

xfers running: 0

xfers deferred: 0

soa queries in progress: 0

query logging is OFF

recursive clients: 0/0/1000

tcp clients: 0/100

server is up and running

- sprawdzamy czy rndc generuje plik

# rndc stats
# more /var/cache/bind/named_stats.txt

+++ Statistics Dump +++ (1353929701)

++ Incoming Requests ++

                 123 QUERY

++ Incoming Queries ++

                 117 A

                   6 AAAA

++ Outgoing Queries ++

[View: internal]

[View: external]

[View: _bind]

++ Name Server Statistics ++

                 123 IPv4 requests received

                  54 requests with EDNS(0) received

                  62 recursive queries rejected

                 123 responses sent

                  54 responses with EDNS(0) sent

                  55 queries resulted in successful answer

                  61 queries resulted in authoritative answer

                   6 queries resulted in nxrrset

                  62 other query failures

++ Zone Maintenance Statistics ++

                   9 IPv4 notifies sent

++ Resolver Statistics ++

(...)

- i dodajemy wywołanie skryptu do crona, generowanie statystyk nastąpi co 5 minut

*/5 * * * * /usr/share/bind9/bind9-genstats.sh > /dev/null 2>&1

2. Plik bind9-stats-2.0.tar rozpakowujemy np. do /usr/share/bind9

3. Modyfikujemy skrypty. W obu należy ustawić ścieżkę do pliku named_stats.txt. Tu podajemy już pełną ścieżkę w systemie plików

/usr/share/bind9/bind9-genstats.sh

STAT_FILE=/var/lib/named/var/cache/bind/named_stats.txt

/usr/share/bind9/snmp/bind9-stats-snmpd.pl

$STAT_FILE = "/var/lib/named/var/cache/bind/named_stats.txt";

4. Do pliku snmpd.conf dodajemy:

pass .1.3.6.1.4.1.2021.55 /usr/bin/perl /usr/share/bind9/snmp/bind9-stats-snmpd.pl

restartujemy demona
# /etc/init.d/snmpd restart

i sprawdzamy:

#snmpwalk -v 2c -c <snmp_community> localhost .1.3.6.1.4.1.2021.55

UCD-SNMP-MIB::ucdavis.55.1.0 = INTEGER: 0

UCD-SNMP-MIB::ucdavis.55.1.1 = INTEGER: 1

UCD-SNMP-MIB::ucdavis.55.1.2 = INTEGER: 2

UCD-SNMP-MIB::ucdavis.55.1.3 = INTEGER: 3

UCD-SNMP-MIB::ucdavis.55.1.4 = INTEGER: 4

UCD-SNMP-MIB::ucdavis.55.1.5 = INTEGER: 5

UCD-SNMP-MIB::ucdavis.55.1.6 = INTEGER: 6

UCD-SNMP-MIB::ucdavis.55.2.1 = STRING: "GLOBAL"

(...)

5. Na koniec kopjujemy plik 

# cp /usr/share/bind9/snmp/bind9-stats-snmp.xml /usr/share/cacti/resource/snmp_queries/

oraz importujemy do Cacti template cacti_data_query_bind_9_statistics_snmp.xml

6. Dodajemy do hosta na którym mamy uruchomiony serwer DNS data query BIND 9 Statistics (SNMP), po czym wykonujemy odczyt danych z serwera (Verbose query) i normalnie dodajemy potrzebne wykresy.

Data Query
Obrazek z http://forums.cacti.net

Statystyka ogólna serwera DNS Bind9
Obrazek z http://forums.cacti.net

Cacti - monitorowanie kontrolera zasilania Tahoe 8216 GSM

Zacząłem ostatnio używać bardzo fajny system do zdalnej kontroli zasilania urządzeń w szafie rackowej. Szczególnie użyteczne jest to w miejscu, gdzie dojazd zabiera trochę czasu a trzeba szybko zrestartować jakieś urządzenie przez wyłączenie zasilania. System zdalnego zasilania Tahoe 8216 GSM udostępnia kontrolę nad zasilanie urządzeń zarówno przez sieć LAN/WAN, jak i pozwala na kontrolę zasilania za pomocą telefonu, przez wysyłanie wiadomości SMS. Oprócz dostępnych 10 gniazdek na jednostce główniej, system umożliwia podłączenie 31 jednostek podrzędnych do pozwala na kontrolowania naprawdę dużej ilości urządzeń :) Oprócz tego urządzenie potrafi w oparciu o zdefiniowane watchdogi samodzielnie restartować wybrane urządzenia, które np. nie odpowiadają na ping przez 5 minut.

Więcej informacji o Tahoe 8216 GSM tutaj.

Przez SNMP urządzenie udostępnia kilka parametrów środowiskowych, takich jak: napięcie, pobór prądu i mocy, temperatura urządzenia i inne. Wszystkie informacje są dostępne w gałęzi enterprice OID: 

.1.3.6.1.4.1.3600.4.2 

oraz standardowym

.1.3.6.1

MIBy do urządzania są tutaj. MIB jest kompatybilny z firmware 1.4.2 rev.499

Co do monitorowania samego urządzenia to stworzyłem do Cacti template urządzenia Tahoe do monitorowania wspomnianych parametrów. Plik jest utworzony w wersji Cacti 0.8.8a.

 cacti_host_template_tahoe_8216gsm.xml

Całość wygląda tak:

Cacti - jak zmienić hasło konta admin ?

Jeśli nie można dostać się na konto admina w Cacti, zostaje jedna droga - zmiana hasła w bazie MySql. Można zrobić to za pomocą np. PhpMyAdmin lub po prostu za pomocą CLI. Proste, łatwe i przyjemne :)

mysql -u root -p

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 4322 Server version: 5.1.63-0+squeeze1 (Debian) Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use cacti

mysql> update user_auth set password=MD5('Password') where username='admin';

XenServer - dodawanie nowego lokalnego SR

Ostatnio musiałem dodać do XEN SERVER 6.0 dodatkowe dyski. Ale tu mała konsternacja, z XenCenter nie ma możliwości dodania nowego lokalnego storage, wyłącznie różne dyski sieciowe - NFS, iSCSI, FC itp. Można to jednak zrobić używając niezawodnej konsoli. Zatem po kolei co zrobić, aby dodać nowy dysk twardy jako Storage Repository.

1. Sprawdzamy zainstalowane dyski twarde

# fdisk -l

Disk /dev/sdb: 999.9 GB, 999989182464 bytes

255 heads, 63 sectors/track, 121575 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

2. Wyświetlamy UUID hosta XEN SERVER

# xe host-list

uuid ( RO)                : a3fa9eea-21de-45f6-a89a-4e23b3010c68
    name-label ( RW): mordor
    name-description ( RW): XenServer 6.0.0

3. Dodajemy storage repository

# xe sr-create host-uuid=a3fa9eea-21de-45f6-a89a-4e23b3010c68  content-type=user type=ext device-config:device=/dev/sdb shared=false name-label="Local Storage 2"

4. Teraz możemy sprawdzić czy nowy dysk jest widziany przez XEN SERVER

# xe sr-list

uuid ( RO)                : d5175b5c-d042-aa49-ec90-1fcc6d2fc7a2
          name-label ( RW): Local Storage 2
    name-description ( RW):
                host ( RO): mordor
                type ( RO): lvm
        content-type ( RO): user

Nagios - monitorowanie kontrolera RAID 3WARE 9650SE

Z uwagi na budżet, nie używam "dużych" serwerów takich jak np. HP Proliant DL380 G7. Do wykorzystywanych przeze mnie funkcjonalności w zupełności wystarcza najmniejszy HP Proliant DL 120 G6 i G7. Niestety HP ograniczyło ich funkcjonalność przez zastosowanie kontrolera RAID SmartArray B110i SATA, który nie jest wspierany przez XenServer. Nie zależnie od ustawień w BIOSie maszyny, XenServer widzi dyski fizyczne a nie np. zestaw RAID1. Funkcjonalność serwera DL120 można poprawić przez zastosowanie kontrolera RAID 3Ware z rodziny 9560SE. Są ta bardzo zaawansowane kontrolery obsługujące od 4 do 24 dysków SATA i umożliwiające zbudowanie macierzy RAID praktycznie każdego poziomu  z RAID6 włącznie. Mogą być one doposażone w moduł bateryjny służący do podtrzymania cache dyskowego w razie nagłej utraty zasilania, co zapobiega utracie danych przy trybie zapisu writeback cache. Niestety jest też dość znaczący minus. Normalnie serwer posiada moduł diagnostyczny i w razie awarii dysku na kieszeni wyświetlany jest alarm w postaci diody LED. Po zastosowaniu kontrolera nie mamy dostępu do tej funkcjonalności. Jest to prawdopodobnie do obejścia, ale wymaga ingerencji w okablowanie wewnętrzne serwera. Z pomocą do monitoringu stanu pracy macierzy, dysków i baterii przyszedł mi Nagios i plugin napisany przez Mariusa Heina z firmy Netways Gmbh a znaleziony na http://exchange.nagios.org. Marius ograniczył się do testowania wyłącznie zestawów RAID na lokalnej maszynie. Rozbudowałem ten plugin o możliwość monitorowania maszyny zdalnej, testowanie dysków fizycznych i baterii. Dzięki temu uzyskałem w pełni funkcjonalny monitoring stanu macierzy dyskowej w serwerach.


jak to działa???

Plugin jest napisany w Perlu, wykorzystuje protokół SSH do zdalnego wykonania programu na monitorowanym serwerze. Do logowania się na zdalnej maszynie użyłem kluczy RSA by nie było konieczności podawania hasła - opisane tutaj. 

UWAGA: Skrypt używa konta roota dla dostępu do zdalnej maszyny - tak wiem jest to niebezpieczne, ale w posiadanym przeze mnie środowisku jest to nieistotne. Można przystosować skrypt do użycia z dowolnym użytkownikiem, który będzie miał możliwość wykonania kodu na zdalnej maszynie. 

Oprócz tego potrzebny będzie interfejs CLI kontrolera 3Ware. To za jego pomocą uzyskamy dostęp do kontrolera i stanu poszczególnych komponentów systemu RAID. W zależności od systemu Linux potrzebny będzie jeden z poniższych plików:
     
tw_cli-linux-x86_64-9.4.1.3.tgz
tw_cli-linux-x86_64-9.5.3.tgz
tw_cli-linux-x86-9.3.0.7.tgz

Program tw_cli odpowiada za bezpośredni dostęp do interfejsu kontrolera, program tw_sched jest portem pomiędzy cronem a tw_cli i pozwala na automatyzację niektórych funkcji, np. cykliczne test macieży. Składnia obu programów jest opisana w załączonej dokumentacji.

Ostatnim krokiem jest konfiguracja Nagiosa - komendy, testy itp.


konfiguracja

Teraz trzeba zebrać to w całość i uruchomić. Zatem po kolei:

1. instalacja tw_cli 

Kopiujemy i rozpakowujemy archiwum z oprogramowaniem dla kontrolera

# tar -xvf tw_cli-linux-x86-9.3.0.7.tgz

Program ma bardzo bogaty help, opisany również w manach.

2. instalacja i konfiguracja pluginu

Plik z pluginem należy skopiować do katalogu /usr/lib/nagios/plugins i upewnić się że użytkownik nagios może wykonywać skrypt, np.

-rwxr-xr-x 1 root root 6723 06-25 13:29 check_3ware.pl

Plugin jest to pobrania TUTAJ

Oprócz tego, jeśli to konieczne należy zmienić użytkownika, który loguje się przez SSH do maszyny - linia 55

$conf{'path'} = 'ssh root@';



3. konfiguracja Nagiosa

W katalogu /etc/nagios-plugins/config należy utworzyć plik z konfiguracją komend dla Nagiosa:


# 'check_3ware' command definition
define command{
        command_name    check_3ware_raid
        command_line    /usr/lib/nagios/plugins/check_3ware.pl -H $HOSTADDRESS$ -C $ARG1$ -U $ARG2
        }

define command{
        command_name    check_3ware_disc
        command_line    /usr/lib/nagios/plugins/check_3ware.pl -H $HOSTADDRESS$ -C $ARG1$ -D $ARG2$
        }

define command{
        command_name    check_3ware_bbu
        command_line    /usr/lib/nagios/plugins/check_3ware.pl -H $HOSTADDRESS$ -C $ARG1$ -B $ARG2$
        }

Następnie w pliku konfiguracyjnym dodajemy nowe serwisy, należy pamiętać o zmianie   parametru hostgroup_name na odpowiedni dla posiadanej konfiguracji.


define service {
        hostgroup_name          xen-servers
        service_description     RAID Unit 0
        check_command           check_3ware_raid!0!0
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     RAID Unit 1
        check_command           check_3ware_raid!0!1
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     BBU
        check_command           check_3ware_bbu!0!0
        use                     template-service
}
define service {

        hostgroup_name          xen-servers
        service_description     Disc 0
        check_command           check_3ware_disc!0!0
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     Disc 1
        check_command           check_3ware_disc!0!1
        use                     template-service
}
define service {
        hostgroup_name          xen-servers
        service_description     Disc 2
        check_command           check_3ware_disc!0!2
        use                     template-service
}

define service {

        hostgroup_name          xen-servers

        service_description     Disc 3

        check_command           check_3ware_disc!0!3

        use                     template-service

}

Na koniec weryfikujemy konfigurację Nagiosa i restartujemy serwis.

# /usr/sbin/nagios3 -v /etc/nagios3/nagios.cfg
# /etc/init.d/nagios3 restart



4. A oto efekt

Alarm modułu bateryjnego

Alarmu dysku fizycznego i macierzy

Linux - SSH bez hasła - klucze RSA

Jeśli Twoja dzienna aktywność wymaga logowania na konta w wielu systemach Linux przez SSH, będziesz szczęśliwy wiedząc (jeśli już nie wiesz :) ), że jest sposób by umożliwić bezpieczny, uwierzytelniony zdalny dostęp, transfer plików, zdalne wykonywanie skryptów bez konieczności pamiętania i wpisywania haseł. SSH umożliwia wykorzystanie mechanizmu kluczy RSA do bezpiecznego logowania się do systemu.


1. generowanie kluczy RSA

Pierwszym krokiem jest wygenerowanie pary kluczy RSA na lokalnym systemie. Klucze użytkownika są przechowywane w katalogu $HOME/.ssh/ Do wygenerowania pary kluczy należy wykonać komendę:

# ssh-keygen -t rsa

Generating public/private rsa key pair. 
Enter file in which to save the key (/root/.ssh/id_rsa):

(Jest to bezpieczne, naciśnij enter tutaj jako / root / .ssh jest domyślnym i zalecanym katalogu do przechowywania RSA plik).

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 

(Hasło tutaj wpiszesz muszą być wprowadzane za każdym razem użyć klucza RSA, ale na szczęście można ustawić bez hasła, naciskając klawisz Enter. Jednak plusem jest to, że trzeba tylko pamiętać jedno hasło dla wszystkich systemów, które uzyskują dostęp przez uwierzytelnianie kluczem RSA. Można zmienić passhrase później za pomocą "ssh-keygen-p").

Your identification has been saved in /root/.ssh/id_rsa. 
Your public key has been saved in /root/.ssh/id_rsa.pub. 

Twoje klucze zostały zapisane w odpowiednim katalogu. Upewnijmy się tylko że nikt inny ich nie odczyta.


# chmod 700 .ssh
# chmod 600 .ssh/id_rsa

# chmod 600 .ssh/id_rsa.pub


2. instalowanie klucza publicznego w zdalnym systemie

Teraz należy zainstalować klucz publiczny w systemie zdalnym. W tym celu należy skopiować plik

$HOME/.ssh/id_rsa.pub

Najlepiej zrobić to za pomoca komendy:

# scp .ssh/id_rsa.pub root@<IP_ADDRESS>:~/

Komenda ta skopjuje klucz publiczny do katalogu domowego użytkownika. Następnie logujemy się za pomocą SSH na system zdalny używając tego samego loginu co poprzednio - po raz ostatni podajemy hasło :) Autoryzowane klucze znajdują się w pliku 

$HOME/.ssh/authorized_keys

Musimy teraz przenieść nasz klucz publiczny do tego pliku.

# cat id_rsa.pub >> .ssh/authorized_keys

Uwaga na dwa ">>", użycie ich spowoduje dołączenie nowego klucza do pliku. W przypadku użycia tylko jednego znaku ">" plik zostanie nadpisany i stracimy zapisane tam inne klucze!!!

Następnie należy upewnić się, że tylko użytkownim ma dostęp do katalogu i pliku z kluczami

# chmod 700 .ssh
# chmod 600 .ssh/authorized_keys


3. sprawdzenie autoryzacji RSA

Po wszystkim sprawdzamy czy autoryzacja RSA działa. Wylogowujemy się z systemu zdalnego i wpisujemy:

# ssh root@<IP_ADDRESS>

Powinniśmy zobaczyć konsolę zdalnego systemu bez pytania się o hasło. Jeśli została podana passphrasse to ją podajemy jako hasło.

UWAGA:
Logowanie za pomocą kluczy jest tak długo bezpieczne jak długo bezpieczny jest nasz klucz prywatny. Nie udostępniaj go nikomu. Tylko za jego pomocą możliwe będzie zalogowanie się na zdalny system. Jego utrata bądź uszkodzenie spowoduje brak dostępu do systemu.