"Warning: the ECDSA host key for 'central.server.domen.rs' differs from the key for the IP address '89.216.x.y'"

obrisi tu liniju iz known_hosts i trebalo bi da proradi.

Obriši ključeve, pa probaj opet.

Brisao known_hosts, kreirao kljuceve ... i onda pisao na forum.
Radio i kao user, i kao root. Pokusavao logovanje i kao SSH user@... i SSH root@...

Nešto previdjam, ne znam sta

Ovo sto si dao iz loga je zbog known_hosts, posalji jos jedan debag log kad si to popravio.

OK.
1. Obrisao sam sadržaj known_hosts fajla na udaljenom klijentu i authorized_keys fajla na serveru
2. Na udaljenom samo ponovo uradio ssh-keygen kao user (ne kao sudo). Prepisao postojeći fajl. Koristim passphrase kod generisanja ključa
3. cat /home/user/.ssh/id_rsa.pub ; sadržaj iskopirao na server u /home/user/,ssh/authorized_keys
4. ssh -vvv [email protected]

user@remote:~$ ssh -vvv [email protected]

user@remote:~$ ssh -vvv [email protected]
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "central.server.domen.rs" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to central.server.domen.rs [89.216.x.y] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.8 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to home.markser.in.rs:22 as 'user'
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
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: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,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]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
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-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
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]
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: ecdsa-sha2-nistp256 SHA256:XN1fO1BPo1y/xyxyxyxyxyhYq9sP0jKP10MFyc
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
The authenticity of host 'central.server.domen.rs (89.216.x.y)' can't be established.
ECDSA key fingerprint is SHA256:XN1fO1BPo1y/xyxyxyxyxyhYq9sP0jKP10MFyc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'central.server.domen.rs,89.216.x.y' (ECDSA) to the list of known hosts.
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
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /home/user/.ssh/id_rsa (0x55c8b02b6600)
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug2: key: /home/user/.ssh/id_ecdsa ((nil))
debug2: key: /home/user/.ssh/id_ed25519 ((nil))
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: password
debug3: start over, passed a different list password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:

... i naravno, nakon unošenja passworda se uloguje ...a trebao bi bez passworda. Čak sam kreirao iste usere sa istim passwordom na obe strane. Potez očajnika, bez efekta ...

Sta kaze log na serverskoj strani?

A zašto ne koristiš ssh-copy-id

ssh-copy-id -i id_rsa.pub user@remote-machine

On ti sredi i privilegije i sve ostalo. Možda je to problem?

Sta kaze :

Možda ... probaću.

To treba da uradis na klijentu sa kojeg se konektujes.

Pogledaj permisije nad folderima.
.ssh folder recimo 750, a fajlovi unutar njega 600, mada moze i 400.

Ali kao sto ti djoka kaze, kreiraj kljuc na racunaru sa ssk-keygen pa kopiraj kljuc na udaljeni racunar sa ssh-copy-id

auth.log
Apr 28 13:58:30 central sshd[27070]: Accepted password for user from 93.87.x.y port 44590 ssh2
Apr 28 13:58:30 central sshd[27070]: pam_unix(sshd:session): session opened for user user by (uid=0)
Apr 28 13:58:30 central systemd-logind[730]: New session 2127 of user user.


syslog
Apr 28 14:07:48 central systemd[1]: Started Session 2148 of user user.

Na racunaru SA koga se logujem sam i obrisao. Mislim da sam između ostalog probao i SSH-copy-id ali pokusacu opet pa javljam.

Da li neko može da mi objasni u teoriji: (možda je tu negde uzrok)

Kada se sa embeded linuxa, tj sa neke od onih 30 lokacija koje rade ok povezujem na Ubuntu, logujem se sa [email protected]. Public kez ubacim u ~/.ssh/autorized_keys koji je u stvari u folderu /root

Kada se kačim sa udaljenog Ubuntu servera, povezujem se sa [email protected] a key sam snimio u /home/user/.ssh/authorized_keys

Da li je TO ispravno/pogrešno i u čemu je u stvari razlika? Činjenica je da se kopiranje radi u folder za koji su potrebna root prava

U authorized_keys ti se nalazi public deo ključa i treba da se nalazi u home folderu usera sa kojim se loguješ.
Ako se konektuješ sa
# ssh user@imeremoteservera
Public key treba da dodaš u /home/user/.ssh/authorized_keys
A ako sa konektuješ sa
# ssh root@imeremoteservera
Onda u /root/.ssh/authorized_keys.

To ti sve završava komanda

# ssh-copy-id user@imeremoteservera


Je ,l ovo typo na forumu ili stvarno imaš zarez u imenu ,ssh foldera? :)

Izlistaj fajlove sa ls -la da vidimo permisije nad fajlovima i sa jedne i sa druge strane.

Procesljaj sve iz pocetka, verovatno je neki banalan problem u pitanju i to na strani tog novog, udaljenog Ubuntu klijenta (posto komunikacije Qnap => Ubuntu lepo rade).

Najpre na tom novom Ubuntu proveri vlasnike i permisije na /root/.ssh, /home/user/.ssh i svim njihovim parent direktorijumima:


Ono sto je bitno je da /home/user/.ssh bude vlanistvo usera 'user', da /root bude vlasnistvo 'root' i da ti direktorijumi nisu otvoreni za pisanje za bilo koga osim njihovih vlasnika. Homedir moze da bude 755, ali .ssh obavezno 700. Proveri vlasnistva fajlova u ~/.ssh direktorijumu - root mora da bude vlasnik svih fajlova u /root/.ssh, dok 'user' mora da bude vlasnik svega u /home/user/.ssh. Na kraju proveri da li je authorized_keys zatvoren za citanje i pisanje za sve osim vlasnika (permisije 600 ili 400). Proveri to na strani servera i klijenta:


Sledeca stvar je fajl /etc/ssh/ssh_config:


Moguce je da tu imas nesto sto forsira PasswordAuthentication ili iskljucuje PubkeyAuthentication? U svakom slucaju, taj fajl mozes da ignorises ako kreiras ~/.ssh/config (makar i prazan). A krajnje je pozeljno da kreiras ~/.ssh/config fajl sledece sadrzine:



Ako radis kao 'user', vlasnik tog fajla mora da bude 'user' i taj fajl mora da bude /home/user/.ssh/config ...
Ako radis kao 'root' tada je vlasnik 'root', svude gde u fajlu pise 'user' stavi 'root' i moras da ga upises u /root/.ssh/config ...

Na žalost nije rešilo problem.

ssh konfiguracija sa serverske strane bi trebala da je OK pošto se 30 drugih uređaja povezuje bez ikakvih problema. Problem mi je samo sa Ubuntu-to-Ubuntu kombinacijom

Naravno, greška u kucanju. Nisam primetio.

Remote (/home/user/):
drwx------ 2 user user 4096 Apr 28 20:36 .ssh

Remote (/home/user/.ssh/):
drwx------ 2 user user 4096 Apr 28 20:36 .
drwxr-xr-x 7 user user 4096 Apr 27 14:44 ..
-rw------- 1 user user 1766 Apr 28 11:51 id_rsa
-rw-r--r-- 1 user user 393 Apr 28 11:51 id_rsa.pub
-rw------- 1 user user 444 Apr 28 20:35 known_hosts
-rw------- 1 user user 444 Apr 28 20:34 known_hosts.old

Central (/home/user/):
drwx------ 2 user user 4096 Apr 28 20:31 .ssh

Central (/home/user/.ssh/):
drwx------ 2 user user 4096 Apr 28 20:31 .
drwxr-xr-x 7 user user 4096 Apr 27 19:14 ..
-rw-rw-r-- 1 user user 393 Apr 28 20:36 authorized_keys

U pravu si, imas višak a ne manjak prava :)

Jesi li ikada cuo za onu poznatu "Less is more"? :-)
Bas u tom visku i jeste stvar ... /home/user/.ssh/authorized_keys ti je otvoren za upisivanje za grupu (permisije su ti 664). Bolje postavi oba fajla da ti budu:

chmod 600 /root/.ssh/authorized_keys /home/user/.ssh/authorized_keys

Proof of Concept ... iliti takticko-pokazna vezba

Ako su permisije na authorized_keys '400', ssh sa serera na samog sebe koriscenjem public key auth - radi:


Ako promenimo permisije - stavimo npr. 660:


Kao sto vidis, trazi mi password. Ako vratim na 400:



To opet radi.

Usput, takodje proveri:

# find /root /home -name id_rsa

On mora da bude strogo postavljen na 400 ili 600, inace imas isti problem - funkcija safe_path() u 'misc.c' vraca -1 (izvor: OpenSSH Source @ GitHub)

Ako ti je okruzenje 'trusted' - tj. ako ti je mreza zatvorena, niko ne moze da joj pridje sa spoljne strane i ne plasis se uljeza mozes da u /etc/ssh/sshd_config na strani servera ukines striktnu kontrolu vlasnistva i permisija, tako sto ces da stavis:


Ovo samo ako nikako ne uspes da se izboris sa problemom. Ali niposto ako su ti serveri izlozeni spoljnom svetu.

Da al tu ce da stane i da javi gresku. Zato probaj da forsiras publickey autentifikaciju. Nebitno da li je problem na klijentu ili serveru.

Pa normalno je da ti trazi password/passphrase ako ga uneses kad generises kljuc. Probaj ponovo, ali BEZ toga, samo lupi dvaput ENTER kad ti trazi passphrase i reseno.

Evo i razlika između uspešnog (publickey) i neuspešnog (password) logovanja. Test sa više lokacija je pokazao da je (ipak) problem do računara koji uspostavlja vezu. Ne utiče distribucija,verzija, kernel, verzija SSH itd (kao što se i dalo pretpostaviti - sada su i testovi to dokazali)

Izvukao sam samo razlike u debug-u ali nisam uspeo za pošetak da pronađem razliku između id_rsa type 0 i 1. Ako neko odavde može da shvati grešku, spasao me je

Ovaj računar se uloguje pomoću pulickey



Odavde dalje je već praktično ulogovan pomoću publickey

Ovako izgleda debug neuspešnog povezivanja, tj kada tražu password

Testiranje tokom noći je potvrdilo da problem definitivno nije sa strane servera. Sa više servera kojima se bavim sam se povezao standardnom procedurom (ssh-keygen, ssh-copy-id, ssh user@server). Jedino se ovaj jedan buni.
Btw provreio sam i authorized_keys je sa pravima 600. Takođe, na klijentu je id_rsa takođe sa pravima 600

Za taktičko-pokaznu vežbu ocena 5 :-) Ovakve stvari su mi nekada jako nedostajale (a i sada ponekad ...)

U situaciji kada sve radi kako treba, kod prvog logovanja traži passphrase ako je uneta prilikom generisanja ključa. Ovde ne traži passphrase nego password. Isto se ponaša i kada izgenerišem ključ bez passphrase. Testirano ...

Da vidimo - RADI:

NE RADI:


Pretraga na temu "id_rsa type" na Guglu dala je ovo ...
Taj tip je defnisan kao:



U prvom slucaju koristis DSA kljuc. U drugom koristis RSA. Da li ti se privatni i javni kljuc uklapaju? Kada si generisao kljuc na tom Ubuntu klijentu i dobio id_rsa i id_rsa.pub, da li na serveru, u /home/user/.ssh/authorized_keys vidis sadrzaj 'id_rsa.pub'? Znam da si koristio ssh-copy-id, ali ko zna, mozda ga nije iskopirao to kako valja?

Nisi nam rekao sta pise u syslogu na serveru. Po defaultu on ne loguje mnogo informacija (severity >= info), ali to mozes da promenis tako sto u /etc/ssh/sshd_config stavis:

LogLevel DEBUG3
SyslogFacility AUTHPRIV

Restartuj sshdi probaj ponovo. Videces dosta poruka i negde ces vec shvatiti gde je problem.

A probaj sa tog problematicnog klijenta da uradis "ssh localhost" ... i ovo sto su ti ljudi vec savetovali, forsiraj pubkey auth:

ssh localhost -o 'PasswordAuthentication no'

ssh server -o 'PasswordAuthentication no'

_{[Ovu poruku je menjao B3R1 dana 29.04.2019. u 15:56 GMT+1]}

passphrase = password

Ako sam dobro ispratio, u ovim tvojim probama si imao situaciju kad sve radi osim sto ti trazi password, ovo moje se odnosilo na to.

Ako ikako mislis da to radi bez nadzora, tj da niko ne mora da ukucava password, najbolje resenje je da generises kljuc bez passphrase (ima i resenje da sistem pokupi password iz nekog fajla ali da ne komplikujemo). Tvoj sistem ima instaliran ssh-agent, pa on "pamti" kad ukucas password prvi put sve dok se ne izlogujes.

^
Koliko sam ja shvatio iz njegovog loga, nije mu trazen passphrase nego password kao sledeći način autentifikacije jer prethodni načini nisu uspeli.

U pravu si, prebrzo sam citao.

Novi momenat je saznanje da kod klijenta postoji firewall! Moguće je da neki paket inspection nešto promeni u tranzitu. Cekam rezultate testiranja u lokalu ... Nastavak sledi

Konacno, u pitanju je bio firewall I ukljucena opcija SSL inspection. Ona nije dozvoljavala razmenu paketa koji bi autentifikovali klijenta i servera pa je, naravno, sledeci method autentifikacije bio password.

Zahvaljujem se svima koji su pokusali da mi pomognu da se izborim sa ovim problemom

Sjajna tema, sjajno rešenje - čestitam na upornosti!