Showing posts with label ssh. Show all posts
Showing posts with label ssh. Show all posts

Thursday, July 30, 2009

ssh tips

most of our servers have timeout for ssh connections or probably the routers or firewalls configured to cut the connections if no data is transferred in either direction after a certain time interval, basically by the time i came back from lunch, all ssh connections will be disconnected. sucks right?

there are 2 ways to prevent this to happen. either do it from the servers or clients side.

1st way: reconfigure sshd on the servers like this:
edit /etc/ssh/sshd_config put ClientAliveInterval 60
and don’t forget to restart sshd on the server;)

2nd way: if you have a bunch lot of servers, i bet you don't want to edit all the servers configs. the easier way is to configure on the client end.

- if your're using linux desktop edit /etc/ssh/ssh_config and add the line:
ServerAliveInterval 60

- if you're using putty - under Connection, put non-zero value for:
Seconds between keepalives (0 to turn off).
eg. 60

- if you're using cygwin edit ~/.ssh/config and add these lines:
Host *
TCPKeepAlive no

ServerAliveInterval 60


or u just can put below options when execute ssh command:
$ ssh -o TCPKeepAlive=no -o ServerAliveInterval=60 servername

so now i can have a longer lunch break huhuhuhuu ;)

oh btw, i've dumped putty + PuTTY Connection Manager, now using cygwin + puttycyg.
with puttycyg, at least u're not stuck with the crap "cmd.exe" windows that comes with cygwin, unless u install Cygwin/X lor. betul dak jep?


1 more thing, ssh to outside world is block from within our company network. here is the trick - reconfigure your sshd to run on port 443. on cygwin install corkscrew, then put these in the ~/.ssh/config
Host outside_server
ProxyCommand corkscrew your_company_proxy_ip 8080 %h 443

$ ssh outside_server
Password:
walla you're now on outside world!

again, if u're using putty - under Connection - Proxy. oh thanks to apai!

p/s: wife aku dok komplen "ape yg awk dok buat ngan screen hitam tu, tak ceria langsung..." eh hitam bukan sebarang hitam ya ;)

Thursday, May 10, 2007

while loop with ssh issue

somehow while loop with ssh only read the first line from the input file & exit without reading the next lines.
eg:
$ cat server.txt
server1
server2
server3
$ while read server
> do
> echo $server
> ssh $server uptime
> done < server.txt
server1
13:15:08 up 49 days, 1:07, 5 users, load average: 0.00, 0.00, 0.00
the uptime command will only be run on the server1 but not on the server2 or server3. to resolve this, use the -n option with ssh, which prevents ssh from reading from standard input:
> ssh -n $server uptime

alternatively, you can use for loop. should be no issue ;)
$ for server in `cat server.txt`
> do
> echo $server
> ssh $server uptime
> done
for more info - http://sial.org/howto/shell/while-ssh/

Thursday, March 15, 2007

keychain rocks!

do you ever feel tired to key in your password or passphrase every time you want to ssh into your servers OR you need to run automate jobs (cron job) to ssh into specific servers but unfortunately unable to do it since you still need to key in your password or passphrase manually. well worry no more, here come the solution: use keychain!

first of all you'll need to setup the authentication using public key instead. then download the keychain from http://dev.gentoo.org/~agriffis/keychain/ & install the keychain into your Linux workstation.

ashterix@desktop:/home/ashterix $ ls -l bin/keychain
-rwx------ 1 ashterix u_026776 53740 Feb 27 08:25 bin/keychain


put this into your .profile or .bash_profile
keychain ~/.ssh/id_rsa
. ~/.keychain/`hostname`-sh


and you're done! the first time your login you'll ask to enter your passphrase of course.

KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/
Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL

* Initializing /home/ashterix/.keychain/desktop-sh file...
* Initializing /home/ashterix/.keychain/desktop-csh file...
* Initializing /home/ashterix/.keychain/desktop-fish file...
* Starting ssh-agent
* Adding 1 ssh key(s)...
Enter passphrase for /home/ashterix/.ssh/id_rsa:
Identity added: /home/ashterix/.ssh/id_rsa (/home/ashterix/.ssh/id_rsa)

ashterix@desktop:/home/ashterix $


if you log off & login again, the ssh-agent already there & you no need to key in your passphrase again.

KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/
Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL

* Found existing ssh-agent (19507)
* Known ssh key: /home/ashterix/.ssh/id_rsa

ashterix@desktop:/home/ashterix $


then from here you can ssh to any servers without key in the passphrase.
the same if you want to run automate ssh cron jobs, the passphrase automatically loaded, there's no need to key in the passphrase manually. cool eh :)

ashterix@desktop:/home/ashterix $ ssh server

ashterix@server :/home/ashterix $


for more info read here:
http://www-128.ibm.com/developerworks/library/l-keyc2/
http://www.gentoo.org/proj/en/keychain/index.xml
http://www.gentoo.org/doc/en/keychain-guide.xml

Wednesday, August 02, 2006

ssh authorized_keys

just now, one user complained that he can't use his public key as an authentication to remote server.
he already generate the public key & did all the necessary steps but still the remote server asked for password after key in the public key.

i tried used my id and it worked just fine, so it could be something wrong with his id or his public key. try to regenerate his public key but still the same thing.
as you see from below verbose message of ssh, it still asked for password after key in the public key:
user1@local_server $ ssh -v remote_server
OpenSSH_3.8.1p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to remote_server [ip_address] port 22.
debug1: Connection established.
debug1: identity file /glb/home/user1/.ssh/identity type -1
debug1: identity file /glb/home/user1/.ssh/id_rsa type 1
debug1: identity file /glb/home/user1/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192)>
Enter passphrase for key '/glb/home/user1/.ssh/id_dsa':
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,gssapi-with-mic,password,hostbased
debug1: Next authentication method: password
user1@remote_server's password:
a friend of mine (trew) found the solution... thanks :)
it is actually because his home directory is group writable (775). for security reason, authorized_keys file cannot be writable by anyone else, this also apply to the parent directory of authorized_keys file, in this case - his home directory.
for more info refer to http://dsd.lbl.gov/~ksb/Scratch/ssh_user_setup.html at the authorized_keys section.

Friday, June 09, 2006

upgrade ssh server remotely

i've been looking for the most efficient way to upgrade ssh server remotely. this task is quite risky since if the upgrade not going as expected you'll lost your access to the box, unless you have console server connected to it, otherwise you'll need to ask somebody on site to log in locally & start the ssh daemon.

so far i've found several ways to do it:

1. install normal way
i found this useful article on how to upgrade ssh server remotely here
quite straight forward. just that you need to kill the ssh daemon manually & be careful not to kill your current session.

2. using at command
you can set specific time using at command to start the ssh daemon after you've installed it.
or something like:
# /etc/init.d/sshd stop; make install; /etc/init.d/sshd start
but i must say that this is quite risky since you are not sure whether the daemon can start up without any problem after the new installation.
Read more...

3. use different port
some say you better use other port for the new ssh installation. if you can connect to the new ssh server using those port then you can revert it back to the normal port which is 22. low risk but extra steps.

4. enable the backdoor
enable the other remote access which is telnet. i think this is the most safest way to do it even though it is security risk to enable telnet but at least you can still access your box if the ssh kaput!

but how about you need to upgrade a ton of servers? which way you should go?
for me i'll go for no 4. write a script to do:
1) enable telnet & make sure you can access using telnet
2) install/upgrade ssh server & test the installation
with 1 condition, all your servers must have the same configuration. otherwise things gonna mess up pretty bad! good luck :)
or maybe i'll come up with the script later...

Wednesday, February 08, 2006

unix tip: ssh - get rid of yes/no message

normally when you ssh to a new unix/linux box, you'll be prompted with yes/no message like below:

$ ssh hostname1
The authenticity of host 'hostname1 (ip_address_hostname1)' can't be established.
RSA key fingerprint is be:eb:c6:2f:0e:d9:56:38:8c:f7:17:cd:96:f9:3c:f5.
Are you sure you want to continue connecting (yes/no)?

most of the time you just type yes, key in your password and you are in the box. but how about you need to create a script to ssh to a few servers to run some commands? then this option become handy:

$ ssh -o StrictHostKeyChecking=no hostname1
username@hostname1's password:

key in your password and you are in and of course you can use ssh-agent to get rid of the password prompt as well :)