Shamil's Blog. Software Engineering Processes, Android, CI, Devops.

In case of need to temporary log in into SSH box from non-secure location (i.e. assuming keyboard wiretapping on Intel ME-enabled system) it's possible to use google auth as second-factor auth. It's also worth considering the worst scenario of man-in-the-middle and enable 2FA for a separate non-sudoer account.

Labels: linux, security, ssh

If you are like me using personal server to store GIT repos you may have the error like this during first pull/clone considering you have project initialized in your remote home with command $ git init --bare reponame.git

$ git clone ssh://servername/reponame.git 
Cloning into 'reponame'...
fatal: '/reponame.git' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

The solution is to use slightly different URL, note part '~/':
$ git clone ssh://vm/~/devvit_test.git

Labels: ssh

I'm not sure when this was changed, but now ssh server key fingerprint is human unreadable. Why is this a serious problem? SSH works like any other public key crypto: to execute key exchange one needs to verify other party's public key. If one doesn't do that, no crypto as man-in-the-middle attack could be executed to catch password. The common use-case makes this attack even more probable: even though people frequently uses key auth, the first login after remote VM setup usually takes place using password. So it's very important to verify server's identity which is done usually using server key fingerprint human comparison like here:

$ ssh ...
The authenticity of host '... (...)' can't be established.
RSA key fingerprint is SHA256:qSj/We80nmhTc8Pc4XPazxlpGrnv95EZNXSZB1YsGl0.

Looks like hash trash because it's not easy readable and for sure not so easily memorable as hex format.
Compare that with SHA-1 fingerprint (actually connecting to the same SSH server):

The authenticity of host '...' can't be established.
RSA key fingerprint is 77:5f:3b:1f:84:eb:d2:0c:ca:bd:b3:5d:f7:3c:c3:6f

Grouped hex digits, no trash.
Maybe I'm wrong, but it looks for me that ssh maintainers in this case are blindly following a modern fashion to use sha256 instead of considering which UX leads to less human errors.
I'm not sure if that's somehow connected to using ECDSA keys or not. Anyway this change to sha256 increases human mistakes in using crypto tools like SSH which is very bad.

Labels: ecdsa, md5, opensource, sha, sha256, ssh

Recently I found tmux. This is a best thing if you manage to work with your server in ssh console on a bad connection or from time to time and would like to save the entire context of what you are doing. For example, you compile kernel and went take a coffee, then back and connection dropped. If you used tmux simply attach to session:

$ tmux a

Need (like me) several consoles? (It's for sure more verbose than to have nohup or Ctrl-z; bg)

<Ctrl-b> , enter "new" <Enter>

For a list of sessions:

<Ctrl-b> , s

(then select from stable list - meaning you remember that for example your unprivileged session is always third one, and first two is sudoed root ones). Example (selected 2nd):

(0) + 0: 1 windows
(1) + 2: 1 windows
(2) + 3: 1 windows (attached)

The only not a good (yet) thing is scroll up as it needs 2 more keys:

<Ctrl-b>, [, then <PgUp/Down> or Arrows

Have fun!

Labels: administering, linux, ssh, tmux

узнал сегодня, что мобильные операторы во франции блокируют ssh, vpn, даже smpp. короче, все, кроме http/s. это хуже, чем даже в китае с их файрволом!
а китайцы ведь разрешают vpn и ssh!

Labels: block, china, firewall, france, mobile operators, network, shit, ssh, vpn

Just note for myself: access rights and cmds for new user ssh keys authorization setup:

mkdir .ssh
chmod 700 .ssh
echo >.ssh/authorized_keys
chmod 600 .ssh/authorized_keys
passwd

updated: mistype line 3

Labels: access rights, authorized_keys, keys, note, ssh