Jest to typowy przykład kompromisu między bezpieczeństwem a wygodą. Na szczęście istnieje wiele opcji. Najbardziej odpowiednie rozwiązanie zależy od scenariusza użytkowania i pożądanego poziomu bezpieczeństwa.
klucz ssh z hasłem, nie ssh-agent
Teraz hasło należy wprowadzić za każdym razem, gdy klucz jest używany do uwierzytelnienia. Chociaż jest to najlepsza opcja z punktu widzenia bezpieczeństwa, oferuje najgorszą użyteczność. Może to również prowadzić do wybierania słabego hasła w celu zmniejszenia obciążenia wielokrotnym wprowadzaniem go.
ssh-key z hasłem, z ssh-agent
Dodanie następującego polecenia ~/.bash_profile
spowoduje automatyczne uruchomienie ssh-agent
i załadowanie kluczy ssh podczas logowania:
if [ -z "$SSH_AUTH_SOCK" ] ; then
eval `ssh-agent -s`
ssh-add
fi
Teraz hasło należy wprowadzić przy każdym logowaniu. Chociaż jest to nieco lepsze z punktu widzenia użyteczności, ma tę wadę, że ssh-agent
monituje o hasło, niezależnie od tego, czy klucz ma zostać użyty, czy nie podczas sesji logowania. Każde nowe logowanie powoduje także pojawienie się odrębnej ssh-agent
instancji, która pozostaje uruchomiona z dodanymi kluczami w pamięci nawet po wylogowaniu, chyba że zostanie wyraźnie zabita.
Aby zabić ssh_agent
przy wylogowaniu, dodaj następujące elementy do~/.bash_logout
if [ -n "$SSH_AUTH_SOCK" ] ; then
eval `/usr/bin/ssh-agent -k`
fi
lub następujące do ~/.bash_profile
trap 'test -n "$SSH_AUTH_SOCK" && eval `/usr/bin/ssh-agent -k`' 0
Utworzenia wielu ssh-agent
instancji można uniknąć, tworząc trwałe gniazdo komunikacyjne z agentem w stałej lokalizacji w systemie plików, na przykład w odpowiedzi Collina Andersona . Jest to poprawa w stosunku do odradzania wielu instancji agentów, chyba że jawnie zabity odszyfrowany klucz nadal pozostaje w pamięci po wylogowaniu.
Na komputerach agenci ssh wchodzący w skład środowiska pulpitu, tacy jak agent SSH Gnome Keyring , mogą być lepszym podejściem, ponieważ zazwyczaj można je poprosić o podanie hasła przy pierwszym użyciu klucza ssh podczas sesji logowania i przechowuj odszyfrowany klucz prywatny w pamięci do końca sesji.
ssh-key z hasłem, z ssh-ident
ssh-ident
to narzędzie, które może zarządzać ssh-agent
w Twoim imieniu i ładować tożsamości w razie potrzeby. Dodaje klucze tylko raz, gdy są potrzebne, niezależnie od liczby terminali, sesji ssh lub logowania, które wymagają dostępu do ssh-agent
. Może także dodawać i używać innego agenta i innego zestawu kluczy w zależności od podłączonego hosta lub katalogu, z którego ssh jest wywoływany. Umożliwia to izolowanie kluczy podczas korzystania z przekazywania agenta na różnych hostach. Pozwala także na korzystanie z wielu kont w witrynach takich jak GitHub.
Aby włączyć ssh-ident
, zainstaluj i dodaj następujący alias do ~/bash_profile
:
alias ssh='/path/to/ssh-ident'
ssh-key z hasłem, z keychain
keychain
to małe narzędzie, które zarządza ssh-agent
w Twoim imieniu i pozwala ssh-agent
pozostać uruchomionym po zakończeniu sesji logowania. Przy kolejnych logowaniach keychain
połączy się z istniejącą ssh-agent
instancją. W praktyce oznacza to, że hasło należy wprowadzić tylko podczas pierwszego logowania po ponownym uruchomieniu. Przy kolejnych logowaniach ssh-agent
używany jest niezaszyfrowany klucz z istniejącej instancji. Może to być również przydatne do zezwalania na uwierzytelnianie RSA / DSA cron
bez hasła w zadaniach bez kluczy SSH bez hasła.
Aby włączyć keychain
, zainstaluj i dodaj coś takiego ~/.bash_profile
:
eval `keychain --agents ssh --eval id_rsa`
Z punktu widzenia bezpieczeństwa ssh-ident
i keychain
są gorsze niż ssh-agent
przypadki ograniczone do czasu trwania konkretnej sesji, ale oferują wysoki poziom wygody. Aby poprawić bezpieczeństwo keychain
, niektóre osoby dodają --clear
opcję do swojego ~/.bash_profile
wywołania pęku kluczy. W ten sposób hasła muszą zostać ponownie wprowadzone przy logowaniu, jak wyżej, ale cron
zadania nadal będą miały dostęp do niezaszyfrowanych kluczy po wylogowaniu użytkownika. Strona keychain
wiki zawiera więcej informacji i przykładów.
klucz ssh bez hasła
Z punktu widzenia bezpieczeństwa jest to najgorsza opcja, ponieważ klucz prywatny jest całkowicie niechroniony na wypadek jego ujawnienia. Jest to jednak jedyny sposób, aby upewnić się, że hasło nie musi być ponownie wprowadzone po ponownym uruchomieniu.
ssh-key z hasłem, z ssh-agent
, przekazywanie hasła do ssh-add
skryptu
Chociaż przekazywanie hasła do ssh-add
skryptu może wydawać się prostym pomysłem , na przykład echo "passphrase\n" | ssh-add
nie jest to tak proste, jak się wydaje, ponieważ ssh-add
nie odczytuje hasła stdin
, ale otwiera się /dev/tty
bezpośrednio do odczytu .
Można to obejść za expect
pomocą narzędzia do automatyzacji interaktywnych aplikacji. Poniżej znajduje się przykład skryptu, który dodaje klucz ssh przy użyciu hasła zapisanego w skrypcie:
#!/usr/bin/expect -f
spawn ssh-add /home/user/.ssh/id_rsa
expect "Enter passphrase for /home/user/.ssh/id_rsa:"
send "passphrase\n";
expect "Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)"
interact
Zwróć uwagę, że ponieważ hasło jest przechowywane w skrypcie w postaci zwykłego tekstu, z punktu widzenia bezpieczeństwa nie jest to wcale lepsze niż posiadanie klucza SSH bez hasła. Jeśli ma być zastosowane to podejście, ważne jest, aby upewnić się, że expect
skrypt zawierający hasło ma ustawione odpowiednie uprawnienia, dzięki czemu jest czytelny, zapisywalny i uruchamiany tylko przez właściciela klucza.