18 replies to this topic

[Rammy]

Hallo,

 

Ik probeer al sinds een paar dagen om via ssh en een private key toegang te krijgen tot de receiver.

Het wil maar niet lukken steeds word ik gevraag om mijn password.

Ik heb al diverse oplossingen van het web geprobeerd maar niets wil werken.

 

Het stappenplan dat ik gebruik is:

 

- aanmaken van de rsa sleutels op mijn PC

- id_rsa.public sleutel toevoegen aan de /home/root/.ssh/autorized_keys file op de receiver

Welke public key algorithm's worden ondersteund door OpenPli?

- ssh-rsa, reeds geprobeerd werkt niet
- dsa
- ecdsa
- ecdsa-sk
- ed25519
- ed25519-sk
- rsa, reeds geprobeerd werkt niet

 

Of doe ik wellicht nog iets fout?

 

Groet.

 

Rammy

[40H3X]

Sinds OpenPLi 8.0 is de default ssh key verandert naar ecdsa-sha2-nistp521 , zie ook de release notes van 8 https://wiki.openpli...enotes-8.0#New:

ssh-keygen -t ecdsa -b 521

 

[WanWizard]

De standaard key op de box is de standaard key voor "root@yourbox", die is dus voor inloggen niet zo relevant, die wordt gebruikt bij het inloggen vanaf de box op een ander device. Bovendien is die in dropbear formaat, niet compatible met openSSH.

 

Gewoon je public key in authorized_keys neerzetten is genoeg.

 

Op de box even voorbereiden:

mkdir /home/root/.ssh
chmod 600 /home/root/.ssh

en dan de key er in zetten.

/
[wanwizard@alfred] $ cd ~/.ssh/
~/.ssh 
[wanwizard@alfred] $ scp id_ecdsa.pub root@dual:/home/root/.ssh
root@dual's password: 
id_ecdsa.pub                                                           100%  182    86.0KB/s   00:00    
~/.ssh 
[wanwizard@alfred] $

En inloggen maar....

[wanwizard@alfred] $ ssh root@dual
The authenticity of host 'dual (172.19.12.63)' can't be established.
ECDSA key fingerprint is SHA256:ME/nPB889AfDGA+lKayagID4y6mXXMC2E3rq2ejiCZQ.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:107: hd66se
    ~/.ssh/known_hosts:118: sf8008
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'dual' (ECDSA) to the list of known hosts.
root@dual:~# 

mijn key is "ecdsa-sha2-nistp256".

 

edit:

 

als je password login wilt uitzetten, edit dan "/etc/defaults/dropbear", en zet de optie "-g" in DROPBEAR_EXTRA_ARGS.

Edited by WanWizard, 7 November 2023 - 18:13.

[littlesat]

Vandaar dat ssh mij al een tijd niet lukt zonder w8woord

Zijn het dan deze opties die je mag gaan selecteren in puttygen?

 puttygen.png   14.91KB   2 downloads

Edited by littlesat, 7 November 2023 - 18:04.

[WanWizard]

Vandaar dat ssh mij al een tijd niet lukt zonder w8woord

Zijn het dan deze opties die je mag gaan selecteren in puttygen?

puttygen.png

 

Dat is afhankelijk van wat je voorheen selecteerde. Een hele rits key encryption types zijn tegenwoordig "weak" en worden standaard door ssh servers geblokkeerd. Geen idee in hoeverre dropbear bij is.

 

Belangrijk in 9.0-release (en develop) is dat CBC, SHA1 en DH-group1 gebaseerde keys niet meer worden geaccepteerd.

Edited by WanWizard, 7 November 2023 - 18:18.
weak cipher info toegevoegd

[Rammy]

De standaard key op de box is de standaard key voor "root@yourbox", die is dus voor inloggen niet zo relevant, die wordt gebruikt bij het inloggen vanaf de box op een ander device. Bovendien is die in dropbear formaat, niet compatible met openSSH.

 

Gewoon je public key in authorized_keys neerzetten is genoeg.

 

Op de box even voorbereiden:

mkdir /home/root/.ssh
chmod 600 /home/root/.ssh

en dan de key er in zetten.

/
[wanwizard@alfred] $ cd ~/.ssh/
~/.ssh 
[wanwizard@alfred] $ scp id_ecdsa.pub root@dual:/home/root/.ssh
root@dual's password: 
id_ecdsa.pub                                                           100%  182    86.0KB/s   00:00    
~/.ssh 
[wanwizard@alfred] $

En inloggen maar....

[wanwizard@alfred] $ ssh root@dual
The authenticity of host 'dual (172.19.12.63)' can't be established.
ECDSA key fingerprint is SHA256:ME/nPB889AfDGA+lKayagID4y6mXXMC2E3rq2ejiCZQ.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:107: hd66se
    ~/.ssh/known_hosts:118: sf8008
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'dual' (ECDSA) to the list of known hosts.
root@dual:~# 

mijn key is "ecdsa-sha2-nistp256".

 

edit:

 

als je password login wilt uitzetten, edit dan "/etc/defaults/dropbear", en zet de optie "-g" in DROPBEAR_EXTRA_ARGS.

De link <https://wiki.openpli...senotes-8.0#New:> werkt niet, ik word verwezen naar <https://openpli.org/#New:> alwaar ik de info niet kan vinden.
Even voor alle duidelijkheid.
Ik open 2 terminal windows, CTRL+Alt+T, en doe dan de volgende stappen:

- terminal Ubuntu 22.04: ssh-keygen -t ecdsa -b 521
- terminal Ubuntu 22.04: sudo scp ~/.ssh/id_ecdsa.pub root@192.168.124.185:/home/root/
- terminal receiver: rm ~/.ssh/authorized_keys
- terminal receiver: touch ~/.ssh/authorized_keys
- terminal receiver: cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys
- terminal Ubuntu 22.04: ssh -vv root@192.168.124.185, zie bijgevoegde file SSHVerbose.txt

Het resultaat van dit alles is dat ik nog steeds om mijn passwd gevraagd wordt.


 

Attached Files

•  SSHVerbose.txt   6.86KB   2 downloads

[WanWizard]

Dit dat de server kant geen probleem heeft, maar je issue lokaal is:

debug1: Server accepts key: /home/pi/.ssh/id_ecdsa ECDSA SHA256:Xsc11LM4HWUpd9XCPnppMkqZq/edXg9hNLOiRvjDD20
Load key "/home/pi/.ssh/id_ecdsa": Permission denied

 

[catastrofus]

De standaard key op de box is de standaard key voor "root@yourbox", die is dus voor inloggen niet zo relevant, die wordt gebruikt bij het inloggen vanaf de box op een ander device. Bovendien is die in dropbear formaat, niet compatible met openSSH.

 

Gewoon je public key in authorized_keys neerzetten is genoeg.

 

Op de box even voorbereiden:

mkdir /home/root/.ssh
chmod 600 /home/root/.ssh

en dan de key er in zetten.

/
[wanwizard@alfred] $ cd ~/.ssh/
~/.ssh 
[wanwizard@alfred] $ scp id_ecdsa.pub root@dual:/home/root/.ssh
root@dual's password: 
id_ecdsa.pub                                                           100%  182    86.0KB/s   00:00    
~/.ssh 
[wanwizard@alfred] $

En inloggen maar....

[wanwizard@alfred] $ ssh root@dual
The authenticity of host 'dual (172.19.12.63)' can't be established.
ECDSA key fingerprint is SHA256:ME/nPB889AfDGA+lKayagID4y6mXXMC2E3rq2ejiCZQ.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:107: hd66se
    ~/.ssh/known_hosts:118: sf8008
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'dual' (ECDSA) to the list of known hosts.
root@dual:~# 

mijn key is "ecdsa-sha2-nistp256".

 

edit:

 

als je password login wilt uitzetten, edit dan "/etc/defaults/dropbear", en zet de optie "-g" in DROPBEAR_EXTRA_ARGS.

Die "chmod 600 /home/root/.ssh" moet dat geen "chmod 700 /home/root/.ssh" zijn in je voorbeeld? Dirs hebben een x-bit nodig.

[WanWizard]

Eh... ja. Had daar ook een cut & paste voor moeten gebruiken...

[Rammy]

 

Dit dat de server kant geen probleem heeft, maar je issue lokaal is:

debug1: Server accepts key: /home/pi/.ssh/id_ecdsa ECDSA SHA256:Xsc11LM4HWUpd9XCPnppMkqZq/edXg9hNLOiRvjDD20
Load key "/home/pi/.ssh/id_ecdsa": Permission denied

Ik heb de file rechten van id_ecdsa op mijn systeem gewijzigd met command: chmod 644 ~/.ssh/id_ecdsa

Nu kan ik inloggen zonder gebruik te moeten maken van mijn passwd.

Het probleem lijkt dus opgelost.

Nu eens kijken hoelang of dit werkt.

 

Bedankt voor het meedenken.

 

 

[Rammy]

 

Vandaar dat ssh mij al een tijd niet lukt zonder w8woord

Zijn het dan deze opties die je mag gaan selecteren in puttygen?

puttygen.png

 

Dat is afhankelijk van wat je voorheen selecteerde. Een hele rits key encryption types zijn tegenwoordig "weak" en worden standaard door ssh servers geblokkeerd. Geen idee in hoeverre dropbear bij is.

 

Belangrijk in 9.0-release (en develop) is dat CBC, SHA1 en DH-group1 gebaseerde keys niet meer worden geaccepteerd.

 

Welke encryption type gebruikt de 7.0 en de 9.0 release dan?

[WanWizard]

Het gaat er niet om wat de server kant gebruikt, het gaat er om wat voor key je aan de client kant hebt gegereneerd in combinatie met wat de server kant accepteert.

 

Voorheen waren DSA en RSA keys, en SHA1 hashing, heel gewoon. Maar die zijn met de hedendaagse CPU's (en vooral GPU's) makkelijk kraakbaar, en dus accepteren de meeste SSH servers ze niet meer.

 

Ik heb de file rechten van id_ecdsa op mijn systeem gewijzigd met command: chmod 644 ~/.ssh/id_ecdsa

 

Dat lijkt me niet correct.

 

Aan de client kant moet de .ssh directory 700 zijn, en alle bestanden daar in 600. En zowel eigenaar als groep moet de gebruikersnaam zelf zijn.

 

644 betekent dat je private key voor iedereen leesbaar is (world R rechten).

[Rammy]

Het gaat er niet om wat de server kant gebruikt, het gaat er om wat voor key je aan de client kant hebt gegereneerd in combinatie met wat de server kant accepteert.

 

Voorheen waren DSA en RSA keys, en SHA1 hashing, heel gewoon. Maar die zijn met de hedendaagse CPU's (en vooral GPU's) makkelijk kraakbaar, en dus accepteren de meeste SSH servers ze niet meer.

 

Ik heb de file rechten van id_ecdsa op mijn systeem gewijzigd met command: chmod 644 ~/.ssh/id_ecdsa

 

Dat lijkt me niet correct.

 

Aan de client kant moet de .ssh directory 700 zijn, en alle bestanden daar in 600. En zowel eigenaar als groep moet de gebruikersnaam zelf zijn.

 

644 betekent dat je private key voor iedereen leesbaar is (world R rechten).

Ik had inderdaad alle bestanden in .ssh dir de rechten 600 toegekend. Maar toen kreeg ik de 'Load key "/home/pi/.ssh/id_ecdsa": Permission denied' error.

Door deze te wijzigen in 644 was het probleem opgelost.

Ik heb nog eens gekeken en de eigenaar en groep naam in de gebruikersnaam gewijzigd en de rechten weer teruggezet op 600.

Ook nu lukt het inloggen weer.

[Rammy]

 

Het gaat er niet om wat de server kant gebruikt, het gaat er om wat voor key je aan de client kant hebt gegereneerd in combinatie met wat de server kant accepteert.

 

Voorheen waren DSA en RSA keys, en SHA1 hashing, heel gewoon. Maar die zijn met de hedendaagse CPU's (en vooral GPU's) makkelijk kraakbaar, en dus accepteren de meeste SSH servers ze niet meer.

 

Ik heb de file rechten van id_ecdsa op mijn systeem gewijzigd met command: chmod 644 ~/.ssh/id_ecdsa

 

Dat lijkt me niet correct.

 

Aan de client kant moet de .ssh directory 700 zijn, en alle bestanden daar in 600. En zowel eigenaar als groep moet de gebruikersnaam zelf zijn.

 

644 betekent dat je private key voor iedereen leesbaar is (world R rechten).

Ik had inderdaad alle bestanden in .ssh dir de rechten 600 toegekend. Maar toen kreeg ik de 'Load key "/home/pi/.ssh/id_ecdsa": Permission denied' error.

Door deze te wijzigen in 644 was het probleem opgelost.

Ik heb nog eens gekeken en de eigenaar en groep naam in de gebruikersnaam gewijzigd en de rechten weer teruggezet op 600.

Ook nu lukt het inloggen weer.

 

Welke key moet er door de client gegenereerd worden voor OpenPli 9.0 en OpenPli 7.0?

[WanWizard]

De enige key die gegenereert moet worden is de key (public + private) die op je client in ~/.ssh staat. Als je dat al niet gedaan had in het verleden.

 

Die key staat verder los van op welk linux systeem je de public key in authorized_keys wilt zetten, het enige waar je voor moet zorgen is dat die key gegenereerd is met een encryptie methode dat ondersteund wordt door het betreffende linux systeem.

 

Ik heb zelf 3 verschilende keys in mijn ~/.ssh staan, omdat ik moet kunnen inloggen op stokoude systemen (die alleen een oude RSA key snappen) en op nieuwe RHEL servers (die de RSA key niet meer accepteren). En ik heb nog 1 systeem die specifiek een CBC key wil (zo lek als een mandje).

[Rammy]

De enige key die gegenereert moet worden is de key (public + private) die op je client in ~/.ssh staat. Als je dat al niet gedaan had in het verleden.

 

Die key staat verder los van op welk linux systeem je de public key in authorized_keys wilt zetten, het enige waar je voor moet zorgen is dat die key gegenereerd is met een encryptie methode dat ondersteund wordt door het betreffende linux systeem.

 

Ik heb zelf 3 verschilende keys in mijn ~/.ssh staan, omdat ik moet kunnen inloggen op stokoude systemen (die alleen een oude RSA key snappen) en op nieuwe RHEL servers (die de RSA key niet meer accepteren). En ik heb nog 1 systeem die specifiek een CBC key wil (zo lek als een mandje).

Dat was wel duidelijk maar mijn vraag blijft welke encryptie methode word er ondersteund door OpenPli 7.0 en OpenPli 9.0.

Of accepteren beide ook de 'ecdsa-sha2-nistp521' encryptie methode?

[WanWizard]

OpenPLi 7 accepteert volgens mij nog RSA keys (met SHA1).

 

OpenPLi 9 accepteert geen DSA en RSA keys meer, en geen keys die gebruik maken van SHA1 of DH-group-1.

 

Mijn keuze voor ecdsa-sha2-nistp256 was meer ingegeven door een zo breed mogelijke acceptatie van de systemen waar ik verbinding mee maken moet, niet echt omdat het de meest secure is. De keuze voor ecdsa-sha2-nistp521 op de box (maar dat is voor jou niet relevant) is dat 521 iets meer secure is dan 256 (en gaat dus hopelijk wat langer mee).

 

Als je wilt weten wat een systeem accepteert, je kunt alle ondersteunde ciphers, MACs en key zien door gebruik te maken van

~
[wanwizard@alfred] $ ssh -vv root@dual
OpenSSH_9.0p1, OpenSSL 3.0.9 30 May 2023
debug1: Reading configuration data /home/wanwizard/.ssh/config
debug2: resolving "dual" port 22
debug1: Connecting to dual [172.19.12.63] port 22.
debug1: Connection established.
...
debug2: KEX algorithms: sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
...
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha256,kexguess2@matt.ucc.asn.au
debug2: host key algorithms: ecdsa-sha2-nistp521,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes256-ctr
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes256-ctr
debug2: MACs ctos: hmac-sha1,hmac-sha2-256
debug2: MACs stoc: hmac-sha1,hmac-sha2-256
debug2: compression ctos: zlib@openssh.com,none
debug2: compression stoc: zlib@openssh.com,none
debug2: languages ctos: 
debug2: languages stoc: 
...

het eerste blok is wat de client kant ondersteund, het tweede blok is wat de server kant ondersteund.

 

De leut is dan vervolgens om een zo goed mogelijke match te vinden,

Edited by WanWizard, 8 November 2023 - 13:51.

[Rammy]

OpenPLi 7 accepteert volgens mij nog RSA keys (met SHA1).

 

OpenPLi 9 accepteert geen DSA en RSA keys meer, en geen keys die gebruik maken van SHA1 of DH-group-1.

 

Mijn keuze voor ecdsa-sha2-nistp256 was meer ingegeven door een zo breed mogelijke acceptatie van de systemen waar ik verbinding mee maken moet, niet echt omdat het de meest secure is. De keuze voor ecdsa-sha2-nistp521 op de box (maar dat is voor jou niet relevant) is dat 521 iets meer secure is dan 256 (en gaat dus hopelijk wat langer mee).

 

Als je wilt weten wat een systeem accepteert, je kunt alle ondersteunde ciphers, MACs en key zien door gebruik te maken van

~
[wanwizard@alfred] $ ssh -vv root@dual
OpenSSH_9.0p1, OpenSSL 3.0.9 30 May 2023
debug1: Reading configuration data /home/wanwizard/.ssh/config
debug2: resolving "dual" port 22
debug1: Connecting to dual [172.19.12.63] port 22.
debug1: Connection established.
...
debug2: KEX algorithms: sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
...
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group14-sha256,kexguess2@matt.ucc.asn.au
debug2: host key algorithms: ecdsa-sha2-nistp521,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes256-ctr
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes256-ctr
debug2: MACs ctos: hmac-sha1,hmac-sha2-256
debug2: MACs stoc: hmac-sha1,hmac-sha2-256
debug2: compression ctos: zlib@openssh.com,none
debug2: compression stoc: zlib@openssh.com,none
debug2: languages ctos: 
debug2: languages stoc: 
...

het eerste blok is wat de client kant ondersteund, het tweede blok is wat de server kant ondersteund.

 

De leut is dan vervolgens om een zo goed mogelijke match te vinden,

O.k., dat is duidelijke taal.

Bedankt voor de info.

[littlesat]

Hier heb ik het nu opgelost met puttygen met de instellingen van mijn eerder aangegeven snapshot...