Two things are infinite..

Opisałem sposób łączenia pomiędzy systemami Linux poprzez VINO, ale otwarta pozostaje kwestia połączenia z systemu Windows. Instalując serwer SAP na SLES 10 musiałem zapewnić sobie w miarę wygodne połączenie z serwerem, aby móc na przykład restartować system ERP lub wykonywać inne czynności. Jest to szczególnie użyteczne, gdy pracuję w domu i nie mam fizycznego dostępu do serwera.
Opisany poniżej sposób działa też przy połączeniach poza sieć korporacyjną, w której jestem. Oznacza to, że pracując w pracy z Windows bez problemu połączę się z domowym komputerem pracującym z OpenSUSE. Zestawienie połączenia jest banalnie proste, ale warunkiem jest brak blokady portu 22. Jest on konieczny przy połączeniu. Pewnie większość osób czytających ten wpis będzie zainteresowanych opcją połączenia się ze swoim domowym komputerem. W swoim opisie wykorzystam program Putty (wersja 0.60), z którego korzystam. Opisana konfiguracja była testowana na SLES 10 SP2, ale taka sama działa na OpenSuSE (lub innej dystrybucji).

Całą procedurę można podzielić na następujące etapy:

1. Konfiguracja SSH na Linuksie i otwarcie portu.
2. Utworzenie użytkownika i generacja klucza
3. Przygotowanie klucza dla Putty
4. Konfiguracja połączenia

Etap 1 – Konfiguracja SSH
Zaczynamy od skonfigurowania pliku /etc/ssh/sshd_config. Poniżej przedstawiam jego zawartość wyszczególniając linie, które zmieniłem w stosunku do oryginalnej wersji. Każdy mój komentarz zaczyna się od „# RD”, a dodatkowo zmienione linie zaznaczone sa pogrubieniem.

#    $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

Port 22 # RD definicja portu (22)

Protocol 2 # RD: Protokół 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no #RD: nie zezwalaj na logowanie jako Root
StrictModes yes #RD
MaxAuthTries 6 #RD Maksymalna ilość prób logowania

RSAAuthentication no # RD
PubkeyAuthentication yes #RD
AuthorizedKeysFile    .ssh/authorized_keys # RD – szczegóły poniżej – w opisie

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
RhostsRSAAuthentication no # RD
# similar for protocol version 2
HostbasedAuthentication no # RD
# Change to yes if you don’t trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
IgnoreUserKnownHosts yes #RD
# Don’t read the user’s ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no #RD nie zezwalaj na puste hasła

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no # RD

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to ‘yes’ to enable support for the deprecated ‘gssapi’ authentication
# mechanism to OpenSSH 3.8p1. The newer ‘gssapi-with-mic’ mechanism is included
# in this release. The use of ‘gssapi’ is deprecated due to the presence of
# potential man-in-the-middle attacks, which ‘gssapi-with-mic’ is not susceptible to.
#GSSAPIEnableMITMAttack no

# Set this to ‘yes’ to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# „PermitRootLogin without-password”. If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10 # RD
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem    sftp    /usr/lib64/ssh/sftp-server

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

Jest to przykładowa konfiguracja, która może być zmieniana w zależności od potrzeb.

Po zapisaniu zmian należy zrestartować demona sshd komendą:

/etc/init.d/sshd restart

Jeżeli chcemy, aby demon zawsze był włączony, to najlepiej sprawdzić (i ewentualnie skorygować) ustawienia w YaST. Włączony demon zapewnia dostępność serwera do zdalnej kontroli. W zastosowaniach domowych można wybrać ręczny start demona w przypadkach, kiedy wiemy że będziemy się łączyli zdalnie.

Warto też zeskanować porty i sprawdzić wynik. Można wykorzystać komendę nmap. Oto przykład wykonania dla adresu IP 16.55.100.50 i jej wynik:

ides:~ # nmap -sS -O 16.55.100.50

Starting Nmap 4.00 ( http://www.insecure.org/nmap/ ) at 2008-12-11 12:26 CET
Interesting ports on ides.site (16.55.100.50):
(The 1666 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE
22/tcp   open  ssh
111/tcp  open  rpcbind
427/tcp  open  svrloc
631/tcp  open  ipp
1527/tcp open  tlisrv
8000/tcp open  http-alt
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X
OS details: Linux 2.4.0 – 2.5.20, Linux 2.5.25 – 2.6.8 or Gentoo 1.2 Linux 2.4.19 rc1-rc7

Nmap finished: 1 IP address (1 host up) scanned in 2.065 seconds

Etap 2 – Utworzenie użytkownika i generacja klucza
Proces tworzenia użytkownika jest na tyle prosty, że nie ma sensu go opisywać. Najlepiej zrobić to w YaST, choć można też w terminalu.
Po utworzeniu użytkownika logujemy się na jego konto. Musimy wygenerować parę kluczy, która będzie służyła do identyfikacji (oprócz hasła). Podnosi to poziom bezpieczeństwa dla połączeń SSH. Generując klucze musimy zdefiniować hasło dostępu.

Klucze generujemy komendą

ssh-keygen –t rsa

Poniżej wynik działania komendy:

zdalny@ides:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/zdalny/.ssh/id_rsa):
Created directory ‘/home/zdalny/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zdalny/.ssh/id_rsa.
Your public key has been saved in /home/zdalny/.ssh/id_rsa.pub.
The key fingerprint is:
9d:db:63:2a:89:00:65:f7:26:61:4a:d6:d1:91:29:14 zdalny@ides
zdalny@ides:~>

Wykonanie opisanej komendy spowoduje utworzenie w katalogu domowym użytkownika nowego katalogu „.shh” . Korzystając z dowolnego menadżera plików (albo z terminala) musimy dostać się do tego katalogu. Powinny się tam znajdować dwa pliki: id_rsa oraz id_rsa.pub.
Plik id_rsa kopiujemy na przenośny nośnik. Będziemy go potrzebowali w systemie Windows.

Oprócz skopiowania pliku id_rsa musimy też wykonać w folderze ./ssh komendę:

cp id_rsa.pub authorized_keys

W wyniku tej komendy utworzony zostanie plik authorized_keys będący kopią klucza id_rsa.pub. Jest to konieczny krok, ponieważ takiego klucza będzie szukał SSH. Jego nazwę mamy zdefiniowaną w pliku konfiguracyjnym pokazanym wcześniej.

Etap 3 Przygotowanie klucza dla Putty
Korzystając z pliku id_rsa wygenerujemy klucz potrzebny do autoryzacji sesji. Musimy w tym celu wykorzystać program puttygen.exe.
Po uruchomieniu programy wybieramy w menu File i potem Load private key.
Wskazując plik id_rsa musimy wybrać opcję odczytu plików każdego typu (*.*).
Powinno pojawić się pytanie o hasło, które ustawiliśmy generując klucz w linuksie. Po jego podaniu ukaże się komunikat, że klucz został wygenerowany. Widać to na zrzucie ekranu pokazanym poniżej.

Ostatnią czynnością po wygenerowaniu klucza jest zapisanie go w formacie *.ppk (wykorzystujemy przycisk Save private key).

Etap 4 Konfiguracja połączenia
Mamy już klucz zapisany w formacie *.ppk (w tym przykładzie jest to plik klucz.ppk), więc czas na konfigurację połączenia w programie Putty. Na początek podajemy adres IP i port. Wszystkie opcje muszą być zaznaczone tak, jak pokazano poniżej.

W polu Saved Sessions wpisujemy nazwę pod jaka będziemy chcieli zapisać połączenie (w tym przykładzie : ides).

W kolejnym kroku rozwijamy drzewko z lewej strony i zaznaczamy SSH. W omawianym przykładzie musimy zaznaczyć opcje w sposób pokazany poniżej.

Dodatkowo wybieramy w SSH pozycje Auth i wskazujemy plik klucza.

Możemy teraz w menu powrócić do pierwszej pozycji i zapisać konfigurację dla ides klikając na przycisku Save (przycisk widać na załączonym wcześniej pierwszym zrzucie z programu Putty).

Klikając dwukrotnie myszką na pozycji ides (w zapisanych sesjach) pojawi się okienko z ekranem logowania.

Na koniec jeszcze jedna uwaga. Zestawiając połączenie pamiętajmy o tym, aby nasza zapora (firewall) nie blokowała portu 22. W celach testowych możemy ją na chwilę wyłączyć. Konfiguracja zapory jest prosta o ile zrobimy to w YaST.

Ewentualne problemy i zdarzenia związane z SSH możemy sprawdzać w pliku /var/log/messages. Udane połączenia są tam logowane w postaci wpisów typu:

Accepted publickey for zdalny from <IP> ….