OpenSSHの設定

OpenSSHは、OpenBSDプロジェクトで開発が行われているSSHサーバおよびSSHクライアントを含んでいます。
2021年4月19日の最新版は8.6です。
ここではFreeBSD 12-2に付属のOpenSSHの設定について記載しています。

その他のOS、たとえばCentOSやRocky LinuxなどでもOpenSSHを使用する場合は基本的に同じです。

目次

OpenSSHの設定

公式サイトOpenSSH

OpenSSHには次の機能があります。

  1. クライアント機能
    • ssh(OpenSSH remote login client)
    • scp(OpenSSH secure file copy)
    • sftp(OpenSSH secure file transfer)
  2. サーバー機能
    • sshd(OpenSSH デーモン)
    • sftp-server(OpenSSH SFTPサーバー サブシステム)
    • ssh-agent(OpenSSH 認証エージェント)
  3. 鍵管理機能
    • ssh-add(OpenSSH認証エージェントに秘密鍵IDを追加)
    • ssh-keysign(ホストベース認証)
    • ssh-keyscan(サーバーからSSH公開鍵を収集)
    • ssh-keygen(OpenSSH認証キーユーティリティ)

SSHサーバの設定

バージョンの確認

FreeBSD 12.2に付属のOpenSSHのバージョンを確認します。

root@ik1-438-51137:~ # /usr/bin/ssh -V
OpenSSH_7.9p1, OpenSSL 1.1.1h-freebsd  22 Sep 2020

バージョンは7.9p1でした。
OpenSSLは1.1.1hです。

最新版を使用する場合は、portsからインストールする必要があります。

sshdの起動

サーバー起動時にsshdが自動起動するように設定します。

FreeBSDでは、/etc/rc.confをviエディタなどで直接編集するかsysrcコマンドを使用して編集できます。
sysrc -aで/etc/rc.confのすべてが表示されます。

root@ik1-438-51137:~ # sysrc sshd_enable=YES
sshd_enable: NO -> YES

RedHat系は以下です。

root@ik1-438-51137:~ # systemctl enable sshd
Created symlink /etc/systemd/system/multi-user.target.wants/sshd.service → /usr/lib/systemd/system/sshd.service.

これで次回OS起動時にsshdが自動で起動します。
マニュアルでの起動は次のコマンドを使用します。

root@ik1-438-51137:~ # service sshd start
Performing sanity check on sshd configuration.
Starting sshd.

sshdの設定変更

設定変更はブルートフォースアタック対策が目的です。
sshdはデフォルトで/etc/ssh/sshd_configの内容を読み取ります。
viエディタなどで/etc/ssh/sshd_configファイルを編集します。

  1. ssh プロトコルバージョン 2のみサポート
    Protocol 2
  2. sshサービスポートの変更
    Port 11022
  3. rootユーザでの接続拒否
    PermitRootLogin no
  4. パスワード認証を拒否
    PasswordAuthentication no
  5. チャレンジレスポンス認証を拒否
    ChallengeResponseAuthentication no
  6. 公開鍵認証を許可
    PubkeyAuthentication yes
  7. 空のパスワードでの接続拒否
    PermitEmptyPasswords no
  8. 許可したユーザー(sakura)のみ接続可能
    AllowUsers sakura
  9. 鍵の種類と強度
    公開鍵認証で使用する鍵ペアの生成の鍵の種類(強度)は、RSA(3072bit)、ECDSA(320bit)またはed25519(256bit)の中から選択することにしました。
    SSHクライアントが対応しているならばed25519(256bit)を使用することとにします。

※RSA(3072bit)は鍵の生成に非常に時間がかかります。また、bitが多いためviエディタなどで表示してコピー&ペーストしてしまうと複数行に分離してしまう可能性があり認証エラーの原因になります。bit数が少なく1行で収まり、暗号強度が同等なed25519(256bit)がおススメです。

sshdの再起動または再読み込み

/etc/ssh/sshd_configの編集が完了したら、設定を反映するためにsshdを再起動するか再読み込みします。

root@ik1-438-51137:~ # service sshd reload
Performing sanity check on sshd configuration.
root@ik1-438-51137:~ # service sshd restart
Performing sanity check on sshd configuration.
Stopping sshd.
Waiting for PIDS: 1159.
Performing sanity check on sshd configuration.
Starting sshd.

OpenSSHで鍵ペアの生成

SSHの公開鍵認証に使用する鍵ペア(公開鍵と秘密鍵)をOpenSSHで生成します。
使用するコマンドはssh-keygenです。
ssh-keygenは、 DSA(dsa)、ECDSA(edcsa)、ED25519(ed25519)、RSA(rsa)の4種類の鍵を生成することができます。

SSH接続ユーザ名sakura
SSHユーザ個別設定ディレクトリ/home/sakura/.ssh
公開鍵格納ファイルauthorized_keys
鍵の種類ed25519
鍵の強度256 bits
公開鍵ファイル名id_ed25519.pub
秘密鍵ファイル名id_ed25519
sakura@ik1-438-51137:~/.ssh $ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/sakura/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/sakura/.ssh/id_ed25519.
Your public key has been saved in /home/sakura/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:8vvEWnNBsS/HjBGnzW7qzDRnehKDvfaZlwNj9owmFzg sakura@ik1-438-51137.vs.sakura.ne.jp
The key's randomart image is:
+--[ED25519 256]--+
|            o .  |
|             O   |
|            = o  |
|           . B   |
|      . S  o= B  |
|       o ..E+%   |
|        . = O+X .|
|         = O+O.B.|
|        o...O++..|
+----[SHA256]-----+
sakura@ik1-438-51137:~/.ssh $ ls -la
total 20
drwx------ 2 sakura sakura 512 Aug 10 01:20 .
drwxr-xr-x 3 sakura sakura 512 Aug 9 09:33 ..
-rw------- 1 sakura sakura 81 Aug 9 09:54 authorized_keys
-rw------- 1 sakura sakura 484 Aug 10 01:20 id_ed25519
-rw-r--r-- 1 sakura sakura 118 Aug 10 01:20 id_ed25519.pub

公開鍵の転送

公開鍵認証で接続する場合は、公開鍵格納ファイルに公開鍵を追加しなければなりません。
今回は別のサーバーを準備していないのでSSHサーバとSSHクライアントが同じホストになりますが、実際には接続先のサーバの接続ユーザの公開鍵格納ファイルに秘密鍵のペアになる公開鍵を追加する必要があります。
以下は転送した先からの説明です。

sakura@ik1-438-51137:~/.ssh $ cat id_ed25519.pub >> authorized_keys

公開鍵格納ファイル「~/.ssh/authorized_keys」は、いろいろなクライアントからの接続のための公開鍵を格納している可能性があるため「>」(上書き)ではなく「>>」(追加)を使用するようにしてください。

SSHクライアントの設定

ここではクライアントおよびサーバは同じFreeBSD12のマシンで説明しています。CentOS8をクライアントにする場合はそのマシンにログインして作業してください。

SSHでのリモート接続はクライアントから接続を行います。
Host名、ポート番号、接続可能ユーザー、認証方式など接続先のSSHサーバーの要件に合わせてクライアントの設定を使い分ける必要があります。
SSHサーバ要件が次の表の通りの場合のSSHクライアントの設定を説明します。

ホスト名ik1-438-51137.vs.sakura.ne.jp
sshd ポート番号11022/tcp
認証方式公開鍵認証のみ
接続可能ユーザsakura
公開鍵格納ファイル~/sakura/.ssh/authorized_keys

sshはデフォルトで/etc/ssh/ssh_configと~/.ssh/configの内容を読み取ります。

ssh_configの設定

/etc/ssh/ssh_configはシステム共通で使用されるsshクライアント用の設定ファイルです。

デフォルトではすべてコメントになっています。
システム共通の設定はデフォルトのままにすることにしました。

# Host *
# ForwardAgent no
# ForwardX11 no
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# BatchMode no
# CheckHostIP no
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# IdentityFile ~/.ssh/id_ecdsa
# IdentityFile ~/.ssh/id_ed25519
# Port 22
# Protocol 2
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,umac-64@openssh.com
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
# VerifyHostKeyDNS yes
# VersionAddendum FreeBSD-20200214

configの設定

~/.ssh/configはユーザ個別で使用するsshクライアント用の設定ファイルです。
この設定ファイルには接続先のサーバの要件ごとに設定を追加すればよいと思います。
今回は、このファイルを作成して個別設定でssh接続することにしました。

こんなに便利

上記要件のSSHサーバへ接続する場合、sshコマンドは以下の様に入力しなければなりません。

sakura@ik1-438-51137:~ $ ssh sakura@ik1-438-51137.vs.sakura.ne.jp -p 11022

非常に面倒です。
そこで、~/.ssh/configにSSHサーバの接続設定を登録します。

Host server1
HostName ik1-438-51137.vs.sakura.ne.jp
User sakura
Port 11022

そうすると、sshコマンドは次のように簡単になります。

sakura@ik1-438-51137:~ $ ssh server1

非常にシンプルになりました。
これならコマンド入力も面倒ではありません。

秘密鍵ファイルの指定は行いませんでしたが、OpenSSHのssh-keygenコマンドを使用したため、デフォルトの場所、ファイル名(~/.ssh/id_ed25519)で秘密鍵ファイルは保存されています。sshが使用する秘密鍵ファイルは/etc/ssh/ssh_configのIdentityFileの設定値を参照してください。
別の場所、別のファイル名の場合は、configに設定すれば接続のたびに指定する必要はなくなります。

Windowsからの接続にはPuTTYを使用しています。

デバッグ

sshコマンドでうまく接続できない場合、内部のどこでエラーになっているのか?
原因が何なのか?

例えば、「Permission denied (publickey,gssapi-keyex,gssapi-with-mic)」というエラーの原因はわかりますか?

さくらのVPSでローカルネットワークを使用してCentOS8からFreeBSD12へSSH接続する際に遭遇したエラーです。
ネットで検索するといろいろヒットはしますが、これといったものは見つかりません。

この原因は、公開鍵格納ファイルにペーストした際にコードが改行されていたことです。
SSHクライアント側で生成した公開鍵ファイルをviエディタで開いて、マウスでコピーしてSSHサーバ側の公開鍵格納ファイルにペーストしました。
鍵の種類はRSAで強度は4096bitを使用していました。非常に長いコードでした。
公開鍵が改行され中途半端なものなのでそれとペアの秘密鍵は存在しません。

OpenSSHの公開鍵ファイルは1エントリ1行

sshコマンドのオプション「-vvv」を使用してヒントを見つることができます。
オプションのvの数がデバッグレベルです。-vvvはMAXのdebug3です。

sakura@ik1-438-51137:~ $ ssh -vvv 192.168.1.1
OpenSSH_7.9p1, OpenSSL 1.1.1h-freebsd 22 Sep 2020
debug1: Reading configuration data /home/sakura/.ssh/config
debug1: /home/sakura/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 192.168.1.1 is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/sakura/.ssh/id_rsa type 0
debug1: identity file /home/sakura/.ssh/id_rsa-cert type -1
debug1: identity file /home/sakura/.ssh/id_dsa type -1
debug1: identity file /home/sakura/.ssh/id_dsa-cert type -1
debug1: identity file /home/sakura/.ssh/id_ecdsa type -1
debug1: identity file /home/sakura/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/sakura/.ssh/id_ed25519 type -1
debug1: identity file /home/sakura/.ssh/id_ed25519-cert type -1
debug1: identity file /home/sakura/.ssh/id_xmss type -1
debug1: identity file /home/sakura/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9 FreeBSD-20200214
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.1.1:22 as 'sakura'
debug3: Fssh_hostkeys_foreach: reading file "/home/sakura/.ssh/known_hosts"
debug3: Fssh_record_hostkey: found key type ECDSA in file /home/sakura/.ssh/known_hosts:1
debug3: Fssh_load_hostkeys: loaded 1 keys from 192.168.1.1
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
debug2: ciphers stoc: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128-cbc
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:vFGkItaIpcvZby7thlqZYQpFGMRhSx9KS+Yx+e4eTV0
debug3: verify_host_key_dns
debug1: skipped DNS lookup for numerical hostname
debug3: Fssh_hostkeys_foreach: reading file "/home/sakura/.ssh/known_hosts"
debug3: Fssh_record_hostkey: found key type ECDSA in file /home/sakura/.ssh/known_hosts:1
debug3: Fssh_load_hostkeys: loaded 1 keys from 192.168.1.1
debug1: Host '192.168.1.1' is known and matches the ECDSA host key.
debug1: Found key in /home/sakura/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/sakura/.ssh/id_rsa RSA SHA256:GufEGxPYk7sMETSpU9gPyc7O4R2BXNZIt7UaO59yjw4
debug1: Will attempt key: /home/sakura/.ssh/id_dsa
debug1: Will attempt key: /home/sakura/.ssh/id_ecdsa
debug1: Will attempt key: /home/sakura/.ssh/id_ed25519
debug1: Will attempt key: /home/sakura/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: Fssh_kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/sakura/.ssh/id_rsa RSA SHA256:GufEGxPYk7sMETSpU9gPyc7O4R2BXNZIt7UaO59yjw4
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /home/sakura/.ssh/id_dsa
debug3: no such identity: /home/sakura/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/sakura/.ssh/id_ecdsa
debug3: no such identity: /home/sakura/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/sakura/.ssh/id_ed25519
debug3: no such identity: /home/sakura/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/sakura/.ssh/id_xmss
debug3: no such identity: /home/sakura/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
sakura@192.168.1.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

このデバッグログを参照すれば以下のことが分かります。

  • ~/.ssh/configを読んでいる
  • そのあとに/etc/ssh/ssh_configを読んでいる
  • ~/.ssh/known_hostsを読んでいる
  • ホスト認証に成功している
  • そのあとに公開鍵認証をしようとしているけど失敗
  • 試す認証の方法がない

なぜ公開鍵認証に失敗しているのか?
正しく秘密鍵ファイル(/home/sakura/.ssh/id_rsa )を認識しています。
しかし、サーバ側にある公開鍵とペアの秘密鍵ではないと判定され他の秘密鍵を試しているようですが、他の種類のキーは生成していませんのでファイルは存在しません。
他に認証方法がないから諦めました。
という結果の様です。

サーバ側にある公開鍵のペアの秘密鍵が見つかるとパスフレーズの入力を促されますが今回のエラーはそこまでいっていません。
パスフレーズが正しく入力されると以下のログメッセージが出力されます。

debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).

ここで、なぜRSA鍵ペアで認証できなかったのか?
公開鍵格納ファイルをviエディタで開いて行を移動中に1エントリ1行でなければならないコードが複数行になっていることに気が付きました。
vi編集画面でペーストしたのが間違いでした。RSAで128ビットのセキュリティー強度をサポートする乱数生成器となると3072ビット以上です。
しかし、RSAをわざわざ使う必要もないので、少ないビットで済むed25519にして、次はcat出力をコピー&ペーストしました。

公開鍵格納ファイルに正しく追加してからはエラーがなくなりました。

OpenSSHを使用したSSHサーバとSSHクライアントの設定について記載しました。

わかりやすいように設定値を現実のものに似せて記載していますが実在はしないので、当サーバには接続はできません。不正アクセスの証拠のログだけが貯まっていく状態ですので注意してください。

WindowsのSSHクライアントはPuTTYがおススメです。

WindowsのWinSCPだといろいろ便利に使用できます。WinSCPの設定からPuTTYの設定ができます。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

大阪府門真市に生まれ、高校卒業まで京都府福知山市で育ち、大学は工学部電子工学科を卒業。半導体設計会社に勤務ののちインフラエンジニアとして監視基盤の運用設計業務に就く。現在は都内の施設に勤務。横浜在住。人の役に立てることができればいいなと日々思っています。

目次