Posts Tagged ssh

Jak usunąć błędny klucz serwera z pliku known_hosts

Lip 12

Posted by Łukasz Stelmach in Linux | Comments off

Prawdopodobnie każdy, kto korzystał trochę dłużej z SSH spotkał się z podobnym komunikatem, występujący przy próbie połączenia z wybranym serwerem:

$ ssh server.example.com
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
63:6a:1e:ef:1a:a8:44:c4:46:ce:d1:97:b1:f3:7a:29.
Please contact your system administrator.
Add correct host key in /home/lukasz/.ssh/known_hosts to get rid of this message.
Offending key in /home/lukasz/.ssh/known_hosts:44
RSA host key for server.example.com has changed and you have requested strict checking.
Host key verification failed.

Pojawienie się go może świadczyć o tym że:

  1. Jesteśmy własnie w obiektem ataku Men in the middle (informacja o tym znajduje się w treści komunikatu).
  2. Klucz serwera z którym chcemy się połączyć uległ zmianie (czyli np. jest to inna maszyna, wygenerowano go ponownie).

Jeżeli wiemy, że mamy do czynienia z sytuacją drugą, to będziemy chcieli zaktualizować odpowiedni klucz i dalej łączyć się z wybraną maszyną.

Najprościej odcisk klucza zmienić poprzez usunięcie odpowiedniego wpisu i ponowne połączenie się z wybraną maszyną. Usuwamy klucz na dwa sposoby:

  • przy użyciu polecenia ssh-keygen:
    $ ssh-keygen -R server.example.com

    Polecenie to spowoduje wszystkich wpisów związanych z danym serwerem z pliku ~/.ssh/known_hosts.

  • ręcznie usuwając odpowiednią linijkę z pliku ~/.ssh/known_hosts. Tutaj może pojawić się problem, ponieważ w nowych wersjach SSH nazwy hostów zostały zakodowane przy użyciu funkcji skrótu. Z pomocą przychodzi tutaj powyższy komunikat błędu, pojawia się tam informacja o linii która sprawia problem:
    Offending key in /home/lukasz/.ssh/known_hosts:44

    Czyli wystarczy otworzyć podany plik i usunąć wybraną linie i po sprawie.

Metoda, która się wybierze zależy od nas, ale warto pamiętać o możliwościach polecenia ssh-keygen. Może się przypadać podczas tworzenia skryptów, lub gdy chcemy usunąć informacje wszystkich kluczach skojarzonych z danym serwerem.

Źródła

Tags: , , , ,

Zdalny dostępu do sieci wewnętrznej przy użyciu protokołu SSH

Lut 14

Posted by Łukasz Stelmach in Linux | Comments off

Zdarza się, że trzeba zalogować się do serwera stojącego za firewallem, do którego nie mamy bezpośredniego dostępu (przynajmniej przy użyciu protokołu SSH).

Jeżeli zapora ogniowa jest oparta

  • firewall jest system opartym o Linuksa, na którym możemy zalogować się przy użyciu SSH
  • mamy możliwość skorzystania z uwierzytelnienia przy użyciu kluczy na oba serwery (nie jest to obligatoryjne, ale nie będzie potrzeby dwukrotnego wprowadzania hasła

Logowanie poprzez wykonanie polecenia

Jedną z podstawowych możliwości aplikacji ssh jest możliwość wykonania komendy na zdalnej maszynie oraz zwrócenie jej wyniku działania. Najprostsza demonstracja:

lukasz@karamba:~$ ssh login@firewall ls -l mysql*
-rw-r--r-- 1 lukasz lukasz 8640154 2008-10-21 04:06 mysql-connector-java-5.1.7.tar.gz

Można to wykorzystać i zamiast polecenia ls wywołać polecenie ssh i połączyć się ze zdalną maszyną:

lukasz@karamba:~$ ssh -t login@firewall 'ssh login@produkcja'

Należy zwrócić uwagę na przełącznik użycie przełącznika -t. Nakazuje on utworzyć terminal na maszynie firewall. Bez tej opcji połączenie będzie działać, ale nie zostanie pokazany np. standardowy znak zachęty.

O czym należy pamiętać:

  • jeżeli korzystamy z uwierzytelniania opartego o klucze, to nasz klucz publiczny musi być zainstalowany na maszynie firewall, oraz klucz publiczny z maszyny firewall musi być zainstalowany na maszynie produkcja, w przeciwnym wypadku będzie trzeba podać hasła
  • niestety sposób ten nie jest kompatybilny z poleceniami scp czy też rsync, aby przekopiować plik z maszyny lokalnej na produkcja należy to wykonać dwuetapowo za pośrednictwem maszyny firewall (w przypadku polecenia rsync da się to ograniczenia ominąć, ale nie jest to już takie oczywiste)

Konfiguracja dyrektywy ProxyCommand

Drugą metodą jest poinformowanie aplikacji ssh, że do połączenia z daną maszyną musi użyć maszyny pośredniczącej w komunikacji.

Należy utworzyć plik (lub zmodyfikować instniejący) ~/.ssh/config:

1
2
Host produkcja
        ProxyCommand ssh login@firewall nc -q0 %h %p 2> /dev/null

Parametr Host (linia 1) wskazuje jakiej maszyny będą dotyczyła konfiguracja. Należy wprowadzić taką nazwę, która będzie użyta podczas łączenia z maszyną wewnątrz sieci. Dyrektywa ProxyCommand (linia 2) informuje aplikację ssh o tym, że należy połączyć się z maszyną firewall i uruchomić polecenie nc.

Po wprowadzeniu tych zmian, można zainicjować połączenie z serwerem produkcja

ssh login@produkcja

Jeżeli używamy uwierzytelniania opartego o klucze połączenie nastąpi automatycznie, w przeciwnym wypadku będzie trzeba podać hasła dostępu do obu serwerów.

O czym należy pamiętać:

  • jeżeli używamy uwierzytelnienia opartego o klucze, to zarówno na maszynie firewall jak i produkcja należy zainstalować klucz z naszego lokalnego systemu (inaczej niż w przypadku pierwszego sposobu)
  • sposób ten jest przezroczysty zarówno dla polecenia scp, rsync czy też innych korzystających ze standardowego klienta ssh, można bezpośrednio kopiować pliki pomiędzy systemami, serwer pośredniczący będzie obsłużony dla nas całkowicie przezroczyście

Źródła

Tags: ,