2023-10-24:su: PAM unable to resolve symbol: pam_sm_acct_mgmt

仲間から「アップデート掛けたら su ができなくなったマシンがあるんでみてほしい」とへぷる要望あり。

一般ユーザーでログインして、そこで sudo コマンドは効く。
のだけど、たとえば sudo su – とかしようとすると、できなくて、/var/log/secure には

Oct 24 08:12:34 devmachine su: PAM unable to resolve symbol: pam_sm_acct_mgmt

というログが出る。
pam_sm_acct_mgmt は /usr/lib64/security/pam_unix.so のなかにあり、なんというか、こいつが解決できないってどういうこと？という。。。
ちなみにマシンは CentOS Linux release 7.9.2009 (Core)
CentOS 7 なんてヤメレ、という意見もあろうけど、現用系とのことでしょうがない。

いろいろググってみるも、pam RPM のバージョンを変えて入れてみろとかあまり役に立つものなし。
そういえば、別で CentOS 7 のマシンあったな、と思い出したのでログインして確認してみる。
そっちの CentOS7 は、長らく yum update してないものの、redhat-release ファイルは同じく CentOS Linux release 7.9.2009 (Core)

で、こっちでは sudo su – に成功する。おお！
入ってる pam RPM のバージョンは同じ、pam_unix.so の sha1sum も同じ。

んー、じゃあ、pam の設定ファイルか？、と /etc/pam.d/su を見てみる。
すると、できるマシンとできないマシンで差分があることを発見。
出来ない方では冒頭に

# Added by Google Compute Engine OS Login.
account    [success=bad ignore=ignore] pam_oslogin_login.so

というのがいる。
どうも、この子（pam_oslogin_login.so）がアレらしい。

乱暴だけど、この account 行をコメントに。
したら su ができるようになった。

ちなみに、もともとできたマシンの方には pam_oslogin_login.so がいない。オンプレマシンでした。
できなくなった子は Google Cloud なマシンだったそうで。
とりあえず、su ができるようになったと喜んでいたので、僕はこれ以上は手を出さず^^;

github にレポジトリあって、ここに issue 報告したらいいのかもだけど、CentOS7 の話をするのも、ねぇ。

2021-10-13:vault.centos.org と letsencrypt ca 証明書問題

無料の証明書発行サービス Let’s Encrypt の使用していたルート証明書 DST Root CA X3 が9月末に切れた問題が vault.centos.org に波及していることに気付く。

昨年11月30日にサポートが終了した CentOS6 だけども、いまでもけっこうな数が現地運用されていて、レポジトリ URL を mirrorlist.centos.org から vault.centos.org に書き換えれば yum コマンドを使い続けられるよ、というのはよく知られたハック。
ただし、yum コマンドはその中で指定された URL から wget で rpm ファイル取得しようとするので、↑の DST Root CA X3 期限切れに伴い、

vault.centos.org が信頼できんわ

を処理に失敗してしまう。

クライアント側に有効な CA 証明書がないから検証できないという問題なので、解決のためには有効な CA 証明書があればいい。
vault.centos.org には更新用の ca-certificates RPM があり、これを取得して更新インストールする。
yum だと証明書エラーでコケるので、手動で（証明書エラーを無視して）wget で RPM を取得して rpm -Uvh で入れる。
依存関係から p11-kit, p11-kit-trust も要求されるので、これらも wget の上、先に rpm -Uvh しておく。

# wget --no-check-certificate https://vault.centos.org/centos/6/updates/x86_64/Packages/ca-certificates-2020.2.41-65.1.el6_10.noarch.rpm
# wget --no-check-certificate https://vault.centos.org/centos/6/os/x86_64/Packages/p11-kit-0.18.5-2.el6_5.2.x86_64.rpm
# wget --no-check-certificate https://vault.centos.org/centos/6/os/x86_64/Packages/p11-kit-trust-0.18.5-2.el6_5.2.x86_64.rpm
# rpm -Uvh p11-kit-0.18.5-2.el6_5.2.x86_64.rpm p11-kit-trust-0.18.5-2.el6_5.2.x86_64.rpm
# rpm -Uvh ca-certificates-2020.2.41-65.1.el6_10.noarch.rpm

これで wget で vault.centos.org から証明書エラーなく rpm ファイルが取得できるようになり、yum コマンドが復活。

2016-12-05:Windows7 で sshd を動かす

要望あって、Windows マシンに sshd 立てて sftp でファイルをやりとりするサーバに、という案件。
いまって Windows 版の OpenSSH なんてあるのねー。
というわけで、セットアップ.

GitHub : PowerShell/Win32-OpenSSH
https://github.com/PowerShell/Win32-OpenSSH/releases

ここから zip ファイルをダウンロードし、C:\ 直下に展開。
自分の場合、C:\OpenSSH-Win64\ になる。これを環境変数 Path にいれる。「マイコンピュータを右クリックのプロパティ」→「システムの詳細設定」→「環境変数」→「システム環境変数の Path の編集」で、末尾に「;C:\OpenSSH-Win64」を追記。

22番ポート以外で動かしたかったので sshd_config を編集。鍵認証の指定もついでに。

Port 22222
PubkeyAuthentication yes

次に、その 22222 のポートを Firewall 的に開ける。
自分は ESET Smart Security なので、そっちで設定。Windows 標準の Firewall だったり、違うセキュリティソフトの方は、適宜それぞれの設定で。

あとは PowerShell で作業。
管理者権限で PowerShell 起動して、

> cd C:\OpenSSH-Win64
> ssh-keygen.exe -A
C:\OpenSSH-Win64\ssh-keygen.exe: generating new host keys: RSA DSA ECDSA ED25519
> Set-ExecutionPolicy Unrestricted
実行ポリシーの変更
実行ポリシーは、信頼されていないスクリプトからの保護に役立ちます。実行ポリシーを変更すると、about_Execution_Policies
のヘルプ トピック (http://go.microsoft.com/fwlink/?LinkID=135170)
で説明されているセキュリティ上の危険にさらされる可能性があります。実行ポリシーを変更しますか?
[Y] はい(Y)  [N] いいえ(N)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"):
> .\install-sshlsa.ps1
> .\install-sshd.ps1
[SC] SetServiceObjectSecurity SUCCESS
[SC] ChangeServiceConfig SUCCESS
 Granting SeAssignPrimaryTokenPrivilege to NT SERVICE\SSHD   ... successful
sshd and ssh-agent services successfully installed
> Set-ExecutionPolicy RemoteSigned
実行ポリシーの変更
実行ポリシーは、信頼されていないスクリプトからの保護に役立ちます。実行ポリシーを変更すると、about_Execution_Policies
のヘルプ トピック (http://go.microsoft.com/fwlink/?LinkID=135170)
で説明されているセキュリティ上の危険にさらされる可能性があります。実行ポリシーを変更しますか?
[Y] はい(Y)  [N] いいえ(N)  [S] 中断(S)  [?] ヘルプ (既定値は "Y"):
>

一時的にセキュリティを落としてからセットアップをして、終わったら戻す、という感じ。
以上で設定終了で、あとは起動するだけ。
自動起動の設定もしておこう。

> net start sshd
sshd サービスを開始します.
sshd サービスは正常に開始されました。
> Set-Service sshd -StartupType Automatic
>

サーバの C:\Users\{ユーザー名}\.ssh\ 以下に authorized_keys を置いておけば、鍵認証で ssh のログインができる。
scp でファイルのやりとりも可能。
すばらしい。

以下は個人的にはまったネタ。解決に1時間以上かかった。
この Windows 版の OpenSSH、実は

Compression に対応していない！

ので、つなぎにいくクライアントサイドで Enable Compression とか、.ssh/config に Compression yes とか書いてると、接続できない。
もし自分以外にも接続できずに困っている方がいらっしゃいましたら、圧縮設定を見てみていただきたく。

この問題、接続できないならできないでその理由を吐けばいいものを、

% ssh -p 22222 192.168.0.101
buffer_get_ret: trying to get more bytes 1 than in buffer 0
buffer_get_char_ret: buffer_get_ret failed
buffer_get_char: buffer error

これしか言われない。
-v をつけても大して得られる情報なし。これじゃエラー内容分かんないよ！！！

試行錯誤の過程で、サーバ側の .ssh/authorized_keys をどかしてパスワード認証にしたりするも

% ssh -p 22222 192.168.0.101
waasuke@192.168.0.101's password: 
Permission denied, please try again.
waasuke@192.168.0.101's password: 
buffer_get_ret: trying to get more bytes 1 than in buffer 0
buffer_get_char_ret: buffer_get_ret failed
buffer_get_char: buffer error

エラーは同じ。
なお、↑の最初のパスワード入力はわざと間違えてて、サーバが正しくパスワード認証をしてることはまではこれで把握。

サーバ側にログないのかな、と探すと、インストール直下に sshd.log がある。
しかし開いてみても、、、

2888 23:03:20 455 Failed password for waasuke from 192.168.0.62 port 45020 ssh2
2888 23:03:22 341 Accepted password for waasuke from 192.168.0.62 port 45020 ssh2

これだけ。
やっぱり役に立たNEEEEE!!!

で、ウンウン唸ってたら、仲間が「別のクライアントならどうだ？」とアドバイスをくれた。
Windows クライアントの PuTTY を試す。なんとログイン成功！
えーーー
これまでハマってた CentOS の ssh クライアントと何が違うんだ。。。
文字コード？改行コード？

しばらくして、さらに「.ssh/config じゃね？」とコメントをもらう。
いったんどかしてみたら、CentOS の ssh クライアントからもログインできた。
ここまできたらかなりの絞り込めたね。
あとは .ssh/config の設定をコメントアウトしたりひとつひとつ試し、結果、Compression yes がガンであることが判明。
ついでに Enable Compression にチェックを入れた PuTTY でのログイン失敗も確認。
やれやれ。。。

ちなみに、sshd_config には #Compression delayed とデフォルトでコメントアウトで入っているのだけど、これをコメントはずして値を yes にして sshd を再起動しても、圧縮ありにしたクライアントからの接続はできず。
sshd 自体に実装が入ってないのかー。
と思って project ページをよく見ると、

https://github.com/PowerShell/Win32-OpenSSH/wiki/Project-Scope
Intent of this project is to get to a state that can converge to and integrate into OpenSSH’s main repo. To simplify this integration, following features have been scoped out and will not work on Windows yet:

– VerifyHostKeyDNS
– Client ControlMaster
略
– Compression
– ProxyCommand (Windows specific feature/work items)
略

ちゃんと書いてはありましたね。。。

（Compression を実装していないことを責めてるわけじゃもちろんないです。むしろポ―ティングには感謝。
（ただ、分からないエラーメッセージには文句言いたい。サーバサイドもクライアントサイドも。

2015-12-16:ELECOM Bluetoothマウス CAPCLIP 3ボタン IRLED搭載 充電式

日常のデスクワークで Bluetooth のマウスを使ってるんだけど、ちょいちょい反応しなくてイライラすることがある。
で、今週は段取り失敗やら自分のミスやらがつのっててそもそも機嫌が悪く、そこに急遽反応しなくなるマウスにかなり苛立ってしまい、「あーもうっ！」と床に向かって投げつけたところ、お陰様できちんと壊れてくれました。ちーん。。。

しばらくレッツノートの静電タッチパッドでのポインティング入力。ただ、やっぱり使いづらい。
しょうがないので（って、自業自得なんだけど）、新しいのを買ってきた。
それがこの ELECOM の CAPCLIP というマウスで、見た目おもちゃ。
が、これがなかなかどうして買い物でした。

本体とキャップからなるこの製品、使うときはキャップを本体のおしり側にはめる。
大きさはかなり小さいのだけど、キャップとあわせると長さがあるので持ちづらいということはない。分解能も1200あるのでそれなりにカーロスが大きく動いて嬉しい（自分の仕事場は20インチモニタ2枚含めて4画面構成）。
使わないときは電源おとしてキャップをかぶせる。これまで使ってたマウスは移動時にむき出しで鞄に放り込んでいたのでホイールボタンのところがおかしくなりがちだったり、不用意にスイッチが入ってたりということがあったんだけど、それがないのは嬉しい。いや、前のも商品パッケージとしては収納ポーチがついてたんだけど、

そんなものはすぐに失くす

のよね。今回の場合、使用時も使用してないときも常に一緒にいさせるデザインなのが安心。
あと、今回のは本体にリチウムイオン電池搭載の充電式。おしりのカバーを開けると microUSB 端子がある。いままでのは単4電池2本だったので、eneloop 使ってたんだけど、これの充電からも解放されるな。
というわけで、期せずして(?)新しいマウスに変えたけど、いい結果になりました、というポストでした。
ちなみにいままでのより値段は安い。。。

参考に、いままでのはこちら（←）です。
別にこれも悪い商品というわけじゃない。これまで2年くらい使ってた気がするし。