macOS 13 VenturaではOpenSSH 9.0が同梱され、SHA-1ハッシュを使用したRSA署名がデフォルトで無効となっているので注意を。
macOS 13 VenturaではOpenSSH 9.0が同梱され、SHA-1ハッシュアルゴリズムを使用したRSA署名がデフォルトで無効となっています。詳細は以下から。 Appleが2022年10月にリリースした「macOS 13 Ventura」では、phpに続きPythonランタイムの同梱が終了されていますが、同じくVenturaではSSHコマンドで利用されているOpenSSHがmacOS 12 Montereyの「OpenSSH 8.6」から「OpenSSH 9.0」へアップデートされています。 このOpenSSH 9.0がデフォルトとなったmacOS 13 Venturaでは、Montereyからのアップグレード後に一部のサーバーへssh接続しようとすると以下のようなエラーが出て接続できなくなっています。 hoge@hoge.com: Permission denied (pub
ssh_config(5) で * の後にホストを除外するやつ - HsbtDiary(2022-04-11)
■ ssh_config(5) で * の後にホストを除外するやつ 1password で sshkey を身体認証で処理できるようになったやつを入れてから便利にはなったものの、vscode でバックグラウンドで git repo を ssh でアクセスしたり、git push をするたびに macOS の指紋認証のモーダルに持っていかれるのが邪魔になってきたので以下のような設定を ssh_config に入れて除外した。 Host * !github.com !*.github.com !git.ruby-lang.org IdentityAgent "/path/to/1password/agent.sock" ssh_config の * の後に ! で除外をかけるというのを知らなかったので大変便利だった。
パスワードの1文字目に「~(チルダ)」を使って痛い目にあった - Qiita
何を言っているんだと思われるかもしれないですが、気軽にパスワードの1文字目に「~」を使わないほうがいいというお話です。 起こった問題 踏み台サーバー経由でサーバーAに接続して作業をしていた時の話です。 いわゆる多段 ssh 接続というもので、リモートワークになってからは結構使われる方も多いかと思います。 サーバーA上で root 権限になろうと sudo su - してパスワードを入力したら Connection to xxx.xxx.yyy.zzz closed. の文字とともにサーバーAから追い出されてしまいました。 なにかの間違いだろうと何度か挑戦していたのですが、結果はサーバーAから切断され踏み台サーバーに戻る羽目に。。。 そのときに入力していたパスワードが ~.xxxxxxxxxx のような ~ から始まるものでした。 調査 ~ って何か意味があったよなーと思ってどう調べようかと
WSLでWindows10標準のssh-agentを使うようにした - ただのにっき(2020-02-06)
■ WSLでWindows10標準のssh-agentを使うようにした Windowsネイティブ側とWSL側でssh鍵を共有するのに、2年前からPuTTY付属のpageantをweasel-pageantを経由してWSLから利用するようにしていたんだけど、「そういえば最近のWindowsにはOpenSSHが標準でインストールされてるんじゃなかったっけ?」と思っていろいろ調べた。 まず、Windows/System32/OpeSSHの下に、ssh関連のバイナリが全部入ってる。もちろんssh-agentも。しかもこのssh-agent、ちゃんとWindows Serviceとして動作するので(サービスから「OpenSSH Authentication Agent」を有効にしてやる必要がある)、自動起動するようにしてやれば良い。あとはssh-addしてやればパスフレーズも覚えてくれる。 あとはW
AWS Systems Manager セッションマネージャーでSSH・SCPできるようになりました | DevelopersIO
AWS Systems Manager セッションマネージャーに待望の機能（のひとつ）がやってきました！ Session Manager launches tunneling support for SSH and SCP サーバーにSSHしたり、ローカル・リモート間での SCP 越しのファイルの送受信も可能になりました。 更には SSH セッション越しにポート転送もできます。 ということで、さっそく試してみましょう！ リモートの準備 SSM エージェントをインストール SSH先サーバーに 2.3.672.0 以上の SSM エージェントがインストールされている必要があります。 古いエージェントがインストールされている場合、アップデートしてください。 Manually Install SSM Agent on Amazon EC2 Linux Instances - AWS Systems
OpenSSH の ~/.ssh/config の見直しをした - @znz blog
最新の man を参考にしながら OpenSSH の ~/.ssh/config の設定を見直してみたので、使っている設定項目についてまとめてみました。 確認バージョン 全て確認したわけではないですが、古いのや新しいのを確認したいときはこの辺りを使いました。 Debian GNU/Linux 8.7 (jessie) の OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 archlinux の OpenSSH_7.5p1, OpenSSL 1.1.0e 16 Feb 2017 参考 https://euske.github.io/openssh-jman/ssh_config.html の日本語訳や man ssh_config で英語のマニュアルを確認したりしました。 優先順位 コマンドラインオプション ユーザごとの設定ファ
rdar://28394826: macOS Sierra permanently remembers SSH key passphrase by default
Summary: After upgrading to macOS Sierra and using SSH to login to an SSH server, I noticed that the passphrase for my SSH key has been permanently remembered by the system. That is, after rebooting the system, SSH still knows the passphrase for my SSH key, such that I do not need to enter any passphrase to log in to my SSH hosts anymore. This permanent storage of my passphrase was done by default
sshrcで環境を汚さずにサーバの .bashrc .tmux.conf .vimrc 等をカスタマイズする | Weboo! Returns.
複数人で管理している本番サーバの環境をオレオレカスタマイズしてる人はいないと思うが、デフォルトのままだと使いにくいので、ぎりぎり許せる最大公約数的な設定をしているという管理者は多いのではないだろうか。 それでも、tmux や screen のプリフィックスは人によって通常使っているキーが違ったりして、これが異なるだけで非常に使いにくかったりする。自分はログインする度に以下のようなコマンドを打ちこんでいた。実に面倒くさい。 $ tmux set-option -g prefix C-t この件についてtwitterで聞いてみたところ、皆さんサーバ上に個人用の設定ファイルを用意して、ログイン時にそれを読み込んだりしているようだった。 で、これを何とかしようと思って少し調べてみた結果、以下の sshrc を使うのが便利という結論に至った。 https://github.com/Russell91
sshのラッパーコマンドを作った - オープンソースこねこね
GoでSSHコマンドに便利機能を追加したコマンドを作りました。 2017/04/11 追記: この記事の内容は古くなっています！ 2017/04/11時点の最新の仕様は、次の記事を参照してください SSHラッパーコマンドEsshのv1.0.0をリリースしました - オープンソースこねこね 追記ここまで。以下は2015/11時点の古い情報となります。 github.com 機能として Luaで~/.ssh/configに相当する設定を書ける。 zshの補完機能を使って、接続先一覧を出す。 サーバ接続時にフックを仕込める。自分はスクリーンの色を変えるの使っている。 複数のリモートサーバにまとめてコマンドを実行する。 といったところです。詳細はリポジトリのREADMEを見ていだければと思います。 ビルド済みバイナリをリリースページにおいてあるので、インストールはダウンロードして解凍してパスの通っ
github.comへのSSH通信を爆速化する - Qiita
Host github.com github.* User git Port 22 Hostname github.com Compression yes ServerAliveInterval 60 TCPKeepAlive yes IdentitiesOnly yes ControlMaster auto ControlPath /tmp/%r@%n:%p ControlPersist yes github.hogeみたいにして秘密鍵を使い分けていても混ざらずに使えました。 MavericksのHomebrewで入れたopenssh 6.7p1でのみ確認していましたが CentOS6上ではyumの最新openssh 5.3p1でControlPersistは対応できますがControlPathの%n表記に対応していないようでした。
最強の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
OpenSSH v7ではまる - jarp,
■ rubyciもkimono labsで運用開始 しばらく動かしてみて問題ないようなのでkimono labsで運用開始。 ちょっとダブらせてみたら Action skipped about 2 hours ago Twitter error: 'Cannot send duplicate tweet.' とログが出てたので今までとまったく同じメッセージを吐かせることに成功した模様。 ■ ワールドトリガー 前に書いたとおりアニメでもドラマでも最近は終わってから一気に見るんだが、 ワールドトリガーはいつまで経っても終わりそうにない。 もう1年だよ。 しかも Wikipediaを見たら 2015年10月11日からは新シリーズ「逃亡者編」が放送され、完全なアニメオリジナル展開に入る予定 などと書かれているではないか。 というわけでとりあえず1話だけ見て切るかどうか判断しようとしたが、 気づいた
SSHの多重接続について
tl;dr デプロイツールによっては 同じサーバに SSH で何回もコマンドを実行することがある(ansible とか)。 コマンドごとに毎回コネクション(トンネル)を確立するとオーバーヘッドも大きくなる。 OpenSSH は $HOME/.ssh/config に次の設定を書くことで、接続を多重化(multiplex)することができる。 # $HOME/.ssh/config Host machine1 HostName machine1.example.org ControlPath ~/.ssh/controlmasters/%r@%h:%p ControlMaster auto ControlPersist 1h multiplex 前後の速度差 SSH を使ってリモートサーバで echo コマンドを実行した時の速度差を計測 before multiplex $ time ssh
GitHubユーザーのSSH鍵6万個を調べてみた - hnwの日記
（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）鍵が見つかりました！常用しているのか試しに登録してみただけなのかはわかりませんが、何にせよ
公開鍵認証をやりすぎてssh でパスワードログインできない。
2014年5月28日 (水曜日) 10:01:54 # Life 公開鍵認証をやりすぎてssh でパスワードログインできない。 新しく設定しているマシンにパスワードでログインしようとしたらログインできず。なんか ssh -v のエラーメッセージみてみたら ssh-agentに登録されている鍵を全部試してみて試行回数の上限（５回？）を超えてコネクションがきられているよう。 僕の手元では管理している対象ごとに鍵をたくさん生成しているのでssh-agentは大量の鍵をかかえているようでした。 .ssh/config に PubkeyAuthentication no にして、公開鍵認証を試さないようにして解決。 Host xxx.yyy.zzz PasswordAuthentication yes PubkeyAuthentication no 公開鍵認証でログインできるように設定したら以下のよ
sshdのお話
第6世代（Gen 6）も登場し、注目を集めるファイバーチャネル（FC） SAN。 FC スイッチは多くのデータセンターで広く使われていますが、実際に「触ったことがある」というエンジニアの方はそれほど多くないのではないでしょうか？ 「触ってみたいけれど、なかなか機会がなくて・・・」 そんな方にも判りやすく、“見てわかる” ファイバーチャネルSAN基礎講座を開催しています。 本シリーズでは、ブロケードFCスイッチのオペレーションを通して、FC SANの設計・導入・運用を学んでいきます。 検討編、設計編、導入編、運用編とお送りしてきたシリーズも、いよいよ最終回（予定）を迎えます。 ファイバーチャネルSANもほかのどのシステムとも同様に、トラブルはあってはならないとはいえ、避けては通れないのが実情です。“もしも”を起こさないために、でも“もしも”が起きてしまったときに、どう対応するか、そのちょっと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
vagrant sshは、素のsshで接続するより179倍待たされる - Qiita
Windows Development Environment for Scala
tmux で attach したら ssh-agent が切れる場合 - Qiita
OpenSSHのクライアントコードに情報流出の脆弱性、秘密鍵が流出する恐れも 
