Dodałem publiczny klucz SSH do pliku autoryzowanych_kluczy . ssh localhost
powinien mnie zalogować bez pytania o hasło.
Zrobiłem to i próbowałem pisać ssh localhost
, ale wciąż prosi mnie o wpisanie hasła. Czy muszę wprowadzić inne ustawienie, aby działało?
Postępowałem zgodnie z instrukcjami dotyczącymi zmiany uprawnień:
Poniżej jest wynik, jeśli to zrobię ssh -v localhost
.
debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Następnie prosi o podanie hasła po powyższym logu. Dlaczego nie loguje mnie bez hasła?
ssh
public-key
authorized-keys
użytkownik482594
źródło
źródło
Odpowiedzi:
Musisz zweryfikować uprawnienia do
authorized_keys
pliku i folderu / folderów nadrzędnych, w których się on znajduje.Aby uzyskać więcej informacji, zobacz tę stronę .
Może być również konieczna zmiana / weryfikacja uprawnień do katalogu domowego, aby usunąć dostęp do zapisu dla grupy i innych osób.
źródło
chmod go-wrx foobar
. Robienie tego rekurencyjnie może poważnie uszkodzić niektóre aplikacje, jeśli masz jakiś dostęp do plików lub grupy, szczególnie jeśli jest to katalog internetowy.chmod go-w $HOME $HOME/.ssh
to załatwi sprawę). Zatem uprawnienia mogą być tak „otwarte” jak 755 dla obu katalogów, jeśli masz na to ochotę. Najprostsze / najmniej inwazyjne polecenia znajdują się w FAQ: openssh.org/faq.html#3.14chmod 700 ~/.ssh && chmod 644 ~/.ssh/authorized_keys
? 600 nie działało tam, gdzie działało 644 ...sudo chown -R {$USER}:{$USER} ~/.ssh/
ponieważ zapisałemauthorized_keys
plik jako root.SELinux może również powodować, że klucze autoryzowane nie będą działać. Zwłaszcza dla root'a w CentOS 6 i 7. Nie trzeba go jednak wyłączać. Po zweryfikowaniu swoich uprawnień możesz to naprawić w następujący sposób:
źródło
restorecon
tego potrzebujesz po ręcznym skopiowaniu plików, np. Na nowy dysk twardy. (W tym przypadku prawdopodobnie powinieneś uruchomić go na wszystkich plikach. Mógłby rozwiązać inne dziwne problemy.)ustawienie kluczy autoryzowanych ssh wydaje się proste, ale ukrywa pułapki, które próbuję wymyślić
-- SERWER --
w / etc / ssh / sshd_config ustawiono,
passwordAuthentication yes
aby serwer mógł tymczasowo akceptować uwierzytelnianie hasłem-- KLIENT --
1. generuj klucze prywatne i publiczne (po stronie klienta)
# ssh-keygen
tutaj naciskając tylko ENTER otrzymujesz DOMYŚLNE 2 pliki „ id_rsa ” i „ id_rsa.pub ” w ~ / .ssh /, ale jeśli podasz nazwę dla klucza, wygenerowane pliki zostaną zapisane w twoim pwd
2. umieść plik your_key.pub na komputerze docelowym
ssh-copy-id user_name@host_name
jeśli nie utworzyłeś domyślnego klucza, jest to pierwszy krok do popełnienia błędu ... powinieneś użyć
ssh-copy-id -i path/to/key_name.pub user_name@host_name
3. Rejestrowanie
ssh user_name@host_name
będzie działać tylko dla domyślnej id_rsa więc tutaj jest 2. pułapką dla trzebassh -i path/to/key_name user@host
(użyj opcji ssh -v ... , aby zobaczyć, co się dzieje)
Jeśli serwer nadal prosi o hasło, to dałeś coś wprowadzić hasło: po utworzeniu kluczy (więc jest to normalne)
jeśli ssh nie nasłuchuje, należy użyć portu 22
ssh -p port_nr
-- SERWER -----
4. zmodyfikuj / etc / ssh / sshd_config, aby mieć
(niewygodne, jeśli sprawa)
To każe ssh zaakceptować klucze autoryzowane i poszukać w katalogu osobistym użytkownika żądła klucza nazwa zapisanego w pliku .ssh / autoryzowane klucze
5 ustaw uprawnienia na maszynie docelowej
Wyłącz także uwierzytelnianie przy użyciu hasła
passwordAuthentication no
aby zamknąć bramę dla wszystkich prób ssh root / admin /....@ twoja_domena
6 upewnij się, że własność i własność grupy wszystkich katalogów domowych innych niż root są odpowiednie.
===============================================
7. rozważ doskonałą stronę http://www.fail2ban.org
8. dodatkowy tunel ssh, aby uzyskać dostęp do serwera MySQL (bind = 127.0.0.1)
źródło
ssh-copy-id
! Sam ten krok byłby świetną odpowiedzią.Upewnij się także, że Twój katalog domowy nie jest zapisywany przez innych
Odpowiedź została skradziona stąd
źródło
chmod 700 ~/.ssh ; chmod 600 ~/.ssh/authorized_keys ; chmod g-w,o-w ~
działało dla mnie. Dzięki.chmod og-w /home/USERNAME
zamiast tego?zdesperowani mogą również upewnić się, że nie mają dodatkowych znaków nowej linii w pliku autoryzowanych kluczy, ze względu na kopiowanie tekstu id_rsa.pub z pomylonego terminala.
źródło
id_rsa.pub
używaniamore
zamiastcat
, co było fatalne z powodu niewidzialnych przełamań linii.użytkownik to twoja nazwa użytkownika
źródło
mkdir -p /home/$USER/.ssh && chown -R $USER:$USER /home/$USER/.ssh && sudo -u $USER ssh-keygen -t rsa && touch /home/$USER/.ssh/authorized_keys && touch /home/$USER/.ssh/known_hosts && chmod 700 /home/$USER/.ssh && chmod 600 /home/$USER/.ssh/id* && chmod 644 /home/$USER/.ssh/id*.pub && chmod 644 /home/$USER/.ssh/authorized_keys && chmod 644 /home/$USER/.ssh/known_hosts && vim /home/$USER/.ssh/authorized_keys # paste keys here!
Uważaj, że SELinux może również wywołać ten błąd, nawet jeśli wszystkie uprawnienia wydają się być w porządku. Wyłączenie to załatwiło sprawę (wstaw zwykłe zastrzeżenia dotyczące wyłączania).
źródło
/var/log/audit/audit.log
.restorecon -R -v /root/.ssh
naprawiono mój konkretny przypadek.Umieszczenie klucza publicznego w .ssh / uprawnionych_kluczy jest konieczne, ale niewystarczające, aby sshd (serwer) mógł go zaakceptować. Jeśli twój klucz prywatny jest chroniony hasłem, musisz za każdym razem podawać hasło ssh (klientowi). Możesz też użyć ssh-agent lub odpowiednika GNOME.
Twój zaktualizowany przebieg jest zgodny z kluczem prywatnym hasło chronione. Zobacz ssh-agent lub użyj
ssh-keygen -p
.źródło
Napisz polecenie:
Po wykonaniu tej czynności upewnij się, że twój katalog jest taki:
źródło
W końcu udało mi się upewnić, że właściciel / grupa nie jest rootem, ale użytkownikiem:
źródło
Spróbuj „ssh-add”, który działał dla mnie.
źródło
Kolejna wskazówka do zapamiętania. Od wersji 7.0 OpenSSH domyślnie wyłącza klucze ssh DSS / DSA ze względu na ich słabość dziedziczenia. Więc jeśli masz OpenSSH v7.0 +, upewnij się, że twój klucz nie jest
ssh-dss
.źródło
W moim przypadku musiałem umieścić mój
authorized_keys
plik.openssh
.Ta lokalizacja jest określona w
/etc/ssh/sshd_config
opcjiAuthorizedKeysFile %h/.ssh/authorized_keys
.źródło
Upewnij się, że użytkownik docelowy ma ustawione hasło. Uruchom,
passwd username
aby ustawić jeden. Było to dla mnie wymagane, nawet jeśli hasło SSH było wyłączone.źródło
to rozwiązuje mój problem
źródło
Kolejna kwestia, którą musisz się zająć. Jeśli wygenerowany plik nie jest domyślny
id_rsa
iid_rsa.pub
Musisz utworzyć plik .ssh / config i ręcznie określić, który plik id będzie używany z połączeniem.
Przykład jest tutaj:
źródło
I wydał
sudo chmod 700 ~/.ssh
ichmod 600 ~/.ssh/authorized_keys
ichmod go-w $HOME $HOME/.ssh
od góry i to naprawić mój problem na polu CentOS7 że miałem pomieszane uprawnienia na starając się dostać samba akcja działa. Dziękiźródło
Wydaje się, że to problem z pozwoleniem. Zwykle dzieje się tak, jeśli uprawnienia do niektórych plików / katalogów nie są poprawnie skonfigurowane. W większości przypadków są
~/.ssh
i~/.ssh/*
. W moim przypadku są/home/xxx
.Możesz zmienić poziom dziennika sshd, modyfikując
/etc/ssh/sshd_config
(wyszukajLogLevel
, ustaw naDEBUG
), a następnie sprawdź dane wyjściowe,/var/log/auth.log
aby zobaczyć, co dokładnie się wydarzyło.źródło
Moim problemem był zmodyfikowany plik AuthorizedKeysFile, gdy nie uruchomiono jeszcze automatyzacji wypełniania / etc / ssh / author_keys.
źródło
Wystarczy spojrzeć na /var/log/auth.log na serwerze . Ustawienie dodatkowej gadatliwości za pomocą opcji -vv po stronie klienta nie pomoże, ponieważ serwer prawdopodobnie nie oferuje zbyt dużej ilości informacji potencjalnemu napastnikowi.
źródło
Upewnij się, że skopiowałeś cały klucz publiczny
authorized_keys
;ssh rsa
prefiks jest konieczne dla kluczem do pracy.źródło
musisz zweryfikować właściwości plików. aby przypisać wymagane użycie nieruchomości:
źródło
Spójrz
/var/log/auth.log
na serwerze pod kątemsshd
błędów uwierzytelniania.Jeśli wszystko inne zawiedzie, uruchom
sshd
serwer w trybie debugowania:Następnie połącz się z klientem:
W moim przypadku znalazłem sekcję dotyczącą błędów na końcu:
Dzięki tym informacjom zdałem sobie sprawę, że
sshd_config
ograniczałem logowanie do członkówssh
grupy. Następujące polecenie naprawiło ten błąd uprawnień:źródło
w tej notatce upewnij się, że konfiguracja sshd ma -;
ustaw powyżej, a następnie uruchom ponownie sshd (/etc/init.d/sshd restart)
wyloguj się i spróbuj zalogować się ponownie!
domyślnie uważam, że -;
źródło
W moim przypadku jest to spowodowane tym, że grupa użytkowników nie jest ustawiona w AllowGroups pliku konfiguracyjnego / etc / ssh / sshd_config. Po dodaniu wszystko działa dobrze.
źródło
Mam katalog domowy w niestandardowej lokalizacji, aw
sshd
logach mam ten wiersz:nawet jeśli wszystkie uprawnienia były w porządku (zobacz pozostałe odpowiedzi).
Znalazłem rozwiązanie tutaj: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191
W moim szczególnym przypadku:
dodano nową linię w
/etc/selinux/targeted/contexts/files/file_contexts.homedirs
:to jest oryginalna linia zwykłych katalogów domowych:
/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
to moja nowa linia:
/data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0
następnie a
restorecon -r /data/
isshd
restartźródło
Miałem ten problem i żadna z pozostałych odpowiedzi go nie rozwiązała, choć oczywiście pozostałe odpowiedzi są poprawne.
W moim przypadku okazało się, że
/root
sam katalog (nie np./root/.ssh
) Miał złe uprawnienia. Potrzebowałem:Oczywiście te uprawnienia powinny być czymś takim (może
chmod 770
) niezależnie. Jednak to specjalnie zapobiegasshd
od pracy, choć/root/.ssh
i/root/.ssh/authorized_keys
obaj mieli odpowiednie uprawnienia i właścicieli.źródło
Miałem ten problem, gdy dodałem grupę użytkownika logowania do innego użytkownika. Załóżmy, że istnieje użytkownik ssh-login o nazwie userA i użytkownik nie-ssh-login userB. użytkownik A ma również grupę użytkownik A. Zmodyfikowałem użytkownika B, aby mieć również użytkownika grupy A. Prowadzi do opisanego zachowania, aby użytkownik A nie mógł zalogować się bez monitu. Po usunięciu grupy userA z userB logowanie bez monitowania zadziałało ponownie.
źródło