概要やら前提やらは簡単にこちらにまとめましたが、あとは実際にやってみます 引き続きこの場合で 接続元(自宅なんかのPC)→A 経由Linuxサーバ→B リモートデスクトップ接続先→C 大まかな流れ 大まかな流れは下記のような感じで、環境さえ整ってれば簡単です。 1のputtyの設定がじゃっかんいつものSSH接続と違うくらい？ですかね ①事前にCのIPアドレスを確認 ②Aでputtyを立ちあげて設定する ③Aからputty(設定済み)でSSHトンネル接続 ④Aでリモートデスクトップを立ち上げて接続 ①事前にCのIPアドレスを確認 Cで、コマンドプロンプトを立ち上げておもむろにipconfigと打って確認します ※今回でいうとIPv4アドレスのところにある「172.21.xxx.xxx」的なやつをメモっておきます ②Aでputtyを立ちあげて設定 セッション>接続先の指定のとこにB(経由lin
Linux Advent Calendar 2017 の23日目です。 Linuxをサーバーとして利用している場合、SSHの公開鍵認証を使うのが一般的ですのでパスワード認証を使う機会はもう少ないだろうと思います。 しかしデスクトップPCへのログインはどうでしょうか。まだまだパスワードが使われていますし、オンプレで設置している物理サーバーのrootパスワードを複数人で共有するといった運用もまだ残っているのではないでしょうか。 こんな時、物理的な認証トークンがあればずっと安全な運用になるのですが、私達はそんなデバイスを既に持っているではありませんか。そう、マイナンバーカードです。 今回はマイナンバーカード内の鍵でLinuxにログインしたり、sudoしたり、多要素認証デバイスとしてカードを活用する方法を紹介します。 LinuxにはPAMという認証システムとアプリケーションを分離するための仕組みが
（2015/1/30 追記）時期は不明ですが、現時点のgithub.comはEd25519鍵にも対応しています。 （2016/5/31 追記）「GitHubにバグ報告して賞金$500を頂いた話」で紹介した通り、既に弱い鍵はGitHubから削除され、新規登録もできなくなっています。 GitHub APIを利用して、GitHubの31661アカウントに登録されているSSH公開鍵64404個を取得してみました。抽出方法*1が適当すぎて偏りがあるような気もしますが、面白い結果が得られたと思うのでまとめてみます。 SSH鍵の種類 鍵の種類 個数 割合 RSA鍵 61749 (95.88%) DSA鍵 2647 (4.11%) ECDSA鍵 8 (0.01%) 約6万個の鍵のうち、8個だけECDSA（楕円DSA）鍵が見つかりました！常用しているのか試しに登録してみただけなのかはわかりませんが、何にせよ
また間が開きましたが、すみだセキュリティ勉強会2015#2を開催しました。発表していただいた@inaz2さん、@yasulibさん、ありがとうございました。当日の発表資料は上記の勉強会ブログからリンクしています。 今回の私の発表は、「攻撃を『隠す』・攻撃から『隠れる』」。ポートスキャンをするとsshが100個現れる「ssh分身の術」がメイン(?)です。 当初は、パケットヘッダやプロトコルのすき間にメッセージを隠したり、ファイルを隠すなども考えていたのですが……。あまりに盛りだくさんになりそうだったので、「ポートスキャンをいかに隠れて実行するか・ポートスキャンからどうやって隠れるか」と、ポートスキャンとnmapに絞って発表しました。 発表資料 私の発表資料は以下です。 (PDF)攻撃を「隠す」、攻撃から「隠れる」 発表ノート付きなのでPDFです。以下、落穂ひろいなど。 スキャンするポート数と
おさかなさんも先日，24歳を迎えました．もう若くはないです． しかしキャビアで有名なチョウザメは寿命が150年〜200年にも達するそうです． 手元の環境でssh XForwardingするとき速度が遅くて困っていたのですが，ちょっと調べると高速化Tipsがあり，効果覿面でしたのでメモがてらに． How to speed up X11 forwarding in SSH – Linux FAQ ~/.ssh/configに Host * Compression yes CompressionLevel 9 TCPKeepAlive yes Ciphers blowfish-cbc,arcfou こんな感じの記述を追加します． ふつう % ssh -YC hogehoge@fugafuga とするとX転送とCompressionが有効な状態になりますが，暗号化処理が結構重たく遅くなるようです．
前回、sshを使ってパスワードなしでログインする方法を書きましたが、linuxのコマンド"expect"を利用することでも、パスワードなしでログインできたのでメモします。 SSHを使いこなそう！Windows上のCygwinからvmware上のUbuntuにパスワードなしでSSH通信するまでのまとめ | Futurismo 環境# 前回と同じように、CygwinからUbunsuサーバに接続してみる。 接続先: ubuntu 接続元: cygwin expectコマンドの紹介# expectコマンドは対話型シェルを実現するためのコマンド。デフォルトでは入っていないようなので、手に入れる。インストール方法は省略します。 覚えるべきコマンドは以下の5つ。 set timeout 設定した秒数の間、標準入力から応答がないとexpectは、終了します。 spawn 自動で実行したいコマンドを指定しま
最近はクラウド上のサーバーを利用する事も多くなってきた。 サーバーの用意やネットワーク周りの設定はインフラ部門がやってくれるけど、アプリのデプロイ／設定は開発者がする事が多いので、開発メインでやってるエンジニアでも最低限SSHの知識は必要になる。 また、Vagrant等でローカル環境にVMを作成する事もあるので、ローカル環境内でSSHを使用するケースも増えてきた。 というわけでインフラエンジニアじゃなくてもSSHクライアントの知識は必須になってきているので、改めてSSHの再学習をしてみることにした。 SSHとは 暗号や認証の技術を利用して、安全にリモートコンピュータと通信するためのプロトコル。 SSHでは以下の点で従来のTelnetより安全な通信が行える。1 パスワードやデータを暗号化して通信する。 クライアントがサーバーに接続する時に、接続先が意図しないサーバーに誘導されていないか厳密に
B! 349 0 0 0 多段sshについて、ターミナルからsshを直接使う場合と WindowsでのPuTTYでの設定について、 久しぶりに設定をしなおしたのでそのまとめ。 ~/.ssh/configで多段接続 同じ踏み台サーバーを持つ物を一括指定 複数の踏み台サーバーを経由してログイン Windows+PuTTYで多段ssh plinkを使用する方法 ログインサーバーにログインしてさらにsshコマンドを実行する ショートカットの作成 Gitサーバーに対する多段接続 ~/.ssh/configで多段接続 ターミナルからsshを使うときには~/.ssh/configファイルが設定ファイルとして 使われます。 直接外部からログインできない様なサーバーに踏み台サーバーを通って ログインするときに、毎回踏み台サーバーにsshしてそこから また入りたいサーバーにログインして。。。は面倒なので そこ
追記：openssh-7.3 以降なら ProxyJump や -J が使えます ホスト名を + で繋げることで多段Proxy接続も簡単に、がコンセプトだった本エントリの設定ですが、OpenSSH 7.3 から ProxyJump という設定が使えるようになったので、使えるなら ProxyJump を使う方が健全だし柔軟で使い勝手も良いのでそちらを覚えて帰ることをオススメします。 使い方は簡単で以下のような感じです。多段も行けるし、踏み台ホスト毎にユーザ名やポート番号を変えることも出来ます。 # 1. bastion.example.jp -> internal.example.jp ssh -J bastion.example.jp internal.example.jp # 2. bastion.example.jp -> internal.example.jp -> super-de
Enhanced terminal for Windows with X11 server, tabbed SSH client, network tools and much more MobaXterm is your ultimate toolbox for remote computing. In a single Windows application, it provides loads of functions that are tailored for programmers, webmasters, IT administrators and pretty much all users who need to handle their remote jobs in a more simple fashion. MobaXterm provides all the impo
ssh 接続をタイムアウトしないようにする 提供：maruko2 Note. 移動： 案内, 検索 目次 1 OpenSSH (Linux, OS X) 1.1 クライアント側の設定 1.2 サーバ側の設定 2 putty (Windows) 2.1 Low-level TCP connection options 3 脚注 OpenSSH (Linux, OS X) ssh の接続が切れないよう（タイムアウトしないよう）にするには、クライアント側かサーバー側のどちらかに以下の設定をすればよい。サーバーとクライアント両方に設定しても問題はない。 クライアント側の設定 sshd サーバと応答確認する間隔 ServerAliveInterval[1] を設定する。 /etc/ssh/ssh_config または ~/.ssh/config を編集する。ServerAliveInterval の
linuxサーバにログインしていろいろしたとき、翌日になって何かまずいことをしでかした事に気づく(でもログがないから何をしたかわからない)ということがままある。というわけでlinuxサーバにsshでログインして何かしたとき、すべてログに残すノウハウ。もうあちこちで紹介されているけど、自分用メモということで。 ~/.bash_profileに下記を追加 # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs PATH=$PATH:$HOME/bin export PATH unset USERNAME # keep everything in the log. P_PROC=
AWSを本格的に使い始めて約3ヶ月になる新参者です。 便利過ぎて今までの時間を返して欲しいくらいなのですが過ぎたものは仕方ないので前に進みましょう。 EC2 への SSH 接続 Amazon EC2 上のインスタンスにSSH接続するベーシックな方法は ですが、これでは何のサーバに接続しているのかさっぱり分からないのでこのまま運用している人はまずいないでしょう。 (AWS Management Console から毎回コピペでがんばっている人はいそう) ~/.ssh/config おそらく多くの人は ~/.ssh/config の設定にそれぞれ工夫を凝らしているのかと思われますが、 インスタンス数が増えてくると ~/.ssh/config の更新も煩わしくなります。 また Auto Scaling 等のダイナミックな運用になるととても追いつきません。 既存サポートツール ec2ssh その煩
EC2でsshアクセスはよく使います 最近、仕事でEC2を使用する機会が非常にふえました。EC2にsshログインして作業をすることもよくあるのですが、 インスタンス数の増加にしたがって、EC2のホスト名を管理するのも面倒になってきます。 通常、ホスト名管理が面倒な場合はconfigファイルに次のようにホスト名の別名を定義すれば楽です。 #~/.ssh/config Host sample-host Hostname ec2-xxx-xxx-xxx-xxx.amazonaws.com 上記configがあれば、下記のようにEC2へsshログイン可能です。 % ssh -i <キーファイル> ec2-user@sample-host しかし、インスタンスを起動したり消したりしていると、当然ながらec2-xxx〜なホスト名は変わってしまいます。 EIPを使えば固定しておけますが、開発の時やAut
みんなが大好きなクラウドホスティングサービスのAmazon EC2ですが、インスタンスをバンバン立てたり落としたりしていると、ホスト名の管理が面倒になってきますよね。たとえば「さっき立てたインスタンスにSSHしたい！」と思ったら、consoleをひらいて、「ec2-xxx-xxx-xxx-xxx.compute.us-west-1.compute.amazonaws.com」なPublicDNSをターミナルにコピペして…みたいな面倒な事をやってしまいがちです。 これを避けるためには、~/.ssh/configをマメに更新したりするといいのですが、これはなかなか面倒な作業です。インスタンスは一旦StopしてRunし直すと、IPが変わってしまいますからね。 そこでec2sshの登場です ec2sshは、インスタンスのNameタグからホスト名を生成して、~/.ssh/configに書きこむツール
2024年下半期のフィルム写真たち ふと気がつくと2024年も残り僅か。 そしてふと振り返るとこのブログに掲載する写真がGRIIIで撮ったものばかりになっていたのだけど、決してフィルムに飽きたということではなく、フィルムはフィルムで淡々と撮り続けているし、モノクロもカラーネガもいつも通り自宅で…
不慣れな環境を不意にいじった時にあるあるネタ。 とりあえずー とか言って勢いで書いたsetupスクリプトを実行してみたら意外と時間かかって、 ちょっと目を離した隙にsshの接続が切れちゃいました！ 。。。ありますよね。ほんとよくありますよね。 そうなる予感はあったんだ なんて後の祭りです。ふとした油断から、screenもnohupすらも使わずにやってしまって、こんなことに。 shellがHUPしなかったからプロセスは生きてるものの、ログが見れないから進行状況がわからない。 うまく行ってるのかどうかモヤモヤした気持ちのまま、プロセスが終わるのをじっと待つ。。。 まぁ実に切ないです。 こんな時、いつも思うこと。 このプロセスの出力、もっかいstdoutに繋げられたらいいのに。。。 はい。というわけでつなげましょう。 長い前座ですみません。 切り離したプロセスを用意 #!/bin/bash wh
意外と知らない人がいるようなのでブログに書いておきます。 GitHub のアドレスのあとに .keys を付けるとその人の SSH 公開鍵が表示される。 たとえば id774 さんの公開鍵であれば https://github.com/id774.keys を参照すれば良い。 ぜひ自分のアカウントで試してみて欲しい。 新規に用意するサーバーの ~/.ssh/authorized_keys に上記アドレスを wget したものを置いて適切なパーミッションを設定しておけばすぐに公開鍵認証ができるというわけである。 もうそろそろ公開鍵をメールで送ってくれとかいう文化が滅亡して GitHub から勝手に公開鍵を持っていくのが常識な世界になってほしい。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
