Odmowa zezwolenia SSH (klucz publiczny), ale root ssh działa


15

Próbuję skonfigurować dostęp ssh dla konta użytkownika, które utworzyłem z szefem kuchni na cyfrowym serwerze oceanu Ubuntu 12.04. Miałem opcje ustawione w cyfrowym oceanie, aby automatycznie kopiować klucz ssh mojego Maca po utworzeniu kropli.

Mogę ssh zalogować się jako root bez żadnych problemów, ale mój inny użytkownik nie może się uwierzytelnić. wydaje się, że jest to powszechny problem, więc sprawdziłem niektóre inne odpowiedzi i znalazłem to polecenie, aby uzyskać więcej informacji:

ssh -vvv -i id_rsa user@serverIP

Dzienniki użytkownika root (który się powiedzie) za pomocą tej komendy to

odpluskwić

1: Offering RSA public key: /Users/evan/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp snip!
debug3: sign_and_send_pubkey: snip!
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

upadający użytkownik:

odpluskwić

1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/evan/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/evan/.ssh/id_dsa
debug3: no such identity: /Users/evan/.ssh/id_dsa: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.

Co dla mnie oznacza, że ​​klucz publiczny jest nieprawidłowy. Ale jeśli zaloguję się jako użytkownik root i przejdę do home/otheraccount/.ssh/authorized_keys, mogę zobaczyć, że jest tam mój klucz ssh. Myślałem, że może wystąpił błąd, więc zrobiłem, cp .ssh/authorized_keys ~/home/otheraccout/.ssh/authorized_keysale to nie pomogło. Nie wiem gdzie jeszcze szukać.

moje etc/ssh/sshd_conig:

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
"sshd_config" 88L, 2508C
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

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

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# GS

SAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM no
Banner /etc/ssh_banner

edytować:

drwx------ 2 deploy deploy 4096 Apr 20 06:00 .ssh
-rw------- 1 deploy deploy 820 Apr 20 05:35 authorized_keys

Edycja2:

Jak sugerowano w komentarzach /var/log/authlog:

Apr 21 04:59:30 localhost sshd[586]: User deploy not allowed because account is locked
Apr 21 04:59:30 localhost sshd[586]: input_userauth_request: invalid user deploy [preauth]

Próbowałem to zrobić sudo usermod --expiredate -1 deployi wróciłono changes


1
Czy twoje uprawnienia są prawidłowe? ~/home/otheraccount/.sshpowinny mieć 700i ~/home/otheraccount/.ssh/authorized_keyspowinny mieć 600pozwolenie, a oba pliki powinny być własnościąotheraccount
clement

Myślę, że są poprawne, wdrożenie jest inne konto: drwx------ 2 deploy deploy 4096 Apr 20 06:00 .ssh -rw------- 1 deploy deploy 820 Apr 20 05:35 authorized_keys
user2936314

jakie są wiersze dziennika w serverIP( /var/log/auth.log), gdy próbujesz zalogować się jako deployużytkownik?
clement

ciekawe, narzeka, że ​​użytkownik jest zablokowany, dodałem dzienniki powyżej.
user2936314,

nie pozwala mi edytować powyższego komentarza: Naprawiłem to za pomocą passwd -u. Mogę ssh jak deployteraz, ale naprawdę ciekawe, dlaczego mój kucharz wdraża tworzenie zablokowanych użytkowników. Skopiuj / wklej swój komentarz powyżej jako odpowiedź, abym mógł wyrazić uznanie
użytkownik2936314

Odpowiedzi:


16
  • Logowania SSH może nie z różnych powodów (nieprawidłowe uprawnienia plików / katalogów, błędnych kluczy itp) oraz klienta łączącego się po prostu Permission deniedalbo No more authentication methods to tryczy jakiś błąd ogólny.

  • Dokładny powód niepowodzenia logowania będzie dostępny w dzienniku ssh /var/log/auth.loglub w /var/log/securezależności od konfiguracji syslog.


To najlepsza odpowiedź na wszystkie pytania dotyczące niepowodzenia logowania SSH, jakie kiedykolwiek widziałem! Zamiast losowego zgadywania o niewłaściwych uprawnieniach i nazwach plików, jak sugerują wszystkie inne odpowiedzi, wystarczy sprawdzić wspomniane dzienniki i zawierają one wszystkie potrzebne informacje!
Yaroslav Admin

Dokładnego powodu nie ma w moim pliku dziennika. Mówi tylko, że sesja była otwarta niż zamknięta.
VectorVortec

3

Ten sam problem dla mnie świeża instalacja CentOS7.

1. sprawdź uprawnienia do katalogu domowego i uprawnienia ~ / .ssh i ~ / .ssh / author_keys (jak mówi @clement)

chmod o-w ~/; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys

2. sprawdź / etc / ssh / sshd_config ustawienia i & service restart sshd (po każdej edycji) Przydatne: spróbuj „LogLevel VERBOSE” w sshd_config.

Po sprawdzeniu, czy wszystko jest w porządku, nadal pojawia się monit o hasło.

Uruchom klienta ssh z dziennikami -vvv:

debug3: send_pubkey_test 
debug2: we sent a publickey packet, wait for reply

Dzienniki serwera (/ var / log / secure):

Failed publickey for * from * port * ssh2: RSA *

Serwer ssh nie wysyła więcej informacji o błędzie do klienta, ponieważ stanowiłoby to zagrożenie bezpieczeństwa.

Gdybym uruchomił sshd na innym porcie 'sshd -p 5555 -d'. Klucz zadziałał. Logowanie bez hasła ok. WTF?

SAD :-( aby powiedzieć, że następnie wyłączyłem selinux (ustaw SELINUX = wyłączone w / etc / selinux / config) i zrestartowałem. Logowanie bez hasła działało wtedy ok.

moje bieżące działające ustawienia sshd_config:

[root@hp-bl-05 ~]# grep -vE "^#|^$" /etc/ssh/sshd_config  
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTHPRIV
LogLevel VERBOSE
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
HostbasedAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication no
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
UseDNS no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem   sftp    /usr/libexec/openssh/sftp-server

Byłoby miło wiedzieć, czy moglibyśmy zmienić coś małego w selinux, aby hasło do logowania ssh działało poprawnie. Czy ktoś może poprawić odpowiedź?

to samo tutaj: /superuser/352368/ssh-still-asks-for-password-after-setting-up-key-based-authentication/1072999#1072999

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.