Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Lepiej aktualizacja do Bustera i repo buster-backports:
https://packages.debian.org/pl/buster-backports/openssh-server
Tam jest wersja 8.4, czyli podobna.
Możesz też użyć zamiast Openssh Dropbeara, działa grzecznie, aczkowiek w Debianie się dziwnie instaluje,
Debian u mnie koniecznie chciał go wpakować do intramfs skryptem post-instalacyjnym, czy jakąś podobną szaloną akcje wykonać, już nie pamiętam dokładnie.
Jest do wszystkich wersji dostępny:
https://packages.debian.org/search?lang=pl&sear … ords=dropbear
Dropbear jest ze dwa razy lżejszy od Openssh,
OpenWRT go domyślnie i bezproblemowo używa.
Dowód rzeczowy:
ssh router dropbear -help 2>&1 |head -n1 Dropbear server v2020.81 https://matt.ucc.asn.au/dropbear/dropbear.html
Pozdro
Ostatnio edytowany przez Jacekalex (2022-11-28 17:52:41)
Offline
Dzięki za sugestie, nie za bardzo chcę mocno ruszać debiana 9, choć jeśli nie znajdę rozwiązania to i tak się stanie, że 10 wrzucę.
Mi chodzi o uruchomienie yubikey, a da się to zrobić od wersji 8.2
Ostatnio edytowany przez noyo (2022-11-28 18:17:24)
Offline
Mieszanie repozytoriów wymaga starannej konfiguracji /etc/apt/apt.conf ale jest jak najbardziej wykonalne miedzy sąsiednimi wydaniami.
Chociaż najpierw zacznij od backupu, nowszy SSH może pociągnąć nowszą bibliotekę libc6,
a ta może od razu pociągnąć do aktualizacji pół systemu.
Lepiej od razu fruwać na jakiś aktualny system.
Z Dropbearem też się niby da Yubi używać, chociaż jeszcze tego nie testowałem.
https://forum.openwrt.org/t/does-anyone-use-a-yubik … for-ssh/70960
Ostatnio edytowany przez Jacekalex (2022-11-29 00:29:11)
Offline
Dzięki! Działa :)
Na czystym debianie 9 bez problemu przyjęło repo backports debiana 10 i zainstalowało nowa wersje openssh.
Może wiesz jeszcze jak zablokować zainstalowaną wersje openssh ? Aby przy jakiejś aktualizacji nie zmieniło wersji?
Dla potomnych:
Edytujemy /etc/apt/sources.list
Haszujemy wszystko i dodajemy na końcu:
deb http://ftp.pl.debian.org/debian/ buster-backports main contrib non-free deb-src http://ftp.pl.debian.org/debian/ buster-backports main contrib non-free deb http://ftp.pl.debian.org/debian/ buster main contrib non-free deb-src http://ftp.pl.debian.org/debian/ buster main contrib non-free deb http://security.debian.org/ buster/updates main contrib non-free deb-src http://security.debian.org/ buster/updates main contrib non-free
Zapisujemy.
Wykonujemy polecenia:
apt update
apt-get -t buster-backports install openssh-server
Mamy już zainstalowanego openssh-server w wersji 8.4p1
Jeszcze tylko przywracamy poprzednie repo, czyli edytujemy /etc/apt/sources.list, usuwamy to co dodaliśmy wcześniej i odhaszowujemy to co zahaszolwaliśmy.
Odświeżamy repo komendą:
apt update
Zostaną zainstalowane następujące NOWE pakiety: libcbor0 libcom-err2 libfido2-1 libunistring2 Następujące pakiety zostaną zaktualizowane: libc-bin libc-l10n libc6 libcomerr2 libgssapi-krb5-2 libidn2-0 libk5crypto3 libkrb5-3 libkrb5support0 libssl1.1 locales openssh-client openssh-server openssh-sftp-server
Ostatnio edytowany przez noyo (2022-11-29 14:41:36)
Offline
Taka zmiana jak wyżej opisałem negatywnie wpływa na proxmoxa w wersji 5, taki błąd wyskakuje:
proxmox IPCC.xs[4261]: PAM unable to dlopen(pam_unix.so): /lib/security/pam_unix.so: cannot open shared object file: No such file or directory
Należy, przed zmianą wersji openssh, dodać użytkownika pve w gui.
Ostatnio edytowany przez noyo (2022-11-30 10:38:18)
Offline
Włączając i wyłączając repo, robisz kompletny burdel w systemie.
Jak Ci wciągnął nowe libc6 z repo bustera to tragedii nie ma, pam też możesz z tego repo zainstalować i powinno śmigać.
To w kontekście tej brakującej pam_unix.so
Oczywiście nie wiem, czy Proxmox nie "dostanie kataru" od tego.
Ale od tego właśnie masz backup, prawda?
:P
Co do blokowania wersji to jest
aptitude hold {paczka}
tylko jak Ci przy aktualizacji dpkg cofnie wersję libc6 albo openssl do tej z Debka 9 to SSH z bustera może zdechnąć i to dopiero będzie przypał.
Dlatego blokowanie wersji można robić jak się diabelnie dokładnie zna możliwe konsekwencje.
Przed taką zabawą wystaw sobie drugi serwer SSH na tej maszynie, żeby chodził równolegle z OpenSSH, wspomniany Dropbear np.
EDIT:
porównaj sobie zależności binarki od bibliotek systemowych:
# root ~> ldd `which sshd` linux-vdso.so.1 (0x00007ffd279c5000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007addbed0b000) libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007addbecda000) libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007addbecc8000) libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007addbec13000) libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007addbe91f000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007addbe918000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007addbe8fb000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007addbe8c0000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007addbe894000) libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007addbe841000) libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007addbe767000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007addbe75f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007addbe57e000) libnsl.so.2 => /lib/x86_64-linux-gnu/libnsl.so.2 (0x00007addbe563000) libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007addbe55b000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007addbe556000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007addbe551000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007addbe54a000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007addbe522000) libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007addbe447000) liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007addbe424000) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007addbe2dd000) /lib64/ld-linux-x86-64.so.2 (0x00007addbee0f000) libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007addbe243000) libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007addbe213000) libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007addbe204000) libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007addbe1fd000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007addbe1ec000) libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007addbe1ba000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007addbe194000)
# root ~> ldd `which dropbear` linux-vdso.so.1 (0x00007ffd321a6000) libtomcrypt.so.1 => /lib/x86_64-linux-gnu/libtomcrypt.so.1 (0x00007263ae0c0000) libtommath.so.1 => /lib/x86_64-linux-gnu/libtommath.so.1 (0x00007263ae0a0000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007263ae09b000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007263ae07e000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007263ae043000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007263ade60000) libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007263adddf000) /lib64/ld-linux-x86-64.so.2 (0x00007263ae1e5000)
Różnica w zależnościach od bibliotek systemowych jest widoczna bez specjalnych okularów.
xD
Pozdro
Ostatnio edytowany przez Jacekalex (2022-12-01 13:13:22)
Offline
Zostaje tylko mieć gdzieś z tyłu głowy, aby uważać z aktualizacją i jak najszybciej podnieść wersję debiana.
Jak coś mam do tych maszyn dostęp fizyczny, więc jak się wysra to się naprawi :)
Backup tez jakiś jest.
Dzięki za podpowiedzi.
Ostatnio edytowany przez noyo (2022-12-01 19:23:06)
Offline