Dodanie klucza publicznego do~/.ssh / autoryzowane klucze nie logują mnie automatycznie

SELinux może również spowodować, że authorized_keys nie będzie działać. Szczególnie dla korzeni w CentOS 6 i 7. Nie trzeba go jednak wyłączać. Po zweryfikowaniu poprawności uprawnień możesz to naprawić w następujący sposób:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

Ustawienie SSH authorized_keys wydaje się być proste, ale ukrywa pewne pułapki, które próbuję wymyślić

-- Serwer --

W / etc / ssh / sshd_config ustaw passwordAuthentication yes, aby serwer tymczasowo akceptował uwierzytelnianie hasłem

-- klient --

Rozważ cygwin jako emulację Linuksa i zainstaluj i uruchom openssh

1. generowanie kluczy prywatnych i publicznych (po stronie klienta) # ssh-keygen

Tutaj wciskając po prostu ENTER dostajesz DEFAULT 2 pliki " id_rsa" i " id_rsa.pub" in ~/.ssh / ale jeśli podasz name_for_the_key wygenerowane pliki zostaną zapisane w twoim pwd

2. umieść your_key.pub to target machine ssh-copy-id user_name@host_name

Jeśli nie utworzyłeś domyślnego klucza, jest to pierwszy krok do błędu ... należy użyć

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. logowanie ssh user_name@host_name będzie działać tylko dla default id_rsa więc tutaj jest 2nd trap for you need to ssh -i path/to/key_name user@host

(użyj ssh-v ... opcja, aby zobaczyć, co się dzieje)

Jeśli serwer nadal pyta o hasło to podałeś smth. aby wpisać hasło: Po utworzeniu kluczy (więc jest to normalne)

Jeśli ssh nie nasłuchuje domyślny port 22 musi użyć ssh -p port_nr

-- Serwer - - - - - -

4. modify / etc / ssh / sshd_config to have

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(uncoment if case)

To mówi ssh aby zaakceptował authorized_keys i poszukał w katalogu domowym użytkownika wpisanego Stinga .plik SSH / authorized_keys

5 set permissions in target machine

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Wyłącz również pass auth

passwordAuthentication no

Aby zamknąć bramę do wszystkich SSH root / admin/....@ your_domain

6 upewnij się, że własność i własność grupowa wszystkich nie-rootowych katalogów domowych są odpowiednie.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user 

===============================================

7. rozważ doskonały http://www.fail2ban.org

8. extra ssh TUNNEL Aby uzyskać dostęp do MySQL (bind = 127.0.0.1) sever

Upewnij się również, że twój katalog domowy nie jest zapisywalny przez innych

chmod g-w,o-w /home/USERNAME

Odpowiedź jest skradziona z tutaj

Wypisanie klucza publicznego w .ssh / authorized_keys jest konieczne, ale nie wystarczające, aby SSHD (serwer) go zaakceptował. Jeśli twój klucz prywatny jest chroniony hasłem, musisz za każdym razem podawać hasło ssh (klient). Możesz też użyć ssh-agent lub odpowiednika gnome.

Twój ślad aktualizacji jest zgodny z kluczem prywatnym chronionym hasłem. Zobacz ssh-agent lub ssh-keygen-p.

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 zrobił sztuczkę dla mnie(Wstaw zwykłe zastrzeżenia o wyłączeniu go).

Desperaci mogą również upewnić się, że nie mają dodatkowych nowych linii w pliku authorized_keys ze względu na skopiowanie id_rsa.pub SMS z zagubionego terminala.

Użytkownik to Twoja nazwa użytkownika

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
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

W końcu udało mi się upewnić, że właściciel/Grupa to nie root, ale użytkownik:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

Spróbuj "SSH-add", które zadziałało dla mnie.

Polecenie zapisu:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Po tym, upewnij się, że Twój dir jest taki:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

Kolejna wskazówka do zapamiętania. Od wersji 7.0 OpenSSH domyślnie wyłącza DSS/DSA klucze ssh ze względu na ich dziedziczenie. Więc jeśli masz OpenSSH v7.0+, upewnij się, że twój klucz nie jest ssh-dss.

Jeśli utkniesz z kluczami DSA, możesz ponownie włączyć obsługę lokalnie przez Aktualizacja plików sshd_config i ~/.ssh/config za pomocą linii: PubkeyAcceptedKeyTypes=+ssh-dss

Upewnij się, że użytkownik docelowy ma ustawione hasło. Uruchom passwd username, aby ustawić pierwszy. Było to wymagane dla mnie, nawet jeśli hasło logowanie SSH było wyłączone.

Kolejna sprawa, na którą musisz się zająć. Jeśli wygenerowany plik nie jest domyślny id_rsa i id_rsa.pub

Przykład jest tutaj:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

W moim przypadku musiałem umieścić plik authorized_keys w .openssh.

Ta lokalizacja jest określona w {[2] } w opcji AuthorizedKeysFile %h/.ssh/authorized_keys.

Wydałem sudo chmod 700 ~/.ssh i chmod 600 ~/.ssh/authorized_keys i chmod go-w $HOME $HOME/.ssh z góry i to naprawiło mój problem na pudełku CentOS7, na którym pomieszałem uprawnienia podczas próby uruchomienia akcji samby. Dzięki

Wygląda na problem z pozwoleniem. Zwykle dzieje się tak, gdy uprawnienia jakiegoś pliku / katalogu nie są prawidłowo ustawione. W większości przypadków są to ~/.ssh i ~/.ssh/*. W moim przypadku są /home/xxx.

Możesz zmienić poziom dziennika sshd modyfikując /etc/ssh/sshd_config(wyszukaj LogLevel, ustaw go na DEBUG), a następnie sprawdź wyjście w /var/log/auth.log, aby zobaczyć, co dokładnie się stało.

To rozwiązuje mój problem

Ssh - agent bash

Ssh-dodaj

Upewnij się, że skopiowałeś cały klucz publiczny do authorized_keys; prefiks ssh rsa jest niezbędny do działania klucza.

Musisz zweryfikować właściwości plików. aby przypisać wymaganą właściwość użyj:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

Upewnij się, że konfiguracja sshd ma -;

PermitRootLogin without-password

Ustaw jak wyżej, a następnie uruchom ponownie sshd (/etc / init.d / SSHD restart)

Wyloguj się i spróbuj zalogować się ponownie!

Default I believe is -;

PermitRootLogin no

W moim przypadku jest to spowodowane tym, że grupa użytkownika nie jest ustawiona w AllowGroups pliku konfiguracyjnego/etc/ssh / sshd_config. Po dodaniu wszystko działa dobrze.

Moim problemem był zmodyfikowany AuthorizedKeysFile, gdy automatyzacja wypełniania /etc/ssh / authorized_keys nie została jeszcze uruchomiona.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Mam katalog domowy w niestandardowej lokalizacji i w sshd logach mam taką linię:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

Nawet jeśli wszystkie uprawnienia były w porządku (zobacz inne odpowiedzi).

Znalazłem rozwiązanie tutaj: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

W moim konkretnym przypadku:

• Dodano nowy wiersz w /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

  • To jest oryginalna linia do zwykłego domu katalogi:

    /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/ I a sshd restart

Wystarczy spojrzeć na / var / log / auth.log na serwerze . Ustawienie dodatkowej szczegółowości za pomocą - vv Po stronie klienta nie pomoże, ponieważ serwer prawdopodobnie nie zaoferuje zbyt wielu informacji potencjalnemu atakującemu.

Miałem ten problem i żadna z innych odpowiedzi go nie rozwiązała, chociaż oczywiście inne odpowiedzi są poprawne.

W moim przypadku okazało się, że sam katalog /root (nie np. /root/.ssh) miał złe uprawnienia. Potrzebowałem:

chown root.root /root
chmod 700 /root

Oczywiście te uprawnienia powinny być czymś takim (Może chmod 770) niezależnie od tego. Jednak w szczególności uniemożliwiło to działanie sshd, mimo że zarówno /root/.ssh, jak i /root/.ssh/authorized_keys miały poprawne uprawnienia i właścicieli.