[ marxer @ 27.04.2019. 20:09 ] @
Pozdrav svima

Imam jedan Ubuntu 16.04 server (zvaću ga centralni) koji mi služi za prikupljanje podataka sa tridesetak udaljenih lokacija. Na tim malim lokacijama se nalaze Qnap-i sa nekim embeded linux-om koji na tim lokacijama rade kao serveri. Svaki dan u određeno vreme svaka udaljena lokacija uradi rsync foldera x sa Qnap-a na folder y Ubuntu servera. Da bih to postigao na svakom Qnap-u je urađen ssh-keygen i odrađeno automatsko logovanje na Ubuntu bez kucanja lozinke. Lokacije su sa dinamičkim adresama i MTS ADSL-ovima koje MTS voli da resetuje pa nikakvo podešavanje nije trajno. Zato se komunikacija inicijalizuje sa tih malih lokacija i kači se na Ubuntu koji je na statičkoj IP adresi. I sve radi OK već neko vreme ...

Onda je na jednoj lokaciji sa većim potrebama postavljen umesto Qnap-a Ubuntu 18.04 zbog potrebe za jačim serverom. Međutim, kada sam odradio ssh-keygen i generisani ključ preneo na centralni server počeli su problemi. Štagod da uradim, uvek centralni server uvek traži password. Ispratio sam savete sa raznih foruma i sve se svodilo podešavanja koja sam i sam probao. U "igru" sam ubacio i treći server za potrebe testiranja (opet Ubuntu 16.04) i problemi su se preslikali bilo da je ovaj server glumio centralnog, bilo da je glumio udaljenog servera ...

Nedelju dana ne mogu da shvatim gde grešim. Svaki savet je dobrodošao i zahvaljujem se unapred

[email protected]:~$ 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 central.server.domen.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: ch[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:QJjwe7L+6SN++snJKxyxyxyxyNwf0Ih2OAxV+cp+0o
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/user/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys from 89.216.x.y
The authenticity of host 'home.markser.in.rs (89.216.x.y)' can't be established.
ECDSA key fingerprint is SHA256:QJjwe7L+6SN++snJKxyxyxyxyNwf0Ih2OAxV+cp+0o.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'central.server.domen.rs' (ECDSA) to the list of known hosts.
Warning: the ECDSA host key for 'central.server.domen.rs' differs from the key for the IP address '89.216.x.y'
Offending key for IP in /home/user/.ssh/known_hosts:2
Are you sure you want to continue connecting (yes/no)? yes
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 (0x561336fbc500)
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:
[ Branimir Maksimovic @ 27.04.2019. 21:43 ] @
"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.
[ tuxserbia @ 27.04.2019. 21:45 ] @
Obriši ključeve, pa probaj opet.
[ marxer @ 28.04.2019. 08:28 ] @
Brisao known_hosts, kreirao kljuceve ... i onda pisao na forum.
Radio i kao user, i kao root. Pokusavao logovanje i kao SSH [email protected] i SSH [email protected]

Nešto previdjam, ne znam sta
[ Branimir Maksimovic @ 28.04.2019. 08:35 ] @
Ovo sto si dao iz loga je zbog known_hosts, posalji jos jedan debag log kad si to popravio.
[ marxer @ 28.04.2019. 11:42 ] @
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]

[email protected]:~$ ssh -vvv [email protected]

[email protected]:~$ 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 ...
[ srbaja @ 28.04.2019. 12:13 ] @
Sta kaze log na serverskoj strani?
[ djoka_l @ 28.04.2019. 12:25 ] @
Citat:
3. cat /home/user/.ssh/id_rsa.pub ; sadržaj iskopirao na server u /home/user/,ssh/authorized_keys


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

ssh-copy-id -i id_rsa.pub [email protected]

On ti sredi i privilegije i sve ostalo. Možda je to problem?
[ Branimir Maksimovic @ 28.04.2019. 12:36 ] @
Sta kaze :
Code:

ssh -o PreferredAuthentications=publickey itd...
[ marxer @ 28.04.2019. 13:00 ] @
Citat:
djoka_l:
Citat:
3. cat /home/user/.ssh/id_rsa.pub ; sadržaj iskopirao na server u /home/user/,ssh/authorized_keys


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

ssh-copy-id -i id_rsa.pub [email protected]

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


Možda ... probaću.
[ CoyoteKG @ 28.04.2019. 13:02 ] @
Citat:
1. Obrisao sam sadržaj known_hosts fajla na udaljenom klijentu

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
[ marxer @ 28.04.2019. 13:08 ] @
Citat:
srbaja:
Sta kaze log na serverskoj strani?


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.
[ marxer @ 28.04.2019. 15:00 ] @
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
[ CoyoteKG @ 28.04.2019. 15:12 ] @
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 [email protected]
Public key treba da dodaš u /home/user/.ssh/authorized_keys
A ako sa konektuješ sa
# ssh [email protected]
Onda u /root/.ssh/authorized_keys.

To ti sve završava komanda

# ssh-copy-id [email protected]

Citat:
3. cat /home/user/.ssh/id_rsa.pub ; sadržaj iskopirao na server u /home/user/,ssh/authorized_keys

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.
[ B3R1 @ 28.04.2019. 16:07 ] @
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:

# ls -ald / /root /root/.ssh /home /home/user /home/user/.ssh
dr-xr-xr-x 24 root root 4096 Nov 28 19:51 /
drwxr-xr-x 8 root root 4096 Apr 21 11:19 /home
drwx------ 7 user other 4096 Apr 22 16:57 /home/user
drwx------ 7 user other 4096 Apr 22 16:57 /home/user/.ssh
dr-xr-x--- 5 root root 4096 Dec 24 20:50 /root
drwx------ 2 root root 4096 Apr 15 2018 /root/.ssh

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:

# find /root /home -name authorized_keys -exec ls -ald {} \;
-r-------- 1 user other 230 Apr 15 2018 /home/user/.ssh/authorized_keys
-r-------- 1 root root 230 Nov 26 12:19 /root/.ssh/authorized_keys

Sledeca stvar je fajl /etc/ssh/ssh_config:

# grep -v ^# /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:

Host central.server.domen.rs central
Hostname central.server.domen.rs
IdentityFile /home/user/.ssh/id_rsa
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
ForwardAgent no
User user


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 ...
[ marxer @ 28.04.2019. 19:39 ] @
Citat:
djoka_l:
Citat:
3. cat /home/user/.ssh/id_rsa.pub ; sadržaj iskopirao na server u /home/user/,ssh/authorized_keys


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

ssh-copy-id -i id_rsa.pub [email protected]

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


Na žalost nije rešilo problem.
[ marxer @ 28.04.2019. 19:41 ] @
Citat:
Branimir Maksimovic:
Sta kaze :
Code:

ssh -o PreferredAuthentications=publickey itd...


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
[ marxer @ 28.04.2019. 19:51 ] @
Citat:
CoyoteKG:
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 [email protected]
Public key treba da dodaš u /home/user/.ssh/authorized_keys
A ako sa konektuješ sa
# ssh [email protected]
Onda u /root/.ssh/authorized_keys.

To ti sve završava komanda

# ssh-copy-id [email protected]

Citat:
3. cat /home/user/.ssh/id_rsa.pub ; sadržaj iskopirao na server u /home/user/,ssh/authorized_keys

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.


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



[ marxer @ 28.04.2019. 20:14 ] @
Citat:
B3R1:
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:

# ls -ald / /root /root/.ssh /home /home/user /home/user/.ssh
dr-xr-xr-x 24 root root 4096 Nov 28 19:51 /
drwxr-xr-x 8 root root 4096 Apr 21 11:19 /home
drwx------ 7 user other 4096 Apr 22 16:57 /home/user
drwx------ 7 user other 4096 Apr 22 16:57 /home/user/.ssh
dr-xr-x--- 5 root root 4096 Dec 24 20:50 /root
drwx------ 2 root root 4096 Apr 15 2018 /root/.ssh

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:



Izgleda ovako:

Klijent:
drwxr-xr-x 23 root root 4096 Apr 25 13:18 /
drwxr-xr-x 5 root root 4096 Apr 27 09:49 /home
drwxr-xr-x 7 user user 4096 Apr 27 14:44 /home/user
drwx------ 2 user user 4096 Apr 28 20:36 /home/user/.ssh
drwx------ 7 root root 4096 Apr 27 09:32 /root
drwx------ 2 root root 4096 Apr 27 18:59 /root/.ssh


Server:
drwxr-xr-x 23 root root 4096 Apr 27 10:47 /
drwxr-xr-x 3 root root 4096 Apr 1 17:55 /home
drwxr-xr-x 7 user user 4096 Apr 27 19:14 /home/user
drwx------ 2 user user 4096 Apr 28 20:31 /home/user/.ssh
drwx------ 8 root root 4096 Apr 27 19:26 /root
drwx------ 2 root root 4096 Apr 28 20:31 /root/.ssh





# find /root /home -name authorized_keys -exec ls -ald {} \;
-r-------- 1 user other 230 Apr 15 2018 /home/user/.ssh/authorized_keys
-r-------- 1 root root 230 Nov 26 12:19 /root/.ssh/authorized_keys




Authorized_keys:
-rw-r--r-- 1 root root 0 Apr 28 11:48 /root/.ssh/authorized_keys
-rw-rw-r-- 1 user user 393 Apr 28 20:36 /home/user/.ssh/authorized_keys


Sve u svemu, deluje mi kao višak, a ne manjak prava ...




Sledeca stvar je fajl /etc/ssh/ssh_config:

# grep -v ^# /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:

Host central.server.domen.rs central
Hostname central.server.domen.rs
IdentityFile /home/user/.ssh/id_rsa
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
ForwardAgent no
User user





Evo i šta kaže za ssh_config fajl:

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no


Ako radis kao 'user', vlasnik tog fajla mora da bude 'user' i taj fajl mora da bude /home/user/.ssh/config ...

E to nije! Evo nove stvari za probu :-)


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

[ srbaja @ 28.04.2019. 22:42 ] @
U pravu si, imas višak a ne manjak prava :)

Citat:
B3R1:
Na kraju proveri da li je authorized_keys zatvoren za citanje i pisanje za sve osim vlasnika (permisije 600 ili 400)
[ B3R1 @ 28.04.2019. 23:20 ] @
Citat:

Authorized_keys:
-rw-r--r-- 1 root root 0 Apr 28 11:48 /root/.ssh/authorized_keys
-rw-rw-r-- 1 user user 393 Apr 28 20:36 /home/user/.ssh/authorized_keys
Sve u svemu, deluje mi kao 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:
[[email protected] ~]$ ls -al .ssh/authorized_keys
-r-------- 1 beri other 230 Apr 15 2018 .ssh/authorized_keys
[[email protected] ~]$ ssh 0 -l beri
Last login: Mon Apr 29 00:11:16 2019 from localhost
[[email protected] ~]$ exit
Connection to 0 closed.


Ako promenimo permisije - stavimo npr. 660:
[[email protected] ~]$ chmod 660 .ssh/authorized_keys ; ls -al .ssh/authorized_keys
-rw-rw---- 1 beri other 230 Apr 15 2018 .ssh/authorized_keys
[[email protected] ~]$ ssh 0 -l beri
[email protected]'s password:


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

[[email protected] ~]$ chmod 400 .ssh/authorized_keys ; ls -al .ssh/authorized_keys
-r-------- 1 beri other 230 Apr 15 2018 .ssh/authorized_keys
[[email protected] ~]$ !ssh
ssh 0 -l beri
Last login: Mon Apr 29 00:12:15 2019 from localhost
[[email protected] ~]$ logout


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:

StrictModes no

Ovo samo ako nikako ne uspes da se izboris sa problemom. Ali niposto ako su ti serveri izlozeni spoljnom svetu.
[ Branimir Maksimovic @ 29.04.2019. 03:43 ] @
Citat:
marxer:
Citat:
Branimir Maksimovic:
Sta kaze :
Code:

ssh -o PreferredAuthentications=publickey itd...


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


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.
[ b416 @ 29.04.2019. 12:29 ] @
Citat:
marxer:

2. Na udaljenom samo ponovo uradio ssh-keygen kao user (ne kao sudo). Prepisao postojeći fajl. Koristim passphrase kod generisanja ključa


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.
[ marxer @ 29.04.2019. 12:48 ] @
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

[email protected]:~$ ssh -vvv [email protected]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016
...
debug1: identity file /home/marxer/.ssh/id_rsa type 1
...
debug1: Enabling compatibility mode for protocol 2.0
...
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
...
debug2: key: /home/user/.ssh/id_rsa (0x55e542fa5a40)
...
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
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,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
...


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

Ovako izgleda debug neuspešnog povezivanja, tj kada tražu password
[email protected]:~/.ssh$ ssh -vvv [email protected]
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
...
debug1: identity file /home/marxer/.ssh/id_rsa type 0
...
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
...
debug2: key: /home/user/.ssh/id_rsa (0x55ca70934630)
...
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
[ marxer @ 29.04.2019. 13:15 ] @
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 [email protected]). 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 ...)


Citat:
B3R1:
Citat:

Authorized_keys:
-rw-r--r-- 1 root root 0 Apr 28 11:48 /root/.ssh/authorized_keys
-rw-rw-r-- 1 user user 393 Apr 28 20:36 /home/user/.ssh/authorized_keys
Sve u svemu, deluje mi kao 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:
[[email protected] ~]$ ls -al .ssh/authorized_keys
-r-------- 1 beri other 230 Apr 15 2018 .ssh/authorized_keys
[[email protected] ~]$ ssh 0 -l beri
Last login: Mon Apr 29 00:11:16 2019 from localhost
[[email protected] ~]$ exit
Connection to 0 closed.


Ako promenimo permisije - stavimo npr. 660:
[[email protected] ~]$ chmod 660 .ssh/authorized_keys ; ls -al .ssh/authorized_keys
-rw-rw---- 1 beri other 230 Apr 15 2018 .ssh/authorized_keys
[[email protected] ~]$ ssh 0 -l beri
[email protected]'s password:


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

[[email protected] ~]$ chmod 400 .ssh/authorized_keys ; ls -al .ssh/authorized_keys
-r-------- 1 beri other 230 Apr 15 2018 .ssh/authorized_keys
[[email protected] ~]$ !ssh
ssh 0 -l beri
Last login: Mon Apr 29 00:12:15 2019 from localhost
[[email protected] ~]$ logout


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:

StrictModes no

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

[ marxer @ 29.04.2019. 13:19 ] @
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 ...

Citat:
b416:
Citat:
marxer:

2. Na udaljenom samo ponovo uradio ssh-keygen kao user (ne kao sudo). Prepisao postojeći fajl. Koristim passphrase kod generisanja ključa


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.

[ B3R1 @ 29.04.2019. 14:44 ] @
Da vidimo - RADI:
debug1: identity file /home/marxer/.ssh/id_rsa type 1

NE RADI:
debug1: identity file /home/marxer/.ssh/id_rsa type 0


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

enum sshkey_types { KEY_RSA, KEY_DSA, KEY_ECDSA, KEY_ED25519, KEY_RSA_CERT, KEY_DSA_CERT, KEY_ECDSA_CERT, KEY_ED25519_CERT, KEY_XMSS, KEY_XMSS_CERT, KEY_UNSPEC};


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]
[ b416 @ 29.04.2019. 15:25 ] @
Citat:
marxer:
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 ...

Citat:
b416:
Citat:
marxer:

2. Na udaljenom samo ponovo uradio ssh-keygen kao user (ne kao sudo). Prepisao postojeći fajl. Koristim passphrase kod generisanja ključa


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.



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.

[ CoyoteKG @ 29.04.2019. 20:12 ] @
^
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.
Citat:

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:
[ b416 @ 29.04.2019. 20:26 ] @
U pravu si, prebrzo sam citao.
[ marxer @ 30.04.2019. 17:59 ] @
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
[ marxer @ 08.05.2019. 17:59 ] @
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
[ Burgos @ 08.05.2019. 20:33 ] @
Sjajna tema, sjajno rešenje - čestitam na upornosti!