【CentOS7】リモートでアカウントを作成する方法

Question

前提

Linuxや、サーバ設定に詳しくありません。
専門用語などを避けていただけると幸いです。

質問概要

鍵認証のみで、遠隔ログインできるCentOS7のマシンに、
ユーザアカウントを追加して、公開鍵・秘密鍵の作成まで行いたい。

質問詳細

セキュリティの為、鍵認証のみリモートログイン可能なCentOS7のサーバに、
管理者権限を持つアカウントでリモートログインし、標準ユーザアカウントを作成して、そのアカウントに対する鍵を作成したいと考えています。

例えば、
$ useradd -m -d /home/test test
とすると、コマンド通りに「test」というアカウントが標準ユーザ（一般？）権限で作成されます。

しかし、パスワードを設定しようとすると、これは一度、今作ったtestアカウントにログインして、
$ passwd <新しいパスワード>
コマンドを叩かないと行けないと思います。

実際、ユーザアカウントを作った後、そのまま$ passwdコマンドを叩くと「パスワードの変更」のような項目が出てきたため、慌ててCtrl+Cをしました。

しかし、鍵認証でしかログイン出来ないため、普通に
$ ssh test@hogehoge
としてもログインできませんし、パスワードが設定されていないので、
$ su - test
としてもアカウントの切り替えができません。

これはどのようにすればよいのでしょうか？
詳しい方がいらっしゃいましたら、ご教示の程よろしくお願い致します。

参考にしたサイト様

• server-memo.net

Answer 1

・他のユーザーのパスワードを設定する（rootから）

passwd ユーザー名で他人のパスワードを設定できます。

・公開鍵の設定
/home/ユーザー名/.ssh/authorized_keysに必要な公開鍵を書き足すだけです。

Comments

[nnahito]

ご回答有り難うございます！
明日試してみます、ありがとうございます

[nnahito]

先ほど実行してみたのですが、アクセスができませんでした……

やった方法として、
$ useradd -m -d /home/test test
で、サーバ側にユーザを作成し、パスワードを設定しませんでした。

手持ちのMacで、
$ ssh-keygen -t rsa
パスワードなどは全て空で、鍵の作成を行い、
id_rsaを「test」に名前変更、id_rsa.pubを「authorized_keys」に名前変更。

サーバに既に作成してある管理者権限の私のアカウントに一度「authorized_keys」を送信し、
先ほど作ったtestアカウントのユーザフォルダに、.sshフォルダを作成し、authorized_keysを移動。
authorized_keysの権限を600に変更。

手持ちのMacで、
$ssh -i ~/.ssh/test test@hogehoge
を実行すると
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
が表示されました。

こちらは何が悪いのでしょうか。
お知恵をお貸しください。

Answer 2

標準ユーザアカウントを作成する際にログインパスワードを設定する方法は、maisumakunさんのご回答の通りです。

そして「鍵認証のみリモートログイン可能」ということであれば、unauさんのご回答の通り、パスワードの生成は必須ではありません。sudo の権限を付与したいならパスワードの生成が必要になります。

ブルートフォースアタックに合うのではないでしょうか？

という点についてですが、これはサーバ側の設定がどうであれ、アタックする側がアタックを試みるかどうかなので、パスワードを設定してもしなくてもアタックされるかもしれません。
しかし、そもそもパスワード認証を許可していないのであれば、パスワードの設定の有無でセキュリティレベルが変わることはないと思います。

学生のPCのApacheがセットアップできなかった時に、代理で使う

とのことですが、この意味がよく分かりません。「誰が」「誰の代理として」「何を」「どこから」使うのでしょうか？
言い換えると、新規作成したアカウント用に生成した「SSH鍵ペア」は誰がどこからどこへアクセスするために使用されるものですか？

いま、対象のCentOS7サーバをXとします。
そしてそこに新規作成したアカウントをAとします。
そうすると、サーバX上でユーザA用に作成したSSH鍵ペアの秘密鍵は、ユーザAのホームディレクトリに存在する事になります。
ですから、サーバXにユーザAとしてログインしている使用者が、他のサーバへ独自の鍵でSSH接続したいケースでしか使用しません。つまり unauさんが仰るとおり、サーバXを他のサーバへSSH接続するための「踏み台」に使用するということです。

それが今回の要件なのでしょうか？

実際に何を実現したいのか、によって、ユーザAのための鍵ペアを新規作成する必要性はないかもしれませんし、あるいは、鍵の生成が必要な場合、生成するだけでは不十分で「秘密鍵」を安全に移動する手立てが必要になるかも知れません。
要するに、秘密鍵を安全に移動するには手間が掛るので、鍵ペアの生成はアクセスの起点となる側のローカル環境で生成するのが普通です。
ですから、サーバX上からユーザAとして他のサーバへSSH接続したいのでない限り、サーバX上でユーザA用に鍵ペアを作成する必要はありません。

Comments

[nnahito]

ご回答有り難うございます。
まさか、利用方法をこんなに突っ込まれるとは思いませんでしたｗ

>「誰が」「誰の代理として」「何を」「どこから」使うのでしょうか？
学生が、自分自身のために、CentOSのサーバを、自身のノートPCから利用します。
学生各自が所持しているノートPCで、よくApacheが起動できない人がいるのです。
（PC初心者でいろいろ変な設定して壊しちゃうんですよね……）
その学生が授業の演習でどうしてもApacheが必要なので、必要最低限の環境の提供を行いたいのです。

結構前の質問からの引用ですが、イメージとしてはこんな感じです。
https://teratail.com/uploads/contributed_images/b666a78d483c76669caf28e9ee11c5f1.png
Macminiではなく、今回はCentOSです。

そして申し訳ない話、
>サーバXにユーザAとしてログインしている使用者が、他のサーバへ独自の鍵でSSH接続したいケースでしか使用しません。
こちらが少し分かりません。

サーバXにログインするために、サーバXに存在する鍵を使って、ユーザAは自分のノートPCから、サーバXのユーザAのアカウントにログインするというわけですよね？
これは……踏み台扱いになるのでしょうか？

[unau]

横から失礼します。
私の回答のコメントに書いたものと対応させると、
(1) 各自パソコン (うち一台を PC A とする)
(2) 臨時サーバ X
(3) 他のサーバ Y
という感じになります。
pi-chan さんは「秘密鍵を安全に移動するには手間がかかる」と書かれていますが、私は学生への指導という観点も鑑みれば、「秘密鍵はコピーも移動も、表示すらもしちゃだめ」としたほうがよいと考えています。（世の中、秘密鍵を安易にコピーしたり、生成した鍵ペアを利用者に渡す、とかいう公開鍵認証の根幹を崩すようなダメ運用が多すぎ）
いずれにしろ、「秘密鍵は鍵ペアを生成したマシン」から動かさないのが普通ですので、もし、ユーザ A が PC A から ssh を経てサーバ X に入り、さらにそこで鍵ペアを生成するとしたら、その鍵ペアを使って他のサーバ Y にログインするんだろうな、と考えるのが「普通」です。
ご質問の中に「管理者権限を持つアカウントでリモートログインし、標準ユーザアカウントを作成して、そのアカウントに対する鍵を作成したい」という文言があったので、私も pi-chan さんも、サーバ X の先のサーバ Y にログインさせたいのかな、と思った、ということです。
このように、目的のサーバにログインするのに、いったんログインする別のサーバが「踏み台」です。ネットワーク構成やアカウント管理の都合で踏み台が必要な場合があります。単に PC A からサーバ X にログインするのは踏み台ではありません。

Answer 3

ssh サーバの運用方針として、「ssh 経由でしかログインできないユーザ」を作ることもありえます。その場合、パスワードを入力するケースがないので、パスワードを設定する必要がありません（私はよく、そういうユーザについては /etc/shadow においてパスワードの部分を * にしていました）。

sudo を実行したいユーザ、すなわち root 権限の必要なコマンドを実行する可能性のあるユーザに関してはパスワードを設定する必要があるので、maisumakun さんの回答にあるように root 権限のあるユーザから当該アカウントのパスワードを設定します。

ところで、ssh サーバに一般ユーザを作るとして、なぜそこで公開鍵認証の鍵ペアを作るのでしょうか。ssh サーバは踏み台ですか。

Comments

[nnahito]

ご回答有り難うございます。

>ssh 経由でしかログインできないユーザ
こちらについてなのですが、ブルートフォースアタックに合うのではないでしょうか？
その辺りはどのように対策するのでしょうか？

>ところで、ssh サーバに一般ユーザを作るとして、なぜそこで公開鍵認証の鍵ペアを作るのでしょうか。ssh サーバは踏み台ですか。
大学の授業で、万が一学生のPCのApacheがセットアップできなかった時に、代理で使うようのサーバなので、アカウントごとに学生を分けたいのです。
なので、人数…アカウント分鍵がいるんです。

[unau]

整理します。

次のマシンが必要、と理解しました。
(1) 各自パソコン : 学生が各自で利用するパソコン。人数分用意。apache も各自ここで動かして実習に用いる
(2) 臨時サーバ : 学生が各自パソコンのセットアップがうまくいかなかった場合に実習に用いるサーバ

臨時サーバでは学生が root 権限を持つ必要はない、とすれば、公開鍵認証で ssh にログインできればよい、
ということになり、臨時サーバのパスワードを設定する必要はありません。
sshd はパスワード認証を許さず、公開鍵認証でしかログインできない設定にします。

学生が臨時サーバに ssh 経由で入るための鍵ペアは各自パソコンで生成し、公開鍵をメールなどで送ってもらって臨時サーバに置くようにします。
秘密鍵はコピーも移動も表示もさせません（学生にそのように指導します）。
臨時サーバで学生が鍵ペアを作ることはありません。
公開鍵の設置作業に関して、管理者がメールでもらったものを設置、というのが手間であれば、学生が自分の公開鍵をアップロードすると、
しかるべきところ (authorized_keys) に設置される、という WEB フォームを作るのも手です。

ブルートフォース攻撃への心配をされているようですが、それは sshd の認証を突破する話でしょうか、あるいは
臨時サーバに入ったあとに他のユーザを乗っ取るという話でしょうか。
前者については sshd でパスワード認証を許していないので攻撃が成立しません。
後者については各学生のアカウントにパスワードが設定されていないので攻撃が成立しません。

もしかすると「/etc/shadow においてパスワードの部分を * に」 のくだりで誤解を与えてしまったかもしれませんが、
/etc/shadow のパスワード部分には、実際のパスワードをハッシュ化したものが記述されています。
ハッシュ化して「*」になる文字列は存在しないのでどんなパスワードを入力してもヒットしない、
すなわちパスワード認証が通ることはない、ということになります。

[nnahito]

コメントありがとうございます。

整理していただきました、
>(1) 各自パソコン : 学生が各自で利用するパソコン。人数分用意。apache も各自ここで動かして実習に用いる
>(2) 臨時サーバ : 学生が各自パソコンのセットアップがうまくいかなかった場合に実習に用いるサーバ
こちらで間違いありません。
ありがとうございます。

>臨時サーバでは学生が root 権限を持つ必要はない、とすれば、公開鍵認証で ssh にログインできればよい、
>ということになり、臨時サーバのパスワードを設定する必要はありません。
sshd はパスワード認証を許さず、公開鍵認証でしかログインできない設定にします。
なるほど……root権限は渡さないので、パスワードはいらないですね。。。

更に、お恥ずかしい話、
>もしかすると「/etc/shadow においてパスワードの部分を * に」 のくだりで誤解を
の、
/etc/shadow
が何なのか、よくわかっておりません……

[unau]

とりあえず、ここで私が提案した運用方針を採用するのであれば、/etc/shadow については知らなくても問題ありません。
ので忘れてもいいです。
が、念のために一応触れておくと、passwd コマンドでユーザのパスワードを設定すると、/etc/shadow にパスワードがハッシュ化されて記録されます。ここでいうハッシュ化というのは SHA-512 などの一方向関数を通す、という意味で、パスワードをハッシュ化すればかならず同じ値になりますが、ハッシュ化された値から元のパスワードを復元することは非常に困難です。
ユーザがログイン時などにパスワードを入力すると、これをハッシュ化したうえで /etc/shadow の値と照合します。これが互いに等しければ正しいパスワードが入力された、と判定できます。
「昔は /etc/passwd にパスワードも記録されていたけど、最近はパスワード部分だけ分離して /etc/shadow に書くようになった」というような話は割愛しますが、興味があったら調べてみてください。

[nnahito]

ご回答有り難うございます。
更に詳しい説明までありがとうございます。
とりあえず、この件が一段落しましたら勉強しようと思います。

さて、下にも書かせていただきましたが、サーバにアクセスができませんでした……

やった方法として、
$ useradd -m -d /home/test test
で、サーバ側にユーザを作成し、パスワードを設定しませんでした。

手持ちのMacで、
$ ssh-keygen -t rsa
パスワードなどは全て空で、鍵の作成を行い、
id_rsaを「test」に名前変更、id_rsa.pubを「authorized_keys」に名前変更。

サーバに既に作成してある管理者権限の私のアカウントに一度「authorized_keys」を送信し、
先ほど作ったtestアカウントのユーザフォルダに、.sshフォルダを作成し、authorized_keysを移動。
authorized_keysの権限を600に変更。

手持ちのMacで、
$ssh -i ~/.ssh/test test@hogehoge
を実行すると
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
が表示されました。

こちらは何が悪いのでしょうか。
お知恵をお貸しください。

[unau]

sshd に接続できない、という件は、別の質問として挙げるとよいと思います。
いくつか考えられる原因がありますが、まずはちょっとググってみて見つけた次のページなども読んでみてください。

http://qiita.com/youcune/items/2f427979403771f2e03a

[nnahito]

ご返信有り難うございます。

頂きました情報を確認しましたが、一応全て一緒のようです。
ただ、最後の「ユーザ追加時の設定を確認する」だけがわかりませんでした。
特にシェルのパスなどは指定してないと思います。

sshのエラーについても、
May 11 15:26:54 server sshd[12067]: Connection closed by IPアドレス [preauth]
とだけのようです。

また、所有者を確認して見たところ、鍵を作った私のMacのユーザ名になっていたので、
test:testに変更してみましたが、変わりなく弾かれました……

[unau]

再度申し上げますが、ssh で接続できない、という問題については、新たな質問として teratail に投稿したほうがよいと思います。ここに書いても他のユーザの目につきにくいですから。

[nnahito]

ご返信有り難うございます。

なるほど、ありがとうございます。
別途スレッドを建てさせていただきます。

また、別質問でのコメントもありがとうございます。
拝見させていただきました！