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_profilespowoduje automatyczne uruchomienie ssh-agenti 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-agentmonituje 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-agentinstancji, która pozostaje uruchomiona z dodanymi kluczami w pamięci nawet po wylogowaniu, chyba że zostanie wyraźnie zabita.
Aby zabić ssh_agentprzy 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-agentinstancji 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-identto narzędzie, które może zarządzać ssh-agentw 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
keychainto małe narzędzie, które zarządza ssh-agentw Twoim imieniu i pozwala ssh-agentpozostać uruchomionym po zakończeniu sesji logowania. Przy kolejnych logowaniach keychainpołączy się z istniejącą ssh-agentinstancją. W praktyce oznacza to, że hasło należy wprowadzić tylko podczas pierwszego logowania po ponownym uruchomieniu. Przy kolejnych logowaniach ssh-agentużywany jest niezaszyfrowany klucz z istniejącej instancji. Może to być również przydatne do zezwalania na uwierzytelnianie RSA / DSA cronbez 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-identi keychainsą gorsze niż ssh-agentprzypadki ograniczone do czasu trwania konkretnej sesji, ale oferują wysoki poziom wygody. Aby poprawić bezpieczeństwo keychain, niektóre osoby dodają --clearopcję do swojego ~/.bash_profilewywołania pęku kluczy. W ten sposób hasła muszą zostać ponownie wprowadzone przy logowaniu, jak wyżej, ale cronzadania 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-addskryptu może wydawać się prostym pomysłem , na przykład echo "passphrase\n" | ssh-addnie jest to tak proste, jak się wydaje, ponieważ ssh-add nie odczytuje hasła stdin, ale otwiera się /dev/ttybezpośrednio do odczytu .
Można to obejść za expectpomocą 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 expectskrypt zawierający hasło ma ustawione odpowiednie uprawnienia, dzięki czemu jest czytelny, zapisywalny i uruchamiany tylko przez właściciela klucza.