この記事は、Supershipグループ Advent Calendar 2021の7日目の記事になります。 先日、sshを使用したファイル転送が回線速度と比べて異常に遅いという現象に遭遇したので、その際に行った調査を再現しつつ原因や対策について書いてみたいと思います。 要約 OpenSSHはデフォルトでinteractiveなセッションに af21 、non-interactiveなセッションに cs1 をDSCP値としてIPヘッダに設定する フレッツ網はIPヘッダのDSCP値を帯域優先サービスで使用しており、契約に応じて指定された優先度以外が設定されたパケットの転送は保証されない そのため、OpenSSHをデフォルト設定のままフレッツ網で使うと通信ができなかったり、速度低下などの悪影響を受ける可能性がある OpenSSHがDSCP値を設定しないようにするためには、IPQoS noneを設
はじめに 2016年にこんな記事を書きました。 Big Sky :: Windows ユーザは cmd.exe で生きるべき。 [D] Windowsはターミナルがダメだから使えないってのは過去の話? 基本的にはいい感じに見えますが、いくつか問題は発覚してます。 http://blog.drikin.com/2015/01/w... https://mattn.kaoriya.net/software/why-i-use-cmd-on-windows.htm この記事は日常からコマンドプロンプトを使うユーザに Windows で生き抜く為の僕なりの方法を教授したつもりです。最近は PowerShell を使われる方も多いと思いますが、僕はどうしても PowerShell が好きになれず、未だにコマンドプロンプトで生き続けています。 あれから4年 記事の反響は結構大きく、いろいろなコメントも
概要 社内プロキシに様々なサイトへのアクセスをブロックされたり、社外サーバにsshできなかったりする人向けに社外プロキシを立ててあらゆるサイトにアクセスする方法のまとめです。(後述しますが半分くらいネタポストです。) 他にも以下のような効果がありますので、プロキシフリーな会社にお勤めもし良かったら参考にして頂ければと思います。 なぜか2015年になっても存在するカフェとかホテルとかでの保護されていなかったりする無線wifiを使っても盗聴されない。 日本からアクセスできないサイトにアクセスできる。(海外のデータセンタ上のVMを使った場合) なお、非認証プロキシを例にしてます。認証プロキシでもあまり変わらないとは思いますが、環境が無いため未確認です。また、プロキシの挙動や設定方法はプロキシサーバの種類や設定によって多岐に渡るため、全てのプロキシで同じ方法が使えるとは限らないとは思います。 最後
http://mosh.mit.edu/ ローミング可能 断続的な接続でも平気 ローカルエコーで快適なレスポンス などの機能をそなえたSSH代替ターミナルソフト。その名も「モッシュ」 iPhone/iPadでウロウロしながらサーバ作業をするのを想定しているようだ。ドキュメントやパッケージの充実度からしてもかなり高質のプロジェクト。こいつら本気でSSHを越えようとしている。 こんな能書き IPが変っても大丈夫 スリープ後もターミナルが生きている 遅いリンクでもローカルエコーにより快適 要は素早く打ち込んでいるときにスクリーンが止っちゃうことがない フルスクリーンモードでも有効 サーバ側と同期化されていない入力はアンダーラインで記される ルート権限がなくてもサーバのインストール可能 サーバは一般プログラムとしてインストールして、それをSSHで立ち上げる SSHをinetdとして使っている感じだ
sshって制限かけなければどこからでもアクセスできてすごく便利だし、サーバの近くで作業するとホコリやファンの音でうるさいから、よほどの精神力を持った人じゃなければ通常はsshを使って作業をしていると思う。 だけど、iptablesの設定をいじっていて葬ってしまったり、ネットワークの設定いじっていたら急にコマンド受け付けなくなったりすることもその分多かったりする。 しかも仮想コンソールとかなければ遠隔じゃどうしようもないから、現場に行かなきゃいけないわけですよ。 そんな精神的ダメージを避けるためにも、事前に対策しておきましょうぜというお話し。 検証環境 検証環境はこんな感じ。 (192.168.1.3) ---------- (192.168.1.5) (getty等立ち上げ) (cu, screen, jerm, minicomによるアクセス)同一ネットワーク内にある2台のサーバ(Cent
ディノでは京都1箇所+都内2箇所＋社内の計4箇所に分散されていたデータセンターを京都に集約しつつあります。私は昨日からその関連作業でネットワークチームと京都に来ています。作業の多くが遠く離れたコンピュータを介して行われる事になると同一データセンターのサーバに対してたくさんのSSHを立あげて作業するこは、ネットワーク的に効率的ではありません。クラウド環境がもてはやされている昨今おなじような状況の方も少なくないと推察されます。そこでリモートコンピュータでのオペレーションを効率的にする方法としてGNU Screenをご紹介します。というか、ネットが瞬断したくらいでいちいち文句垂れる奴は迷惑なのでいい加減にGNU Screenを使えばいいとおもいます。 やり方まず、作業用のサーバをデータセンター側に一つ作ります。このサーバへはローカルからSSHのAgentForwardを介してアクセスするので自分
sshにはダイナミック転送という機能がある。この機能を使うと、sshはアプリケーション側にはSOCKSプロクシとして振る舞うが、そこからsshの接続先までは暗号化された状態で通信が行われる。 これだけだと通常のトンネリングとどう違うのかよくわからないかもしれないが、ダイナミック転送の場合は転送ポートを指定する必要がない。ここがダイナミックと表現される所以だろう。 例えば、オフィスAにある開発サーバdev1にオフィス外からアクセスしたいとする。しかし、dev1はオフィス外には公開されておらず、踏み台サーバladd1を経由してしかアクセスするしかない。ladd1はsshのみが動いており、これまではsshのトンネリング機能を使ってアクセスしてきたのだが、ウェブアプリケーションをデバッグする際はいちいちウェブアプリケーションのポート毎にトンネルを掘るのが面倒くさい。オフィスに限らずデータセンターへ
http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txtやCPNI-957037: SSH 通信において一部データが漏えいする可能性, Plaintext Recovery Attack Against SSH - SSH - Company - News, CPNI-957037: SSH 通信において一部データが漏えいする可能性 - セキュリティホール memoによると, SSHプロトコルに設計のエラーがあり, OpenSSHの標準の設定だと, 2の-14〜-18乗の確率で14〜32bitの平文を回復できる可能性があるとのことです(当初32バイトと書きましたが間違いでした, また手法によって確率と回復できる平文のbit数に違いがありました). 攻撃の詳細はわかりませんが, 対策として暗号モードにCTRモードを利用することが挙げ
ご存知のとおり、SSHは公開鍵暗号と共通鍵暗号のふたつを使いわけています。お互いの認証やSSH sessionで使う共通鍵のネゴシエーションには公開鍵暗号で、共通鍵を共有した後は共通鍵で暗号化します。公開鍵による暗号化はオーバーヘッドがあって遅いからです。このため、いくつものSSH sessionを張ったり、ログインとログアウトを繰り返す場合、時間がかかります。また、firewallでSSHのbrute-forceをsession数によって制限している場合、短時間でログインとログアウトを繰り返す操作が阻害されることがあります。 OpenSSHにはControlMasterというキーワードで、既存のSSH sessionを再利用する仕組みがあります。これにより、すでにSSH sessionが存在する場合はそのsessionを再利用して、(ネットワーク的に)新たなSSH sessionを作成し
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Anti Wrinkle Creams Health Insurance song lyrics Contact Lens Migraine Pain Relief Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
公開鍵管理の概要 読者の皆さんの多くはリモートメンテナンスのために、各サーバでsshデーモンを動作させているはずです。しかしtelnetではなくsshにすればそれだけで安心安全、というわけではありません。共通鍵認証ではそれぞれの通信自体は暗号化されているとはいえ、近年では総当たり攻撃のターゲットとなっているケースも非常に多くセキュリティ的に安心できるものではないためです。皆さんはちゃんとRSAやDSAによる公開鍵認証を利用されていますか？ 公開鍵認証のメリットは、共通鍵認証と比較して、より安全な認証を実現することができる点にあります。その一方、クライアント側には秘密鍵ファイルと多くの場合はパスフレーズが、サーバ側には公開鍵ファイルが必要になるため、デメリットとしてユーザ数が多いとそれらの管理も煩雑になることが挙げられます。 たとえば管理対象のサーバが100台あるとすれば、あるユーザの入社時
これまで構築してきた自宅サーバーによるサービスを，外出先からも利用できたら便利だ。そこで今回は，SSHサービスとポート・フォワードを設定し，外からも自宅サーバーを使えるようにしてみよう。 連載の最後となる今回は，自宅サーバーでSSH（Secure Shell）サービスを稼働させる。SSHは，外部から自宅サーバーへのリモート・ログインを可能にするサービスだ。このSSHとポート・フォワード機能を併用すれば，SSHで接続したクライアントはLAN内に設置したように，メールやWebなどのサービスを利用できる。 もちろん外部向けのサービスを稼働すれば，それだけ攻撃を受ける可能性が高くなる。そこで，よりセキュアに運用できるよう，公開鍵（かぎ）認証やファイアウオールを設定したSSHサーバーを構築しよう。 SSHの認証方法 SSHを使って，外部からリモート・ログインを行うときのユーザー認証では，パスワード認
● SMB over SSH どうせお前らWeb開発者は、会社に行かずに家のPC(Windows)からPuTTYで会社のサーバに入って開発していて、プログラムコードの作成はemacs,vimで書けるんだけど、画像の編集だけはリモートでは難しいので、Photoshop並の画像加工するCGI(Ajax)をさっさと作れよ世界の天才達よ、と相手が見えない不満を溢しつつ、結局手元のmspaintでゴリゴリ修正してるんだけど、手元でやると更新したファイルをアップする方法が意外と面倒で、samba はリモートでは危険だし、ろだ用意するのも大げさだし複数一気には無理だし、cygwin で scp てのも cygwin 入れてないし、WebDAV は日本語ファイル名とか昔おかしくなったしつーか用意するのが面倒だし、そういえばセカちゃんが shfs を薦めてたけどあれも準備が大変だし、と脳内で作業を想像しただ
（技術的なメモをエントリにしてみる実験です） 最近のLinuxディストリビューションはUTF-8がデフォルトになっているので、相互に利用するには問題は無いのだが、少し前のサーバーなんかだと、EUC-JPで環境構築されていることも多く、sshでログインする際など、文字コード設定がいちいちややこしい。 今まで、私も毎回ターミナルの設定を変えたり、ターミナルにサーバー毎のプロファイルを作っていたりしたのだが、IWAMURO Motonoriさんらが中心に開発されている「cocot」を使ってみて、感動した（いまさらですかね？）。 例えば、私の実例だと、LANG=ja_JP.UTF-8なMac OS XのターミナルからLANG=ja_JP.EUC-JPなサーバーにログインして、vimで日本語ファイルを編集しなければいけないような場合に、 $ cocot -t UTF-8 -p EUC-JP ssh
日頃より楽天のサービスをご利用いただきましてありがとうございます。 サービスをご利用いただいておりますところ大変申し訳ございませんが、現在、緊急メンテナンスを行わせていただいております。 お客様には、緊急のメンテナンスにより、ご迷惑をおかけしており、誠に申し訳ございません。 メンテナンスが終了次第、サービスを復旧いたしますので、 今しばらくお待ちいただけますよう、お願い申し上げます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
