Czy moje hasło zostało naruszone, ponieważ zapomniałem nacisnąć Enter po nazwie użytkownika ssh?

Właśnie próbowałem zalogować się do serwera Fedora (wydanie 13 Goddard) przy użyciu SSH (PuTTY, Windows). Z jakiegoś powodu Enterpo wpisaniu mojej nazwy użytkownika nie udało się przejść, wpisałem hasło i ponownie wcisnąłem Enter. Zdałem sobie sprawę z mojego błędu, kiedy kelner przywitał mnie z zadowoleniem

myusername MYPASSWORD @ server.example.com hasło:

W tym momencie zerwałem połączenie i zmieniłem hasło na tym komputerze (przez osobne połączenie SSH).

... teraz moje pytanie brzmi: czy takie nieudane logowanie jest przechowywane w postaci zwykłego tekstu w jakimkolwiek pliku dziennika? Innymi słowy, czy właśnie wymusiłem moje (teraz nieaktualne) hasło przed oczami zdalnego administratora, kiedy następnym razem skanuje swoje dzienniki?

Aktualizacja

Dziękujemy za wszystkie komentarze dotyczące dorozumianego pytania „co zrobić, aby temu zapobiec w przyszłości”. Do szybkich, jednorazowych połączeń użyję teraz tej funkcji PuTTY:

aby zastąpić opcję „automatycznie loguj się na nazwę użytkownika”

Zacznę też częściej używać kluczy ssh, jak wyjaśniono w dokumentach PuTTY .

W skrócie: tak.

# ssh 192.168.1.1 -l "myuser mypassword"
^C
# egrep "mypassword" /var/log/auth.log
Oct 19 14:33:58 host sshd[19787]: Invalid user myuser mypassword from 192.168.111.78
Oct 19 14:33:58 host sshd[19787]: Failed none for invalid user myuser mypassword from 192.168.111.78 port 53030 ssh2

Jeśli dobrze pamiętam, to rzeczywiście jest rejestrowany w dzienniku, jeśli poziom dziennika jest ustawiony na DEBUG lub TRACE.

EDYCJA: Potwierdzono, próbowałem zalogować się na mój serwer i znalazłem to w moich logach.

Oct 19 14:34:24 sd-xxxx sshd[26563]: pam_unix(sshd:auth): authentication failure; logname=     uid=0 euid=0 tty=ssh ruser= rhost=xxx-xxx-xxx-xxx.rev.numericable.fr 
Oct 19 14:34:26 sd-xxxx sshd[26563]: Failed password for invalid user toto from xxx.xxx.xxx.xxx port 56685 ssh2

Uwaga: adresy IP są ukryte

Lub ze względu na dodatkowe bezpieczeństwo i wygodę, naprawdę powinieneś rozważyć skonfigurowanie kluczy SSH ...

# ssh-keyget -t rsa
(zaakceptuj wszystkie wartości domyślne)

i dostajesz ...

~ / .ssh / id_rsa
~ / .ssh / id_rsa.pub

Uwaga dodatkowa: możesz zmienić nazwę plików kluczy, jeśli dodasz ~ / .ssh / config z czymś w rodzaju następującej treści:

# cat ~ / .ssh / config
Gospodarz *
IdentityFile ~ / .ssh / ddopson_employer_id_rsa

Cat zawartość klucza publicznego (będzie pojedynczą linią):

# cat ~ / .ssh / id_dsa.pub
ssh-rsa AAAAB3NzaC1kc3MAAACBAOOVBqYHAMQ8J ... BbCGGaeBpcqlALYvA == ddopson @ nazwa hosta

Teraz zaloguj się do pola docelowego i wklej ten wiersz do ~ / .ssh /

Uwaga dodatkowa: linia klucza pubkey kończy się ciągiem czytelnym dla człowieka, takim jak „ddopson @ nazwa hosta”. Możesz to zmienić, aby bardziej opisywać klucz, którego używasz (np. Jeśli masz dużo kluczy). Ten ciąg NIE jest używany jako część uwierzytelnienia i służy jedynie do opisania klucza do innych ludzi.

Otóż ​​to. Teraz, gdy łączysz się z hostem, nie będziesz nawet proszony o podanie hasła.

Jeśli martwisz się o przechowywanie swojego klucza prywatnego (id_rsa), możesz dodać hasło do samego klucza (patrz ssh-keygen), chroniąc go przed użyciem przez każdego, kto ma dostęp do twoich plików. Następnie można użyć ssh-agent do odszyfrowania klucza i bezpiecznego przechowywania go w pamięci, aby można go było używać do wielu połączeń SSH.

Hasło zostało zaszyfrowane podczas przesyłania. Tak, możliwe, że hasło zostało naruszone, ponieważ zostało wydrukowane w dzienniku na serwerze docelowym. Jednak powiedziałbym również, że za każdym razem, gdy wpiszesz hasło na komputerze, może to zostać naruszone, ponieważ na twoim komputerze może znajdować się oprogramowanie szpiegujące lub keylogger podłączony do komputera.

Jeśli jesteś jedynym administratorem tego systemu i uważasz, że ten system nie został naruszony, możesz z względną pewnością założyć, że twoje hasło nie zostało naruszone, tak jak zwykle zakładasz, że na twoim komputerze nie ma programów szpiegujących, ponieważ nie masz był świadkiem czegoś podejrzanego. Możesz edytować dziennik na tym serwerze i usunąć odniesienie do hasła.

Ten incydent jest jednym z powodów, dla których lepsze jest używanie kluczy SSH zamiast haseł. Wtedy nawet jeśli ktoś dostanie hasło, które podasz na twoim komputerze, aby odszyfrować klucz prywatny na twoim komputerze, nadal nie będzie mógł uzyskać dostępu do zdalnego serwera; potrzebują również samego pliku klucza prywatnego. Bezpieczeństwo polega na warstwach. Nic nie jest idealne, ale jeśli dodasz wystarczającą liczbę warstw, jest to na tyle trudne, że atakujący po prostu ruszy dalej lub złapiesz je, ponieważ zajmuje to więcej czasu.

Nie zrobiłbym powyższego, jeśli twoje hasło chroni bardzo wrażliwe informacje lub krytyczne zasoby. To zależy od wrażliwości twojego hasła.