20211007のLinuxに関する記事は4件です。

Raspberry Pi に Arch Linux をインストール

RaspberryPi4 に Arch Linux をインストールして、クロスのイーサーネットケーブルで接続するまでの方法です。 Host 192.168.0.10 RaspberryPi 192.168.0.13 ダウンロードするファイル ArchLinuxARM-rpi-4-latest.tar.gz マイクロSD カードの作成 パーティションの削除と作成 # fdisk /dev/mmcblk0 Welcome to fdisk (util-linux 2.37.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/mmcblk0: 14.84 GiB, 15931539456 bytes, 31116288 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x9730496b Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 2048 411647 409600 200M c W95 FAT32 (LBA) /dev/mmcblk0p2 411648 31116287 30704640 14.6G 83 Linux ファイルシステムの作成 # mkfs.vfat /dev/mmcblk0p1 # mkfs.ext4 /dev/mmcblk0p2 マウントポイントの作成 # mkdir /mnt/raspberry # mkdir /mnt/raspberry/boot # mkdir /mnt/raspberry/root マウント # cd /mnt/raspberry # mount /dev/mmcblk0p1 boot # mount /dev/mmcblk0p2 root ダウロードしたファイルの展開 # cd /mnt/raspberry # bsdtar -xpf /home/uchida/ArchLinuxARM-rpi-4-latest.tar.gz -C root # sync rootフォルダーから bootフォルダーへファイルを移動 # mv root/boot/* boot boot/config.txt の編集 gpu_mem=64 hdmi_force_hotplug=1 hdmi_group=2 hdmi_mode=35 hdmi_drive=2 ネットワークの設定 /etc/systemd/network/eth0.network [Match] Name=eth0 [Network] DHCP=false Address=192.168.0.13/24 Gateway=192.168.0.10 DNS=192.168.1.1 # DHCP=yes # DNSSEC=no アンマウント # umount /dev/mmcblk0p1 # umount /dev/mmcblk0p2 MicroSD カードを、Raspberry Pi の底面に差して、電源を入れる。 クロスケーブルで接続 User: alarm Password: alarm $ ssh alarm@192.168.0.13 alarm@192.168.0.13's password: Welcome to Arch Linux ARM Website: https://archlinuxarm.org Forum: https://archlinuxarm.org/forum IRC: #archlinuxarm on irc.libera.chat $ uname -a Linux alarmpi 5.10.46-1-ARCH #1 SMP Mon Jun 28 19:14:16 UTC 2021 armv7l GNU/Linux $ cat /etc/os-release NAME="Arch Linux ARM" PRETTY_NAME="Arch Linux ARM" ID=archarm ID_LIKE=arch BUILD_ID=rolling ANSI_COLOR="38;2;23;147;209" HOME_URL="https://archlinuxarm.org/" DOCUMENTATION_URL="https://archlinuxarm.org/wiki" SUPPORT_URL="https://archlinuxarm.org/forum" BUG_REPORT_URL="https://github.com/archlinuxarm/PKGBUILDs/issues" LOGO=archlinux su で root になれます。パスワードは root [alarm@alarmpi ~]$ su Password: [root@alarmpi alarm]# ホスト側で IP FORWARD の設定 ホスト経由でインターネットに接続する為に必要です。 sudo sysctl net.ipv4.ip_forward=1 sudo iptables -t nat -A POSTROUTING -o wlp2s0 -j MASQUERADE sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT sudo iptables -A FORWARD -i enp3s0f2 -o wlp2s0 -j ACCEPT pacman -Syu でエラーが出た時の対策 初回に次のようなエラーが出ます。 error: key "77193F152BDBE6A6" could not be looked up remotely error: required key missing from keyring error: failed to commit transaction (unexpected error) 対策 # pacman-key --populate archlinuxarm こちらを参考にしました。 Raspberry Pi 4にArch Linuxをインストール
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gtk3アプリ パーシャルクラス自動生成ツール

パーシャルクラス自動生成ツール Release 既存のクラスからパーシャルクラスを生成す るツールを作りました。 使い方 Riderの外部ツールに登録する 引数を設定する 引数はReadMeを参照ください ファイル名に使いたい文字をコピーする エクスプローラーで生成したい元クラスを選択する 元のクラスの中身 外部ツール 実行する Riderのエクスプローラーの右クリックから実行します 生成されたパーシャルクラス パーシャルクラスが同じ階層に生成されます。 生成されたパーシャルクラスの中身 続く
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Rocky Linux8 →MIRACLE LINUX8 にしてみる

リポジトリ定義を変更して、dnfが通るかどうかを確認してみました。 Rocky Linux8は以下の状態のVMです。 Rocky-8.4-x86_64-dvd1.iso からインストール dnfでのアップデートは一切なし Rocky Linuxの状態確認 /etc/os-release NAME="Rocky Linux" VERSION="8.4 (Green Obsidian)" ID="rocky" ID_LIKE="rhel fedora" VERSION_ID="8.4" PLATFORM_ID="platform:el8" PRETTY_NAME="Rocky Linux 8.4 (Green Obsidian)" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:rocky:rocky:8.4:GA" HOME_URL="https://rockylinux.org/" BUG_REPORT_URL="https://bugs.rockylinux.org/" ROCKY_SUPPORT_PRODUCT="Rocky Linux" ROCKY_SUPPORT_PRODUCT_VERSION="8" /etc/redhat-release Rocky Linux release 8.4 (Green Obsidian) アップデート作業 リポジトリ定義を追加 ファイルを作成 /etc/yum.repos.d/miraclelinux.repo # miraclelinux.repo [8-latest-BaseOS] name=8-latest-BaseOS mirrorlist=https://repo.dist.miraclelinux.net/miraclelinux/mirrorlist/$releasever/$basearch/baseos enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY [8-latest-AppStream] name=8-latest-AppStream mirrorlist=https://repo.dist.miraclelinux.net/miraclelinux/mirrorlist/$releasever/$basearch/appstream enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY まずは通常のアップデート sudo yum -y erase rocky-indexhtml sudo dnf check-update --disablerepo=* --enablerepo=8-latest-BaseOS,8-latest-AppStream sudo dnf -y update --disablerepo=* --enablerepo=8-latest-BaseOS,8-latest-AppStream --allowerasing --nogpgcheck ※rocky-indexhtml 以外にもエラーになるパッケージがある場合にはあらかじめ erase この段階では正常終了。 Rocky固有のパッケージを置き換える パッケージ確認 $ rpm -qa | grep ^rocky- rocky-repos-8.4-26.el8.noarch rocky-logos-84.5-7.el8.x86_64 rocky-backgrounds-84.5-7.el8.noarch rocky-gpg-keys-8.4-26.el8.noarch rocky-release-8.4-26.el8.noarch 置き換え sudo dnf -y downgrade setup --disablerepo=* --enablerepo=8-latest-BaseOS,8-latest-AppStream --nogpgcheck sudo rpm -e rocky-release rocky-repos rocky-gpg-keys rocky-backgrounds rocky-logos --nodeps sudo dnf -y install redhat-release system-logos system-backgrounds miraclelinux-repos miraclelinux-logos miraclelinux-backgrounds miraclelinux-release --nogpgcheck --releasever=8 他のパッケージを確認 $ rpm -qa |grep rocky anaconda-gui-33.16.4.15-1.el8.rocky.x86_64 platform-python-pip-9.0.3-19.el8.rocky.noarch initial-setup-0.3.81.7-1.el8.rocky.x86_64 initial-setup-gui-0.3.81.7-1.el8.rocky.x86_64 anaconda-user-help-8.3.3-1.el8.rocky.1.noarch anaconda-tui-33.16.4.15-1.el8.rocky.x86_64 python3-cups-1.9.72-21.el8.rocky.x86_64 anaconda-core-33.16.4.15-1.el8.rocky.x86_64 anaconda-widgets-33.16.4.15-1.el8.rocky.x86_64 python3-pip-9.0.3-19.el8.rocky.noarch python3-pip-wheel-9.0.3-19.el8.rocky.noarch MLのパッケージで置き換え sudo dnf -y downgrade anaconda-gui platform-python-pip initial-setup initial-setup-gui anaconda-user-help anaconda-tui python3-cups anaconda-core anaconda-widgets python3-pip python3-pip-wheel sudo dnf -y install miraclelinux-logos-ipa miraclelinux-indexhtml sudo dnf check-update sudo dnf -y update アップデート後の確認 /etc/os-release NAME="MIRACLE LINUX" VERSION="8.4 (Peony)" ID="miraclelinux" ID_LIKE="rhel fedora" PLATFORM_ID="platform:el8" VERSION_ID="8" PRETTY_NAME="MIRACLE LINUX 8.4 (Peony)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:cybertrust_japan:miracle_linux:8" HOME_URL="https://www.cybertrust.co.jp/miracle-linux/" DOCUMENTATION_URL="https://www.miraclelinux.com/support/miraclelinux8" BUG_REPORT_URL="https://bugzilla.asianux.com/" MIRACLELINUX_SUPPORT_PRODUCT="MIRACLE LINUX" MIRACLELINUX_SUPPORT_PRODUCT_VERSION="8" /etc/redhat-release MIRACLE LINUX release 8.4 (Peony) 再起動 さて、起動中の画像はどこで変えるんだったかな…
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

SSHでVPNを張れるらしい

こんにちわ、久しぶりの投稿です。 仕事でL2TP/IPsecなVPNを構築しているのですが、インストールや設定などの手間がそこそこ掛かるので、良い感じにお手軽なVPNは無いか調べていました。 すると、我らがSSH大先生でVPNまで張れちゃうとの情報を入手したので、早速試してみることにしました。 SSH万能すぎん?? 解説 SSH Tunneling - ssh.com SSHには SSH Tunneling という仕組があり、それを利用することでVPNを構築できます。 重要なのは「ベースはSSHだが独立した仕様」ではなく「SSH本体機能の一部」なので、普通に ssh コマンドを叩いてトンネリング有効化のオプションを付与すれば、ポートも認証方式も暗号化も、そっくりそのままVPNを張れるのです。 通常のシェル接続で使用するコネクションやチャネルをそのままトンネリング接続へ転用しているため、技術的には全く同じものとなります。 接続までの流れ 実際に行っている処理は、だいたい下記のようになります。 ローカル・リモート間でコネクションを確立 コネクション内でチャネル0をオープン (シェル用) ローカルとリモートへそれぞれVNICを生成 コネクション内でチャネル1をオープン (トンネリング用) チャネル1の両端をVNICで終端 トンネル開通 イメージ図 [Terminal] [VNIC] [Shell] || || || { -------- SSH Client -------- } | || || | | Connection | | <Ch:0> <Ch:1> | | || || | { -------- SSH Server -------- } || || [Shell] [VNIC] このうち (2) までは、シェル接続とトンネリング接続で同じ挙動となります。 普通にSSH接続する場合はチャネル0を使用してリモートのシェルを操作するだけで事足りるためです。 そして (3) からが、トンネリング接続でのみ行われる処理となります。 と言っても難しい話ではなく、SSHクライアントがローカル (直接) とリモート (チャネル0経由) のシェルへ接続してコマンドを叩き、VNICを生成しているだけです。 VNIC生成の時点で新たにチャネル1が開かれ、チャネル1の両端がVNICで終端されることで、晴れてローカルとリモートを結ぶトンネルが完成となります。 プロトコル VNIC (仮想ネットワークデバイス) として Tun / Tap を利用することから、トンネル内のプロトコルは PPP もしくは Ethernet のどちらを使用するか選択できます。 なおパケット構造については、ローカル・リモート間を往来するのはあくまでSSHパケットなため、データ本体が格納されるエリア (ペイロード) へEthernetやIPのフレームが丸ごと乗っかり、カプセル化されます。 そのため、L2TP/IPsecやOpenVPNなどの専用プロトコルと比較した場合、オーバーヘッドは大きい傾向にあります。 まぁ何より、環境を選ばず手軽に扱えるのがウリなので、効率を求めるなら専用プロトコルを使えば良いだけの話です。 イメージ図 ----------------------------------------------- | SSH Packet | | HEADERS | Payload(Data) | PADDING | ----------------------------------------------- | Ethernet Frame | | HEADERS | Payload | ----------------------- 注意事項 非常に使い勝手の良さそうなSSH Tunnelingですが、1点だけ注意が必要です。 ローカルとリモートの双方でVNICを操作するため、ローカルとリモートのどちらも、ルート権限での実行が必須となります。 SSHサーバーの初期設定値を見てみると、ルートアカウントへのログインはパスワード認証以外で可能、つまり公開鍵認証や証明書認証などの非対称でセキュアな認証方法でのみ可能となっています。 その制限を緩めてパスワード認証でルートログインを許すことは無いと思いますが、公開鍵認証を使用する際も注意を払う必要があります。 例えば公開鍵認証の場合は、使用する暗号アルゴリズムを ED25519 / X25519 などの強固な物のみ使用すうよう明示的に設定したり、それらの暗号アルゴリズムが実際にどう振る舞うのかをよく調べてから使用するようにしましょう。 (この辺の暗号技術については元気があったら別途記事にしようと思います) sshd_config PermitRootLogin prohibit-password 実際に接続してみる ざっくり解説も済んだところで、早速繋いでみたいと思います。 まずSSH Tunnelingを使用するにあたり、そこまで大掛かりではありませんが、いくつかの設定変更が必要となります。 なお、ポート開放やファイアウォール制御については、繰り返しになりますが、あくまで往来するのはSSHパケットそのものなので、既にSSHが接続できる環境であれば変更は不要です。 サーバー設定 サーバー側は sshd_config の <PermitTunnel> を変更するだけです。 <PermitTunnel> クライアントからのトンネリング接続要求を制御します。 yes ... クライアント側でPPPまたはEthernetを選択可能 point-to-point ... PPPのみ許可 ethernet ... Ethernetのみ許可 no ... トンネリングを拒否 (デフォルト値) sshd_config PermitTunnel yes 設定を変更したら、デーモンを再起動して準備完了です。 systemctl restart sshd クライアント設定 クライアント側は ssh コマンドを叩くときにオプションとして全ての設定を指定できます。 しかし、設定項目が多く毎回入力は面倒なので、トンネリング接続用のプロファイルを ~/.ssh/config に作っておくと便利です。 ~/.ssh/config Host (name) HostName (host) Port (port) User root PubkeyAuthentication yes PasswordAuthentication no KbdInteractiveAuthentication no PreferredAuthentications publickey Ciphers aes256-gcm@openssh.com KexAlgorithms curve25519-sha256 MACs hmac-sha2-256-etm@openssh.com HostKeyAlgorithms ssh-ed25519 StrictHostKeyChecking no Compression yes IdentitiesOnly yes IdentityFile /home/(user)/.ssh/(key) Tunnel ethernet TunnelDevice 0:0 PermitLocalCommand yes LocalCommand ifconfig tap0 10.0.0.2 netmask 255.255.255.0 RemoteCommand ifconfig tap0 10.0.0.1 netmask 255.255.255.0 これは私の使い回し用テンプレです。 暗号アルゴリズム周りは、狙った物へ誘導するために1種類へ絞っています。 「誘導」と言ったのは、SSHで実際に使用される暗号アルゴリズムは、クライアント側とサーバー側がそれぞれ持っている複数の候補の中からネゴシエートされるためです。 クライアント側から候補を1個しか提示しなければ、サーバー側はそれを使わざるを得ません。 そして、トンネリング接続に関係する項目は下記となります。 <Tunnel> VNICとしてTunまたはTapのどちらを使用するか指定します。 ethernet ... Tapを使用 point-to-point ... Tunを使用 なお、サーバー側の <PermitTunnel> をどちらかへ制限している場合、クライアント側の <Tunnel> と合致しない場合、接続要求は拒否されます。 <TunnelDevice> VNICを生成する際のデバイス番号を指定します。 0:0 のように記述し、左値はクライアント側で右値はサーバー側のデバイス番号となります。 <PermitLocalCommand> 接続完了後に、後述の <LocalCommand> で記述したコマンドの実行を許可するかを選択します。 yes ... 実行を許可 no ... 実行を拒否 <LocalCommand> <RemoteCommand> 接続完了後にローカルまたはリモートのシェルで実行するコマンドを記述します。 ここでは、接続時に生成されたVNICへIPアドレスを割り当てています。 他にも、IPマスカレードやルーティングなどもここへ記述できるため、活用の幅が広がります。 鍵生成 この辺は既出情報が豊富なため、本記事に必要か迷いましたが、使用する暗号アルゴリズムについて少し触れたので、ついでに載せておきます。 ssh-keygen ssh-keygen -q -t ed25519 -N "" -f ./(key) これも私の使いまわし用テンプレです。 2021年現在、公開鍵はとりあえずED25519/X25519を使用しておけば、まず間違いは無いと思います。 接続 さて、いよいよ接続です。 ssh コマンドをルート権限で実行しますが、ここで注意したいのは、ルート権限で実行した場合にデフォルトで読み込むコンフィグファイルは ~/.ssh/config ではなく /etc/ssh/ssh_config となります。 そして sudo コンテキスト内では ~ が指し示すディレクトリは置き換わるので、ホームディレクトリ配下にアクセスしたい場合はフルパス指定が必須となります。 そのため -F オプションを付与し、コンフィグファイルの読み込み先をフルパスで指定する必要があります。 プロファイルの <IdentityFile> がフルパスで指定されているのも同じ理由です。 sudo ssh -Nq -F /home/(user)/.ssh/config (profile) コマンドを入力し、何も応答が返らなかったら接続成功です。 応答が返らない間は、常にトンネリング状態となります。 トンネリング状態を解除 (切断) したい場合は CTRL+C で切断できます。 なお、VNICは切断時に自動で削除されるため、切断後の手動削除は不要です。 ifconfig や nmcli connection show などでネットワークインターフェースを確認すると、IPアドレス付与済のVNICが生成されていると思います。 もしインターフェースが見当たらなかったら、どこかで接続が失敗しています。 -vvv オプションを付与し、ログを確認してみてください。 おわりに 今回はVNICを使ったVPNでしたが、思ったより簡単に動いて驚きました。 SSHは他にも ポートフォワード というVPN機能があるので、今度はそちらも試してみたいと思います。 ポートフォワードはVNICを使用せずルート権限が不要なため、敷居も下がるかと思います。 いやSSH万能すぎん?????? 参考 - 公開鍵暗号の強度 参考として、各種公開鍵暗号の強度について載せておきます。 複数の暗号アルゴリズムを組み合わせた場合の最終的なセキュリティ強度は、その中で最低強度のアルゴリズムへ依存します。 例えばRSA-2048 (112bit) とAES-256 (256bit) を組み合わせた場合、総合的な強度は112bitとなります。 公開鍵 種類 強度 (bits) 備考 RSA-2048 RSA 112 や め と け RSA-3072 RSA 128 演算が非効率的 (遅い)古代遺産にも対応ECCが使えないとき用 NIST-P256 ECC 128 演算効率重視のパラメータNISTを信頼できるか否か NIST-P521 ECC 260 2^521-1なので超高速(P256より速いらしい)AES-256の強度が損なわれないNISTを以下略 ED25519X25519 ECC 128 2021年現在のトレンド脆弱性を回避した設計鍵長が短い割に高強度 ED448X448(Goldilocks) ECC 224 25519の上位互換2021年現在まだ普及していない RSAは鍵長が長い割に強度が低いうえ、鍵長を増やすと演算負荷も極端に増えるため、最近ではあまり使われなくなってきています。 NIST系は演算効率に特化しているのが特徴ですが、過去NISTはバッグドア疑惑など色々とグレーな問題を起こしてきたようで、その点において信頼できるか否かは、皆さんの判断によると思います。 ED25519はツイストエドワーズ曲線、X25519はモンゴメリ曲線という異なる楕円曲線を利用していますが、この2曲線は、あるパラメータ (下記) の時に同値となる双有理同値という性質を持っています。 x={\sqrt {-486664}}u/v,\quad y=(u-1)/(u+1)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む