08 maja 2010 blog security ssh
Generujemy parę kluczy, eksportujemy na serwer i zrobione.
ssh-keygen -t rsa #kilka razy potwierdzamy enterem
ssh-copy-id -i ~/.ssh/id_rsa.pub uzytkownik@serwerssh #kopiowanie kluczy
Programik ssh-copy-id można zastąpić doklejeniem id_rsa.pub na koniec .ssh/authorized_keys na serwerze. Po uprzednim skopiowaniu klucza publicznego, logujemy się na serwer i:
cat klient-id_rsa.pub >> ~/.ssh/authorized_keys
Jeszcze inny sposób:
cat ~/.ssh/id_rsa.pub | ssh -p 22 uzytkownik@serwerssh 'cat >> ~/.ssh/authorized_keys'
Więcej informacji na www.debian-administration.org, help.ubuntu.com oraz jimmyg.org.
Jeśli wszystko poszło dobrze, w tym momencie dostęp do serwera powinien być możliwy bez podawania hasła.
Gdyby dostęp wciąż był niemożliwy bez podawania hasła, przyczyn może być kilka.
Naprawdę, sprawdź 2 razy konfigurację firewalla, forwardowanie portów w routerze, wpisy w /etc/hosts.allow i /etc/hosts.deny, konfigurację wszelkich filtrów w stylu iplist. Jak skończysz, sprawdź jeszcze raz. Większość błędów jest spowodowana pomyłką człowieka, więc na 80% problem jest spowodowany przez zapomnienie o którejś ze wspomnianych rzeczy.
Więcej informacji (niewiele więcej ;)) na forums.gentoo.org.
Chodzi o akceptowane sposoby łączenia się z serwerem SSH. Ja mam włączoną autoryzację hasłem (tak na wszelki wypadek) i kluczami. Odpowiadają za to następujące wpisy w /etc/ssh/sshd_config:
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
Po zmianie, należy zrestartować serwer ssh. W zależności od dystrybucji:
sudo /etc/rc.d/sshd restart
lub
sudo /etc/init.d/sshd restart
Należy się upewnić, że pliki mają nadane odpowiednie uprawnienia (na serwerze i na klientach).
chmod 700 ~/.ssh
chmod 644 ~/.ssh/*
chmod 600 ~/.ssh/id_rsa
Problem objawia się komunikatem:
debug3: no such identity: /home/dmn/.ssh/id_dsa
Należy się w pierwszej kolejności upewnić, że prawa dostępu są dobrze ustawione (patrz: punkt wyżej). Natomiast we wspomnianej wersji OpenSSH musimy wskazać położenie kluczy klientów uprawnionych do logowania bez podania hasła. Odpowiada za to następujący wpis w konfiguracji (/etc/ssh/sshd_config):
AuthorizedKeysFile %h/.ssh/authorized_keys
Magiczne "%h" mówi serwerowi ssh, żeby przeszukał katalog domowy użytkownika.
Więcej informacji na www.gossamer-threads.com.
Problem objawia się komunikatem:
Agent admitted failure to sign using the key
W tym przypadku rozwiązań jest kilka.
Ustawiamy zmienną przed połączeniem się z serwerem:
SSH_AUTH_SOCK=0 ssh uzytkownik@serwerssh
Używamy ssh-add, który powinien dodać naszą tożsamość do agenta autoryzacji:
ssh-add; ssh uzytkownik@serwerssh
Jeśli używamy gnome, prawdopodobnym sprawcą jest demon seahorse.
gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false
Więcej informacji na bugs.launchpad.net.
Problem objawia się komunikatem:
debug1: Next authentication method: publickey
debug1: Trying private key: /home/dmn/.ssh/jakasdziwnanazwa
debug3: no such identity: /home/dmn/.ssh/jakasdziwnanazwa
Rozwiązanie: podanie ścieżki do pliku id_rsa:
ssh -i ~/.ssh/id_rsa serwer
Ostatecznym rozwiązaniem, nie sprawdzonym przeze mnie, jest instalacja alternatywnego oprogramowania.
Więcej informacji na www.cybermilitia.net.
No trudno, może tak miało być... Zbierz pliki konfiguracji, listingi plików z katalogów .ssh oraz informacje debugera i udaj się z tak przygotowaną paczuszką na jakieś forum linuksowe :)
Na koniec jeszcze jak włączyć wspomniane informacje. Na serwerze (z uprawnieniami root):
`which sshd` -ddd -p 2222
Na kliencie:
ssh -vvv uzytkownik@serwerssh -p 2222