Dodanie klucza publicznego do ~ / .ssh / author_keys nie loguje mnie automatycznie

Dodałem publiczny klucz SSH do pliku autoryzowanych_kluczy . ssh localhostpowinien 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?

Musisz zweryfikować uprawnienia do authorized_keyspliku i folderu / folderów nadrzędnych, w których się on znajduje.

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

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.

chmod go-w ~

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:

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

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 yesaby serwer mógł tymczasowo akceptować uwierzytelnianie hasłem

-- KLIENT --

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

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 docelowymssh-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_namebę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ć

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

(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

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

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.

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

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

7. rozważ doskonałą stronę http://www.fail2ban.org

8. dodatkowy tunel ssh, aby uzyskać dostęp do serwera MySQL (bind = 127.0.0.1)

Upewnij się także, że Twój katalog domowy nie jest zapisywany przez innych

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

Odpowiedź została skradziona stąd

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.

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

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).

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.

Napisz polecenie:

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

Po wykonaniu tej czynności upewnij się, że twój katalog 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

W końcu udało mi się upewnić, że właściciel / grupa nie jest rootem, ale użytkownikiem:

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

Spróbuj „ssh-add”, który działał dla mnie.

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.

Jeśli utkniesz z kluczami DSA, możesz ponownie włączyć obsługę lokalnie, aktualizując pliki sshd_configi ~/.ssh/configza pomocą takich linii:PubkeyAcceptedKeyTypes=+ssh-dss

W moim przypadku musiałem umieścić mój authorized_keysplik .openssh.

Ta lokalizacja jest określona w /etc/ssh/sshd_configopcji AuthorizedKeysFile %h/.ssh/authorized_keys.

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

to rozwiązuje mój problem

ssh-agent bash

ssh-add

Kolejna kwestia, którą musisz się zająć. Jeśli wygenerowany plik nie jest domyślny id_rsa i id_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:

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

I wydał sudo chmod 700 ~/.sshi chmod 600 ~/.ssh/authorized_keysi chmod go-w $HOME $HOME/.sshod 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

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ą ~/.sshi ~/.ssh/*. W moim przypadku są /home/xxx.

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

Moim problemem był zmodyfikowany plik AuthorizedKeysFile, gdy nie uruchomiono jeszcze automatyzacji wypełniania / etc / ssh / author_keys.

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

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.

Upewnij się, że skopiowałeś cały klucz publiczny authorized_keys; ssh rsaprefiks jest konieczne dla kluczem do pracy.

musisz zweryfikować właściwości plików. aby przypisać wymagane użycie nieruchomości:

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

Spójrz /var/log/auth.logna serwerze pod kątem sshdbłędów uwierzytelniania.

Jeśli wszystko inne zawiedzie, uruchom sshdserwer w trybie debugowania:

sudo /usr/sbin/sshd -ddd -p 2200

Następnie połącz się z klientem:

ssh user@host -p 2200

W moim przypadku znalazłem sekcję dotyczącą błędów na końcu:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

Dzięki tym informacjom zdałem sobie sprawę, że sshd_configograniczałem logowanie do członków sshgrupy. Następujące polecenie naprawiło ten błąd uprawnień:

sudo usermod -a -G ssh NEW_USER

w tej notatce upewnij się, że konfiguracja sshd ma -;

PermitRootLogin without-password

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 -;

PermitRootLogin no

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.

Mam katalog domowy w niestandardowej lokalizacji, aw sshdlogach mam ten wiersz:

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

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/i sshdrestart

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 /rootsam katalog (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. Jednak to specjalnie zapobiega sshdod pracy, choć /root/.sshi /root/.ssh/authorized_keysobaj mieli odpowiednie uprawnienia i właścicieli.

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.