Ssh_config, problem z kluczami SSH i hasłami w programach z GUI po aktualizacji Fedora 33 do 34 (KDE/Plasma)

Oprogramowanie komputerowe GNU/Linux
#1

Od dawna używam takiej konfiguracji ssh_config. Loguję się po SSH po klucz i haśle, jeśli tego klucza nie ma na serwerze. Po aktualizacji z Fedora 33 do 34 mam taki problem, ze Krusader czy Nautilus nie chcą mnie logować po haśle (nie pytają o nie) na poniższej konfiguracji. Działają tak, jakby chciały koniecznie użyć klucza, którego nie ma dla niektórych serwerów.

Terminal SSH działa poprawnie.

Host *
    ServerAliveInterval 120
    #Legacy
    KexAlgorithms diffie-hellman-group1-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
    IdentityFile ~/.ssh/klucz1
    IdentityFile ~/.ssh/klucz2
    IdentityFile ~/.ssh/klucz3
    IdentityFile ~/.ssh/klucz4

Część kluczy jest szyfrowana.

Jeśli usunę wszystkie IdentityFile, to wydaje się wszystko działać i w terminalu i w programach dla KDE, ale np terminal w PHP Storm nie widzi żadnego klucza, przez co zawsze forsuje hasło.

Poniekąd rozwiązaniem na ten problem jest to:

Host *
    ServerAliveInterval 120
    #Legacy
    KexAlgorithms diffie-hellman-group1-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1

Host hostnr4.com
    IdentityFile ~/.ssh/klucz4

Ale w tym wypadku z PHP Storm z wbudowanego terminala zaloguje się po kluczu tylko na hostnr4.com. A chciałbym się logować wszędzie - tam gdzie jest użyty klucz SSH po klucz, a tam gdzie nie ma, to po haśle.

Co mam zmienić w ssh_config, zeby działalo po staremu?

#2

Widzę opensuse, jaka/która plasma, jajko?
bo był problem z jednym jajkiem
W 5,14 chyba naprawili
Nic Ci config nie da, jak Ci system nie przepuści-tak w skrócie
Walczyłem kiedyś z kluczami i ssh włáśnie z KDE.
głupi portfel mi blokował

#3

Nie oglądaj awatarów :slight_smile: Kiedyś był openSUSE, na którym też ta konfiguracja działała, teraz jest Fedora 34 po aktualizacji z 33, jw. pisałem.

Jądro to 5.14.11-200.fc34.x86_64.

No właśnie portfel też jest podejrzany, ale czy to na pewno on. Przy wpisaniu loginu z tyłka np hfiaufhaiaf@serwer nie monituje o hasło, a jeśli wpisze istniejącego użytkownika, który nie ma klucza SSH, to zczytuje hasło z portfela. Co ciekawe np gdy nie odszyfruje klucza prywatnego w ssh-agencie, to Krusader cyz Nautilus monitują o hasło do klucza i wpusczają.

[DODANE 15:47]

Choć po przelogowaniu już zaczyna pytać o hasła dla loginów, które nie sitnieją. Sam nie wiem, ale wg mnie KDE w jakiś sposób inaczej odczytuje plik ssh_config i nie wiem dlaczego.

#4

Przeinstaluj to wszystko, wyłącz walleta restart i zobacz.

#5

Mogę przeinstalować, ale wątpię, aby cokolwiek to zmieniło. Na złość teraz ta konfiguracja jako tako działa, poza mankamentem z PHP Storm. W innym IDE używam jawnie kluczy lub hasła, więc nie ma z tym problemu.

Zobaczę też na laptopie na niemal identycznej konfiguracji.

Ja mam zestaw:
kf5-kwallet.x86_64 5.85.0-1.fc34
kf5-kwallet-libs.x86_64 5.85.0-1.fc34
kwalletmanager5.x86_64 20.12.2-1.fc34
pam-kwallet.x86_64 5.22.5-1.fc34
ksshaskpass.x86_64 5.22.5-1.fc34

kwallet+kwalletmanager nie używam.

#6

Chyba doszedłem, że to ssh-agent coś miesza.

Jesli mam w pliku ssh_config wpisy IdentityFile to:
Jeśli po starcie systemu wpiszę w Nautilusa sftp://login@serwer:port/, to normalnie zczytuje hasło i od razu wchodzi, ewentualnie pyta o hasło. Ale wystarczy, że dodam klucze przez ssh-add ~/.ssh/klucz1 aż do klucz3, to Nautilus przestaje się próbować logować po haśle. Jeśli wpiszę ssh-add -D i usunę wszystkie klucze ze sesji, to Nautilus znowu zaczyna działać.

jeśli zaś usunę wszystkie wpisy IdentityFile to praktycznie wszystko działa ale z pewną uwagą. Gdy loguje się z terminala PHP Stormowego, to zamiast użyć klucza, to pyta o hasło do serwera. Ale wystarczy w systemie wpisać ssh-add ~/.ssh/klucz4 i już poprawnie widzi klucz.

W międyczasie użyłem jeszcze update-crypto-policies --set DEFAULT:FEDORA32, ale nie pomogło.

#7

Nie wiem, czy to ma związek z PHP Storm, ale ostatnia aktualizacja OpenSSH wyłączyła SHA1.

Potentially-incompatible changes

This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K [1]

For most users, this change should be invisible and there is
no need to replace ssh-rsa keys. OpenSSH has supported RFC8332
RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys
will automatically use the stronger algorithm where possible.

Incompatibility is more likely when connecting to older SSH
implementations that have not been upgraded or have not closely tracked
improvements in the SSH protocol. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options. For example, the following stanza in ~/.ssh/config will enable
RSA/SHA1 for host and user authentication for a single destination host:

Host old-host
    HostkeyAlgorithms +ssh-rsa

PubkeyAcceptedAlgorithms +ssh-rsa

We recommend enabling RSA/SHA1 only as a stopgap measure until legacy
implementations can be upgraded or reconfigured with another key type
(such as ECDSA or Ed25519).

[1] „SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust” Leurent, G and Peyrin, T
(2020) https://eprint.iacr.org/2020/014.pdf

Dla ssh-agent w zasadzie tak działa, że pierwszeństwo mają klucze, potem dopiero hasło.

1 polubienie
#8

Akurat tego powodu nie czytałem, jedynie o tym, aby zmienić konfigurację, co wcześniej uczyniłem, ale nie pomogło. Akurat tu nie ma związku, bo wśród pojedynczych muzealnych hostów ten z PHP Storm jest nowy.

Co do zasady to rozumiem działania ssh-agenta na pustym ssh_config, jednak oczekiwanie działanie w przypadku uzupełnienia IdentityFile jest takie, że najpierw sprawdza klucze SSH, zaś ostatecznie używa hasła, o czym zapewne mówi wpis PasswordAuthentication yes. I dokładnie tak działa bazowy terminal w systemie, a uściślając zapewne klient „ssh”…