Próbuję ssh na serwerze CentOS, nad którym nie mam kontroli. Administrator dodał mój klucz publiczny do serwera i nalega, że wina leży po mojej stronie, ale nie mogę zrozumieć, co jest nie tak.
Konfiguracja w .ssh:
tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa
Zezwolenie na moje pliki kluczy:
tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim 746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub
Dziennik połączeń, którego nie rozumiem:
tim@tim-UX31A:~$ ssh -vvv [email protected]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key:
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
ssh [email protected]
jak dziennik wspomina o Kerberos, serwer CentOS może być zintegrowany z domeną (AD, IPA, ...). Musisz dowiedzieć się, z którego użytkownika powinieneś korzystać. Zapytaj administratora. Na przykład używamy IPA, więc umożliwiamy użytkownikom łączenie się z niektórymi serwerami za pomocą konta domeny IPA i pary kluczy, a jeśli to konieczne, mogą sudo. Brak dostępu do katalogu głównego :)Odpowiedzi:
Zwykle rozwiązuje to większość problemów związanych z uprawnieniami klucza SSH po stronie serwera , zakładając, że ktoś nie wprowadził dodatkowych zmian w uprawnieniach.
Jeśli administrator utworzył plik .ssh / lub .ssh / Author_keys jako root (co najczęściej jest realizowane w ten sposób), to posiadanie pliku przez innego użytkownika (nawet jeśli root!) Jest niedozwolone.
Userify (zastrzeżenie: współzałożyciel) automatycznie robi to dokładnie w ten sam sposób. Https://github.com/userify/shim/blob/master/shim.py#L285
źródło
sudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -R
co pozwoli zaoszczędzić czas na pisanie, ale dla początkującego może być trudniejszeMiałem dokładnie ten sam problem na dwóch serwerach: Linuksie z uruchomionym Debianem stretch i na NAS (Synology DS715)
okazało się, że w obu przypadkach uprawnienia do katalogu domowego na serwerze były nieprawidłowe
auth.log na serwerze był bardzo pomocny
w Linuksie miał bit zapisu / grupy na (drwxrwxr - x), więc musiałem usunąć przynajmniej zapis na grupie (chmod gw ~ /), a potem zadziałało
na Synology, z jakiegokolwiek powodu, było trochę kleju
Musiałem to zmienić
i mógłbym wtedy połączyć się bez hasła
źródło
chmod -t
... Skończyłem z:admin@SYN:~$ ls -ald . .ssh .ssh/* drwxr-xr-x 6 admin users 4096 Jan 10 15:54 . drwx------ 2 admin users 4096 Jan 10 15:54 .ssh -rwx------ 1 admin users 401 Jan 10 15:54 .ssh/authorized_keys -rw------- 1 admin users 1679 Jan 10 15:49 .ssh/id_rsa -rwxr--r-- 1 admin users 396 Jan 10 15:49 .ssh/id_rsa.pub -rwx------ 1 admin users 396 Jan 10 10:04 .ssh/known_hosts
Korzystając z CentOS 7, jestem przekonany, że dotyczy to także innych systemów operacyjnych Linux korzystających z sshd. Dzięki prawom dostępu root możesz dowiedzieć się więcej o tym, dlaczego uwierzytelnianie może nie powieść się. Aby to zrobić:
vi /etc/ssh/sshd_config
SyslogFacility AUTH LogLevel INFO
systemctl restart sshd
tail -l /var/log/messages
Na przykład miałem takie same problemy jak wspomniano powyżej.
Wykonując te czynności udało mi się potwierdzić, że problem dotyczy uprawnień do pliku uprawniony do kluczy. Ustawiając chmod na 644 w pliku autoryzowanych kluczy mojego użytkownika, problem został naprawiony.
źródło
Wygląda na to, że uprawnienia do Twojego
.ssh
folderu nie zostały poprawnie skopiowane i wklejone. Czy możesz dodać go ponownie?Jeśli włączony jest tryb ścisły, musimy upewnić się, że
.ssh
ma odpowiednie uprawnienia:.ssh/
powinien mieć perms0700/rwx------
.ssh/*.pub
pliki powinny być644/rw-r--r--
.ssh/*
(inne pliki w .ssh)0600/rw-------
Jak wyglądają twoje sprawy pod względem uprawnień?
źródło
Na wypadek, gdyby ktoś natknął się na tę odpowiedź - żadne z zaleceń nie zadziałało w moim scenariuszu. Ostatecznie problem polegał na tym, że utworzyłem konto bez ustawionego hasła. Kiedyś ustawiłem hasło za pomocą,
usermod -p "my password" username
a następnie siłą odblokowałem konto,usermod -U username
wszystko było brzoskwiniowe.źródło
Miałem podobny problem , w którym połączenie ssh próbuje klucz
~/.ssh/id_rsa
przed nieoczekiwanym zatrzymaniem:W moim przypadku było to spowodowane starym plikiem klucza publicznego leżącym w
.ssh
katalogu:Przeniesienie / usunięcie
id_rsa.pub
z.ssh
katalogu rozwiązało problem.Z tego, co rozumiem: kiedy klucz publiczny jest obecny po stronie klienta, SSH 1st sprawdza klucz prywatny względem niego. Jeśli się nie powiedzie, nie będzie próbował użyć klucza prywatnego do zdalnego połączenia.
Wysłałem wiadomość e-mail na listę mailingową openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .
źródło
openssh-8.0p1-5.fc30.x86_64
btw. Miałem klucz publiczny z wcześniejszego serwera o tej samej nazwie co nowy, leżący w pobliżufedora@(baloo).sshkey.pub
, który jestfedora@(baloo).sshkey
przekazywany w wierszu poleceń z-i
opcją. Uwierzytelnianie nie powiodło się, gdy nowy klucz serwera został znaleziony w nowymfedora@(baloo).sshkey
- klucz RSA.Napotkaliśmy ten problem. Uprawnienia i prawa własności do plików .ssh były prawidłowe. W / var / log / messages znaleźliśmy:
SO, rozwiązaniem dla programistów vm, w którym nie dbamy o bezpieczeństwo, jest wyłączenie selinux. Edytuj / etc / sysconfig / selinux i zmień SELINUX = wyłączony i uruchom ponownie.
źródło
Na wszelki wypadek to też kogoś ratuje. Próbowałem skopiować klucz z mojej maszyny Ubuntu 18.04 na 2 serwery CentOS 7. Kiedyś
ssh-copy-id
je przenosiłem. Jeden działał, drugi nie. Przeszedłem więc debugowanie wszystkich uprawnień i nic nie znalazłem. W końcu podciągnąłem plik/etc/ssh/sshd_config
na obu serwerach i przeszedłem przez nie linia po linii. W końcu znalazłem, prawdopodobnie coś, co ktoś zmodyfikował na długo przed tym, jak dostałem pracę.Jeden odczyt:
AuthorizedKeysFile .ssh/authorized_keys
I kolejny odczyt:
AuthorizedKeysFile ~/.ssh/authorized_keys
który był na serwerze, który nie akceptował moich kluczy. Oczywiście patrząc między dwoma plikami i zauważając komentarz, który stwierdza, że domyślne wzorce wyszukiwania nie obejmują wiodącego~/
, usunąłem go i ponownie uruchomiłem sshd. Problem rozwiązany.źródło
Napotkałem również ten problem. Wydaje się, że setroubleshoot nie działa w moim środowisku, więc nie ma takiego zapisu w / var / log / messages. Wyłączenie SELinux nie było dla mnie opcją, więc zrobiłem to
Po tym logowanie za pomocą klucza rsa działało poprawnie.
źródło
Powodem w moim przypadku była niestandardowo ustawiona opcja
AuthorizedKeysFile
w pliku/etc/ssh/sshd_config
. Został ustawiony na/home/webmaster/.ssh/authorized_keys
katalog domowy dir ( ) innego użytkownika , więc użytkownik, którego próbowałem się zalogować, nie miał dostępu do tego pliku / katalogu.Po zmianie i ponownym uruchomieniu ssh-server (
service ssh restart
) wszystko wróciło do normy. Mogę teraz zalogować się przy użyciu mojego klucza prywatnego.źródło
W naszym przypadku problemy związane były z tym, że nasza zapora i reguły NATing nie zostały poprawnie skonfigurowane.
port 22, był kierowany do niepoprawnego serwera, na którym nasze klucze i użytkownik nie byli rozpoznawani.
Jeśli ktoś dojdzie do tego punktu. tcpdump i telnet mogą być twoimi przyjaciółmi
Zauważysz, że te dwa serwery mają różne wersje openssh. To pomogło mi dość szybko wykryć problem. Jeśli twoje hosty używają tych samych wersji ssh, będziesz musiał wykonać spakowane śledzenie w miejscu docelowym, aby sprawdzić, czy ruch faktycznie dociera do miejsca docelowego.
Ssh może generować duży ruch, co sprawia, że tcpdump trudno znaleźć to, czego szukasz.
To mi pomogło
Spróbuj telnet z 3 innego serwera niż twój obecny komputer @ [mylocalip]. Chcesz zobaczyć, jaki ruch faktycznie dociera do twojego serwera.
źródło
Dziennik błędów po stronie klienta kończy się tak:
może być spowodowane ograniczeniem logowania użytkownika root po stronie serwera, gdy plik konfiguracyjny sshd zawiera:
Sugestia JonCav, aby włączyć rejestrowanie, była pomocna w debugowaniu takiego problemu. Podczas gdy spew debugowania po stronie klienta był wyjątkowo nieprzydatny, umieszczenie następujących elementów w pliku sshd_config serwera sshd :
skończyło się na tworzeniu pomocnych komunikatów w dzienniku:
W przypadku, gdy tylko logowanie do katalogu głównego kończy się niepowodzeniem i pod warunkiem, że stosowanie tylko uwierzytelniania opartego na kluczach do logowania do konta root jest dozwolone przez zasady bezpieczeństwa, zmiana pliku sshd_config może pomóc:
Twój przebieg może się różnić, choć często to pomaga, niektóre inne konfiguracje mogą nadal zakłócać zgodnie z komentarzem znalezionym w niektórych plikach sshd_config :
Nawet jeśli nie można łatwo zmienić konfiguracji zdalnego serwera w celu debugowania w ten sposób, można do pewnego stopnia sprawdzić konfigurację po stronie klienta, używając tych samych plików tożsamości do ssh do konta użytkownika innego niż root na tym samym serwerze zdalnym.
źródło
Rozumiem, dlaczego ochrona może niepokoić ludzi. Właśnie miałem
ssh won't use my key
problem ponownie. Rozwiązałem to, logując się do zdalnego serwera i uruchamiająca następnie z mojego pulpitu (próbuję ssh na serwer)
Na serwerze mam
Authentication refused: bad ownership or modes for directory /
Niektórzy nowi administratorzy pomieszali uprawnienia i prawa własności, które naprawiłem za pomocą:
(Jestem przyzwyczajony do potrzeby,
chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pub
ale sprawdzanie sshd / znajdowanie uprawnień roota jest dla mnie nowe). Teraz zamierzam sprawdzić rootkita, a następnie wyczyścić i zainstalować ponownie.źródło
W moim przypadku problem dotyczył nieprawidłowego wykonania powłoki.
Zmieniono plik / etc / passwd dla tego użytkownika
źródło
Miałem ten problem na CentOS 7. Jestem zwykłym użytkownikiem Linuksa opartym na Debianie, więc byłem rybą z wody. Zauważyłem, że na niektórych serwerach działało, a na jednym nie. Audyt.log nie powiedział nic przydatnego, a bezpieczny.log też nic nie dał. Odkryłem, że jedyną prawdziwą różnicą były różnice w kontekście bezpieczeństwa plików i katalogów między tymi, które działały, a tymi, które nie działały. Uzyskaj bezpieczeństwo dzięki
sudo ls -laZ <user-home>/.ssh
katalogu (zakładam wiele domyślnych ustawień sshd_config).
Powinieneś zobaczyć niektóre
ssh_home_t
iuser_home_t
atrybuty. Jeśli nie, użyjchcon
polecenia, aby dodać brakujące atrybuty.Na przykład
W moim przypadku podejrzewam, że użytkownik został utworzony w niestandardowy sposób. Jego domem był katalog
/var/lib
.Więcej informacji: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/
źródło