Question 1

Teleportの統合テストTestTimeReconciliationが'expected notification is not found'エラーで断続的に失敗するのはなぜですか？

Accepted Answer

This flaky testは、x/cryptoのアップデートで導入されたspin loopバグが原因でした。この問題は、PR #67111でそのアップデートをrevertすることで解決されました。修正するには、TeleportビルドにこのPR（May 26以降にマージ）が含まれていることを確認してください。アップグレードできない場合の一時的な回避策は、spin loop最適化を無効にするか、ローカルでx/cryptoの変更をrevertすることです。

Question 2

Redshift JDBCドライバーがTeleportプロキシ経由の接続に失敗し、'Illegal UTF-8 sequence'エラーが発生するのはなぜですか？

Accepted Answer

Redshift JDBCドライバーは、PostgreSQLスタートアップメッセージが単一のTCPパケットで送信されることを想定しています。Teleportのプロキシはこのメッセージを複数のパケットに分割するため、UTF-8デコードエラーが発生します。回避策：Redshift固有のドライバーではなく、標準のPostgreSQL JDBCドライバー（org.postgresql.Driver）を使用してください。このドライバーはTeleportのプロキシで正しく動作します。恒久的な修正については、issue #29417を追跡してください。

Question 3

ユーザーのホームディレクトリが存在しない場合に tsh scp が 'server unexpectedly closed connection: unexpected EOF' で失敗する問題の修正方法

Accepted Answer

これは既知の Teleport のバグです（v18.7.3 で確認されました）。`tsh ssh` は動作する（`/` にフォールバックする）にもかかわらず、ログインユーザーのホームディレクトリがターゲットホスト上に存在しない場合、`tsh scp` が `error receiving version packet from server: server unexpectedly closed connection: unexpected EOF` というエラーで失敗します。対処方法は2つあります：

1. **Teleport をアップグレードする** — このバグはアップストリームで修正されました（gravitational/core PR #563、issue #65579 は解決済みとしてクローズ）。修正を含むリリースへ、Teleport クラスター（ターゲットノード上の SSH Service）と `tsh` クライアントの両方をアップグレードしてください。

2. **回避策（アップグレードなし）：** SFTP がワーキングディレクトリを設定できるように、ターゲットホスト上にユーザーのホームディレクトリを再作成します：
```
sudo mkdir -p /home/testuser
sudo chown testuser:testuser /home/testuser
```
ホームディレクトリを復元すると、`tsh scp testuser@host:/etc/hostname .` が再び正常に動作します。

Question 4

Teleportでリソースを新しいtctlハンドラーフォーマットに追加または移行する方法

Accepted Answer

Teleport は、tctl のリソース処理を、従来の方式（リソースごとに 1 つのコレクションと create/update 関数、および `ResourceCommand.getCollection` と `ResourceCommand.Delete` の巨大な switch 内の case）から、PR #59518 で導入された一元化された `Handler` 構造体へ移行しています。リソースを移行または追加するには: 1) そのリソースのすべてのロジックを含む専用ファイル `tool/tctl/common/resources/<resource-kind>.go` を作成します。2) そのファイル内に、そのリソースの get/create/update/delete の動作を実装する `Handler` 構造体を定義します。3) `tool/tctl/common/resources/resource.go` の `Handlers()` 関数でそのハンドラーを登録します。追加の配線は必要ありません。一度登録すれば、そのリソース種別に対して `tctl get`、`tctl create`、`tctl update`、`tctl delete`、または `tctl edit` を実行した際に、そのハンドラーが自動的に使用されます。なお、`types.KindNetworkRestrictions` は、Teleport v15 でその機能が非推奨となり削除されたため（名残のコードのみが残っています）、移行リストから除外されました。すでに移行済みのリソースの一覧と、例として参照できる PR については、追跡 issue #60370 を確認してください。

Question 5

Teleport SSH (tsh ssh) セッションが w や loginctl に表示されないのはなぜですか?また、logind Class=background セッションを修正するにはどうすればよいですか?

Accepted Answer

原因: Teleport の PAM 連携は `pam_open_session()` の前に `PAM_TTY`（および `PAM_RHOST`）を一切設定しないため、`pam_systemd` は TTY が空のまま `Type=unspecified`、`Class=background` にフォールスルーします。OpenSSH が正常に動作するのは、`PAM_TTY="ssh"`（いわゆる PAM_TTY_KLUDGE）を設定しており、pam_systemd がこれを特別扱いして `Type=tty`、`Class=user` にするためです。古いホストでは `w` が `/run/utmp` を読んでいたため、この問題は表面化していませんでした。utmp のない新しい systemd（例: 259、Ubuntu 26.04）では、`w` は logind に依存するため、Teleport ログインに対して `0 users` と報告します。

Teleport が修正をリリースするまでの回避策（パッチは issue #69773 で提案されていますが、v18.11 時点では未テスト・未マージ）: pam_systemd が尊重する PAM 環境変数を使ってセッションの type/class を上書きします。

1. `/etc/security/teleport-session-env` を作成します:
```
XDG_SESSION_TYPE DEFAULT=tty
XDG_SESSION_CLASS DEFAULT=user
```
2. カスタム PAM サービス `/etc/pam.d/teleport` を作成し、セッションスタック内で pam_systemd より前に pam_env を読み込みます:
```
session required pam_env.so envfile=/etc/security/teleport-session-env
session optional pam_systemd.so
```
（これに加えて、`sshd` サービスファイルからコピーした通常の auth/account 行も記述します）
3. teleport.yaml で Teleport がそのサービスを使うように指定し、再起動します:
```
ssh_service:
  pam:
    enabled: true
    service_name: teleport
```
4. 確認: `loginctl show-session "$XDG_SESSION_ID" -p Class -p Type` で `Class=user`、`Type=tty` と表示され、`w` にそのユーザーが一覧表示されるはずです。

注意点: この環境変数による上書きは、PTY を持たない非対話型セッションを含め、その PAM サービスを使用するすべてのセッションに適用されます。恒久的な正しい修正方法は、Teleport が PAM セッションを開く前に `PAM_TTY`（例: OpenSSH のようにリテラルの `ssh`、または実際の pts 名）と `PAM_RHOST` を設定することです。

Teleport

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト