[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

タグ

sshに関するymm1xのブックマーク (32)

  • 大容量ファイルのSCP転送を高速にする方法 (ver.2019) - 元RX-7乗りの適当な日々

    9年ほど前にこういうエントリを書いたのですが、まだそれなりに見られているようなので、最近はどうなのかなーと、再検証・再計測してみたエントリーです。 ↑の過去エントリにも記載しているのですが、SSH/SCP では暗号化方式(強度)によってファイル転送のスループットが変わります。 もちろん、オープンなネットワークでやるにはセキュリティがー、とか、インターナルでやるなら、そもそも netcat (nc) でいいやんー、とか、そもそも大量にファイル数あるなら、事前に固めてしまえー、とか色々あると思うのですが、エントリではあくまで暗号化方式 の違いでスループットがどう変化するのか、それはどのくらいスループットが出るのか、を確認したログとなります。 ベンチマークで利用した環境 Google Compute Engine (GCE) の インスタンス (n1-highcpu-4) を2台準備しました

    大容量ファイルのSCP転送を高速にする方法 (ver.2019) - 元RX-7乗りの適当な日々
  • SCP転送を高速にする - ふなWiki

  • 【Linux小技】 scp(ssh)での暗号化方式の違いによる転送速度ベンチマーク 「知ったかブログ」

    目的 ホスト間のファイルのコピーは、セキュリティの問題もあってscpsftpは普通で良く使うのですが、特に大きなファイルを転送しようとすると、同じギガビットイーサネットスイッチに二つのホストを繋いでいてもなぜか50MB/sくらいしかなりません。何か設定がおかしいかといろいろ試したのですが、ftpで転送すると普通に100MB/s出ることから、どうやらssh側の制限らしいことまでは突き止めました。 色々調べていくと、今のsshの場合は送信時に暗号化方式をいくつか選択することができ、暗号化方式によっても転送速度が異なるようです。たぶん暗号化と復号にCPUを使っているからでしょうか。 理屈はまあ脇に置いておいて、取り急ぎは暗号強度は無視して転送速度を確認したいです。というわけで、暗号方式の違いによる転送速度を比較してみました。 ssh暗号化方式の変更方法 一言でいえば、 # scp -c [暗号

  • expectやsshpassを使わずにシェルでSSHパスワード認証を自動化する - Qiita

    はじめに 接続先サーバ側を変更できるのであれば公開鍵認証方式をおとなしく使いましょう。 どうしてもパスワード認証方式を使わないといけない場合は、接続クライアント側にソフトウェアをインストール可能ならSSHPassを使いましょう。巷にはexpectコマンドを使った方法があふれていますが、インストール可能な環境ならSSHPassのほうが良い (参考: sshにパスワードで自動ログインするならexpectよりもsshpassを使おう サーバ側もクライアント側も変更がどうしてもできない…残念ながら大人な事情でそういうこともあります。そんな時は記事が参考になるかと思います。 実現方式 sshにはSSH_ASKPASSという仕組みがあります。以下、引用。 SSH_ASKPASS パスフレーズを入力する際、ssh が端末から起動されているとssh はパスフレーズをその端末から要求します。ssh が制御

    expectやsshpassを使わずにシェルでSSHパスワード認証を自動化する - Qiita
    ymm1x
    ymm1x 2022/02/08
  • Homebrewでインストールが非推奨!?になったsshpassはソースコードビルドでインストールしよう - Qiita

    Homebrewでインストールが非推奨!?になったsshpassはソースコードビルドでインストールしようMacsshpass sshパスワード認証に用いるパスワードを引数渡しで利用出来るsshpassコマンドはLinuxの場合はパッケージマネージャーから簡単にインストール出来ますが,Macの場合は標準ではHomebrewからインストール出来ません1。故に従来は参考の様な方法でインストールを行っていました。しかし,最近はbrew doctorコマンド実行時に以下の様な警告が出る様になりました。どうやらHomebrewによるインストール対象アプリケーションのリポジトリ一覧からsshpassが削除されてしまっている様です。 Warning: Some installed kegs have no formulae! This means they were either deleted or i

    Homebrewでインストールが非推奨!?になったsshpassはソースコードビルドでインストールしよう - Qiita
  • 【設定爆速】VS CodeのRemote Developmentを使ってSSH接続したEC2上のファイルを編集する | DevelopersIO

    めっちゃ簡単にリモートマシン上でVS Codeが使えるRemote Developmentの紹介です。Insider版限定機能ですが、やってみると感動すること請け合いです。 なんとなく試しているけれど、Visual Studio CodeのRemote Development、死ぬほど便利やんけ。とりあえず、~/.ssh/config使ってSSH接続先管理してたら、鬼のように簡単にリモートマシンに接続できる。 — 濱田孝治(ハマコー) (@hamako9999) May 29, 2019 先日、MicrosoftよりRemote Development with VS Codeという衝撃的なアップデートが発表されました。 Remote Development with Visual Studio Code 従来のVS Codeの機能を拡張機能含めてリモートマシン(コンテナやWSLも含む)上

    【設定爆速】VS CodeのRemote Developmentを使ってSSH接続したEC2上のファイルを編集する | DevelopersIO
  • ssh-agent のしくみ - eagletmt's blog

    ssh-agent のように daemon として起動し秘密の情報を保持しつつ別プロセスと通信するようなプログラムを書きたくて、ssh-agent はどう実装しているのかざっくり調べた。 https://github.com/openssh/openssh-portable 通信方法 これは普通に ssh-agent を使っていてもすぐ気付くことだけど、ssh-agent は UNIX domain socket を使って通信している。 eval $(ssh-agent) のように実行すると SSH_AUTH_SOCK と SSH_AGENT_PID の2つの環境変数がセットされ、SSH_AUTH_SOCK は UNIX domain socket のパスを、SSH_AGENT_PID は daemon 化した ssh-agent の pid を指している。 SSH_AUTH_SOCK は

    ssh-agent のしくみ - eagletmt's blog
  • .ssh/configもDRYで書きたい - Qiita

    Host hoge-humidai HostName hoge.com User hoge port 10022 Host hoge-a HostName 10.15.0.10 User hoge IdentityFile ~/.ssh/hoge-a ProxyCommand ssh -W %h:%p hoge-humidai Host hoge-b HostName 10.15.0.20 User hoge IdentityFile ~/.ssh/hoge-b ProxyCommand ssh -W %h:%p hoge-humidai Host hoge-c-1 HostName 10.15.0.30 User hoge IdentityFile ~/.ssh/hoge-c ProxyCommand ssh -W %h:%p hoge-humidai Host hoge-c-2 Hos

    .ssh/configもDRYで書きたい - Qiita
    ymm1x
    ymm1x 2021/01/12
  • ~/.ssh/config による快適 SSH 環境 - Qiita

    言いだしっぺの法則により、Advent Calendarのトップバッターになってしまったので、Web開発で便利なTipsを紹介したいと思います。 概要 ~/.ssh/config にサーバーごとの接続設定を書いておくと、ssh コマンドや scp コマンドを実行するたびにいちいち引数を指定する必要がなくなり、幸せになれます。 初級編 ユーザー名やポート番号の指定 通常、ログインユーザーとは異なるユーザーや、22番以外のポートを使ってSSH接続する場合は、次のようにコマンドライン引数で指定してあげる必要があります。

    ~/.ssh/config による快適 SSH 環境 - Qiita
    ymm1x
    ymm1x 2021/01/12
  • Amazon Linux 2 のインスタンスを作成する時に必ずやっておきたい事 | DevelopersIO

    はじめに こんばんは、菅野です。 Amazon Linux 2 への移行は終わりましたか? Amazon Linux 2 へ移行するには新しいインスタンスを作成する必要がありますが、その時におすすめしたい設定があります。 ※2020-07-08に「注意点 その2」を追記しました。 おすすめの設定 セッションマネージャーを利用できるようにすること メモリ使用率とディスク使用率を CloudWatch で見れるようにすること これらを設定しておくと、今後の運用が楽になります。 セッションマネージャーを使うメリット メリットとしては、SSH 接続をしなくても EC2 のコマンドが実行できるようになりますので、セキュリティグループで SSH を解放する必要が無くなりセキュリティの向上につながります。 この画像はマネジメントコンソールから EC2 にログインした時のものですが、AWS Systems

    Amazon Linux 2 のインスタンスを作成する時に必ずやっておきたい事 | DevelopersIO
    ymm1x
    ymm1x 2020/07/08
  • EC2のhost名でSSM経由なSSH接続をしたい - Qiita

    Host dev01 HostName i-xxxxxxxxxxxxxxxxx ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" Host web01 HostName i-xxxxxxxxxxxxxxxxx ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" #!/usr/bin/python import sys import subprocess import argparse from boto3.sessio

    EC2のhost名でSSM経由なSSH接続をしたい - Qiita
    ymm1x
    ymm1x 2020/06/12
  • さよならした本番サーバを復帰させてみる

    今年のAdvent Calendarで注目を集めているのが、 番環境でやらかしちゃった人 Advent Calendar 2019だ。自分は宗教行事には参加しない主義なのでAdvent Calendarに記事は書かないが、このシリーズはちょっと見逃せない。で、稿では12月3日に公開されたこちらの記事を取り上げたいと思う。 さよなら番サーバー トラブルの原因は何かsshログインできなくなったそもそもの原因は、~/.ssh/authorized_keys へのパーミッションが不適切になってしまったために、sshdがログインを拒否する状態になったということだ。そのきっかけになったのが、クライアント(依頼主)からのCSVファイルの取得依頼だったという流れだった。実験サーバを立てて、これを模してみよう。 [north@sayonara ~]$ chmod og+w /home/north [n

    さよならした本番サーバを復帰させてみる
  • さよなら本番サーバー - Qiita

    とあるSESの現場では番リリースの時期が近づいてきており、僕を含めた数人のエンジニアは間に合いそうもない残作業の開発を進めたり、番で使うためのデータの整備を番サーバー内で行ったりしていた。ほとんどがその案件のために集められたメンバーだったため特に和気あいあいとするでもなく、エアコンの風の音が響く小さなオフィスの片隅で静かに作業をしていた。 業務上のやりとりもRedmineで行われており、声を発するのもたまにメンバー同士で話をしたり、クライアントから電話がかかってきた時だけ。その日もメールで通知が届いてきており、確認してみるとRedmineで僕が関係しているチケットにコメントが届いているという通知だった。 通知のURLをクリックしてRedmineのチケットを確認してみる。 それによると一旦番サーバー上に存在するデータの中の一部の主要データをCSV形式で送ってほしいという依頼だった。無

    さよなら本番サーバー - Qiita
    ymm1x
    ymm1x 2019/12/03
    Qiita文学だ
  • ssh ポートフォワード - どさにっき

    ■ ssh ポートフォワード _ sh スクリプトの中から、ポート転送しないとたどりつけないホストにアクセスしたい。ただし、常時ポートフォワードしてるわけではないので、スクリプトの中でポート転送を開始し、終了もスクリプトの中で面倒見る必要がある。 _ 教科書的なやりかたはこう。 _ ssh をバックグラウンドで起動し(-f)、リモートホストでは何もコマンドを実行しない(-N)。が、バックグラウンドにいってしまったプロセスを止めるために ps | grep でいくつも動いてる(かもしれない) ssh のコマンドの中からスクリプトで起動したものを特定して kill するという処理が必要になる。めんどくさい。pid をどっかのファイルに吐き出してくれる、とかいうオプションがあればいいんだけど、そういうものはなさげ。 _ じゃあどうしよう。

  • EC2 SSM で ssh レスの夢を見るか - Qiita

    mediba advent calendar 2017 15日目担当の沼沢 @numasawa です。 インフラストラクチャー部所属、AWS インフラ全般やってます。 SSM の記事ではありますが、タイトルに深い意味はありません。 皆さん、SSM 使ってますか?というより知っていますか? Amazon EC2 Systems Manager ←こいつですね。 今回はこの SSM についてお話をしたいと思います。 なお、"SSM" は Simple Systems Manager の略なのですが、公式紹介ページでの名称から Simple が無くなっているのはとても深い謎です。 公式ドキュメント内でも表記が揺れているようですので、気にしないでおきましょう。 SSM とは そもそも SSM とはなんぞや。 一番簡単な使い所で言うと、ssh ログインせずとも、Management Console

    EC2 SSM で ssh レスの夢を見るか - Qiita
    ymm1x
    ymm1x 2018/05/07
  • 最強のSSH踏み台設定 - Qiita

    追記: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

    最強のSSH踏み台設定 - Qiita
    ymm1x
    ymm1x 2017/11/14
  • お前らのSSH Keysの作り方は間違っている - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    お前らのSSH Keysの作り方は間違っている - Qiita
  • サーバが多くSSH鍵の管理が大変です。どんな工夫をしていますか? - Qiita

    これは「コードを書いていて困ったときに、suinがチャットで質問に答えたり相談に乗るsuinのプログラミング相談室(仮)」で頂いた質問と僕の回答の要約です。 質問 管理するサーバ数が増えてきて、SSH秘密鍵の管理も大変になってきています。suinさんは、SSH鍵の管理をどうやっていますか? suinの回答 サーバって何台くらいになりますか?僕はせいぜい20台〜30台くらいがマックスなので、参考にならないかもしれませんが、戦略として次の2つをやっています。 使う鍵を減らす ログイン情報をモジュール化する 鍵を減らす 鍵を減らすのは同じ公開鍵を使い回す方法です。僕はできるだけこれをしてますね。セキュリティと利便性のトレードオフでバランスを取る戦略です。サーバの運用ルールや、与えられた鍵でしかアクセスできないなどで、できないこともあります。 ログイン情報をモジュール化する ログイン情報をモジュー

    サーバが多くSSH鍵の管理が大変です。どんな工夫をしていますか? - Qiita
  • SSHで他サーバにコマンドを送る方法 - maru.cc@はてな

    パイプで渡す $ echo command | ssh user@hostname 複数コマンドを渡す $ echo "command;command" | ssh user@hostname sshの機能を使う $ ssh user@hostname command 複数コマンドを渡す場合 $ ssh user@hostname command1;command2これだとcommand2はローカルで動いてしまう。ので、文字として渡す $ ssh user@hostname "command1;command2"

    SSHで他サーバにコマンドを送る方法 - maru.cc@はてな
  • sslh でport443 を有効活用して、sshもhttpsも同時に待ち受けする。 - それマグで!

    443ポート以外が絶滅しそうです あちこちでポートは閉じられています。ssh や sftp もプロキシ利用も、各種ポートでは、全く外部に出れず、接続できないネットワークが多いです。 TCP/IPなのにIPとポートを使った通信ができない、壊れたネットワークが当然になりました。 これらの接続制限にとても不便を感じることが多いです。 サーバー管理者の気分一つでポートが空いたり閉じたり、私が触ってたネットワークではポリシーが統一されず、クソネットワーク管理者に振り回されて、動くはずのものが動かず、不便なことが多かったのです。そこで仕方なく443を使っています。 私達が利用する端末では80/443 のポートの外部接続が閉じられることは少なく、443であれば通信できます。 そのため、443ポートに様々なアプリケーションを起動していると思います。 443 ポートとIPアドレスが枯渇する・・・ よほどのG

    sslh でport443 を有効活用して、sshもhttpsも同時に待ち受けする。 - それマグで!